惰性は過去の革新への取り組みの名残である。放置すると、次世代の革新のために必要なリソースを消費する。

- ジェフリー・ムーア

100%の稼働率は不確実性を助長する。

- Don Reinertsen

イノベーションと計画策定の概要

すべてのソフトウェア開発方法論は特定のコンテキスト向けに最適化されている。アジャイルは、動作する、テスト済みのソフトウェアを頻繁かつ迅速に納品するように最適化されている。また、アジャイルで新しい価値を納品するには、技術基盤のための迅速で創発的な設計が欠かせない。しかし、1つのシステムにおいて、ある属性に対する最適化は他の側面の非最適化を引き起こす恐れがある。我々の場合、短いインクリメントで迅速に価値を納品することが最も望ましい結果であるが、アジャイルにより「緊急という名の専制」が強いられることも認識している。スプリントに次ぐスプリントを実施するにはチームは完全に集中しなければならないし、企業は全員に依存するからである。目と鼻の先に常に重要な新しい機能のデモがあるので、気をつけなければ思考、設計、計画は優先度の低い活動として放置されかねない。これに対処するため、SAFeはイノベーションと計画策定(IP)スプリントを提供し、以下のようなさまざまな目的に用いる。

  • 目標を達成するための見積もりのバッファーとする
  • 検査と適応、リリース計画策定活動のための専用時間
  • リズムに基づくイノベーションのための機会
  • 継続的な教育のための時間
  • 技術インフラ、ツールや他の障害を対処するための時間など

さらに、PIのマイルストーンが重要なリリースである場合、最終的なシステム妥当性検証が必要であれば、IP反復によりそのための時間が提供される。

詳細

IPスプリントは、インクリメンタルなリリースの通常リズムでは対処しにくい活動をチームが行う定期的な機会となる。また、リズムに基づくリリース計画策定検査と適応ワークショップの時間としても使用でき、すべてのスプリントの長さを揃えるのに役立つ。このようなIPスプリントは任意であるが、ほとんどのチームとプログラムは、自分たちの効率、ベロシティー、持続的なペース及び仕事に対する満足度が、この「バッテリを充電して刀を研ぐ」という定期的な機会によって向上したと報告している。チームがこの時間をどのように利用するかにはさまざまな形があるが、以下にいくつかを紹介する。

検査と適応、リリース計画策定活動、準備

SAFeでは、検査と適応、リリース計画策定活動は任意で行う作業ではない。これらの活動を専用のスプリントで行うことによって、それにかかった時間が他のスプリントへ影響することがなくなるため、他のスプリントはいつもと同じ長さとベロシティーを保つことができる。さらに、これらの活動は大量のリソースを投入しなければならない非常に重要な活動であるため、対応できる最後の瞬間におけるジャストインタイムのプログラムバックログの手入れ、フィーチャーの推敲、ドメインやシステムのモデリングをこの期間内に行うことによって、今後の計画策定セッションの生産性を大幅に向上できる。

見積もりのバッファー

リーンフローは我々に100%の稼働率は不確実性を助長することを教えてくれた。単純に、もし全員のすべての処理能力が計画に入れられた場合、必然的に発生する問題に対処する余裕がなくなる。その結果として価値納品の遅延と不確実性が生じる。これに対処するために、リリース計画時の見積もりのバッファーや「保護帯」としてIPスプリントを使用する。このスプリントの計画にはストーリーが含められない。このバッファーはチームに必要な余分な時間となる。チームはこの時間を利用し、予測できなかったイベント、依存先における遅延、他の要因などに対応する。その結果、チームプログラムのPI目標を達成するための能力が高められる。ビジネス側により非常に歓迎される指標であるプログラムの予見性が、持続的に向上する。

継続的な教育

ソフトウェア開発実践者は生涯学習者である。技術の変化はもちろん、方法論やプラクティスの変化も日常茶飯事である。一方、継続的な教育ははるかに少ない。さらに、アジャイルへ移行する初期段階では、ストーリーの作成、TDD、ATDD、自動テスト、共同所有、アジャイルアーキテクチャー、継続的なインテグレーション、ペア作業、POやSMのスキル、チームビルディングなどたくさんの新しいテクニックが必要である。継続的な教育時間の提供とは、これらの新しいテクニックを学習し、把握するために必要となる時間をチームに提供することである。また、この時間は、そのようなトピック専用の実践コミュニティーを育て、支援するのにも使用できる。最終的な結果として、個人と企業両方が恩恵を受けられる。つまり、従業員のスキルと仕事に対する満足度が向上し、ベロシティーが高くなり、市場への投入時間が短縮する。

ソフトウェア開発インフラの促進

アジャイル納品を行うとソフトウェア開発インフラの負担が増える。新しいCMサーバーやCIサーバーの立ち上げをしなければならないし、新しいテスト自動化フレームワークのインストールと維持もしなければならない。サーバーを構築することで頻繁に更新が必要になる。アジャイルプロジェクト管理ツールを導入したり、チーム内、チーム間のコミュニケーションシステムを更新、あるいは機能強化しなければならない。作業リストはまだまだ続く。このリストにある大部分の項目は各反復内で対処できるし対処しなければならない(多くはチームの振り返りで見つかった改善ストーリーである)が、数日後に重要なデモが控えていない時に、更新や移行を行ったほうがもっと効率的な場合もある。常に刀を研がなければならないことを我々は理解している。アジャイルチームも同様である。実際、アジャイルチームは他と比べ、作業環境への依存度が高い。

イノベーション

すでに説明したが、アジャイルは、強力であると同時に、固定的なリズムで確実にエンドユーザーへ価値を提供できるよう最適化されている。自由な連想とイノベーションのために時間を見つけることは難しいかもしれない。そのため、多くのアジャイル企業は、調査と設計のスパイクや「ハッカソン」のために、周期的なIPスプリントを行う。ハッカソンのルールは以下のような簡単なものである

1.チームメンバーは作業したい人と一緒に好きなことを行う(会社の使命を反映する限り)
2. 終了時に他の人に作業結果をデモする

以下の図1は「ハッカソン」を介してイノベーションを制度化しているある会社のリズムに基づくプロセスを示している。図から分かるが、「ハッカソンを行う自由」を得るには、8週間ごとに質の高いリリースを納品する必要がある。

Figure 1. One Companys Innovation Cadence

図 1. ある会社のイノベーションリズム

システム妥当性検証

最後に、よくあることだが、IPスプリントをリリースの前に行う場合、そのIPは最終なシステム妥当性検証を行うための時間となる。これには最終性能やほかの非機能要求のテスト、ユーザー受け入れテスト、最終のリリースドキュメント作成、あるいは各スプリントで実施すると経済性がよくないあるいは実施できないその他のリリース準備活動が含まれる。

イノベーションと計画策定スプリントのカレンダー

上記すべてを考慮すると、多くのチームのIPスプリントは標準的なスケジュールと形式になる。図2に1つの例を示す。

Figure 2. Typical Calendar for IP Sprint

図2. IPスプリントのカレンダーの例

 


さらに知りたい場合

[1] Reinertsen, Donald G. The Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing. 2009.

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

Last update: 15 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.