「Clean Agile 基本に立ち戻れ」
本の概要
ボブおじさんこと、Robert C. Martinさんがアジャイル開発とは何か？どうやって生まれ、どのように進化したのか？を教えてくれる一冊です。
ボブおじさんは、「アジャイル」という言葉の生みの親であり、アジャイル開発のイデオロギーである「アジャイルソフトウェア開発宣言」ができた、サミットの主催者の一人です。アジャイル開発を正確に理解するために必要な事実情報を伝えるのに適切な人物と言えます。
アジャイルには、さまざまメソッドが世の中で用いられていますが、その本質やイデオロギーが理解されていないことで、手段が目的化しているケースが往々にして見受けられます。
チームや開発の課題をしっかり捉え、あるべき姿を見失わずに、改善を積み重ねていくために最適な一冊です。
アジャイルとは？
アジャイルとは
小さなことをしている、小さなプログラミングチームの小さな問題を扱う小さなアイデアです。大きなことをしている大きなチームの大きな問題を扱う大きなアイデアではありません。
小さなことをする小さなチームがいくつも集まり、コラボレーションしながら大きなことを成し遂げるためのアイデアがアジャイルです。
イデオロギーとメソドロジー
イデオロギーとは、アイデアと理想からなるシステム。
メソドロジーとは、手法とプラクティスからなるシステム。
イデオロギーは目指すべき理想を定義します。この理想に近づくために、一つ以上のメソドロジーを使用します。
アジャイルマニュフェストはイデオロギー。スクラム、XP等のアジャイル手法のメソドロジーは、すべて同じ目的のための手段。
メソドロジーやプラクティスにこだたわりすぎると、チームや組織が本当の目的を見失ってしまう。
プラクティスのない原則は抜け殻だが、原則のないプラクティスは機械的に実施されてしまう。原則がプラクティスをガイドする。プラクティスが原則を具現化する。両者は密接に関連している。
アジャイルが可能にしていること。
アジャイルは、データを計測・可視化することによって、「スケジュール」、「スタッフ」、「クオリティ」、「スコープ」の4つをコントロールするマネジメントフレームワークです。
「ベロシティ」や「バーンダウンチャート」などの形でデータを提供します。
アジャイルとは、経験主義的なフィードバック駆動型であり、毎月、毎週、毎日の結果を見ながら、調整していきます。
希望があると、進捗を誤解させてしまう。希望はプロジェクトキラーなので、アジャイルで希望を破壊し、冷静に非常な現実を直視できるようにする。
どれだけうまくいってないことがアジャイルによって、できる限り早く知ることができ、その状況をマネジメントできるようになります。
イテレーションの目的は、マネージャーのためにデータを生成すること。コードができていれば素晴らしいが、できていなくてもデータは生成される。
イテレーションが失敗するのは、データを生成できていないときになります。
権利章典
アジャイルの目標は、ビジネスと開発の分断を修復することです。
ボブおじさんが、アジャイルに魅力を感じている背景に、儀式よりも規律に対する強いコミットメントがあります。
アジャイルは、プロフェッショナルなソフトウェア開発を支える規律のフレームワークで、倫理的な専門性の土台を形作る権利、期待、規律の一式です。
顧客の権利
顧客には、計画のどの部分に関しても、いつまでに、何が、どのくらいのコストで達成できるかを知る権利がある
不確実性の度合いを計画、見積もり、スケジュールに適切に反映させて、その不確実性を軽減する方法定義し、確率ベースの計画を顧客は知る権利がある。
顧客には、全プログラミング期間を通して、最高価値を手にする権利がある。
顧客には、自らが書いた再現可能なテストを通すことで、システムが機能することをちゃんと証明してもらい、現行システムの進捗度合いを知る権利がある。
顧客には、考えを途中で変えて機能を差し替えたり、プライオリティを変更したりする権利がある。その際に特別に多額の出費は必要ない。
変更容易性がソフトウェアの本質。
顧客には、スケジュールの変更があったら連絡を受ける権利がある。なお、その連絡は、最初に決めた期限を守るため、どうスコープを減らすかを決めるのに手遅れにならないよう、十分速やかに行われなければならない。そしていつでも発注を取り消し、その時点までの投資に見合う、ちゃんと機能するシステムを手にする権利がある。
顧客にはスケジュール遵守を要求する権利はない。顧客の権利は、スコープの変更によるスケジュールの管理に限定されている。この権利のうち最も重要なのが、スケジュールに危険が及んでいることを知る権利。
開発者の権利
開発者には、何が必要とされているのかを明確なプライオリティとあわせて知る権利がある。
イテレーションの期間中は、要件や優先順位は変わらない。
開発者には、常に質の高い仕事をする権利がある。
開発者には、同僚や上司、顧客に助力を求め、それを受ける権利がある。
プログラマーがコミュニケーションを取る権利。助力を求める権利には、助力を求められたときには応じる責任もある。
開発者には、自ら見積もりを行い、またそれを更新する権利がある。
見積もりはコミットメントではない。
開発者には、責任を割り当てられるのではなく、責任を自ら引き受ける権利がある。
仕事やタスクに対して、「ノー」という権利がある。
アジャイル開発とソフトウェア
ソフトウェアとは？
ソフトウェアとは、「変更しやすい製品」という意味です。ソフトウェアが発明されたのは、マシンの動作をすばやく簡単に変更する方法が求められたからです。
「要件変更」は我々のゲームの名前であり、我々の仕事は、変更を受け入れてエンジニアリングする能力と、そうした変更を比較的安価にできるかどうかにかかっています。
あるチームのソフトウェアの変更が難しければ、そのチームは自分たちのソフトウェアの存在意義を台無しにしているといえます。顧客、ユーザー、マネージャーはソフトウェアが変更しやすいことを期待しており、またその変更のコストは小さく、増加は線形であることを期待している。
それら実現可能にするのが、アジャイルのプラクティスになります。
アジャイルプラクティス
著者は、アジャイルを本当に理解したければ、XPを学ぶべきで、XPは、アジャイルの本質を示した原型であり、最も典型的なものだと言っています。
ボブおじさんは初版の「エクストリームプログラミング入門」がベストな書籍だと言っている（第2版ではない）
ビジネスプラクティス
計画ゲーム: Planning Game
小さなリリース: Small Release
受け入れテスト: Customer Tests
チーム全体: Whole Team
チームプラクティス
メタファー: Metaphor
持続可能なペース: Sustainable Pace
共同所有: Collective Ownership
継続的インテグレーション: Continuous Integration
テクニカルプラクティス
テスト駆動開発: Test-Driven Development
リファクタリング: Refactoring
シンプルな設計: Simple Design
ペアプログラミング: Pair Programming
計画ゲーム
プログラマーとは、タスクをコード行に分割できるスキルを持つ人のことを指す。
正確で精度の高い見積もりが必要であれば、コード行まで分割すればいい。しかし、見積もりとは推測であり、プロジェクトにかかる時間を実際に構築することなく知りたい。
見積もりはできる限り正確であるべきだが、見積もりのコストが抑えられるように精度は低くしたい。私が死ぬのは1000年以内だと見積もる。非常に正確だが、精度が低い。
正確な見積もりにおける精度とは、対象のイベントがほぼ確実に発生する機関の範囲を示している。見積もりを正確にしたまま、できるだけ狭い範囲を選択できるように、時間を短縮すべき。
ストーリーはシンプルに記述する。詳細は、ストーリーではなく、受け入れテストとして記録する。
ストーリーはINVESTのガイドラインに従う。
Independent
できるだけ他のストーリーに依存しないようにする
Negotiable
詳細を開発者とプロダクトオーナーで交渉できるようにする。ストーリーを詳細に記述しない理由。
Valuable
ストーリーはビジネス的に明確で定量化できる価値を持たなければならない。ストーリーには常にビジネス価値が存在しなければいけない。
Estimable
ストーリーは、開発者が見積もりできる程度に具体的でなければいけない。ストーリーは、1−2人の開発者が1回のイテレーションで実装できる大きさを超えてはいけない。
Testable
ビジネスサイドは、ストーリーが完成したことを担保するテストを明確に示す必要がある。通常QAが記述し、自動化され、ストーリーが完成したかどうかを判断するために使用される。
小さなリリース
アジャイルはチームのリリースサイクルのサイクルタイムを0に近づける。
リリースは、ソフトウェアが技術的にデプロイ可能であることを意味している。（デプロイするかはビジネス判断。ただリリースとデプロイが一致していることが最善）
受け入れテスト
DONEの定義は受け入れテストをパスすること。ベロシティに含めるのは、受け入れテストをパスしたストーリーだけ。具体的かつ計測可能な形で進捗し、信頼できるデータを手に入れるため。
受け入れテストの基本的なアイデアは「要求はビジネス側が仕様化する」というシンプルなもの。
ビジネス→QA←プログラマ。ビジネスが仕様を記述し、プログラマがそれを自動化する。QAは仕様から、テスト要件を記述し、正しくコードに翻訳されているかに責任を持つ。
チーム全体
顧客とは、ユーザーのニーズを理解しており、開発チームと一緒にいる人やグループのメタファー。
スクラムでは、プロダクトオーナーが顧客。プロダクトオーナーは、ストーリーを提供し、優先順位を設定し、FBを即時に提供する人。
メタファー
チームが効果的にコミュニケーションするためには、制約と起立を持つ用語や概念が必要で、これをケント・ベックがチームの共通知識と関連付けたことから、メタファーと呼ぶようになった。
「メタファー」はドメイン駆動設計の「ユビキタス言語」と同一。
継続的インテグレーション
継続的ビルドは絶対に壊してはいけない。ビルドが壊れたら緊急事態で、すべてのプログラマは作業を中断してビルドの復旧に努めるべき。
テスト駆動開発
テスト駆動開発
複式簿記のメタファー。
帳簿に記入する取引は、必ず2回記入する。1回目は勘定科目を貸し方に、2回目は対になる勘定科目を借り方に。これらが最終的に一つの帳簿に流れ込み、貸借対照表ができる。双方の差分が0にならなければなにかしらのエラーが発生していることになる。このプラクティスは適切な会計処理に不可欠であるため、世界のほぼすべての地域の法律になっている。
テスト駆動開発は、それに対応するプログラマーのためのプラクティス。必要となる振る舞いは必ず2回入力する。
複式簿記もTDDも同じ。どちらも同じ機能を持ち、すべての記号が正しくあるべき重要なドキュメントのエラーを防ぐというもの。
TDDのシンプルな3つのルール
失敗するテストを書くまではプロダクションコードを書いてはいけない（テストはコードの不足で失敗する）
失敗するテストを必要以上に書いてはいけない（コンパイルの失敗も失敗に含める）
プロダクションコードを必要以上に書いてはいけない（失敗しているテストをパスさせるためだけに書く）
事後テストだと、必然的にテストは書きづらいものになっていく。コードを書くときにテスト容易性については考えてないし、テストが可能なように設計してもいないから。先にテストを書くようにすれば、テストが難しい機能を書けなくなる。テストしやすいように自然と機能を設計できる。テストしやすい機能にするために分離する。TestabilityとDecouplingは同義語。
上記の3つのルールのゴールは、システムを安全にデプロイできることを知らせてくれる、自動テストスイートを作ること。
テストのカバレッジは90%台が妥当。
3つのルールに従うことで、デバッグの軽減、優れた低レベルのドキュメンテーション、楽しさ、完全性、分離といった、さまざまな利点がある。
もっとも重要な利点は、勇気。完全なテストスイートがあると、コードを変更する恐怖がなくなる。コードをクリーンにする恐怖がなくなる。だからコードをクリーンにするようになる。システムの秩序を維持するようになる。
リファクタリング
システムの設計やアーキテクチャが最適ではないことに気づき、システムの構造を大きく変えなければいけないことがあるが、それらも「レッド/グリーン/リファクタ」のサイクルのなかで行う。そういった大きなリファクタリングであったとしても、プロジェクトを立ち上げたり、特別に時間を確保することをせず、通常のアジャイルサイクルの中で、継続的に新機能を追加しながら、小さなステップで少しずつコードを移行していく。
シンプルな設計
シンプルな設計はリファクタリングのゴールのひとつ。シンプルな設計とは、必要とされるコードだけを書いて、最もシンプルで、最も小さく、最も表現力のある構造を維持するプラクティス。
ケント・ベックの設計のルール（数字は実行順序と優先度）
すべてのテストをパスさせる
意図を明らかにする
重複を減らす
要素を減らす
シンプルな設計のゴールは、コードの設計のウェイトを可能な限り減らすこと。
複雑が複雑になれば、プログラマーにかかる認知的負荷は大きくなる。この認知的負荷が設計のウェイト。複雑な設計で複雑な要求をシンプルにすることもできる。既存の機能に適切な設計を選択することでシステムの全体的な複雑さを軽減できる。設計と機能の複雑さのバランスをとることが、シンプルな設計のゴール。要求とのバランスを保ちながら、継続的にシステムの設計をリファクタリングしていくことで生産性を最大化できる。
ペアプログラミング
ペアは任意。チームでペアになるべき時間はおそらく50%程度。
チームとして振る舞うためにペアになる。チームメンバーの知識を共有し、サイロ化を防ぐための最善の方法。誰も欠かせない存在にしないための方法でもある。
コードレビューは静的なレビューだが、ペアリングは動的なレビュー。
さまざまな研究で、ペアリングの直接的なコストは15%増になることが示されている。時間の50%をペアに費やすチームは、生産性の面で8%程度の影響を受ける。ただ、トレーニング型での知識交換や集中的なコラボレーションの利点を考慮すると補いうる差分。
アジャイルの価値基準
勇気
合理的なリスクをとる勇気。品質と規律が速度を上げる。この信念を持つことが勇気。
コミュニケーション
高速で、混沌とした、インフォーマルで頻繁なやり取りのなかでアイデアは生まれ、インサイトが手に入る。
フィードバック
アジャイルの規律は、重大な意思決定をする人たちに高速なフィードバックを提供することが目的。計画ゲーム、リファクタリング、テスト駆動開発、継続的インテグレーション、小さなリリース、共同所有、チーム全体は、フィードバックの頻度と量を最大化する。フィードバックがあることで、チームは効果的に働ける。
シンプリシティ
シンプリシティとは、直接的なこと。コードを直接的にする。コミュニケーションや行動も直接的にする。間接的なものは、相互依存等の複雑さを軽減するための最小限にする。
世の中に無数にアジャイル手法が存在しているが、どの手法を選んでも、自らのニーズに合わせて調整するので、最終的には同じ場所にたどり着く。その中でも、完全なるサークルオブライフを採用すべき。
サークルオブライフを対応できるようにチームに同意してもらう。勇気、コミュニケーション、フィードバック、シンプリシティを忘れずに、定期的に規律と行動を調整していこう。
この記事が気に入ったらサポートをしてみませんか？