千里の道も一歩から

中国のことわざ

計画(Plan). 実行(Do). 評価(Check). 改善(Act)

E. Deming

反復の概要

アジャイル手法(カンバンを除く)は「反復」という基本構成要素、すなわち厳格な時間枠(タイムボックス)に基づく。この時間枠の中で、チームは動作するテスト済みのソフトウェアを通じ、インクリメントに価値を提供する。SAFeでは、基本となるチームレベルのアジャイルプロジェクト管理プラクティスがスクラム上に築かれていると前提する。また、信頼性のある大規模システムを構築するために必要なコード品質は高いレベルの固有特徴であるため、アジャイル技術的なプラクティスにも注力する。これらの技術プラクティスはエクストリームプログラミング(XP)から大いに取り入れるだけではなく、アジャイルアーキテクチャー、アジャイルモデリングや受け入れテスト駆動開発においても、その拡張や後開発からも取り入れた。

反復は標準的で、繰り返しのパターンを持ち、その上にSAFeが築かれている(スクラムではスプリントと呼ばれる。SAFeでは、反復とスプリントは両方、同意味を使う)。簡単に言うと、各アジャイルチームは共通の通常2週間の時間枠で価値のあるソフトウェアのインクリメントを定義、構築、テストする。作業の流れは簡単である:反復を計画する、ゴールやストーリーを確約する、選択されたストーリーを実装する、主要な利害関係者に作業結果をデモする、最後に振り返り(ここでは、チームはパフォーマンスを改善するために必要な変更を分析、決定する)を行う。さらに、これらの反復はアジャイルリリース列車(ART)のコンテキストで実行される。ARTは1つの共通ミッションのため、複数のチームを連携し、同じリズムでスプリントを繰り返し、途中の調整のために必要なフィードバックを提供する。

詳細

各反復では、アジャイルチームは固定した時間枠内で、選択されたユーザーストーリーの詳細化とコードの開発やテストによって、ビジネス価値の確かなスコープの提供を確約する。反復を重ね、アジャイルチームは製品の完成と共に成長する。

反復の構成

SAFeでは、反復は通常2週間の固定期間で実行される。これは、PI期間中に、必要な変更の適用に十分なフィードックポイントを確保しつつ、ビジネスに価値を提供するために、十分なユーザーストーリーを定義/構築/テストできる最適の時間枠である。SAFeでは、各チームは反復の開始と終了が同期される。これによって、2週間の区切りでは結合、評価、全システムのデモの実施が可能になる。図1はアジャイルリリース列車のコンテキストにおけるチームの反復/スプリントプロセスを示す。

図1.SAFeにおけるチームのスプリント

図1.SAFeにおけるチームのスプリント

  • 計画策定 – 計画策定では、チームバックログフィーチャーや目標を納品するために識別されたストーリーとともに提供される。これらはリリース計画策定時に識別され、確約される。反復計画策定時に、チームはチームバックログから、スプリント内で納品できる、できるだけ多くのストーリーを選択する。バックログ以外に、計画策定のインプットは前の反復からのフィードバック、システムデモからのフィードバック、チームのPI目標から提供されたコンテキストを含む。スプリント計画ミーティングの時間枠は4時間以下で、以下の3つのアウトプットがある。
    1) ストーリー(大半は関連の受け入れテスト基準を持つ)からなる反復バックログ
    2) スプリントゴール、スプリントのビジネス目標をまとめた文
    3) スプリントゴールへのチームの確約
  • 実行 – 反復期間中、チームは反復バックログからストーリーを選択し、受け入れ基準を満たすために必要な機能を協力的に開発やテストすることによって、実装を行う。ストーリーが一旦完了すると、プロダクトオーナーに対しデモを実施し、レビューしてもらう。プロダクトオーナーは a)ベースラインへストーリーの受け入れを行い、受け入れ成功の時点で、チームが次の優先順位高いストーリーに着手する。b)チームは必要に応じ、コードの再作業を行い、テストを行う。たくさんのチームは反復の途中でチームバックログ手入れミーティングを行う。このミーティングの目的は、計画された将来の反復に向けてユーザーストーリーを詳細化するで、バックログの手入れをすることである。

    すべてにストーリーが完了させたかにも関わらず、2週間の時間枠が終了した時点で、スプリントが終了する。スプリントの終わりに、チームデモと振り返りという2つの重要な活動がある。

  • チームデモ –  チームデモの目的は、開発チーム、プロダクトオーナー及び他の該当する利害関係者に動作するソフトウェアを披露することでチームの進捗を測定ことである。 このフィードバックは1-2時間で新しい機能をデモすることで構成される。
  • 振り返り– 各スプリントの最後の活動は短い反復の振り返りである。振り返りの目的は反復を反省し、プロセス改善のために新しいアイデアを洗い出すことである。この活動は、個人やチームで改善マインドを植え付けるのに役立つ。そして、各反復では、チームがプロセスのいくつかの小さな改善を行うことを保証するのに役立つ。

その後、一部のチームメンバーはシステムデモを参加するかもしれない。プロダクト管理やほかのビジネス利害関係者のレビューのため、個々のスプリントの成果を一貫性のあるシステムレベルの振る舞いに集約する。

実施と追跡

次のセットに移す前に、ストーリーを完全に完了することによって、仕掛作業を制限する。これはをリーンのベストプラクティスからの教えである。これは反復の予測性を改善しながら、作業の流れを平均化し、早期の価値提供を可能にする。チームは品質とリズムの持続性を維持するためには、継続的なインテグレーションやテストの自動化などアジャイルのコード品質プラクティスにも従う。これらのプラクティスはフローとベロシティーの確保に役にったつ。

以下の方法とツールを用いて、チームは反復のステータスを追跡する。

  • ストーリーボード/BVIR – チームのストーリーボードや大きな目に見える情報発信板(BVIR)で、各ストーリーがどのような状態であるかをビジュアル的に示し(図2)、反復バックログの各項目の進捗の良さを可視化する。ストーリーボードは、チームが反復を成功裏に完了させるために何が残っているかを容易に識別することを支援する。さらに、ストーリーボードは、仕掛作業の制限に関するリマインドとして機能する。(チームによって、実際に各状態で仕掛作業の制限をかける場合もある)

    (注意:問題を痛惜するため、多くのエンタープライズチームは効果的なアジャイルプロジェクト管理ツールを適応しているが、視覚的なストーリーボードーはくっきり目に入る、感覚的な有用な進捗表示板である。

  • デイリースタンドアップミーティング – 短い15分のミーティングである。このミーティングでは、チームは前日の進捗に関する情報を共有したり、本日の作業を調整したり、依存性を識別したり、障害を報告したりする。
  • バーンダウンチャート(BDC) – いくつかのチームは、残時間ではなく、残作業のグラフ表示を使用する。(図2、ステータスボードの左側に示す)。

図2. デイリースタンドアップミーティング

反復の主要なアウトプットはテスト済みの動作するソフトウェアである。チームにとっては未完了の作業(例えばテストの自動化、ドキュメントとの同期、非機能要求のテストなど)を反復の境界線を超えさせないことが非常に重要である。何等かの理由で初期において、即時にすべてを実施するのは不可能かもしれない。したがって、チームは反復における現実的に達成可能な「完了の定義」(DoD)を考え出すべきである。その後、未完了作業を貯めないような理想的なDoD状態になるまで、徐々に各反復の後にDoDを拡張する。

まとめ

SAFeは従来スクラムやXPに説明された反復、あるいはスプリントという基本要素に築かれるため、アジャイルに初めてのチームはこれらの基本的なプラクティスを適用できるし、アジャイルチームは基本的なスクラムプロジェクト管理のプラクティスやXPから取り入れた技術プラクティスを継続的に利用できる。このように、これらの証明された、効果的な大いに標準化されたアジャイルプラクティスにより提供された恩恵を受けることができる。アジャイルリリース列車やSAFeエンタープライズの世界では、反復が同期されている、見積もりが基本経済理解の一部として正規化されている、コード品質が再強調されている、反復計画はリリース計画によりユーザーストーリーが提供される、チームはシステムレベルのデモで協力し合い、チームだけではなく、システムもスプリントすることを確実にする。このように、基本的な反復パターンは異なる構造で回す。


さらに知りたい場合

[1] Cohn, Mike. Succeeding with Agile: Software Development Using Scrum. Addison-Wesley, 2009. ​Chapter 14.

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

[3] Cohn, Mike. Agile Estimating and Planning, Addison-Wesley. 2006.(邦訳:アジャイルな見積りと計画づくり ~価値あるソフトウェアを育てる概念と技法~、毎日コミュニケーションズ、2009)

Last updated 14 July, 2014

This 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.