反復

私の発明の中に、偶然生まれたものなどない。満たす価値のあるニーズに気付き、試行錯誤を重ねて作り上げるのだ。

─トーマス・エジソン

反復の概要

反復は、アジャイル開発の基本となる構成要素である。各反復は、固定期間の時間枠であり、その枠の中で、ビジネス機能やプロダクト機能のインクリメンタルな要素が構築される。SAFeの2週間の反復は、フィーチャーやコンポーネントを構築するアジャイルチームの基本的な開発リズムとなる。この短い期間の間に、チームは、そのチームの反復バックログに含まれるストーリーを実行し、その成果を他のチームの成果と統合し、システムデモの準備をしてデモに参加する。各反復の後には次の反復が続き、それが継続的に価値を開発し配置する基本のテンポとなる。

反復のリズムはSAFeの第一のリズムだが、SAFeでは、短い反復が複数まとまって長いプログラムインクリメント(PI)の時間枠になるという、ネストした構造も用意されている。この時間枠が外側のリズムとなって、アジャイルリリース列車(ART)上のすべてのチームが一緒に計画を立て一緒に統合とデモを行い一緒に学習することができる。

詳細

素早い学習がSAFeの学習サイクルの主要目的なので、アジャイルチームは、図1に示すように、完全な計画-実行-評価-調整のサイクルをできるだけ短期間で実施する。

図1.  反復内のPDCA

各PDCAサイクルが反復であり、その反復が、価値のインクリメントを作成したり、これまでのインクリメントを洗練するための、規則正しい予測可能な開発リズムとして使われる。各チームは、2週間ごとに完全なシステムのインクリメントを作成するという状況の中で、自分の担当部分を計画し、構築し、テストし、統合し、デモする。このような短い反復のおかげで、チームやプロダクトオーナープロダクト管理者やその他の利害関係者は、動くシステム上で技術やビジネスの仮説を検証することができる。各反復には統合ポイントも固定されている。これは、機能、品質、整合、使用適合性といったシステムのさまざまな側面を、全チームのそれぞれの担当部分にまたがってまとめる「プルイベント」である。

反復の計画

反復計画ミーティングは、PDCAサイクルの「計画」(Plan)のステップである。これによってチームメンバー全員の足並みが揃い、チームのPI目標に記載されたチームの共通のゴールと、チームデモおよびシステムデモでデモ対象となる成果に向かって、進むことができる。

計画という工程で具体的に何を行うかは、チームがスクラムXPを使っているかカンバンを使っているかで異なるが、チームはチームバックログを見直して一連の反復のゴール(反復の終わりに統合とデモの準備ができている予定のものについてシステム的な視点から詳細に記述したもの)を作成する。

反復の実行

反復の実行では実際の作業が行われる。反復の間に、チームは新しい機能の構築とテストを行って、PDCAの「実行」(Do)のステップを完了する。チームはストーリーをインクリメンタルに納品する。つまり、完成して準備が済み次第、順次、ストーリーをプロダクトオーナーにデモする。進捗を見せる準備ができた状態でデモにやってくる。

実行の中でも小さいPDCAサイクルが実施される。これはデイリースタンドアップミーティングを見てもわかる。チームメンバーは毎日集まって、反復のゴールに向けての進捗を評価し、それぞれの進捗の最新状況を伝え合う。これは1日の中での完全なPDCAサイクルを表すもので、このミーティングによってチームは毎日、反復計画の計画と評価と調整を行うことができる。

チームデモ

チームデモはPDCAサイクルの「評価」(Check)のステップである。デモにおいて、チームはテストの済んだ価値のインクリメントをプロダクトオーナーに見せて、作成したものについてのフィードバックを得る。このミーティングの結果が次の反復のチームバックログに反映される。ストーリーの中には、受け入れられるものもあれば、反復中の学習によって修正されるものもある。

チームデモの後、チームメンバーは統合されたシステムデモにも参加する。これは、アジャイルリリース列車(ART)に乗っているチーム間の最初の必須の公式統合ポイントであり、プログラムレベルで早く統合と検証を行うためのプルイベントとなる。反復の中では、チームはシステムのコンテキストが許す限り短い間隔で、統合と評価を繰り返す。

プロセスの改善

反復の振り返りが反復全体の「調整」(Adjust)のステップとなる。ここで、チームは、プロセスと前の反復で生じた改善ストーリーとを評価し、問題と根本原因や良かった点を特定し、改善ストーリーを作成する(これは次の反復に向けてチームバックログに入れられる)。このように頻繁に振り返りを行うことが、チームレベル容赦ない改善SAFeのリーン-アジャイルの考え方の柱の1つ)を確実に行う主な方法の1つである。反復の振り返りによって、プログラムレベルでのプロセスの変更も行いやすくなる。これはすぐに実施されることもあれば、検査と適応のワークショップで行われることもある。

次の計画策定が始まる前に、デモや振り返りでの決定事項をバックログに反映する。プロダクトオーナーは、必要に応じて、バックログの新しい項目や古い項目をリファクタリングしたり、優先順位を付けなおしたりする。


さらに知りたい場合

[1] Cockburn, Alistair.?gUsing Both Incremental and Iterative Development.?h STSC CrossTalk 21 (2008):27 – 30.

[2] Maurya, Ash.Running Lean:Iterate from Plan A to a Plan That Works.O’Reilly Media, 2012.(邦訳:Running Lean ―実践リーンスタートアップ、オライリージャパン、2012)

Last update:19 October 2015