我々、仕事、そして知識はすべて一つにまとまっている。

 

 

チームレベル概要

大規模ソフトウェア企業における開発の俊敏性に導くため、SAFeのチームレベル、プログラムレベルとポートフォリオレベルは抽象的な組織及び関連する役割とプラクティスを提供する。チームレベルはアジャイルチームの作業のための組織、成果物、役割とプロセスモデルを提供している。SAFeでは、すべてのアジャイルチームはアジャイルリリース列車(ART)に乗り、チームを持っていないARTが存在しないため、チームレベルは本当にプログラムレベルの透過パーティションである。

各アジャイルチームは、一連の固定期間の反復(スプリント)内で、チームバックログからのユーザーストーリーに対し定義/構築/テストを責任持つ。チームは共通のスプリントリズムと同期を用いて、ほかのチームとベクトルを合わせする。また、システムに定期の結合ポイントや強制された結合ポイントを提供する。チームだけではなく、システムも反復しなければならない。

チームは定期的に高品質のコードを納品するため、スクラムやスクラムバンといったプロジェクト管理プラクティスを利用し、また、拡張された、XPから取り入れた技術的なプラクティスを利用する。

詳細

アジャイルチームはソフトウェア開発のエンジンである。各チームは 7 +/- 2 のチームメンバーからなり、一定品質のソフトウェアインクリメントを構築するのに必要な役割が含まれる。これらの役割はスクラムマスタープロダクトオーナー、専任の開発者とテスト担当者、さらにチームが価値を納品するために必要な専門的リソースが含まれる。チームはシステムアーキテクト、技術ライター、システムチーム共有されたリソースなど必要な人たちによって支えられ、そして、少なくとも2週間ごとに動作するテスト済みのソフトウェアを定義し、開発し、テストし、システムのベースラインへと納めることができる

アジャイルチームは主にスクラムやスクラムバン、その延長線にあるカンバンを利用し、アジャイルプロジェクト管理プラクティスを実装する。また、チームは高品質のソフトウェアの創出を可能にするため、拡張された、XPから取り入れたアジャイル技術(コード品質) プラクティスも利用する。チームは期間一定なイノベーションと計画策定 (IP) 反復を用いて、イノベーションスパイクや、リリース計画策定といった作業を行うことが可能である。PIの区切りで出荷する場合、チームは出荷直前の最終的なシステム妥当性を確認し、リリースドキュメントを作成するため、この期間を利用する。この反復は計画に対するバッファーであり、チームはこの反復にストーリーを計画しない。すなわち、各PIが100%より少ない稼動率で計画するという意味である。これによって、スルーアウトと納品の信頼性を向上できる。

反復

チームは通常長さが2週間の反復(スプリント)と呼ばれる短い固定期間で、合意されたスプリント目標に沿ってソフトウェアを開発する。チームは共通の反復期間を採用するため、各反復の区切りのシステム統合点でコードの成熟度(短い期間のブランチを切る)が同等になる。各反復は新たな機能の価値を提供する。これは、品質に力を入れ、反復を計画する、機能を確約する、ストーリーを構築テストする、利害関係者に新たな機能をデモする、振り返りを行う、繰り返すという標準のパターンを絶えず繰り返すことによって達成される。各スプリント終了時に、チームはシステムデモをサポートする。アジャイルリリース列車にとっては、システムデモは重要な結合のポイントである。

1つのPIにおける反復の回数

反復を複数回重ねることより、より大きな、システムレベルの機能プログラムインクリメントに集約される。1つのプログラムインクリメントにおける反復の回数や実際にインクリメントをいつリリースするかという判断はリリース列車に委ねられている。多くの場合、PI区切りでのリリースに限らず、リリースはもっと頻繁に行う。実際にプログラムはリズムに合わせて開発、要望に合わせて納品できるはず、できなければならない。

ユーザーストーリーとチームバックログ

ユーザーストーリー価値のストリームを通じて顧客の要求をコードと実装へ運ぶ主要なものである。チームバックログはチームが実装のために識別したユーザーストーリー、今後開発するフィーチャー及びその他のバックログ項目からなる。リリース計画策定中に、プロダクト管理ビジョンロードマッププログラムバックログを説明し、多くのバックログ項目が識別される。ユーザーストーリーを識別し、維持し、優先順位付けをし、スケジュールを決め、推敲し、実装し、テストし、受け入れるというのがアジャイル企業で機能する主要な要求管理プロセスである。


さらに知りたい場合

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

[2] Bruce Tuckmanが提唱した「形成(Forming)、混乱・乱立(Storming)、統一(Norming)、機能(Performing)」のタックマンモデルをご参照ください。

 

Last update 29 June, 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.