Clean Agile 基本に立ち戻れ
書籍「Clean Agile 基本に立ち戻れ」から分かるアジャイル入門ポイントをまとめます。
アジャイル開発入門
本書は「小さなことをする、小さなソフトウェアチームがうまくやっていくために!」という副題のとおり、小規模な開発チームにおける様々なプラクティスについてまとめられた本です。
著者のロバート・C・マーティン（アンクル・ボブ）は元プログラマーでありアジャイルの第一人者です。アジャイル開発の誕生の瞬間に立ち会った人物のひとりで、その後は世界中の大企業を対象にコンサルティングやトレーニング、スキル開発を行っています。
著者は、冒頭で本書は分量が少なく、約20年間アジャイルと関わってきた私の個人的な思い出、観察、意見であると述べています。
それだけに少し砕けた表現になっており、本質的なものに要点も絞られているため、シンプルで読みやすい本です。小規模開発に関わっている人がアジャイルを取り入れるために読む本としては最も適しているのではないでしょうか。
ポイント
アジャイルの概要
鉄十字
あらゆるプロジェクトは、鉄十字と呼ばれるプロジェクトマネジメントのトレードオフを選ばなければなりません。それは、「品質」「速度」「費用」「完成」のうち、好きな３つは選べるが、４つは選べないということです。高品質で高速で安価なプロジェクトは完成することはできず、安価で高速で完成するプロジェクトは高品質ではないといったようにすべてを満たすことはできません。
優れたマネージャーはこの４つの属性に係数があることを理解しています。すべてを100%にするのではなく、十分な品質と速度と費用を保ちながらし、必要な分だけ完成させながら進行します。
このような各属性の係数をうまくマネジメントすることを支援するフレームワークがアジャイルです。
そして支援をうまく使うためには、データ化することが重要です。
次の記事で説明しますが、ストーリーポイントをグラフ化したチームのベロシティや、バーンダウンチャートのようなツールを使って進捗具合を確認するために、データをチームマネージャーに提供することが重要です。
ソフトウェア開発の特性
ソフトウェア開発の世界は、納期は固定されるのに対し、要求は常に変更される世界です。
特にウォーターフォールモデルでは、半年後に納期が決まっているが要求ははっきりしないというシステム開発において、しばしば不思議な奇跡が起こります。
調査・分析は予定の２ヶ月が経ったというだけで、質はどうあれ完了となります。
同じく設計も予定の２ヶ月も期間が経ったというだけで完了となります。実際は要求が変わり調査・分析が必要になっていたとしてもです。
そして残りの実装フェーズの２ヶ月にしわ寄せがきます。分析も設計も明確な完了基準がなかったのに対し、コーディングには明確な完了基準があり、完了したふりはできません。
そしてデスマーチを呼ぶ可能性が高くなります。
この惨事はウォーターフォールだからというわけではなく、ウォーターフォールは正常に機能していれば分かりやすい方法です。しかし大きな被害をもたらしやすい現実があります。
アジャイルのアプローチ
アジャイルでも最初に知るべきは納期です。その納期に対し、イテレーションやスプリントという定期的な期間に分割します。2週間程度で区切るのがちょうど良さそうです。
なお、これはウォーターフォールを小分けにしたのとは異なり、イテレーションの中で、要求分析、アーキテクチャ、設計、実装を継続的に実行します。
このイテレーションの早い段階で、どの程度時間がかかるのかの計測ができてきます。このデータが重要です。
このデータをもとに、計画を調整することで、新しい終了日を次のイテレーションで設定することができます。
このデータの積み重ねにより、予測と実績の誤差が小さくなり、根拠のない希望を持つことなくプロジェクトを進行することができるようになります。
上司が「進捗はどうですか？」と聞いたときに、希望を含めて「順調です」と答えることもなくなります。
なお、アジャイルは速く進むことだと誤解している人もいますが、アジャイルとは、どれだけうまくいっていないかをできるだけ早く知ることです。
鉄十字のはなしに戻ると、マネージャーはデータをもとに、どれだけの品質、速度、費用、完成度のプロジェクトにするかを決めます。そのために、「スケジュール」「スタッフ」「クオリティ」「スコープ」を調整することになります。
- ○：スケジュールを延期する
- 数イテレーションで納期に間に合うかのジャッジができるため
- △：スタッフを増やす
- 基本的に遅れているプロジェクトへの要員追加はさらに遅らせるため、プラスに転じるまでの期間を見極める必要がある
- ×：クオリティを下げる
- 速くて汚いものなどありません。クオリティは最大にしましょう。
- ○：スコープを変える
- 納期を変えるには困難を極めるが、合理的なデータがあれば、納期までの機能の取捨選択も可能になります。
- 納期を変えるには困難を極めるが、合理的なデータがあれば、納期までの機能の取捨選択も可能になります。
アジャイルの概要をまとめると、ポイントは以下のとおりです。
- プロジェクトをイテレーションに分割するプロセス
- 各イテレーションのアウトプットを計測し、スケジュールを継続的に評価する
- 最も価値のあるものが最初に実装されるよう、ビジネス価値の順番で機能を実装していく
- クオリティは可能な限り高める
- スケジュールはスコープの調整によって管理する
サークルオブライフ
アジャイル開発における開発手法のひとつにXP（エクストリームプログラミング）があります。
このXPのプラクティスを描いた図が以下のとおりで、本書ではすべてのアジャイルプロセスのなかで、XPが最も適切に定義され、最も完全で、最も混乱が少ないといいます。
サークルオブライフは３つのリングに分割できます。それぞれについて解説します。
外側のリング
最も外側にあるリングは、ビジネス向けのプラクティスです。これはスクラムのプロセスに相当します。
チームとビジネス側とがコミュニケーションするためのフレームワークと原則を提供します。
プロジェクトを機能・ストーリー・タスクに分割する方法と、それぞれの見積もり、優先順位付け、スケジューリングのガイダンスを提供します。
小さな単位で作業するようにチームをガイドします。
機能・ストーリー・タスクの「DONE」の定義を提供します。明確な完成基準の設定方法をチームに示します。
さまざまな職種（プログラマー、テスター、マネージャーなど）が共通のゴールを目指して協力するという考えを示します。
中間のリング
中間にあるリングは、チームのプラクティスを示します。
開発チームがチーム内やマネージャーとコミュニケーションするためのフレームワークと原則を提供します。
開発チームがリソースをすぐに消費してしまい、ゴールの前で力尽きないようにするためのプラクティスです。
チームに知識の断絶が起きないようにするためのプラクティスです。
チームが現在地を常に把握できるよう、フィードバックを繰り返すことにフォーカスするプラクティスです。
チームとビジネス側がシステムについてコミュニケーションするための語彙や言語を作成し、広めるためのプラクティスです。
最も内側のリング
最も内側にあるリングは、最高の技術品質を保証するために、プログラマーをガイドおよび強制するための技術プラクティスを示します。
革新性と正確性を促進するレベルで、技術チームが知識の共有、レビュー、協力ができるようになるためのプラクティスです。
チームがムダなことをしないようにガイドするためのプラクティスです。
すべての作成物の継続的な改善と改良を促進します。
技術チームが高品質を維持しながらすばやく進むための命綱です。
アジャイルにする理由
アジャイルとは、ソフトウェア開発を支える、規律のフレームワークです。
アジャイルは開発プロセスでもなければ、流行りの何かでもありません。単なるルールの集合というわけでもなく、倫理的な権利、期待、規律の一式だといえます。
それはすべてまっとうさというところから来ているといえます。
過度な期待はしないし、無理もしないという哲学的な考え方が含まれます。
顧客にも開発者にも期待があり権利があります。
顧客には、計画やコストを知り、最高価値を手にする権利があります。自ら書いたテストで機能することを証明してもらう権利もありますし、プライオリティを変更する権利もあります。
開発者には、プライオリティを知る権利があり、質の高い仕事をする権利があります。また、サポートを受ける権利や自ら見積もりをし、それを更新する権利もあります。
このような規律の中で、マネージャーやステークホルダー、顧客のまっとうな期待を受け入れ、それに従うという、権利と期待をお互いが引き受けて協議するという規律のある専門性こそが、ソフトウェアの倫理的な基準の土台になるということです。
サークルオブライフに基づく、各プラクティスの詳細については、別の記事で紹介したいと思います。
詳しくはこちらの記事で紹介しています。
目次
- アジャイル入門
- アジャイルの歴史
- スノーバード
- アジャイルの概要
- サークルオブライフ
- 結論
- アジャイルにする理由
- プロフェッショナリズム
- まっとうな期待
- 権利章典
- 結論
- ビジネスプラクティス
- 計画ゲーム
- 小さなリリース
- 受け入れテスト
- チーム全体
- 結論
- チームプラクティス
- メタファー
- 持続可能なペース
- 共同所有
- 継続的インテグレーション
- スタンドアップミーティング
- 結論
- テクニカルプラクティス
- テスト駆動開発
- リファクタリング
- シンプルな設計
- ペアプログラミング
- 結論
- アジャイルになる
- アジャイルの価値基準
- 動物のサーカス
- トランスフォーメーション
- コーチング
- 認定資格
- 大規模アジャイル
- アジャイルのツール
- コーチング（もうひとつの視点）
- 結論（再びボブから）
- クラフトマンシップ
- アジャイルの二日酔い
- 期待の不一致
- 開発者のアジャイル離れ
- ソフトウェアクラフトマンシップ
- イデオロギーとメソドロジー
- ソフトウェアクラフトマンシップにプラクティスはあるか？
- プラクティスではなく価値にフォーカスする
- プラクティスの議論
- クラフトマンシップが個人にもたらすインパクト
- クラフトマンシップが業界にもたらすインパクト
- クラフトマンシップが企業にもたらすインパクト
- クラフトマンシップとアジャイル
- 結論
【内容情報】
小さなことをする、小さなソフトウェアチームがうまくやっていくために!
アジャイルとは、小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイデアである。アジャイルとは、大きなことをしている大きなプログラミングチームの大きな問題を扱う大きなアイデアではない。
大きなことは大きなチームなんかじゃできない。小さなことをする小さなチームがいくつも集まり、コラボレーションしながら大きなことを成し遂げるのだ。
このことを、我々はあらためて認識する必要がある。【著者情報】
Clean Agile 基本に立ち戻れ 内容紹介より
Robert C.Martin
Robert C. Martin(アンクル・ボブ)は、1970年からプログラマーである。
cleancoders.comの共同創業者であり、ソフトウェア開発者向けの学習用動画をオンラインで提供している。
また、Uncle Bob Consulting LLC.を設立し、世界中の大企業を対象としたソフトウェアコンサルティング、トレーニング、スキル開発を行っている。
シカゴに本拠地を置くコンサルティングファーム8th Light, Inc.では、Master Craftsmanを務めていた。
