完了状態(Done)と未完状態(Undone）
Jeff Sutherland および Ken Schwaber 著 Scrum.org
2012 年 1 月
完了インクリメントを提供することは、アジャイル ソフトウェア開発が成功するうえで重要です。実際例や理論的な例を使用して、著者は、"完了" の概念と "完了" の現実の違い、および "完了" がプロジェクトの成功にどのような影響を及ぼすかについて説明します。また、以下の例を使用して、著者は、彼らの理にかなう完了の定義、チームが依存関係を通信できるようにするメソッド、および "完了" の意味を活用して、チームが作業を開始する際に役立つツールや方法を示します。
対象
アプリケーション ライフサイクル管理; Team Foundation Server
この記事の内容:
Introduction
Anna の企業で失われた透過性
人々が発生していると思っていた状況
実際に発生した状況
学んだレッスン
Nanomedtronics AZ の技術的負債
人々が発生していると思っていた状況
実際に発生した状況
学んだレッスン
複数のチームにおける技術的負債の増幅
Datum Corporation のリリース計画
人々が発生していると思っていた状況
実際に発生した状況
学んだレッスン
作業を完了するための大規模な手法
スクラムのスクラム ミーティング
継続的インテグレーション
まとめ
スクラムは、反復的でインクリメンタルな、アジャイル フレームワークです。チームは、このアジャイル フレームワークを使用して、各インクリメントやスプリントに、"完了" のインクリメントや潜在的に使用できるソフトウェア機能を迅速に提供できます。
"完了" は単純ですが、誤って解釈されることが多い単語です。私にとって完了 (done) とは、終了している、完成している、達成している状態を意味します。完了するということは、やるべきことが何も残されていない状態を意味します。完了を定義することは簡単ですが、完了インクリメントを提供することは、依然として、スクラムとアジリティ (敏捷性) の理解しにくい基本的な要件の 1 つとなっています。
アジリティには、正しく機能するソフトウェアの、すぐに使用できる完了インクリメントがスプリントごとに必要です。ただし、ほとんどのスクラムとアジャイル チームでは、部分的に完了した不完全なインクリメントが生成されます。プロダクト バックログ要件がスプリントで完全に実行されなかった理由を尋ねられると、スクラム チームは「時間がありませんでした」と答える場合がよくあります。
ここでは、スクラムの初期の頃の実際のケース スタディの例を通じて、完了インクリメントに関連する問題を取り上げます。関与した個人の名前や住所は変わってしまっても、それぞれの個人によってチーム メンバーや彼らが成し遂げた成果は認識されることでしょう。この記事全体で、特に記述がない限り、すべてのスプリントは月単位のイテレーションです。
Anna の企業で失われた透過性
Anna は自分の部門のプロパティ タイトル変更の受け取りを自動化する必要がありました。彼女が働いていた企業では、北米のほとんどを占めるガス パイプラインを建設および運営していました。彼女の部門は、パイプラインが通る土地の所有者へのロイヤリティの処理と支払いを担当していました。Anna の部門が受け取るタイトル情報は、プリントアウトされたものか、プロパティ変更用紙に記述されたものでした。これら書類の量が膨大になってきたため、Anna はフィードとロイヤリティの支払いプロセスを自動化したいと考え始めました。
そこで、私たちの開発チームは、スクラムを使用して Anna のロイヤリティ システムを構築することを提案しました。これにより、Anna は各月の検査を行う有効なソフトウェアを活用できるようになります。私たちのチームが次に何を行うかについて、月ごとに彼女の考えが変わってもかまわないことにしました。
3 番目のスプリントの終わりまでに、1 つの州からのフィードを完成させ、古いデータと統合することができました。まず、簡単な SQL ソリューションを使用してこのシステムを彼女に説明しました。Anna は自分のスタッフのプロダクト バックログのほとんどがこの州からであったため、喜びました。
開発チームが提供したソフトウェアを Alice のスタッフがすぐに使い始められるように、彼女はスタッフへの SQL の指導を求めました。
Alice がソフトウェアを使用したいとは、どのような意味でしたか?Alice は、スプリントで完了するということを、ソフトウェアで完了することとは解釈していませんでした。
私たちは Anna にソフトウェアで完了するということを可能な限り慎重に伝えました。Alice は青ざめました。「完了していないとは、どういう意味ですか? 私は、最初のインクリメント、2 番目のインクリメントを確認しました。今はこれを使い始めたいのです。配置して、SQL を指導していただければ、私たちは使い始めることができます。
私たちは不安を感じ始めました。そこで、Anna に「完了していますが、Anna さんが考えているような種類の完了ではありません。」と伝えました。Anna に示すために完了させましたが、ソフトウェアを使用するには、解決する必要がある次のような問題が残されています。
受信したレコードの一部を処理できませんでした。処理できなかったレコードをスローするのではなく、格納して管理する機能が必要でした。
受信したレコード内のいくつかのフィールドは、文書化以外の目的で使用されているようです。これらのレコードをどのように処理すべきでしょうか。
既存のデータベースのフィールドには、参照情報のようなポインターや情報が含まれていました。この状態は、データベース全体に分散していました。
受信したフィードを実行してデータベースをクエリすると、システムは何度もクラッシュしました。これらのクラッシュ時に、データが破損したようでした。
Anna は、彼女が考えるような完了 (使用可能な完了) にするには、どのくらいの期間がかかるのか尋ねました。私たちは、インクリメントを使用可能にするには、別に 2 つのスプリントが必要であると推測しました。Anna は、プロセスを進めて彼女の部門で使用できるようにしてほしいと言い、その翌朝に私とミーティングを行いたいと求めました。
翌朝のミーティングには、Anna と彼女の上司、開発のディレクターが出席しました。彼らは、私が売りにしていた透過性が存在しないと、失望感を表しました。バグとして単に記録する方法とは異なる方法で、未解決の問題を処理すべきであったと、彼らは感じていました。全員に提供されたバーンダウン レポートに反映されていた進行状況が正しくなかったため、彼らは困惑していたのです。
ミーティングの後に、互いが合意した注文は次のようなものでした。
4 つのバグを調べて修正する。
Anna の部門が使い始められるように、最初の 3 つのインクリメントを完了して配置する。
完了の定義が Anna の定義 (ビジネスですぐに使用できるという定義) と同じになるように、エンジニアリング スキルとテストのオートメーションを改善する。
欠陥が修正されるまで要件が完了したと見なされないように、私たちが欠陥を記録する方法を変更する。
私たち全員がこれらのレッスンから学ぶことができれば、今回の問題は学習するための良い機会ではないかとも言われました。
.gif "Hh765983.collapse_all(ja-jp,VS.110).gif")
人々が発生していると思っていた状況
私たちはシステムのベースライン計画を作成しました。これは、利害関係者と Anna が、発生すると想定する内容を表すものでした。開発チームは、リリースが順調に進行していることを示す進行状況を報告すると、このレポートは信頼されました。
開発チームは実際、計画での記述どおりに作業が進行していることを示すことで、正しいことをしていると考えていました。
実際に発生した状況
ベロシティは、スプリントごとに開発チームの生産性を示す測定単位および履歴レコードです。ベロシティは、各スプリントで測定され、生産性のパターンを確立するために使用されます。
私たちの開発チームは、計画を満たすために各スプリントで 8 つの完成した作業単体を含む、ベロシティの維持が必要でした。8 を下回るようなベロシティの低下が起こったときは、それらの項目においてはあらゆる作業を完了させませんでした。
適切に動作する機能を提供しましたが、この機能を使用またはビルドするためには、完成度が十分ではありませんでした。そのため、後で改善する予定にしていました。未処理の作業の見積もりをすると、別に 14 単位の作業が追加されました。
最初のタイトル フィードの難しさを踏まえて、約 20 か月のスケジュールを反映するように、計画全体を作成し直しました。Anna の部門は、新しいフィードを有効にするインクリメントを約 2 か月ごとにリリースしました。新しい自動フィードは、全体的な手動による作業を大幅に減らしましたが、システムは起動後 22 か月稼働すると、期待外れな結果になりました。
学んだレッスン
透過性を確保するには、インクリメントを表示するユーザー全員に対して同じ内容が表示され、全員が同じ内容を理解することが要求されます。インクリメントの透過的なチェックでは、Anna がリスクを管理し、予測可能性を得ることができるようにする必要があります。ただし、インクリメントは透過的ではなかったため、彼女は効果的に計画できませんでした。
プロジェクトの開始時に、Anna はリリース目標を立てました。スプリント 1 の後に、Anna は、彼女が利用可能なインクリメントであると考える内容をチェックすることで、ゴールに向かってその進行状況を評価しました。Anna は目標に向けたインクリメンタルな進行状況に基づいて、スプリント 2 で行う内容について意志決定を行いました。作業の進行状況が不十分であると彼女が考えた場合、彼女はプロジェクトをキャンセルできました。
スプリント 3 の終わりの時点で、合計の 10 分の 1 が完了したと信じていましたが、これは明らかに誤っていました。
残念なことに、私たちは彼女に例示するために十分なインクリメントを完了しただけでした。未完了の作業によって、Anna の部門はインクリメントを使用できず、チェックの透過性を失いました。
インクリメントを検査する際の不透明さは、サーモスタットを冷たい濡れタオルで覆うようなものです。このようなサーモスタットは、実際の室温を正確に読み取ることができなくなってしまい、冷却すべきときに暖房を誤って開始してしまうでしょう。
透過的なインクリメントなしでは、利害関係者は実際に起こっていることを理解できず、理にかなわないアクションを誤って実行する場合があります。
つまり、完全な透過性がない状態では、チームがチェックを行い、効果的に対応する機能は失われます。
Nanomedtronics AZ の技術的負債
技術的負債とは、ソフトウェアが完了と見なされる前に完了する必要がある遅延作業です。技術的負債は、品質が低いデザイン、コードの重複、信用できない機能など、多くの形態を持ちます。次の例では、プロジェクトの経過と共に未完了となった作業の場合の、技術的負債の原因と影響について説明します。
Nanomedtronics AZ は、小規模なソフトウェアの立ち上げ企業です。スクラム チームを組んでライフクリティカル製品 (高血圧が原因で起こる患者の動脈血栓を除去するためにナノ ロボットによって使用されるソフトウェア) の新しいリリースに取り組んでいました。
人々が発生していると思っていた状況
チームが作業を開始すると、スプリント バックログ項目を選択して、1 か月のスプリントである作業を完了できるように (作業が残されていない状態、使用可能で潜在的に出荷できる状態)、タスクに取り組みました。開発チームは、完了インクリメントの要件を完全に開発するためのスキルのすべてを備えていました。
スクラム チームが最初のスプリントを開始すると、10 か月後までに完了しなければならない作業は 80 単位も確認されました。その結果、開発チームは各スプリントの 8 単位の作業を忠実に選択しました。スプリントごとに 8 単位のみを取得した場合、企業が要求している 10 か月後までに完了できると、理由付けました。
開発チームは、各スプリントの終わりに作業中のインクリメントを示しました。外部からは、スクラムは機能しており、Nanomedtronics AZ による製品の配布は計画どおり順調であるように見えました。
実際に発生した状況
開発チームに明確ではなかったことは、実際配布された各インクリメントには、品質の悪い実装、重要ではないバグ、繰り返されているロジック、一般的に乱れたコードが含まれていました。さらに、開発チームはスプリントで時間が押していたため、インクリメントで完全なテストを行いませんでした。開発チームはスケジュールに従い納期を守ることに専念しましたし、順調な作業の進行を維持する方法として、品質を落とすという方法はよく使われています。
チームは懸命に作業を行い、10 か月かけて製品をビルドしました。顧客はソフトウェアの実装を喜び、使用する準備は整っています。しかし、開発チームが蓄積した未完了の作業は 48 単位にも及んでいました。次の図に、新しい技術的負債を示します。
.png "完了した作業と完了していない作業")
Nanomedtronics AZ のチームは、完了するために本当に必要なアクティビティと作業のすべてを考慮していなかったのです。以下に列挙した項目は、チームが考慮できなかった内容であり、すべて網羅したものではありません。列挙できる項目はこれらの他にも数多くあります。
分析
設計
依存関係の分析
パフォーマンス テスト
安定性テスト
リファクタリング
免疫学応答のテスト
製品を開発している他のチームの作業との統合
他のチームの作業との統合テスト (インクリメントはすべてのチームの貢献を表す全体像であるため)
リリース ノート
製品が販売される場所の 6 つのカルチャに対する国際化
ユーザー受け入れテスト
回帰テスト
コード レビュー
上記の作業は、スプリントの終わりまでに完了、統合、およびインクリメントを生み出すために完了しなければならないものです。しかし、ほとんどの開発チームは、上記の一部の作業を完了しませんでした。一部の "未完了" 作業はスプリントごとにそのまま保留にされました。このことは、品質の低いデザイン、重複したコード、非常に複雑なロジック、テストされていない機能やその他の不完全性を生み出しました。このようにして、チームはソフトウェアの技術的負債を生み出すのです。
顧客への配布に必要なすべての機能がこの企業の製品に含まれていたが、多くの欠陥も同時に含まれており、製品を市場に実際投入するのに必要なパッケージ化と最終工程の作業に欠けていたことを、Nanomedtronics AZ は学びました。開発チームは、誤って、スプリントごとに 8 単位の無効なベロシティが既にあることを想定して、さらに 6 か月かかる追加の作業のバックログを生み出すことになりました。
製品の出荷を 6 か月待機するのは、企業のリーダーだけでなく、未完了の作業が残されたままの製品が出荷されてから 3 か月しか過ぎていない状態では、許されることではありません。損失の可能性は、製品の出荷が 3 か月遅れることだけではありませんでした。開発チームが将来のスプリントで技術的負債に対応する必要があったため、新機能を追加する能力が低下しました。
学んだレッスン
技術的負債は、実際の進行状況を不透明にし、製品所有者と利害関係者による重要な意志決定に必要な透過性を曇らせてしまいます。技術的負債は、技術的問題の修正にかかる意図的な時間か、出荷の遅延または低品質による損失によって、代償を払われます。
ほとんどの場合、未完了の作業の少なくとも 50% は、リリース後の製品に残されたままになります。したがって、未完了の作業は進行中の負債として制度化されてしまいます。技術的負債は、短期間で製品の脆弱性の原因となり、最終的には、ソフトウェアの作成し直しや製品の破棄に投資するというような、負のビジネスの意志決定を強いる場合もあります。
複数のチームにおける技術的負債の増幅
開発チームは、スプリントで実行できる作業量と同じだけの作業量を慎重に選択しなければなりません。開発チームは、この選択のためにどれ程多くの作業量が必要であるかを経験を通じて学んでいます。さらに、チームはあらゆることを達成するための自動ビルドと回帰テストのように、モダンなエンジニアリング手法を導入する必要があります。これらを導入した場合、手動による作業は 4 番目または 5 番目のスプリントによってチームが過負荷になる可能性があります。
3 人のプログラマと 2 人の QA スペシャリストを検討します。毎日、プログラマはソース コード システムに入力されるコードをチェックします。コードはテストされ、バグが検出されると、担当プログラマに送られます。検出および報告されるコードや欠陥の各チェックの間にも時間が経過します。この時間に、他のプログラマが欠陥のあるコードの上位のコードでチェックする可能性もあります。最初の問題の修正に必要な労力はこれで、増幅しています。開発チームは、継続的なビルドとテスト機能がある場合、エラーはすぐに検出されます。そのため、問題を調査し、修正してから先に進むことができました。不要な作業と無駄を回避できたのです。
多くの組織では、ソフトウェアの構築に複数のスクラム チームを使用します。この場合、前のセクションで説明した技術的負債の問題が非常に増幅されます。欠陥あるコードの上位のコードをチェックする機会が大幅に大きくなります。ソフトウェアの増大する脆弱性を修正するコストは、作業の進行に応じて急激に増加します。
Datum Corporation のリリース計画
Datum Corporation (インフラストラクチャ ソフトウェア企業) と呼ばれる別の企業と、最近、仕事をする機会がありました。主要な製品ラインでは、250 人のプログラマを含めて 800 人を超える開発者を雇います。開発インフラストラクチャは、部分的に自動であったり、手動であったりします。テストによって、多くの場合、数日間コーディングが遅れました。欠陥のあるコードをプログラマがチェックする間の時間、それらが検出および報告される間の時間は、10 日間以上になることが多くありました。
多くのプログラマの複雑さを最小限に抑えるため、各開発チームは独自のコード分岐で作業を行いました。開発管理者は、依存関係を最小限に抑えるプロダクト バックログの要件を管理できます。各開発チームは、メイン コード行に毎日コードをマージした場合、潜在的な再作業の量は最小限になります。
しかし、管理部門はこれには時間がかかりすぎると感じました。そして、3 スプリントごとにすべてのコード分岐をルートにマージすることを決めました。統合テストによって欠陥が検出された場合、これらは修正されます。リリース候補は、3 番目の月の月末には準備ができました。
人々が発生していると思っていた状況
次の図に、計画されたリリースのスケジュールとサイクルを示します。
.png "計画済みのリリース スケジュールとサイクル")
想定された元の計画:
9 スプリント
3 つのリリース候補、そして完全なリリース
800 人の開発組織
実際に発生した状況
この組織が 9 か月間のスプリントの後でリリース日を迎えても、製品はリリースの準備ができていませんでした。6 番目のリリース候補には、5,000 個を超える欠陥が含まれており、2,000 個を超えるプロダクト バックログが不完全でした。この状態の結果がどのようになるか不安を感じていました。3 か月ごとにリリース候補を確認しました。調査した際、各開発チームのコード分岐からのデモを見つけました。統合がまったく起きていなかったのです。統合テストもまったく起きていませんでした。
リリース日に必要なベロシティを保持するため、開発チームは統合作業のための遅れを確保しなかったため、膨大な量の技術的負債が生み出されました。結果として、予定されたリリース日から 8 か月の遅れが生じました。"リリース候補" という単語は意味を持ちませんでした。
次の図は、実際のプロジェクトと、安定化に必要な時間を示しています。
.png "実際のプロジェクトと安定化に必要な時間")
リリース候補には、各チームのコード分岐から得られた部分的な機能がありました。リリース前まで "安定化" するために 5 か月を要しました。他の欠陥よりも提供を遅らせた、あるやっかいな欠陥とは、"パフォーマンス低下" でした。この問題は最初のスプリントでログに記録されていました。
学んだレッスン
同じソフトウェアを開発している別のチームが最終的に、これらの作業をマージします。作業を確認する統合ソフトウェアによって、統合時のリスクが軽減されるため、統合が頻繁に発生するようになります。
複数のチームの作業がマージするまで待機することは、マージのコストの遅延を許すため、心動かされることでもあります。この最終的なコストの遅延は、関与するチーム数、および統合する必要がある分岐の数だけ増幅されます。
作業を完了するための大規模な手法
複数のチームで "完了" 状態を達成するのは簡単なことではありません。達成するための複雑さは計り知れません。チーム間の依存関係と、コード分岐全体の依存関係が存在します。この複雑さの範囲には、コストも含まれ、同期したチームが調子を合わせて配信した場合に達成できることであり、これにより、膨大な価値が提供されます。
複数のチームが協調する場合に役立つ、いくつかの方法を次に示します。
スクラムのスクラム ミーティング
多くのスクラム チームが同じプロジェクトで作業している場合、互いの作業を調整する手法が必要です。私は、"スクラムのスクラムミーティング (Scrum of Scrums)" を推奨しています。これは、毎日のイベントであり、各チームの毎日のスクラムの後ですぐ行われるミーティングです。各チームの技術担当者が出席します。各チーム担当者が、自分のチームが作業した内容について説明します。次の日に予定している作業についても説明します。この情報に基づいて、担当者は必要な再作業、将来の依存関係、および再スケジュールする必要がある作業を特定します。
スクラムのスクラム ミーティングは、数多くの組織で有効でしたが、これで十分ではありませんでした。問題は既知のものではなく、予測されるものであるため、依存関係および再作業は正常に識別される場合とされない場合があります。予測されなかった依存関係は、再作業とテストの失敗につながります。一部のチームは、依存関係の作業と再作業に各スプリントの 50% を超える時間を費やしました。
継続的インテグレーション
エクストリーム プログラミング (XP) には、チームの作業の継続的インテグレーションとインテグレーション テストが必要です。これをすべてのチームに拡張してみましょう。チーム数に関係なく、チームには、各スプリントの終わりに、統合され、統合テストされたインクリメントが必要です。これを行うには、チームが互いの作業を頻繁に統合する必要があります。統合されていない作業は、未解決の依存関係を含む可能性があります。継続的インテグレーションは最も適した解決策です。
すべての作業の継続的インテグレーションは、リーン生産手法と同様です。リーン生産ラインでは、多くの手法を使用して、生産プロセス全体での製品の品質を評価します。偏差または品質の問題が発生すると、生産ラインは停止されます。継続的インテグレーションおよび統合テストにより、ソフトウェア製品の開発と同じ手法が提供されます。
簡単ではありませんが、継続的なビルドまたはテストが失敗した場合、各チームとチーム メンバーはコーディングを停止することをお勧めします。どのような継続的作業にも、欠陥がありながら構築される可能性があります。このことはエラーの波及効果をもたらします。継続的インテグレーションを使用する場合、チームは統合エラーを回避するために密接に連係します。これによって、作業特性の向上、無駄の削減、および品質の向上がもたらされます。
スクラムを導入するほとんどの組織では、完了インクリメントの構築に一部のエンジニア スキルやツールが使われずに開始されました。完了インクリメントを達成する厳密なプログラムを開始し、追求する必要があります。50 人未満のグループは、スプリント内で完了インクリメントを完了するという状態に、短期間で達成できます。500 人を超える開発者が属する組織は、これと同じ状態に達するまで数年を要する場合も少なくありません。
未完了インクリメントは、無駄を生み出し、チームが真のアジリティに達するのを妨げます。未完了の作業の実際のコストは、インクリメントにおける機能の欠落よりはるかに膨大です。このようなコストには、インクリメントが実際完了していない場合に必要となる再計画と再作業の無駄だけでなく、予測可能性の低下と高いリスクに伴うコストが含まれます。
多くの組織は、アジリティのメリットを求め、利益を得るためにスクラムを導入します。完了インクリメントを提供することは、アジャイル ソフトウェア開発が成功するうえで重要です。チームは、彼らの理にかなう完了の定義から作業を開始し、時間の経過と共に意図的に定義を拡張します。では、どのようにして本当のアジリティを達成できるのでしょうか。