Sprint Execution

すぐさま強引に実行する良い計画のほうが、来週の完璧な計画よりも優れている。

- ジョージ・Sパットン将軍

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

- トーマス・エジソン

実行の概要

SAFeでは、1つの反復(スプリント)が2週間という固定的な時間枠(タイムボックス)を持つ。標準的なスクラムと同様に、アジャイルチームは、この2週間のうちにスプリントバックログから個々の項目を取り出し、定義/構築/テストを行い、システムのベースラインに入れる。可能な限り最高のコード品質を広く確保するため、チームはXPなどの品質プラクティスを適用する。また、目に見える大きな情報発信板を用いて、チームは作業を可視化し、最適的なスループットが得られるように、WIP(仕掛かり作業)制限を適用する。

アジャイルリリース列車(ART)は、共通のPI目標に複数のチームやスプリントのベクトル合わせをさせる。各スプリントはアジャイルリリース列車のコンテキストで実施され、チームデモとシステムデモで終了する。チームデモやシステムデモから、チームとARTの運行、途中の是正措置のために必要となる迅速なフィードバックが得られる。スプリントを実行するため、継続なコミュニケーション、同期とソフトウェアの職人技能は必要となる。

詳細

迅速な価値の納品に注力するように個別のアジャイルチームに権限を委譲することで、エネルギーや動機、目的及び従来のプロセスやガバナンスモデルよりよい使命感がチームにもたらされる。ただし、チームは自然に局所最適化に陥る傾向があり、自分が担当する利害関係者にフィーチャーを納品することに注力してしまう。SAFeでは、共通目的に対して継続的にチームのベクトル合わせをし、プログラムの実行を最適化することにシステム全体が注力できるようにする。これを実現するため、SAFeの各チームはアジャイルリリース列車のコンテキストで活動し、アジャイルリリース列車PI目標に向かって意図的にチームを連携させる。このページでは、このより大きな目的のコンテキストにおけるスプリントの実行についてのガイダンスを提供する。

ベクトル合わせと同期

チームによる結合、評価、チームデモ/システムデモにおけるチームによるデモのため、アジャイルリリース列車内の全てのチームは同じリズムと同じスプリント期間で作業を同期できるようにする。スプリントを成功させるための要因は以下である:

  • 不断のコミュニケーション:文書化と引き継ぎを最小化にする
  • 日次の同期:作業を連携するための15分のデイリースクラム
  • ストーリーの定義-構築-テストをシリアルに行う:ミニウォーターフォールを避ける
  • コード品質:: テストファースト開発や継続的なインテグレーションリファクタリングなどXPから取り入れたプラクティスと、 アジャイルアーキテクチャーによって達成する
  • 仕掛かり作業を管理するフローを最適化し、共同所有を促進し、タスクの切り替えによるオーバーヘッドを最小限にする

環境とコミュニケーション

チームが協力し合うには、オープンな環境と、チームが同じ場所にいることが重要である。そうしないと、疑問や仮定により遅延が生じ、それがそのまま価値納品の遅延を引き起こす。チームが分散している場合、ウェブカメラやインスタントメッセージなどの協力のためのツールを常に「オン」の状態にし、ダイヤルトーンによる接続性を確立する。

チーム内

デイリースクラム – 毎日、チームが同じ時間、同じ場所で以下の質問に答えることによって、作業の連携を行う

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

チームの同期と自己組織化を行うには、デイリースクラムが重要である。スプリントの目標に関わるストーリー(タスクではない)がハイライトされた、大きな誰でも見える情報発信板(BVIR、図3)の前でデイリースクラムを行う方法が最も効果的である。デイリースクラムは15分の時間枠内で行わなければならない。これは、問題解決ミーティングではなく、課題、依存関係を識別し、会話するのための主要な仕組みである。スクラムマスターはさらに議論しなければならないトピックを「ミートアフター」ボードに書き留める。ミートアフターには関係者だけが残って議論する。効果のないデイリースクラムはより深い問題がある兆しである。このような問題に対処するため、スクラムマスターによる組織的なアプローチを促進しなければならない。

チーム間

スクラム・オブ・スクラムズ(SoS) – プログラム進捗の可視化、障害と依存関係の識別、リスクへの対処を行うために、スクラムマスターとリリース列車エンジニアがSoS会議を開く。一般的に、SoSは30-45分の時間枠で週に2回開催する。(デイリースクラムと同様に)会議後に、問題解決のためのミートアフターも開催する。この会議には生じた課題を解決するチームの任意の人が必要に応じて参加する。

他のチームと協力し合う – SAFeにおけるチームは孤立した島ではない。以下のようなプログラムのイベントや他のスクラムチームの儀式への参加によって、チームや個人が作業を連携する

  • バックログの手入れ: 次のスプリントに何が来るかを理解する
  • スプリント計画:: 要求の調整
  • デイリースクラム: 実行と連携のフォローアップ
  • チームデモ: 進捗を確認し、要求を調整する
  • システムデモ: 作業を結合する

アジャイルチームは自分たちのコードを他のチームのコードと高い頻度(1スプリントで少なくとも数回。目標は毎日)で結合し、システムチームと一緒に自動化されたシステムレベルのテストを行い、他のチームの依存関係をよりよく管理するためにシステムアーキテクチャーと作業する。

定義-構築-テスト-結合のストーリーのサイクル

有効な「SAFeスクラムXP」チームは、複数の定義/構築/テストのサイクルでスプリントのスコープを実現する。これによって、チームは仕掛かり作業(WIP)を制限することができ、ミニウォーターフォールを防止することができる。

スプリントをウォーターフォール化しない

チームはスプリントをウォーターフォール化する傾向を避けなければならない。代わりに、図1に示すように、確実にスプリント中に複数のDBTサイクルを完了させる。

Figure 1. Avoid Waterfall with Cross Functional Sprints

図1. 機能横断的なスプリントでウォーターフォールを避ける

スプリント内のインクリメンタル開発

図2に示すように、ストーリーを薄く縦に切り分けて実装していくことは本当のインクリメンタル開発、結合とテストのための土台である、これによって、短いフィードバックのサイクルが実現できるし、チームは動作するソフトウェアのより小さな塊に対して作業を行い、継続的なシステム全体の結合やテストを行うことができる。また、チームメンバーの機能性に対する理解が深まり、動作するソフトウェアに関するより頻繁なペア作業と結合が促進される。依存する側のチームがすぐに新しい機能性を使用するため、列車内や列車間の依存関係がより効果的に管理できる。これは、不確実性を低減すること、アーキテクチャーと設計に関する意思判断を妥当性検証すること、早期の学習と知識を共有することに役に立つ。

Sprint Exe Figure 2

図2 ?ストーリーを縦のスライスで実装することが重要である

コード品質のプラクティス

アジャイルリリース列車で開発を行うには、チームは、持続可能な最も早いリードタイムで新しい機能を作成および納品し、予測可能なプログラムベロシティーを高めるために品質の高いコードを作成する必要がある。SAFeでは、非常に大きなソフトウェアシステムであってもコード品質の向上に著しく貢献する、6つの包括的なアジャイルソフトウェアエンジニアリングプラクティスを推奨している。

システムインテグレーション

システム全体の継続的なインテグレーションは重要なソフトウェアエンジニアリングプラクティスの一つである。これによって、チームがスケールアップできるようになり、頻繁に成功したシステムビルドを作り上げることができる。結果として、スプリントの時間枠の終了時に、価値のあるシステムインクリメントが作成できる。システム全体を継続的にインテグレーションしなければ、実績に基づくメトリックス(例:プログラムベロシティーなど)の概念を活用したり頻繁に納品することは不可能である。

テストとテストの自動化

テストファーストの考えはテスト駆動開発(TDD)と受け入れテスト駆動開発(ATDD)に分けられる。両方がテストの自動化によってサポートされる。また、テスト自動化ではシステム全体の継続的なインテグレーション、チームベロシティーと開発効率をサポートしなければならない。

主にXPから取り入れたテスト駆動開発では、開発者はまず自動化された単体テストを作成し、実行し、失敗する。次に、テストに合格するために必要最小限のコードを書く。受け入れテスト駆動開発はより高度なプラクティスである。受け入れ可能なシステムの振る舞いに関する基準がプロダクトオーナーによって承認され、それが自動化された受け入れテストに変換される。システムが進化するとともにこれらのテストを繰り返し実行することによって、継続的なシステムの整合性を確保する。

フローの実現

スプリントの追跡

反復におけるストーリーや欠陥の状態、チームが行った他の作業の状況を可視化しなければ、スプリントの進捗を追跡することができない。数多くのチームはチームの部屋の壁に大きな情報発信板(BVIR)を用いて可視化を図る。図3は1つの例である。チームは毎日のデイリースタンドアップの前に、BVIR上にある「リボン」を今日の位置に移動する。これによって、チーム全員が反復のどこにいるのか視覚的に理解しやすくなる。図3の場合、リスクがあることがすぐわかるだろう。チームがスプリントを無事に完了させるために必要なことを可視化できる。もし離れた場所にいる参加者や主要な利害関係者が状況の情報をほしがれば、現時点の写真を取り、メールでの送付やWikiでの共有が簡単にできる。ほとんどの企業レベルのアジャイルチームは、進捗と状況を共有するために、BVIR以外に、アジャイルプロジェクト管理ツールを利用する。

Figure 3 - Tracking Progress with a BVIR

図3 BVIRを利用し進捗を追跡する

WIPの管理

WIP制限を導入すると、処理能力とのマッチングが必要になり、フローが増す。スクラムXPチームは自分たちの作業を計画し、ベロシティーを基にスプリント中に達成できると判断した量のストーリーだけを引き受ける。こうすることで、インプット速度(交渉されたスプリントゴール)が処理能力(チームのベロシティー)と一致する。ストーリーが完了したかどうかに関わらず、スプリントの時間枠の終了時にスプリントが完了となるので、スプリントの時間枠のおかげで作業が膨らんで制御できなくなる状況を避けられる。グローバルのWIPプールは、エンタープライズバックログにあるフィーチャーやエピックからなり、ローカル(チーム)のWIPプールによって制限される。チームのWIPプールは現在のPIによって促進したチーム現在のバックログを反映する。新しい、より高い優先順位の活動に関するより速いレスポンス時間がWIPを制限することによって改善する。

例えば、図3の場合、WIP制限がなければ、開発者はストーリー5を完了した後に何をするだろうか。おそらく新しいストーリーに着手するだろう。「進行中」、「テスト」にそれぞれ3ストーリーのWIP制限を設けている場合、開発者は代わりにストーリーのテストを行わなければならない。それによりスループットが向上する。WIP制限によって、ソフトウェア開発のボトルネックを防ぎ、プロダクト開発フローを大いに改善する戦略が提供される。また、焦点が定まって情報共有が改善し、共同所有が促進される。すべてのSAFeチームは確実に自分たちのWIPとフローを理解しなければならない。

ストーリーの受け入れ

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

 


さらに知りたい場合

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

The information on this page is © 2010-2014 Leffingwell, LLC. and is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.

Last updated 15 July, 2014