反復の実行

実行の伴わないビジョンはただの幻想である。

─トーマス・エジソン

反復の実行の概要

アジャイルチームはただ1つのことに集中する。効果的で高品質な、テストの済んだ動くシステムのインクリメントを開発することである。そしてそのすべてを1つの短い時間枠の中で行う。これは、すべてのリーン-アジャイルチーム、プログラム、価値のストリーム、ポートフォリオ、企業に課された基本の課題である。どれだけ準備をしても、どれだけ計画を立てても、効果的に反復の実行が行われなければ、規模の拡大はほとんど不可能だし、ソリューションの品質も妥協せざるをえない。マイナスのビジネス効果を誰もが感じることになる。

このページでは、有能なアジャイルチームが反復の時間枠を通じて作業をどう管理するかの指針を、個々のチームの視点とアジャイルリリース列車のメンバーとしての視点の両方から説明する。

反復のあいだ、チームは緊密に協力しながら、反復計画の策定時に確約したストーリーの定義、構築、テストを行う。そしてそのすべてをチームデモでデモする。ストーリーやカンバンボードやデイリースタンドアップミーティングを使って、反復の進捗を追跡し、価値のフローを改善する。反復全体を通じてストーリーを納品し、時間枠を「ウォーターフォール化」させないようにする。プラクティスや課題について振り返って検討し、インクリメントごとに小さい改善を行う。同じ列車の他のチームと効果的に協力する。品質の作り込みを行って大きなシステムを正しく構築する。大変な仕事だが、有能なアジャイルチームには可能である。

詳細

アジャイルチームに権限を与えて迅速な価値の能品に集中させることで、従来の管理/開発モデルでは手の届かなかったレベルのエネルギー、動機、目的、使命感がチームにもたらされる。こういった利点すべての中心にあるのが、各反復の効果的な実行である。チームはこの結果を得るためにさまざまなプラクティスを導入するが、その目的は常に同じで、反復計画策定時に確約したストーリーを納品して反復のゴールを達成することである。

しかし、ローカルで効果的に反復の実行を行うだけでなく、チームはもっと大きな、プログラムの実行(SAFeの4つの中心的価値の1つ)を最適化するという目的に組み込まれている。これを達成できるよう、チームはアジャイルリリース列車(ART)のコンテキストで仕事をする。ARTは、合意済みのチームおよびプログラムのPI目標に向かって、チームの足並みを揃える。全チームの反復のリズムと期間を揃えることで、統合、評価、チームデモおよびシステムデモ時のチームによるデモに向けて、作業を同期させることができる。

反復の実行を成功させるための主な要因を以下に挙げる。

  • 反復の進捗管理:ストーリーボードやカンバンボードを使って反復の進捗を管理する。
  • シリアルかつインクリメンタルなストーリーの構築:ミニウォーターフォールにならないよう、ストーリーをインクリメンタルに構築する。
  • 不断のコミュニケーション:チームでデイリースタンドアップミーティングを行って、常にコミュニケーションと同期を行う。
  • フローの向上:WIPを管理し、品質を作り込み、継続的にストーリーを受け入れることで、フローを最適化する。
  • プログラムの実行:ART全体で協力してプログラムのPI目標を達成する。

反復の進捗管理

反復の進捗を管理するには、ストーリーや不具合などチームが反復中に行う作業の状況を、可視化する必要がある。そのために、ほとんどのチームは、チームの部屋の壁に大きな見やすい情報発信板(big visible information radiator:BVIR)を作る。カンバンチームはカンバンボードを使用するし、スクラムXPチームはおそらく図1のようなストーリーボードを使用するだろう。

図3.  BVIRによる進捗管理

 

この単純なストーリーボードで、赤いリボンを当日の位置に移動していく。こうすることで、チームが反復内のどこにいるかを目に見える形で理解できる。(図1の反復の危機的な状況が明らかになっていることに注目してほしい。)チームは、この情報をもとに、反復を成功裏に終わらせるためには何が必要かを議論することができる。離れた場所にいる参加者や主要な利害関係者が状況を知りたがった場合には、ウェブカメラで共有したり、メールで送付したり、Wikiで共有したりすることができる。もちろん、規模が大きい場合には、ほとんどすべてのアジャイルチームが最新のアジャイルプロジェクト管理ツールを使って、ストーリーや状態、不具合、テストケース、見積もりと実際、割り当て、バーンダウンなどを把握する。しかしこれは通常、BVIRに追加して使われる。

不断のコミュニケーション

チームが協力し合うには、オープンな環境と、チームが同じ場所にいることが重要である。そうでないと、疑問が生じたり想定に基づいて作業を進めてしまうことで遅延が生じ、それがそのまま価値納品の遅延につながる。最悪の、チームが分散している状況では、ウェブカメラやインスタントメッセージなどのコラボレーションツールを常に「オン」の状態にして、オープンなコミュニケーション環境を構築する。

デイリースタンドアップ(DSU):毎日、同じ時間、同じ場所にチームが集まって、各メンバーに以下の質問をすることによって、作業の連携を行う。

  • 昨日、どのストーリーの作業を行ったか(作業状況はどうだったか)
  • 今日、どのストーリーを完了できる予定か
  • 作業の進行を妨げているものは何か(手詰まりになっていないか)

チームの同期と自己組織化を行うにはDSUが重要である。これは、反復の目標であるストーリーが明示されたBVIRの前で行うのが最も効果的である。DSUは必ず15分の時間枠内で行わなければならない。また、これは問題解決のためのミーティングではない。主に課題や依存関係や話し合わなければならないことを識別するための仕組みであり、その多くは後で対処する必要がある。スクラムマスターは、別途議論しなければならないトピックを「ミートアフター」ボードに書き留める。ミートアフターには関係者だけが残って議論する。DSUの効果がないのはより深い問題が存在するしるしなので、系統だった対策が必要である。それを進めるのもたいていはスクラムマスターの責任である。

注:DSUはスクラムの要素だが、多くのカンバンチームでもカンバンボードの前でDSUを行って、調整をしたり、ボトルネックやWIPの問題がないかをボードで確認したりする。

フローの向上

WIPを管理する

WIP制限は、開発のボトルネックを防ぎ、フローを向上するための戦略となる。また、焦点が定まって情報共有が改善し、共同所有が促進される。すべてのSAFeチームは自分たちのWIPとフローをしっかりと理解しなければならない。

カンバンチームは明示的にWIP制限を適用する。スクラムXPチームもWIP制限を使用する。この場合は明示的でも暗黙的でもかまわない。たとえば、チームが自分で作業を計画し、自分のベロシティーで達成可能だと予測できる量のストーリーだけを引き受ける場合は、暗黙的に使用していることになる。こうすると、入ってくる速度(取り決めた反復のゴールやストーリー)と処理能力(チームのベロシティー)がつりあう。反復の時間枠が決まっていることでもWIPが制限される。作業が制限なく拡大することを防げるためである。

スクラムXPチームがストーリーボードに明示的にWIP制限を適用することもある。たとえば、上の図1でWIP制限がない場合、ストーリー5を完了したら、開発者はその後に何をするだろうか。おそらく別のストーリーに着手するだろう。しかし、「進行中」および「テスト」の段階に3というWIP制限が設けられていると、開発者はストーリーのテストを手伝わなければならなくなり、スループットが向上する。WIP制限の詳細は、SAFeの第6原則のページを参照のこと。

品質を作り込む

アジャイルリリース列車は、持続可能な最も早いリードタイムで新しい機能を作成し納品する。そのためには、開発ベロシティーが予測可能になる高品質なシステムを作成しなければならない。SAFeでは、非常に大きなソリューションにおいても品質の作り込みに大きく貢献する、品質とエンジニアリングに関する5つのプラクティスを規定している。テストファースト、継続的インテグレーション、リファクタリング、ペアワーク、共同所有の5つである。最初から確実に品質を作り込むことで、より早く、より容易に、コストを抑えて、価値を納品することができる。

継続的にストーリーを受け入れる

継続的にストーリーを受け入れるとフローが向上する。(ここでもう一度、フローがうまくいっていない図1の反復の状態を見てほしい。開始して6日が経っているが、受け入れが済んだストーリーは1つだけである。)チームは、チームデモの日を待たず、準備ができしだい、ストーリーのデモを行う。受け入れられなかったストーリーに関しては、再作業を行う。こうすると、問題に素早く効率的に対処でき、動かないストーリーを使って新しいストーリーを構築することがなくなり、コンテキスト切り替えが発生するのを避けることができる。

テストを自動化する

可能であれば、プロダクトオーナーやその他のアジャイルチームメンバーが作成した受け入れ可能なシステムの振る舞いの基準を、ストーリーの受け入れテストに変換する。それを繰り返し実行することで、システムが進化しても使用適合性やシステムの整合性を変わらず確保することができる。自動化するとシステムの回帰テストを迅速に実行することもでき、それによってシステム全体の継続的なインテグレーションや、リファクタリングや、保守を強化できる。これらのテストは、ビジネス側にも理解可能な、ドメイン固有の言語で作成されることが多いため、システムの「自動的に実行可能な仕様兼テスト」を作成することになる。

シリアルかつインクリメンタルなストーリーの構築

反復内の「ウォーターフォール化」を避ける

反復は「ウォーターフォール化」しがちなので、チームはそれを避けなければならない。代わりに、図2に示すように、1つの反復の中で「定義-構築-テスト」のサイクルを複数回実施する。

図2.  機能横断的な反復を実施してミニウォーターフォール化を避ける

インクリメンタルにストーリーを構築する

ストーリーを縦に薄く切り分けて実装することは、本当の意味でインクリメンタルな開発と統合とテストを実施するための基本である。その様子を図3に示す。

図3.  インクリメンタルな開発をするにはストーリーを縦に切り分けて実装することが重要である

これによって、短いフィードバックサイクルが実現でき、チームは動くシステムの小さなインクリメントを対象として継続的に統合やテストを行うことができる。また、アジャイルチームメンバーの機能の理解が深まり、動くシステムについてより頻繁にペア作業や統合が行われるようになる。依存する側のチームがすぐに新しい機能を使用できるため、チーム間やさらには列車間の依存関係をより効果的に管理できる。これは、不確実性を低減すること、アーキテクチャーと設計に関する意思決定の妥当性を検証すること、早期の学習と知識共有を促進することに役立つ。

プログラムの実行の重視

反復を成功させることは重要だが、全チームの最終目標は、プログラムインクリメントの実行を成功させることである。局所最適化だけに集中するのを避けるために、SAFeのチームは、図4に示すように、一緒に計画を立て一緒に統合とデモを行い一緒に学習する

図4.  チームは一緒に計画を立て、一緒に統合とデモを行い、一緒に学習する

チームが一緒に仕事をしてプログラムインクリメントを成功させるためのプラクティスについては、アジャイルチームのページで詳しく説明する。


さらに知りたい場合

[1] Leffingwell, Dean.Agile Software Requirements:Lean Requirements Practices for Teams, Programs, and the Enterprise.Addison-Wesley, 2011.(邦訳:アジャイルソフトウェア要求:チーム、プログラム、企業のためのリーンな要求プラクティス、翔泳社、2014)

Last updated 15 October 2015