Clean Agileを読んで学んだアジャイルのまとめ

概要

Clean Agile　基本に立ち戻れ (アスキードワンゴ) | Ｒｏｂｅｒｔ Ｃ．Ｍａｒｔｉｎ, 角 征典, 角谷 信太郎 | 工学 | Kindleストア | Amazon を読んでのまとめです。

アジャイルソフトウェア開発の本来の目的の概要を提供する本です。

この記事では、この本から私が学んだことをただまとめます。

解釈については私見のため、間違えている可能性があります。

これは書籍からの引用を表します。

より深く知りたい場合は、書籍をご参照ください。

アジャイルソフトウェア開発宣言

2001年2月に17名のソフトウェアの専門家がスノーバードに集まった。

これは、ウォーターフォールのような儀式的で効果のない重量級のプロセスの開発ではなく、効果のある軽量級のアプローチを広めるためのアジャイルソフトウェア開発宣言を作成するためだった。

アジャイルは小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイディア

大きなことは大きなチームなんかじゃできない。
小さなことをする小さなチームがいくつも集まり、コラボレーションしながら大きなことを成し遂げるのだ

著者曰く、かつての先人たちが気づいていた上記のアイディアを広めるために「アジャイル」という名前をつけたとのこと。

大規模アジャイル

アジャイルは小規模から中規模なチームのための手法なので、著者は本書の後半で、大規模アジャイルはないと言う立場をとっている。
大規模なチームの問題は社会と文明の問題であり、それは様々な専門家が5000年以上かけて取り組んできた問題である。

ソフトウェアプロジェクトのマネジメントでは何をするか？

マネジメントは、開発者に納期を迫るものではない。

「品質」「速度」「費用」「完成」(鉄十字)
の4つの係数を調整するのが優れたマネジメントで、
アジャイルはこういったマネジメントを支援する。

もちろんアジャイルを用いていても、マネージャーが適切な意思決定をできない場合などに失敗することがある。

アジャイルはどのようにマネジメントを支援するか。

アジャイルは、データを提供することで、マネージャーの適切な意思決定を支援する。

ベロシティグラフとバーンダウンチャートを貼るのはめちゃくちゃ大事だと書かれている。

この２つによってチームの速度と、残りの作業をマネージャーは知ることができる。

鉄十字の調整

鉄十字のために、マネージャーは以下を調整する

スケジュールを延期	ビジネス上の正当な理由であれば変更できない。 便宜的に日付を選んでいるだけの場合は変更可能な場合もあるため速く伝える。
スタッフを増やす	ブルックスの法則によりさらに遅れる。 プラスになるにはチームに新規人員が馴染む、十分な時間と改善が必要。
クオリティを下げる	がらくたを作っても速くはならない。 スケジュールを短縮するにはクオリティを上げるしかない。
スコープを変える	「期限までに全ての機能が必要です」というステークホルダーに対して、アジャイルで出ているデータを元に無理だと伝える。

納期は最初に知るべき

納期はビジネス上の理由であり、開発者が作れないという理由だけで変更できるものではない

しかしシステムの要求は常に再評価され、再検討されるもので凍結することはできない。

ウォーターフォールの物語

分析、設計、実装があるとする。

それぞれ2ヶ月割り当てられている場合、分析と設計は期限がくると必ず完了する。
なぜなら、分析や設計は明確な完了基準がなく、完了したかどうかを確認する手段がないためである。

実装は実際に完了させる必要があり、完了したふりはできない。
実装フェーズの途中で完了できないことに気づき、それをステークホルダーに伝えると、
「分析や設計の時は問題があるって言ってませんでしたよね？」と言われてしまう。

そしてデスマーチへ

時がたち、プロジェクトが終了すると、

「こんなプロジェクトは二度とごめんだ。
次こそは正しくやろう！もっと分析して、もっと設計しよう」
と思ってしまう。

これを著者は**「暴走プロセスのインフレ」**と呼ぶ。
うまくいかなかったことをやめずに、もっとやろうとしているから。

ウォーターフォールの手法はわかりやすい。

1. 問題を分析し、
2. ソリューションを設計して
3. 設計を実装する

ウォーターフォールはシンプルで直接的、明確で非常にわかりやすく、そして間違っている。

アジャイルもわかりやすい

1.まず納期を知る。
2.納期までの期間を定期的な期間(イテレーション)に分割
3.ユーザーストーリーを作成、見積もり、計画し、設計する。

プロジェクトの全てのイテレーションには、最初から最後まで、分析・設計・実装が含まれる。

これはミニウォーターフォールとも違う
イテレーションの最初に分析が完了するわけでも、実装が最後に完了するわけでもない。

希望の喪失

イテレーションが終了するたびに、イテレーションで完了できるストーリーポイントがわかり、
元の終了日には希望がないことがわかる。

この希望の喪失がアジャイルのゴールだ。
希望がプロジェクトを殺す前に、アジャイルで希望を破壊するのである。

希望はプロジェクトキラー
希望を持つとソフトウェアチーム「進捗が順調です」といって、マネージャに進捗を誤解させるため。

アジャイルは速く進むことではない

アジャイルはどれだけうまくいっていないかをできるだけ速く知ること

マネージャーはデータを収集し、それを元に最善の意思決定をすることでソフトウェアプロジェクトをマネジメントする。
アジャイルはデータを生成する。

ビジネス価値の順番

ビジネス価値の順番で機能を実装していく。
機能には依存関係があるが、我々はプログラマなので、依存関係には対処できる。

サークルオブライフ

A New Software Development Framework: Ideasでロン・ジェフリーズがXPのプラクティスを描いた図。

著者は以下のように述べている

アジャイルを本当に理解したければ、XPを学ぶ以上の方法はない。

著者はアジャイルの規律に惹かれた。
世界はソフトウェアであふれており、そのコードを書くのはプログラマだが、その仕事はなかなかお粗末になっている。きちんとテストのあるソフトウェアがどの程度あるのか？

著者はアジャイルソフトウェア開発の規律により、コンピュータプログラミングが名誉ある職業へと変わることを期待している。

課題とアジャイルの規律の対応

問題	規律
ゴミのようなソフトウェア (ex: ユーザがプログラマのように考えないといけないソフトウェア)	テスティング、リファクタリング、シンプルな設計、顧客からのフィードバック
人為的な遅延	価値の順に開発、 イテレーション終了時に技術的にデプロイ可能。
チームの生産性低下	アーキテクチャ・設計・コードをクリーンに保つ。テスティング、ペアリング、リファクタリング、シンプルな設計、計画ゲーム
変更への恐怖	TDD、リファクタリング、シンプルな設計
手動テスト	TDD、継続的インテグレーション、受け入れテスト
チームの一人がいないと進まない	ペアプログラミング、チーム全体、共同所有
不誠実な見積もり	計画ゲーム、チーム全体
納期のプレッシャーでノーが言えない	チーム全体
変化の早い業界知識・教えること	チーム全体

権利章典

ケントベックは、アジャイルの目標はビジネスと開発の分断を修復することであると述べた。

顧客の権利	補足
計画のどの部分に関しても、いつまでに、何が、どのくらいのコストで達成できるかを知る権利	ビジネスには計画が必要であり、計画には納期とコストが含まれる。 しかし、スコープも納期も調整可能である必要がある。 確率ベースの計画によって調整可能を表現する。
全プログラミング期間を通して最高価値を手にする権利	イテレーションのタイムボックスで提供する利用可能なビジネス価値は、可能なかぎり高くなる。
自らが書いた再現可能なテストを通すことで、システムが機能することを証明してもらい、現行システムの進捗度合いを知る権利	顧客には進捗の変化を知る権利がある。受け入れ基準を指定し、受け入れ基準を満たしていることを、迅速かつ再現可能な形式で立証してもらう権利がある
考えを途中で変えて機能を差し替えたり、プライオリティを変更する権利	ソフトウェアなのだから、マシンの動作を簡単に変更できる。
スケジュールの変更があったら連絡を受ける権利。 いつでも発注を取り消し、その時点までの投資に見合う、ちゃんと機能するシステムを手にする権利	顧客にはスケジュールの順守を要求する権利はない。スコープの変更によるスケジュール管理に限定される。最も重要なのはスケジュールの危険を知る権利で、これにより顧客は臨機応変にスケジュール管理できる

開発者の権利	補足
何が必要とされているのかを明確なプライオリティと合わせて知る権利	開発者には用件の詳細と重要度を知る権利がある。 この権利が適用されるのはイテレーション期間中のみ。イテレーション中は要件や優先順位は変化しないと見なす権利がある
常に質の高い仕事をする権利	ビジネス側が、開発者に対して手抜きや質の低い仕事をするように指示する権利はない。
同僚や上司、顧客に助力を求め、それを受ける権利	要件のわかりやすい説明など、コミュニケーションをとる権利
自ら見積もりを行い、それを更新する権利	見積もりは推測であり、決してコミットメントにはならない
責任を割り当てられるのではなく、責任を自ら引き受ける権利	プロの開発者には仕事やタスクに対して「ノー」という権利がある。チームには誰が何をするのか協力しながら決定する権利がある

ビジネスプラクティス

計画ゲーム

プロジェクトは構成要素に分割し、それらを見積もる。
コード行まで分割させれば非常に正確な見積もりができるが、本来は実際に構築することなく、プロジェクトにかかる時間を知りたい。

この定義から見積もりは精度の低いものとなる。
開発者は見積もりを正確にしたまま、できるだけ狭い範囲を選択できるように、時間を短縮する。

三点見積り

大きなタスクに有効な見積もり技法

以下の3つの数値で構成

ケース	信頼性	あるタスクに対する例
最良ケース	5%	1週間以内に完了する可能性は5%
最有力ケース	50%	2週間以内なら50%
最悪ケース	95%	3週間以内なら95%

PERTを参考にすると良い。

ストーリーポイント

プロジェクト内部で使うには3点見積もりは精度が悪すぎるので、ストーリーポイントを利用する。

ユーザーストーリーとは、システムの機能をユーザーの視点から簡潔に記述したもの。

例: 車の運転手として、アクセルペダルを強くふみたい。それは車の速度を上げるためだ。

詳細は書かない。ストーリーを開発する時まで遅らせる。
詳細は変更されることを我々は知っているから。

詳細はストーリーではなく、受け入れテストとして記録する

著者はストーリをインデックスカードに書くことをお勧めしている。どんな風にも扱えるためである。

詳細化を避けるのは難しく、鍛錬である。
ストーリーをマネジメント可能、スケジュール可能、見積もり可能にするには「一時的な詳細の欠如」が必要。

平均的なストーリーを選び、平均的な点数(ポイントの範囲を1~6としたなら3など)をつける
これをゴールデンストーリーとし、比較して他のストーリーのポイントを見積もる

このポイントは見積もり時間ではなく、見積もり労力である。
つまりやる人によって時間が変わったりする。

IPM

イテレーションはイテレーションプランニングミーティング(IPM)から始まる。
イテレーション期間の1/20の時間になるようにする。

ステークホルダーの仕事は、
イテレーションでプログラマとテスターが実装するストーリーを選択すること。

ベロシティ(プログラマが完成できると考えるストーリーポイントの合計)に基づいてストーリーを選択する。
ベロシティは確約でもなければ、試みようと約束するわけでもない。ただの推測。

イテレーションには中間地点レビューがあり、ステークホルダーはデータをみて計画にポイントを追加、削除する。
計画時には前回のイテレーションで完成したポイントで計画する。これを昨日の天気と呼ぶ。

ストーリーのINVEST

ストーリーが従うべきガイドライン

英	日	概要	補足
Independent	独立した	お互いに独立し、特定の順番で実装する必要がない	ログアウトの前にログインを実装する必要はない。 他のストーリーの実装に依存するストーリーも存在するため、ゆるい条件とされている
Negotiable	交渉可能	詳細を記述しない理由。開発者とビジネス側で詳細を議論できるようにする	開発の観点からUIを提案する
Valuable	価値がある	ビジネス的に価値があること	リファクタリングやアーキテクチャはストーリーではない。通常、ストーリーはシステムの全てのレイヤーを通る
Estimatable	見積もり可能	開発者が見積もりできる程度に具体的である	「システムは高速でなければならない」は見積もり可能ではない
Small	小さい	1~2人の開発者が1回のイテレーションで実装できる大きさ	厳密に守る必要はない。ガイドライン
Testable	テスト可能	ビジネス側はストーリーが完成したことを担保するテストを明確に示す必要がある	通常はテストはQAが記述し、自動化され、ストーリーが完成したかどうかを判断するために使用する。

ストーリーの見積もり

大体広域デルファイ法が元になっている。
フライングフィンガー、シャツのサイズ、プランニングポーカーなどがある。

スパイクはストーリーを見積もるためのストーリー。システムの全てのレイヤーを通る、先の尖った細長いものを開発することが多いので、スパイクと呼ばれる。
あるライブラリを使ったことがない場合は、ライブラリの仕組みを理解するために、何をすべきか把握し、見積もる。

イテレーションのマネジメント

各イテレーションの目標は、ストーリーを完成させてデータを生成すること。
IPMが終わったらすぐに、プログラマーは自分が担当するストーリーを手に取る。
ストーリーはプログラマー個人が手に取るものであり、マネージャーがリーダがアサインするのは避ける。

受け入れテスト

ストーリーの自動受け入れテストの記述はIPM終了後すぐに取り掛かる。
終わっていなければ何人かの開発者が受け入れテストを書く。しかし自分の担当ストーリーのテストは書かない。

受け入れテストがないとストーリーは完成できない。
ベロシティで報告するのは、受け入れテストをパスしたストーリーのみ。

デモ

大体1~2時間程度
デモではこれまでのテストを含む、全ての受け入れテストと全てのユニットテストを実行する。
また、新しく追加された機能も見せる。
開発者が機能していないところを隠せないように、ステークホルダーがシステムを操作すると良い

ベロシティ

イテレーションの最後にはベロシティとバーンダウンチャートを更新する。

イテレーション初期はベロシティの傾きはノイズの多いものとなるが、数回繰り返すと安定する。
長期的にはチームの速度は大きくあげたり下げたりしたくない。

傾きが正になっても、チームが実際に速くなっているわけではない。プレッシャーが高まるとチームは無意識に見積もり値を変える。
ベロシティは計測結果であり、目的ではない
計測しているものに圧力をかけないのは制御理論の基本である。

ベロシティの傾きが負になる時は、コード品質に問題があり、リファクタリングが十分でない可能性が高い。

ベロシティのインフレを回避するには、ストーリーの見積もりを定期的にゴールデンストーリーと比較する。

小さなリリース

開発チームはできるだけ頻繁にソフトウェアをリリースすべき。
目標は継続的デリバリー = 変更するたびに本番環境にコードをリリースするプラクティス
デリバリーサイクルだけではなく、実際にはすべてのサイクルを短縮したい

受け入れテスト

基本アイディアは「要求はビジネス側が仕様化する」

受け入れテストの例:

もしユーザーが有効なユーザー名とパスワードを入力する
かつ「ログイン」をクリックする
ならばシステムは「ようこそ」ページを表示すること

これは明らかに仕様であり、テストでもある。また、自動化できる。

様々な混乱や論争があったが、プラクティスとしてはシンプルである。

ビジネス側がユーザーストーリーの振る舞いを形式的なテストで記述し、
開発者がそれらのテストを自動化するだけ

ストーリーのテストは、ビジネスアナリストとQAで作成。
ビジネスアナリスト: ハッピーパス(正常系)を仕様化
QA: ハッピーではないパスを仕様化

開発者はそれを継続的ビルドに統合する。
テストを実行するのはプログラマー。
継続的ビルドでサーバーがモジュールのチェックインのたびに、全テストを実行するように自動化する。

テストはイテレーションにおけるストーリーの完成の定義である。
ストーリーは受け入れテストが作成されるまで仕様化されていない。
ストーリーは受け入れテストをパスするまで完成ではない

QA

QAは後方でテスターとして活動するのではなく、前方で活躍する仕様作成者となる。
QAが最後に手動でテストすると、QAがボトルネックになる。上流工程の全てがQAの肩にかかってしまう。

QAがうまくやっていることは欠陥を発見した数となることが多く、欠陥が良いものとされてしまう。
また、納期に間に合わせないといけない開発者も、欠陥から利益を受ける。
この欠陥の闇経済は組織を衰弱させる。

チーム全体

オンサイト顧客と呼ばれる。
ユーザーとプログラマの距離が縮まることで、コミュニケーションが改善されて開発が速くて正確になるのではないか？

顧客とは、ユーザーのニーズを理解しており、開発チームと一緒にいる人やグループのメタファー
スクラムではPOのこと。

このプラクティスはチームプラクティスではなくビジネスプラクティスである。

同じ部屋にいる方が非言語コミュニケーションなどの関係からリモートよりもうまくできる。

チームプラクティス

メタファー

効率的なコミュニケーションのために、チームの共通知識とプロジェクトを関連づけること。

不快感のある変なメタファーを付けないように注意。

**DDD(ドメイン駆動設計)**はメタファーの問題を排除した。
ユビキタス言語による全員が合意した語彙というのがメタファーの役割をはたす。

持続可能なペース

ソフトウェアプロジェクトはスプリントの連続ではなく、長距離走。
長期にわたって持続できるペースで走る必要がある。
速く走るとゴールライン手前でスローダウンする。

残業は雇用主への献身を表さない。

あなたが計画できない人であり、合意すべきでない納期に合意した人であり、守れない約束をした人であり、専門家ではなく従順な労働者であることを示す

プログラマーの生活でもっとも重要なのは十分な睡眠

共同所有

誰もコードを所有しない。
チーム全員ですべてのモジュールを学習し、すべてのモジュールを改善する。

共同所有で、チームメンバーはモジュールの境界を理解し、システム全体の振る舞いを理解する。
これにより、チームのコミュニケーションや意思決定能力が大幅に向上する。

継続的インテグレーション

継続的ビルドは絶対に壊してはいけない。

継続的ビルドが壊れたら緊急事態で、CEOに警報を鳴らしたいくらいのもの。
すべてのプログラマは作業を中断してビルドを復旧する。

スタンドアップミーティング

• 任意。なくてもうまくやっているチームはある
• 毎日より頻度は低くても大丈夫
• 大規模チームでも10分以内
• シンプルなやり方に従う

3つの質問に答える

1. 前回のミーティングから何をしたか
2. 次回のミーティングまでに何をするか
3. 何か邪魔になっているものはあるか。

スタンドアップミーティングで話をするのは開発者だけ(参考: 豚と鶏)

４番目に**誰に感謝したいか？**を追加するのもおすすめ

テクニカルプラクティス

テスト駆動開発(TDD)

会計士は複式簿記の規律で取引を必ず2回記入する。
差引勘定を計算する前に複数の取引を入力してはいけない。

これに対応するプログラマーのプラクティスがTDD。
必要となる振る舞いは、必ず二回入力する。

どちらもすべての記号が正しくあるべき重要なドキュメントのエラーを防ぐという点で共通している。

TDDの3つのルール

• 失敗するテストを書くまでプロダクションコードを書いてはいけない
• 失敗するテストを必要以上に書いてはいけない
• プロダクションコードを必要以上に書いてはいけない（失敗しているテストをパスさせるためだけに書く）

これは5秒程度のサイクルであり、どのプログラマを選んでも過去1分以内にすべてのテストをパスするようにできるはず。
全てが必ず過去１分以内に動作しているなら、デバッグは1分以内に発生した障害に対して行うだけで良い。

テストはプログラマにとって完璧なドキュメンテーションである。

テストを後にすると、テスト容易性についてコードを書くときに考えないので、大変な作業となる。
これによりテストスイートに穴が開いてしまう。

テストを先にするとテストが難しい機能を書けなくなる
テスト容易性(testability) = 分離(decoupling)

警告

• テストカバレッジはチームの指標であり、マネージャーはこの指標をゴールやターゲットにしてはならない
• カバレッジが不十分でもビルドを失敗させてはいけない

勇気

テストスイートがあるとコードをクリーンにする恐怖がなくなるので、コードをクリーンにするようになる。

リファクタリング

「テストで定義された振る舞いを保ちつつ、コードの内部構造を改善する」プラクティス

TDDのサイクルに含まれる

1. レッド
2. グリーン(コードを動かすことに集中)
3. リファクター(汚いコードをクリーンにする)

リファクタリングは継続的なプロセスで、スケジュールを立てて実行するものではない
システム設計やアーキテクチャの変更など、大きなリファクタリングも、TDDのサイクルの中で行う。
特別に時間を確保しないこと。

シンプルな設計

必要とされるコードだけを書いて、最もシンプルで、最も小さく、最も表現力のある構造を維持するプラクティス

ケントベックのシンプルな設計のルール
1.　全てのテストをパスさせる
2.　意図を明らかにする
3.　重複を排除する
4.　要素を減らす

ゴールは設計のウェイトを減らすこと
設計が複雑になれば、プログラマーの認知的負荷は大きくなる。

複雑な設計を採用すれば、複雑な要求をシンプルにできる。

設計と機能の複雑さのバランスをとることが、シンプルな設計のゴールである

ペアプログラミング

ペアになるのは任意で、強制されるべきではない
常にペアになるわけではない

ストーリーはペアに割り当てるものではない。ペアではなく個人のプログラマーがストーリーの完成に責任を持つ。

知識を集めるではなく、知識を交換することがゴールである
専門分野を持つプログラマーは専門外のプログラマーとペアになる

ペアリングのコストは15%増となる。(100人分の作業は、115人のペアのプログラマーが必要)
ペアリングがコードレビュー代わりになれば生産性が落ちることはない

マネージャーがペアリングの中止を求める場合、あなたは専門家であり、作業方法に責任を持つのはマネージャーではなくあなたであることを思い出してもらう。
ペアになる許可はマネージャーに求めてはいけない。

あなたは専門家だ。あなたが決めよう

アジャイルの価値基準

勇気	合理的なリスクをとる。 品質と規律が速度を上げるという信念を持つ
コミュニケーション	領域を横断する、頻度の高い直接的なコミュニケーションを大切にする
フィードバック	フィードバックの頻度と量を最大化する。早い段階から問題を特定し、修正する。
シンプリシティ	直接的にする。コード、チーム、コミュニケーション、行動をシンプルにする

著者はアジャイル導入に関して、サークルオブライフ、特にテクニカルプラクティスを採用することを強くアドバイスしている。

アジャイルへのトランスフォーメーションは中間管理職が障壁となる。
中間管理職に変化を起こすことは不可能

アジャイル組織には移行するのではなく、作ること。

さいごに

何か気になることがありましたら、コメント等いただければ幸いです。