【アジャイル】書籍「Clean Agile」より「小規模開発のアジャイルプラクティス」
book_cleanagile_practice
スポンサーリンク

Clean Agile 基本に立ち戻れ

書籍「Clean Agile 基本に立ち戻れ」から分かるアジャイルのプラクティスのポイントをまとめます。

アジャイル開発 プラクティス編

本書は「小さなことをする、小さなソフトウェアチームがうまくやっていくために!」という副題のとおり、小規模な開発チームにおける様々なプラクティスについてまとめられた本です。
ここではアジャイル開発における立場やプロセスごとのプラクティスについて詳しく説明します。
前回の記事で紹介した、下図のサークルオブライフを基準に説明します。

前回の記事はこちらです。

書籍「Clean Agile」より小規模開発のアジャイル入門

ポイント

サークルオブライフ

サークルオブライフ

サークルオブライフは3つのリングに分割できます。外側のリングから内側へ向かって順にそれぞれについて解説します。

外側のリング

最も外側にあるリングは、ビジネス向けのプラクティスです。これはスクラムのプロセスに相当します。
チームとビジネス側とがコミュニケーションするためのフレームワークと原則を提供します。

サークルオブファイル(外側)
計画ゲーム
プロジェクトを機能・ストーリー・タスクに分割する方法と、それぞれの見積もり、優先順位付け、スケジューリングのガイダンスを提供します。

見積もりは細かく細分化するほど精度を上げることができるのは明らかです。しかしその代償として時間がかかります。不正確にすべきではありませんが、見積もりのコストは抑えたいと考えます。
有効な技法として「三点見積り」があります。この見積りは、「最良ケース」「最有力ケース」「最悪ケース」の3つの数値で構成されます。これらの数値は信頼性のより見積もられます。これはPERT法として調べると詳しい情報が得られるでしょう。
しかしながら三点見積りは長期のプロジェクトには有力ですが、プロジェクト内部のマネジメントで使うには精度が悪すぎるため、「ストーリーポイント」を用いるとよいということです。

ユーザー視点での機能であるユーザーストーリーに対し、具体的な時間の工数ではなく、相対的な見積りをするための架空の単位がストーリーポイントです。
本書ではATMのシステム開発を例に、ログイン、ログアウト、引き出し、預け入れ、送金のストーリーを挙げています。そのうち「ログイン」を基準のストーリーとして3ポイントとし、「ログイン」より簡単と思われる「ログアウト」には1ポイント、2倍難しいと思われる「引き出し」には6ポイントを設定しています。
つまり見積り時間ではなく見積り労力ということです。

ひとつのイテレーション(スプリント)でチームがこなせる合計のストーリーポイントをベロシティと呼びます。
イテレーションとは、前回の記事で紹介していますが、納期に対して定期的な期間に分割したものです。規模によりますが、2週間〜1ヶ月程度で区切るのがちょうど良いとのことです。
もちろん最初のイテレーションでベロシティを決めることはできませんので、推測値から始め、イテレーションを繰り返しながら精度をあげることになるでしょう。

イテレーションに中間地点を設け、完成具合をチェックすることも必要です。ベロシティを30ポイントと設定したのであれば、中間地点では15ポイント完成している必要があります。しかし、ここで15ポイントより前後するようであれば、ベロシティを見直す必要があるということです。

なお、ストーリーポイントには、フェボナッチ数列のように「1、2、3、5、8、13、20、40」のような値を設定することが多いそうです。
しかし、ユーザーストーリーは1〜2人の開発者が1回のイテレーションで実装できる大きさを超えてはなりません。ストーリーが大きい場合にはさらに分割する必要があります。そしてそこに技術的な調査が必要だったとしても、その調査も1つのストーリーとして扱います。このストーリーを見積もるためのストーリーをスパイクといいます。

ストーリーの完成の定義は受け入れテストにパスすることです。本書ではQAと表現されていますが、規模により品質管理部門によるチームからテストエンジニアと個人の場合まであるでしょう。ストーリーは実装完了時点で随時受け入れテストがされるべきであるため、ストーリーはテスト可能な単位である必要もあります。

イテレーションの終わりにはやるべきことがあります。
ひとつにはデモです。ステークホルダーに簡単なデモを実施し、進捗を確認してもらうことです。
もうひとつは、ベロシティとバーンダウンチャートの更新をすることです。バーンダウンチャートは、時間を横軸に、未完了のストーリーポイントを縦軸にグラフ化したものです。
イテレーションの間、ベロシティのポイントから0に向かって右肩下がりにプロットされるはずチャートです。
そして次のイテレーションに備えてベロシティやポイントの基準などの見直しを行います。

小さなリリース
小さな単位で作業するようにチームをガイドします。

ここでのプラクティスは、開発チームはできるだけ頻繁にソフトウェアをリリースすべきということです。
アジャイルの黎明期には「1〜2ヶ月」ごとにリリースすべきとされてきましたが、現代ではさらに短い目標を設定します。それが継続的デリバリーです。現代ではGitを使用することで、いつでもコミットし、変更からデプロイまでの障壁は昔に比べかなりなくなっているといえます。そこにすべてをテストできる包括的で高速なテストスイートがあれば、継続的デリバリーは実現的になります。

受け入れテスト
機能・ストーリー・タスクの「DONE」の定義を提供します。明確な完成基準の設定方法をチームに示します。

受け入れテストのプラクティスは、最も理解され難く、最も使われておらず、最も混乱させるものだといいます。それはビジネス的な要求を仕様化することがあいまいなケースが多いからです。
仕様が詳細に決まれば、機械が検証することができるはずです。ここが受け入れテストのプラクティスです。
システムの要求はできるだけ自動テスト化すべきです。
イテレーションの始めには既にビジネスアナリストとQAによってストーリーのテストを作成し、継続的ビルドの中で、プログラマーがテストを実行することでスムーズに受け入れテストが実施されることになります。

チーム全体
さまざまな職種(プログラマー、テスター、マネージャーなど)が共通のゴールを目指して協力するという考えを示します。

チームには様々な役割があります。プログラマーはもちろん、マネージャー、テスター、テクニカルライター、プロダクトオーナーとなる顧客もその一員です。
コミュニケーションの観点からもチーム効率を最大にするには、すべてのメンバーが同じ空間にいるのが理想です。
リモートがうまくいかないというわけではありませんが、同じ空間であればもっとうまくやれたはずといえるということです。


中間のリング

中間にあるリングは、チームのプラクティスを示します。
開発チームがチーム内やマネージャーとコミュニケーションするためのフレームワークと原則を提供します。

サークルオブライフ(中間)
メタファー
チームとビジネス側がシステムについてコミュニケーションするための語彙や言語を作成し、広めるためのプラクティスです。

チームが効果的にコミュニケーションするためには、制約と規律を持つ用語や概念が必要です。
プログラマーだけでなく、QA、マネージャー、顧客、ユーザーを含めた全員が合意できる語彙を使うべきです。ドメイン駆動設計でユビキタス言語と呼ばれる用語でもあります。
決してチーム独自の用語を使用せず、共通語となる用語を設定しましょう。

持続可能なペース
開発チームがリソースをすぐに消費してしまい、ゴールの前で力尽きないようにするためのプラクティスです。

ソフトウェアプロジェクトはスプリント(短距離走)ではなく、マラソン(長距離走)です。
著者がアジャイルの定期的な期間をイテレーションと表現し、スクラムの用語であるスプリントという表現を嫌うのもこのことからです。
長期にわたって持続できるペースで走らなければなりません。ペースを上げてゴールライン手前でスローダウンしてしまえば、平均速度は遅くなります。
残業は顧客や雇用主へ献身さを示すことにはなりません。残業はあくまで緊急時に限ります。
十分な睡眠を確保し、持続可能なペースを心がけましょう。

共同所有
チームに知識の断絶が起きないようにするためのプラクティスです。

アジャイルプロジェクトでは誰もコードを所有しません。共同で所有します。
これは何も全員がすべてを理解しましょうということではありません。専門性は必要です。
しかし、全体や他の分野を把握することができる環境であることが重要です。
クローズドなことでもっとも悪質なのは、コードの重複です。
別々に同じようなコードを書いていれば効率は悪くなってしまいます。

継続的インテグレーション
チームが現在地を常に把握できるよう、フィードバックを繰り返すことにフォーカスするプラクティスです。

継続的インテグレーション(CI)とは、すべての開発者の作業コピーを定期的に共有されたメインラインにマージすることです。1日に数回行われるのが一般的です。
今では継続的ビルドツールが充実してきており、導入もしやすいでしょう。
継続的ビルドは絶対に壊してはならず、プログラマーは自らの変更コードをメインラインであるマスタービルドとローカルでマージしビルドおよびテストを事前に試すことです。それにより、プッシュ後のマスタービルドでの失敗可能性を下げることができます。


なお、アジャイルでは毎日の「デイリースクラム」や「スタンドアップミーティング」というものがあります。
このミーティングは毎日より頻度が低くても構いませんが、どんなに大規模なチームでも10分以内に収めるべきです。
その場でやることは、チームが円になって以下の3つの質問に答えることです。

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

開発者以外のマネージャーやその他の人が参加しても構いませんが、ミーティングには介入すべきではないということです。

最も内側のリング

最も内側にあるリングは、最高の技術品質を保証するために、プログラマーをガイドおよび強制するための技術プラクティスを示します。

サークルオブライフ(内側)
テスト駆動開発
技術チームが高品質を維持しながらすばやく進むための命綱です。

テスト駆動開発(TDD)とは、テストファーストなプログラムの開発手法です。つまり、プログラムの実装前にテストコードを書き、そのテストコードに適合するように実装を進めていく方法です。

テスト駆動開発には3つのシンプルなルールがあります。

  • 失敗するテストを書くまでメインのコードを書かない
  • 失敗するテストを必要以上に書かない(コンパイルを失敗させるなどやりすぎない)
  • メインのコードを必要以上に書かない(失敗したテストをパスさせる目的にならないようにする)

プログラマーは、テストを書いてからでなければ、その対になるメインのコードが書けません。
これは一見不便に思えるかもしれません。しかし、デバッグには大きく貢献するはずです。
バグが発見されたときに、少し前にはバグがなかったことが保証されるからです。バグの原因を追加したコード部分に絞り込むことができます。

また、ひとつひとつのテストコードはサンプルコードとなりドキュメンテーションにも貢献します。
テストのしやすさを考慮することでメインの設計の質も上がります。
そしてテスト機構があれば、古いコードや他人のコードを変更する抵抗が下がります。

こうしてTDDを実践すれば、コードの秩序を保ち、クリーンにする勇気を与えてくれます。

リファクタリング
すべての作成物の継続的な改善と改良を促進します。

リファクタリングとは、「テストで定義された振る舞いを保ちつつ、コードの内部構造を改善する」プラクティスです。これはテストを壊すことなく、名前、クラス、関数、式などを変更することで、TDDと強く結びついています。

リファクタリングは規模の大小に関わらず、特別に時間を確保することはせず、通常のアジャイルのサイクルの中で行います。継続的に新機能を追加しながら、小さなステップで少しずつコードを移行していきます。

シンプルな設計
チームがムダなことをしないようにガイドするためのプラクティスです。

シンプルな設計はリファクタリングのひとつでもあります。
シンプルな設計にはルールがあります。

  1. すべてのテストをパスさせる
  2. 意図を明らかにする
  3. 重複を排除する
  4. 要素を減らす

上から優先に、コードの設計のウェイトを可能な限り減らすことが重要です。
設計が複雑になれば、プログラマーにかかる認知的負荷が大きくなり、必要な時間や労力も増えます。

ペアリング
革新性と正確性を促進するレベルで、技術チームが知識の共有、レビュー、協力ができるようになるためのプラクティスです。

ペアリング(ペアプログラミング)は2人が一緒に同じプログラミングの課題に取り組むことです。
これはペアになることを強制するわけではありませんが、知識を共有し、孤立化を防ぐことに役立ちます。
また多くのチームがペアリングによってエラーが減少し、品質が向上したと報告しています。

コストについては、もちろん増えることにはなるが、ペアリングはコードレビューの代わりにもなり、クロストレーニングの側面から単純に算出することはできません。すべてのコーディングをペアにする必要はないため、プロジェクトに応じて30%、50%、80%と設定すればよいでしょう。

まとめ

アジャイルは、「ビジネスと開発の分断を修復すること」が目標だとされました。
しかし、ステークホルダーとプログラマーのベクトルがずれたり、アジャイルのプロセスだけが独り歩きしたり、当初の目的から外れてきたということです。アジャイルのコーチング役であるスクラムマスターは後からできた無意味なものだと著書ではいいます。認定資格もあるらしいがそもそも特定の人物だけをトレーニングすること自体が間違いで、チーム全体のトレーニングこそ必要だということです。

本書の副題にもあるとおり「基本に立ち戻れ」のとおり、アジャイルの基本的かつ本質的なところを理解するには非常に有用な著書であることがわかります。


目次

  1. アジャイル入門
    • アジャイルの歴史
    • スノーバード
    • アジャイルの概要
    • サークルオブライフ
    • 結論
  2. アジャイルにする理由
    • プロフェッショナリズム
    • まっとうな期待
    • 権利章典
    • 結論
  3. ビジネスプラクティス
    • 計画ゲーム
    • 小さなリリース
    • 受け入れテスト
    • チーム全体
    • 結論
  4. チームプラクティス
    • メタファー
    • 持続可能なペース
    • 共同所有
    • 継続的インテグレーション
    • スタンドアップミーティング
    • 結論
  5. テクニカルプラクティス
    • テスト駆動開発
    • リファクタリング
    • シンプルな設計
    • ペアプログラミング
    • 結論
  6. アジャイルになる
    • アジャイルの価値基準
    • 動物のサーカス
    • トランスフォーメーション
    • コーチング
    • 認定資格
    • 大規模アジャイル
    • アジャイルのツール
    • コーチング(もうひとつの視点)
    • 結論(再びボブから)
  7. クラフトマンシップ
    • アジャイルの二日酔い
    • 期待の不一致
    • 開発者のアジャイル離れ
    • ソフトウェアクラフトマンシップ
    • イデオロギーとメソドロジー
    • ソフトウェアクラフトマンシップにプラクティスはあるか?
    • プラクティスではなく価値にフォーカスする
    • プラクティスの議論
    • クラフトマンシップが個人にもたらすインパクト
    • クラフトマンシップが業界にもたらすインパクト
    • クラフトマンシップが企業にもたらすインパクト
    • クラフトマンシップとアジャイル
    • 結論

【内容情報】
小さなことをする、小さなソフトウェアチームがうまくやっていくために!
アジャイルとは、小さなことをしている小さなプログラミングチームの小さな問題を扱う小さなアイデアである。アジャイルとは、大きなことをしている大きなプログラミングチームの大きな問題を扱う大きなアイデアではない。
大きなことは大きなチームなんかじゃできない。小さなことをする小さなチームがいくつも集まり、コラボレーションしながら大きなことを成し遂げるのだ。
このことを、我々はあらためて認識する必要がある。

【著者情報】
Robert C.Martin
Robert C. Martin(アンクル・ボブ)は、1970年からプログラマーである。
cleancoders.comの共同創業者であり、ソフトウェア開発者向けの学習用動画をオンラインで提供している。
また、Uncle Bob Consulting LLC.を設立し、世界中の大企業を対象としたソフトウェアコンサルティング、トレーニング、スキル開発を行っている。
シカゴに本拠地を置くコンサルティングファーム8th Light, Inc.では、Master Craftsmanを務めていた。

Clean Agile 基本に立ち戻れ 内容紹介より

Amazonで買う
紙の本を買う
Amazonで買う
電子書籍を買う
hontoで買う
紙の本を買う
hontoで買う
電子書籍を買う

スポンサーリンク

Twitterでフォローしよう

おすすめの記事