なぜ仕事をするかに重きを置くべきである。

W・エドワーズ・デミング

待ち行列はフィードバックを遅らせる。フィードバックが遅れると、コストが高くつく。

Donald Reinertsen

 

 

プログラムバックログの概要

プログラムバックログは、アジャイルリリース列車ソリューションを進めるために予定されている今後のすべての作業のための唯一の決定的なリポジトリである。バックログは、主にユーザーのニーズに対処し、ビジネス上の利点を提供することを目的とする、今後のフィーチャーによって構成される。また、アーキテクチャー滑走路を構築するために必要なアーキテクチャーフィーチャーも含まれる。「重みづけされた最短作業から着手」(WSJF)を利用し、バックログ内のフィーチャーに効果的に順序と優先順位を付けるのは、プロダクト管理者の責務であり、プログラムを経済的に成功させるための重要ポイントである。WSJFには、時間に基づく重要な要素があるため、各プログラムインクリメントの区切りで、バックログに対する優先順位の調整(見直し)を行う。

詳細

プログラムバックログは、フィーチャーを短期的に保有する場所であり、プロダクト管理によって作成、維持される。フィーチャーは特定のアジャイルリリース列車のためのプログラムビジョンから導き出される。ビジョンのページや図2に示すように、戦略テーマポートフォリオやプログラムエピック、顧客/価値のストリームのフィードバック、アーキテクチャーフィーチャーなど、バックログを促進するためのビジョンへのインプットは複数あり、アジャイルチームからのインプットもある。

Figure 2. Inputs to Program Backlog

図1.プログラムバックログへのインプット

結果として、バックログ内の一連のフィーチャーが作成される。図2に示すように、これらのフィーチャーは「ストーリーポイント」で見積もられる。(フィーチャーの見積もりに関する詳細は「フィーチャー」のページを参照。)

図2.プログラムバックログの分解図。ストーリーポイントで見積もる

バックログの洗練

各アジャイルリリース列車は、安定した8~10週間の「計画-&gt実装-&gtデモ-&gt検査と適応」のリズムで運行している。この安定したリズムによりプログラムバックログの準備も促進される。バックログをよく推敲せずにリリース計画策定セッションに参加しても、効率が悪く、立ち上げがうまくいかない。そのため、PI計画策定イベントの間はプロダクト管理とシステムアーキテクトたちにとっても忙しい時期である。なぜかというと、次のセッションに向けて、彼らはずっとバックログを洗練し続けているからである。通常、バックログの洗練では以下を行う。

  • フィーチャー定義や受け入れ基準のレビューと更新
  • フィーチャーを小さなインクリメンタルな価値のかたまりに分割する方法を分析する
  • チームと協力して見積もりを確立する
  • 新しいフィーチャーバックログによって生じたアーキテクチャーフィーチャーを決定し、また、容量の割り当てを確立する(以下を参照)

バックログの優先順位付け

バックログに優先順位を付けることは、プログラムの経済面での主要原動力である。そのため、プロダクト管理者は、リーンの「重みづけされた最短作業から着手」の優先順位付け法を用いて作業の順番を決定する。要約すると、WSJFは最終的に以下の簡潔な公式に変換される。

この公式を適用するには、分子の各項目をそれぞれ相対的にランク付けする必要がある。分母は作業規模であり、相対的な測定や絶対的なストーリーポイント見積もりを利用できる。すでに進行中の作業の場合、分母には、残作業規模だけを含めるべきである。フィーチャー(作業)に関する残作業がバックログ内の他のフィーチャーより優先度が低いと判断されれば、このフィーチャーを「十分によい」ものとして、チームは優先順位の高い他の作業に移ることができる。これは暗黙のうちにReinertsenの主要経済原則E17(参考文献[2])を実践している。E17は「サンクコスト原則:すでに使った金を考えるな」である。

リリース計画策定の準備

リリース計画策定の1~2週間前もとても忙しい時期である。プロダクト管理者は最終のバックログ準備を行い、ビジョンの概要説明を更新し、プロダクトオーナーと協力して、イベントの前にバックログについて知らせておく。システムアーキテクトは、モデルやアーキテクチャーフィーチャーの定義を更新し、エンドユーザーの価値を提供するためにフィーチャーがどのように連携するかを示すユースケースを開発し、リリース計画策定時の概要説明を準備する。

容量の割り当てによって価値提供とシステムの統一性を最適化する

すべてのプログラムが直面する課題に、ユーザーフィーチャーのバックログと、アーキテクチャー滑走路への継続的な投資ニーズとのバランスをどう取るかという問題がある。ベロシティーの低下を避けたり、技術が時代遅れになってシステム全体をリプレースしなければならなくなる時期を先に延ばせるよう、アジャイルチームはソリューションのアーキテクチャーフィーチャーの進化に絶えず投資しなければならない。その結果、作業の優先順位付けは複雑になる。プロダクト管理者は常に市場に新しいビジネスフィーチャーを提供するために努力しているからである。図3に示すように、時折、この2つの観点からジレンマが生じる。

図3.フィーチャーとアーキテクチャー滑走路のジレンマ

幸い、我々はこの課題に対処できるツールを持っている。カンバンでは、Anderson[3]が言うように、「システム全体のフローにWIP制限を確立したら、作業項目の種類やサービスの等級ごとに容量の割り当てを検討することができる……容量を割り当てることで、カンバンシステムが受け取った作業の種類ごとにサービスを保証することができる」。容量の割り当てにより、チームは、まず、次のPIでチームの全体工数を活動の種類ごとにどのくらい適用できるかという方針を決定する。次に、種類ごとに作業をどのように実施するかを決定するための方針を確立する。図4および表1にその結果を示す。

図4.1つのPIのプログラムバックログにおけるアーキテクチャーへの容量の割り当て

バックログ管理に関するポリシーは明確でなければならない。下記表1に例を示す。

  1. 各区切りで新フィーチャーの開発とアーキテクチャーとに、どのような割合でリソースを配分するかに同意する
  2. アーキテクトが設計の権限を持ち、その部分の作業の優先順位を付けることに同意する
  3. プロダクト管理が内容に関する権限を持ち、その部分の作業の優先順位をつけることに同意する
  4. 経済面を考慮して、共同で作業の優先順位をつけることに同意する
  5. 顧客価値を最大化するよう、協力して作業の順序をつけることに同意する

表1 アーキテクチャーとフィーチャーの容量の割り当てを管理するためのポリシー例

同意したポリシーはしばらく続けて使用することができるが、割り当てられる容量の量は状況により変化させなければならない。ARTのコンテキストでは、この決定は、各PIの準備のためにバックログを洗練する作業の一環として見直すことができる。

バックログ、待ち行列、リトルの法則、待ち時間

参考文献[1]の第9章で、私たちはバックログ、待ち行列、リーンフロー、リトルの法則の関係について詳細に議論した。これは重要な議論なので、完全に理解するためにはそちらを参考してほしい。ただし、プログラムバックログは納品の時間とスループットに大いに影響しかねない重要な「バックログ」であるため、ここでは、その議論を要約しておきたい。

  1. リトルの法則は、待ち行列内の項目の平均待ち時間が、待ち行列の平均の長さを待ち行列内の項目の平均処理速度で割ったものに等しいことを立証している。待ち行列が長ければ長いほど、待ち時間が長くなり、ばらつきが大きくなる。(スターバックスで並んでいるとしよう。もし、自分の前にトールコーヒーを注文する人が10人がいるなら、数分後には自分の番になるだろう。しかし、その人たちが全員、特別熱いバニララテと温めたベーグルを注文するなら、ミーティングに遅刻してしまうかもしれない!)
  2. 長い待ち行列はよいことがない。モチベーションの低下、品質の悪化、より長いサイクル時間、大きなばらつき(スターバックスを考えて)およびリスクの増加を引き起こす。(参考文献[2])
  3. プロダクトバックログは1つの待ち行列ではない。各項目は素早く納品できるよう他の項目を飛び越すことができるからである。また、常にバックログのすべてに対し、対応しないことを選択できる。(これらはどちらも、スターバックスの例には当てはまらない。)
  4. しかし、バックログの項目を利害関係者に確約している場合、バックログは待ち行列と同様に動作し、長くなればなるほど、利害関係者が対応をより長く待たなければならない。そして、長く待たせすぎると、彼らは、別のコーヒーショップを探しにいってしまう。この店では、彼らの急速に変化する市場のニーズを満たすことができないからである。

開発プログラムのスピードを上げ、素早い対応を可能にするには:積極的にバックログを管理し、そして、短くしておく。長期的な作業には、開始前に確約をしない。それよりも重要な項目が現れるかもしれないからである。もし確約が束縛になると、迅速に対応できなくなる。確かに、あなたは確約したことを実行し、信頼できるかもしれないが、時間がかかりすぎて競争に勝てないかもしれない。積極的にバックログを管理し、そして、短くする。こうすることにより、信頼性と迅速さの両方を手に入ることができる。


さらに知りたい場合

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

[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

[3] Anderson, David. Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press, 2010. (邦訳:カンバン ソフトウェア開発の変革、リックテレコム、2014)

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