精読「アジャイルサムライ」(第一部 「アジャイル」入門)
アジャイルサムライ――達人開発者への道
アジャイル開発を実践するための具体的な方法論と心構えを学べる一冊です。チームで成果を出す秘訣や、迅速かつ柔軟に価値を届けるためのツールや考え方をわかりやすく解説。初心者から経験者まで、アジャイルの本質を知りたいすべての人におすすめのガイドブックです！
関連記事
ざっくり分かるアジャイル開発
本章を読めば、次の３つがざっくりわかる
- アジャイルな計画の立て方
- プロジェクトがうまく行っている度合いを測る方法
- ３つの真実を受け入れることの効能
価値ある成果を毎週届ける
価値ある成果を毎週必ず届けるために、大事にしなければいけないこと
- 大きな問題は小さくする
- 本当に大事なことに集中して、それ以外のことは忘れる [1]
- ちゃんと動くソフトウェアを届ける
- フィードバックを求める
- 必要とあらば進路を変える
- 成果責任を果たす
期待をマネジメントする
ソフトウェア開発プロジェクトでは、暗黙的な期待は認識されにくく、対処が難しい。
暗黙的な期待が満たされない状況が続くと、プロジェクトやチームの関係が悪化し、不満や対立が生じやすい。
プロジェクトの成功には、関係者間の期待を明確化し、それを継続的に調整・維持することが必要。
期待を一方的に設定したり、問題が起きてから調整するのではなく、継続的に話し合い、状況に応じて合意内容をアップデートするべき。
アジャイルな計画づくりがうまくいく理由
- マスターストーリーリスト：プロジェクトのToDoリストとして、顧客が実現したいフィーチャ（ユーザーストーリー）が含まれる。フィーチャの概要を記述し、顧客が優先順位をつけて、開発チームが見積もりを行うことでプロジェクト計画の基盤が作られる
- イテレーション：1〜2週間の短い期間で、顧客が価値が高いと考える機能を順番にテスト済みで動くソフトウェアに変換する。ベロシティを測定して、チームがどれだけの作業をこなせるかを把握し、将来の作業量を予測する。これにより、計画の信頼性が向上する
- スコープの柔軟性：作業量が多すぎる場合は、スコープを調整して現実に適応する。計画が現実と合わなくなった場合、計画を変更してバランスを保つことが大切
- 誠実な計画と顧客との協力：アジャイルでは、顧客に事実を隠さず、状況を十分に伝えた上で、スコープ、予算、期日について顧客と協力して判断を下す
「完了」とは完了のことだ
- アジャイル開発における「完了の定義」は、作業が完全に終了しており、リリース可能な状態であること
- 具体的には、コードのリリースに必要な分析、設計、コーディング、テスト、UXデザインなど、すべての作業が完了していることが求められる
-ただ、イテレーション内で全機能を完了させて公開することではなく、もし顧客から「リリースしてください」と言われた場合に、すぐにリリースできる状態であることが重要
３つの真実
ソフトウェア開発の３つの真実
- プロジェクトの開始時点にすべての要求を集めることはできない
- 集めたところで、要求はどれも必ずといっていいほど変わる
- やるべきことはいつだって、与えられた時間と資金よりも多い
アジャイルチームのご紹介
本章を読めば、次の３つがわかる
1. 典型的なアジャイルチームはどんな姿をしているのか
2. 自分のチームをどう編成すればいいか
3. チームにメンバーとして参加するにあたり、どんな心構えで仕事に臨めばいいのか
アジャイルなプロジェクトはどこが違うのか
アジャイルプロジェクトの３つの主な特徴
- 役割分担がきっちり区別されない：メンバーは肩書や従来の役割[4]に縛られず、プロジェクト成功のための幅広い活動に協力する
- 継続的な開発工程：開発工程が独立せず、途切れることなく連続的に進行する
- チーム全体で成果責任を負う：チームが一丸となり、品質や成果に責任を持つ
チームをアジャイルにするためのコツ
- 同じ仕事場で働く：物理的に一緒に働くことで、質問や問題解決がスムーズになり、意思疎通が摩擦なく行われ、信頼関係も築きやすくなる
- 積極的に深く関わる顧客：顧客が開発チームにデモを見たりフィードバックを提供したりすることで、プロダクトをより魅力的で画期的なものにできる
- 自己組織化：役割に人を合わせるのではなく、メンバーのスキルや情熱に応じて役割分担を決め、計画や見積もりを自分たちで行い、自ら動く姿勢が必要（そのために次の成果責任と権限委譲が必要）
自己組織化されたチームで交わされる会話
👨「……もちろん、ボビーが得意なのはコードを短かくすることだと思う。でもそれだけじゃなくて彼はデザインへの造詣も深いから、ちょっとしたモックアップを作るのも手伝ってもらおう」
👨「うん、確かにスージーは最高のテスターだけれども、彼女が本当に活躍するのは、お客さんの期待をマネジメントすることだよ。彼女はやり方を心得てるし、それをするのが好きなんだよね」」
- 成果責任と権限委譲：成果責任を果たすためには、チームに権限が委譲され、自発的に課題解決ができるようになることが必要
- 職能横断型チーム：顧客の要望に初めから終わりまで対応できる開発チームで、ゼネラリストが望ましく、必要に応じてスペシャリストを加えることがある。こうしたチームは他部門との調整が不要で、素早く成果を出せる
よくある役割分担
大別すれば、顧客（何を作るべきか分かっている人） と開発チーム（それを作ることのできる人） がいるだけ
-
アジャイルな顧客
要求の「真実の源」として優先順位を決め、フィードバックを提供する重要な役割を担う。大切なのは「顧客を巻き込むほどプロダクトは良くなる」という考えを理解し、積極的な関与と決断を促すこと。 -
開発チーム
職能横断的なメンバーで構成され、役割分担は曖昧で柔軟。従来型のチームに自己組織化を求める際は、馴染みのある用語で説明しつつ、役割変化への理解を促すことが重要 -
アジャイルなアナリスト
顧客と協力して本当に必要なものを明らかにし、ユーザーストーリーの作成や分析、モックアップやプロトタイプの作成などを行う。探求心を持ち、詳細な調査と意思疎通を通じて、フィーチャの実現を支援する役割 -
アジャイルなプログラマ
質の高いリリース可能なソフトウェアを作るプロフェッショナル。テストを活用して設計を進め、アーキテクチャの改善を継続し、コードを常にデプロイ可能な状態に保つ。 -
アジャイルなテスター
ソフトウェアが動作することが重要だと理解し、早期からテストを定義して即座に動作確認ができるようにする。顧客や開発者と協力し、テスト自動化や不具合修正、探索的テストを行い、負荷テストやスケーラビリティも考慮する -
アジャイルなプロジェクトマネージャ
開発チームの成功を支えるために障害を取り除き、計画や方向性を調整します。上位関係者への報告やチームを守る役割も担う。優れたマネージャは指示を出すのではなく、チームが自立できるよう環境を整え、不在でもプロジェクトが進むようにする -
アジャイルなUXデザイナ
顧客の要求を理解し、チームと協力して価値あるプロダクトを作り上げる。デザインはイテレーションを通じて少しずつ進め、素早いフィードバックを得て改善する -
スクラムマスター
アジャイルコーチとプロジェクトマネージャを兼ね備え、チームを軌道に乗せる重要な役割 -
アジャイルコーチ
チームにアジャイルの原則を説明し、効果的なチーム作りをサポートします。チームが練度を高めると専任コーチは不要だが、経験が浅いチームには効果的
チームメンバーを探すコツ
アジャイルプロジェクトに適したチームメンバーを探すコツとして、以下の点が挙げられる
-
ゼネラリスト
アジャイルプロジェクトでは、プロジェクト全体にわたって自分の力を発揮するゼネラリストが向いている。例えば、プログラマならフロントエンドからバックエンドまで、アナリストやテスターなら両方をこなすことが求められる -
曖昧な状況に適応できる人
アジャイルプロジェクトでは計画や要求が変わることが多いため、柔軟に対応できる人を探す -
我を張らないチームプレイヤー
チームで協力し合い、役割分担が曖昧でも問題なく進められるメンバーが理想。自分の領域に固執せず、お互いに学び合う姿勢が大切
参考
Discussion