アジャイルサムライ 要点まとめ
ざっくりわかるアジャイル開発
できるようになること
この章ではアジャイル開発とはなにかについて理解をしていこう。
- アジャイルな計画の立て方
- プロジェクトの進捗状況を測る方法
- 3つの真実を受け入れることの効能について
価値ある成果を毎週届ける
一旦、お客さんの立場になって考えてみよう。 君が信頼に足ると判断するのは次のうちどちらのチームでしょう？
1. 最終的に実施計画書や大量の製品文書、作業報告書を納品してくれるチーム 2. 一番大事だと思う機能から実装して、テスト済みのソフトウェアとして毎週必ず届けてくれるチーム
答えは2番です。
「顧客満足を最優先し、価値あるソフトウェアを早く継続的に届ける」ことがアジャイル開発において非常に重要となります。
ここでは、そのために必要なことを6つに分けて説明します。
1. 大きな問題は小さくする
例えば以下のタスクあったとしましょう。
ウェブサイトの構築 3か月
「毎週届ける」といっても1週間は短いのですべての工程のタスクを1週間で終わらせるなんて到底無理だと感じるかもしれません。
その場合、1週間で終わりそうにない大きくて厄介な問題についてはもっとシンプルにして扱いやすく分割してあげましょう。
例えば、トップページ作成、ユーザアカウント、FAQ、利用規約など各パーツで考えてみるなんて方法も良いかもしれません。
2. 本当に大事なことに集中して、それ以外のことは忘れる
本書では納品物の大部分が無駄で様々なドキュメント、実施計画書でさえ不要だといいます。
これらはあくまで動くソフトウェアを補完するためのものであり、お客さんの立場に立って価値ある成果を毎週届けたいのであれば、無駄を省く必要がある。
そうすることで、本当に必要な工程だけに時間を使えるようになるといいます。
3. ちゃんと動くソフトウェアを届ける
2で説明したように、無駄な作業を極力省かないといけません。
しかし、当然ながら届けたものは動かないといけない。ということはテストをもっと大事にしないといけないということになります。
プロジェクトの中で、いろいろ省いたとしても、日々のテストだけは疎かにしてはいけない。テストする習慣。そしてそれを守る責任は自分にあると意識しましょう。
4. フィードバックを求める
プロジェクトが進み始めたら考えてほしいこと。それは、当初の計画通り進んでいるか確かめることです。
それをする方法はただ一つ。定期的にお客さんに尋ねること。フィードバックをもらうことは、行く手を照らすヘッドライトのようなもの。
フィードバックをもらうことによってお客さんは、プロジェクトのハンドルを切ることができる。そしてあなたは、切られたハンドルのとおり動くことができるようになる。
5. 必要とあらば進路を変える
アジャイル開発では、顧客の要望をくみ取りつつ進めることになる。
そのため、今週は極めて重要だった内容が、翌週にはどうでもよくなることだってあります。
立てた計画に対して、そのまま従っていては大きな変化が起きた場合、その衝撃に耐えられなくなる。
そのため、計画を乱すような要望に遭遇した場合、計画を変えましょう。
6. 成果責任を果たす
成果責任を果たす。ということは以下のことになります。
- 仕事の質に責任を持つ
- スケジュールを守る
- お客さんの期待をマネジメントする(顧客の明示的な期待、暗黙的な期待に応える)
- 身銭を切っているかのような覚悟でお客さんの資金を扱う
アジャイルな計画づくりがうまくいく理由
上記を見てもらうとわかる通り、アジャイル開発におけるプロジェクトの計画づくりは、予定が立て込んだ週末の準備と変わらない。
用語として、ToDoリストのことをマスターストーリーリスト、タスクのことをユーザーストーリーと呼ぶ。
アジャイルにおけるユーザーストーリーとは？書き方例とテンプレートを解説
それぞれのユーザーストーリーの記述レベルについては概要がわかる程度でOK。
顧客がリストの項目に優先順位をつけて、それを開発チームが見積もる。
それが終われば、イテレーションという単位に分割する。
イテレーションとは、一連の工程を短期間で繰り返す、開発サイクルのことです。
ストーリーを元に、顧客が最も価値が高いと思うものから順番に、開発を進めていく単位のことになります。
イテレーションと似た言葉としてスプリントというものも存在します。本書でもイテレーションはスプリントと読み替えてもらって構わないと記載されています。
具体的な違いについては以下のリンク先の方が説明されているので確認お願いします。
イテレーションとは？スプリントとの違いや開発プロセスを解説！｜ITトレンド
そして、一回のイテレーションで完了させられるストーリーの量をベロシティといいます。
ベロシティがしっかり実測できていれば、計画は信頼できるものになりますし、開発チームとして限界を超えた成果量や作業量になることを避けられます。
「完了」とは完了のことだ
アジャイル開発においての完了というのは、各イテレーションで完成したばかりの機能をお客さんに公開することではない。
少し、心構えの問題でもあるが、「リリースしてください」と言われたらリリースできる状態にしておくことが「完了」だ。
そのために、常に動くソフトウェアを作ることこそが進捗を測るうえで最も重要な尺度となります。
３つの真実
最後にソフトウェア開発における、3つの真実をお伝えします。
1. プロジェクトの開始時点にすべての要求を集めることはできない。 2. 集めたところで、要求はどれも必ずといってもいいほど変わる。 3. やるべきことはいつだって、与えられた時間と資金よりも多い。
1つ目については、情報が揃っていなくても、未知なる公開へ旅立つことをいとわないということ。
要求は発見される(途中で追加や変更されるもの)であり、すべて出揃うまで前に進めないというものじゃない。
2つ目は、変化は恐れるものでもなければ避けるものでもないということ。
起きた変化に応じて計画を変更しつつ、前に着実に進んでいくことが重要です。
3つ目は、与えられた時間とリソースを超えるToDoリストを前にしてもプレッシャーを感じないこと。
リソースを超えるToDoリストだったとしても、とにかく優先順位をつけて一番高いものから実施していく。
優先順位の低いものは後回しで構わない。
最後に
これで、アジャイル開発の基礎を理解したと思います。 次回はアジャイルでのチームはどうやって仕事を進めていくかを見ていきます。
