☹️ 🦍 👗 柔軟なリリース計画101（Excelベース） 🐜 🏢 👨🏽

翻訳者の序文：最近、アトラシアン製品ファミリーを使用して製品リリース計画プロセスを実装する方法について話し、Team Foundation ServerとRedmineで同じことを行う方法に関する記事へのリンクを提供しました。

そして、会社がJIRA、TFS、またはRedmineを購入する準備ができていない場合、どうすればExcelだけを実行できますか？

この記事では、その方法について説明します。

この記事では、リリース計画を作成するための簡単なメカニズムについてお話したいと思います。柔軟なリリース計画の根底にある原則と価値については触れませんが、記事の最後に、これを理解するのに役立つ資料へのリンクがあります。

これはリリース計画を立てる1つの方法に過ぎず、他にも多くのオプションがあると確信しています。このアプローチは、さまざまなサイズと複雑さの多くのプロジェクトで、さまざまなサイズの多くのチームで使用しました。多くの場合、私はそれを拡張して補足しましたが、基本は常に同じままでうまくいきました。チームでこれを行う方法についてコメントさせていただきます。

ユーザーストーリーのリスト（製品バックログ）

まず、ユーザーストーリーのリスト（製品バックログ）が必要です。簡単にするために、4つのフィールドのみがあります。

IDは、各ストーリーの一意の識別子です。私の例では、1000から始めました。IDをデフォルトの優先度フィールドとして使用しないことをお勧めします（使用するためのこのようなオプションも見ました）。

ユーザーストーリーは、各ユーザーストーリーの簡単な短い名前です。「ユーザー履歴名」フィールドに履歴を完全に書き込もうとする必要はありません。リストの拡張バージョンでは、履歴の完全な説明、受け入れ基準、分類オプションなどの個別のフィールドを追加できます。

優先度 -このフィールドは、製品所有者がストーリーを受信する順序を示します。この番号には、隠されたロジックが番号に埋め込まれてはなりません（少し後で説明します）。

労働評価 -ストーリー実装のチームの推定労力。ストーリーポイント、開発日、時間をすぐに使用することは提案しません。冒頭で、スクラムチームが使用するのに便利な高レベルの評価システムを使用することをお勧めします（後で意味が明らかになります）。

カスタムストーリーの追加

ユーザーストーリー生成ワークグループ、顧客フォーカスグループなど、ユーザーストーリーを収集する方法は多数あります。これについては、この記事の主題ではないため、ここでは説明しません。ただし、製品所有者はそれらを収集してリストに追加します。通常、ストーリーをブレーンストーミングするときは、世代が存在する順序でストーリーを記録するだけで、この段階では分類または優先順位付けを試みません。時にはこれはアイデアの流れを妨げる可能性があります。そのため、ストーリーのリストを作成する必要があります。

Excelのストーリーの初期リストの簡単な例を次に示します（ウォールステッカーの後に使用できる最も簡単なツール）。

初期の高レベルの優先順位付け

リストがある場合、チームに評価を求める必要があると言う人もいますが、最初に高レベルの優先順位付けを行うことをお勧めします。そのため、最初に最も重要だと思われるストーリーにチームの時間と注意を集中させます。

必要以上に難しくしないでください。次のようないくつかの値を持つ単純なメトリックを使用します。must（必須）、need（明確に必要）、want（希望）。または、1,2,3を使用します。または-高、中、低。実際、それらの間に大きな違いはありません。この例では、1,2,3を使用します。Excelでリストを並べ替える方が簡単になるからです。

リストを見て、各ストーリーの議論に1分以内で専念し、各ストーリーに最初の優先順位を付けます。このイベントに参加するすべての人が、これが最終的な優先事項ではなく、プロジェクトの過程で再評価および変更できることを理解してください。これは、あらゆるものを死に至るまで分析する衝動を抑えるのに役立ちます。

主な優先事項を含むストーリー（製品バックログ）のリストを以下に示します。（注：私は物語を作り上げたので、それらに固執しないでください。）

初期の高レベルの労働投入量の推定

最初の優先度でソートされたストーリーのリストを取得したら、それをスクラムチームに渡して、複雑さの初期の高レベルの推定値を提供します。プロセスのこの段階では、優先度と同様に、小（小）、中（中）、大（大）などの単純なインジケータを使用して、同様のアプローチを使用できます。優先順位の場合のように、これらの推定値は最終的なものではなく、チームは将来、それらをより綿密に研究するように求められるため、時間をかけすぎないようにしてください。これは幸いです。エンジニアは正確であることが大好きであり、彼らを浅くすることは非常に難しいからです。たとえば、プレーニングポーカーなど、チームに合った何かを知っている評価方法を使用できます。

チームが評価に通常のメトリック（たとえば、フィボナッチ数列）を使用できると確信している場合は、それを使用させます。私が提案したアプローチは、実際にはすべてがまだ一般的な用語である最初の段階で最良であり、そもそも何をする必要があるのか、そしてどのくらいのコストがかかるのかを知りたいだけです。既に述べたように、プロジェクト中は常に優先順位と評価を指定します。ストーリーのリストが十分に長い（長い）場合は、ビジネスにとって最も価値のあるトップストーリーに注目する必要があります。

初期の労働強度の推定値を含むユーザーストーリーのリスト。

ユーザーストーリーと優先度を調整する

プロダクトオーナーはストーリーがいかに面倒かをある程度理解したので、優先順位を変更したり、ストーリーを共有したりできます。彼がそれらを受け取りたい順番で決めた後、物語の優先順位を示すために彼のアプローチを変える時が来ました。

前述のように、優先度フィールド（実行順序）に追加のロジックはありません。この形式で番号を使用しているのを見ました-1102。これは、関係者が2011年2月までに物語を実現したいことを意味します。これは、この日付より前にストーリーを実装するようチームに圧力をかけ、関係者はこれが行われる日付であることを意味するため、良いアプローチではありません。しかし、この数値は通常、チームの速度やチームが提供する評価に基づいていないため、これは災害のレシピです。

この方法でフィールドが使用されないようにする最善の方法は、常に1から開始し、残りのストーリーに順番に番号を割り当てることです。リスト内のストーリーを再配置するたびに、優先順位番号は1から始まります。開発の反復（スプリント）が完了すると、リスト内の残りのすべてのストーリーに再び1から優先順位を割り当てます。数。

優先度のあるストーリーのリスト-実行の順序。

労働投入量の推定値の改善

最初の優先順位付けと同様に、スクラムストーリーのリストをチームに渡し、チームが通常の測定システムでグレードを調整できるようにします（最初にそうしなかった場合を除く）。次のイテレーションで実装される可能性が高いため、トップストーリーでより多くの時間を費やしてください。次に、ストーリーのリストにできる限り進むようにします（そのサイズと利用可能なチーム時間に応じて）。一般に、スクラムチームは各イテレーション中にその時間の10％から15％を費やして、最初に発表されなかった新しいユーザーストーリーが表示されたときにストーリーのリストを整理するのに役立ちます。そのコンパイル。

これで、チームの能力を最大限に活用して優先順位を付けて評価されるストーリーのリストができました。

リストの一部の記事にはかなり大きな評価があることに気付くでしょう。これは、不確実性、リスク、ネットサイズ、複雑さなど、多くの要因によって引き起こされる可能性があります。スクラムチームは、ストーリーの最大サイズを決定する必要があります。これにより、反復に含めることができます。この境界を設定すると、チームは、自分の意見では1回の反復では完了できないストーリーを返すツールを提供します。プロダクトオーナーは、これらのストーリーを打ち破るか、チームの質問に答えて、成績を改善および削減できるようにする必要があります。

大規模なユーザーストーリーはリストの一番下にあります。近い将来に実装されるとは思わないため、後でリストに載り、反復に含まれるようになると、それらに戻ります。リストの上部に大きなストーリーがある場合は、許容可能なサイズになるまでリストを分割するか、リストの下に移動する必要があります。

このリストでは、大きなストーリーが一番下に移動され、優先度フィールドが1から再入力されます。私のスクラムの例では、コマンドは13より大きいストーリーは1回の反復には大きすぎると判断しました。

初期パフォーマンスの決定

パフォーマンス（速度）は、チームが反復中に完了するすべての複雑さの見積もりの合計です。プロジェクトの開始時には、チームのパフォーマンス（パワー）がどうなるかわからない場合があります。繰り返しの長さ、利用可能な開発者の日数、チームの規模などに基づいて、オンラインアルゴリズムと優れた数学を備えたあらゆる種類のオプションを見ました。どの方法を使用しても、間違いを犯す可能性が最も高いことを知っておいてください。これは正常です。最初の反復の後、実際のパフォーマンスが得られ、使用と追跡を開始できます。

スクラムチームと会合を持ち、リストの一番上にあるストーリーについて話し合い、最初のイテレーションでどれくらいのストーリーを取ることができるかを尋ねることをお勧めします。間違いを犯す可能性はまだ大きいので、これに時間をかけすぎず、チームが計算を遅らせることはありません。

例として、15に等しい初期計画生産性を検討します。反復の期間は3週間で、プロジェクトは2013年1月1日に開始されます。

初期リリース計画の作成

優先順位付けおよび評価されたストーリーのリスト、およびチームの初期生産性（リリースリリースを計画するときに計画パフォーマンスと呼びたい）があれば、リリースリリース計画の作成に最初のパスを作成できます。リストの一番上から始めて、15に達するまで（またはその数値を調べる直前に）スコアを合計していきます。スコアが13のストーリーがあり、次のストーリーのスコアが3の場合、反復でそれらを結合しないでください。これは、計画パフォーマンス15を超えるためです。リストの下部にあるストーリーが大きすぎて、 1回の反復で実装を行う場合、それらで停止します。

Excelでこれを行う場合、以下に示すように、繰り返しでストーリーのグループ化を簡単に示すために代替色を使用します。

ストーリーは計画されたパフォーマンスに基づいて反復でグループ化されるので、プロジェクトの提案された開始日と反復の長さを使用してグループに日付を追加し、ストーリーのタイミングのアイデアを得ることができます。これは非常に高いレベルであり、新しい反復ごとに計画が絶えず改訂されることを忘れないでください。

この時点で、製品所有者はリリース日に関連する利害関係者と議論を開始できます。一部の企業は顧客にとって十分な価値があると考えるたびにリリースを発行するため、最初は利害関係者はほとんど日付を無視し、リストからすでに受け取ったストーリーの数と、機能が使えるようになるまでの残りの量を単純に調べます顧客に転送されます。その後、次のイテレーションで修正されることを考えると、いつになるかについてある程度の考えを持ちます。

会社がリリースの計画的リリース（たとえば、年中旬の計画的リリースまたはその他のオプション）を作成する場合、リリースのリリース日に近い反復の終了日を見つけることができます。その後、どの機能が実装され、クライアントにどのような価値をもたらすかを確認できます。顧客に最大の価値を提供するためにユニットとして提供する必要がある機能グループの実装の計画タイムラインが目標リリース日を超えると、問題が発生する可能性があります。その場合、製品所有者はいくつかの難しい選択を行う必要があります。

ほとんどの場合、明らかになったらすぐにストーリーのリストのグルーミングが行われます。このようにして、プロダクトオーナーはストーリーの移動、分割、結合などを行うことができます。プロダクトオーナーはストーリーのリストを確認するたびに、評価を確認するようにチームに通知する必要があります。これは、彼が単にストーリーを移動した場合でも発生するはずです。一部の推定値には、履歴Aがすでに作成されていて、それらをスワップする場合に推定値を明確化する必要がある場合に実装が容易なポイントBに関する仮定があるためです。

今後のバージョンでは不要になるストーリーを含むスプレッドシートに別のシートを作成することを検討し、リリース作業計画として必要なストーリーとともにシートを使用します。その後、プロダクトオーナーはシート間でストーリーを移動できます。これは、ストーリーのリストが多数ある場合に役立ちますが、リリースに関してはそれほど多くありません。それらを分離しておくと、管理しやすくなります。

各反復でのリリース計画の改訂

反復のたびに、プロダクトオーナーは利害関係者と協力してストーリーのリストを常に確認し、スクラムチームからスコアを受け取るだけでなく、追加、削除、調整、優先順位付けを行います。

反復の最後に、スクラムチームの最新の実際のパフォーマンスを取得し、履歴データと一緒に使用して、計画されたパフォーマンスを調整できます。 1つのアプローチは、最低の3つと平均を取り、最悪の計画パフォーマンスを計算してから、最高のシナリオの最高3つを平均することです。利害関係者にこの範囲のリリース計画を提供すると、利害関係者が個々の日付に固執しないようになります。

更新されたリリース計画は、各反復後にチームと関係者と共有する必要があります。リリースの目標日に近づくと、ストーリーリストとリリース計画がより明確で正確になります。理解すべき主なことは、リリース計画がEtch-A-Sketchに似ていることです。Etch-A-Sketchは、最新の証拠に基づいて、各反復の最後に振って再作成します。

リリース計画の追加と改善

この単純なアプローチはうまく機能しますが、ほとんどの場合、特定のニーズを満たすためにそれを拡張および補足する必要があります。追加しすぎないように注意し、リリース計画を計画から外れるようなものにしてください。とても簡単です。さまざまな理由で作成しなければならなかった一般的なアドオンを次に示します。

バグの追加 - バグをリストおよびリリースプランに含める際のバグの処理方法に関する多くの議論に参加しました。多くの人は、エラーを除去する複雑さを評価することに時間を費やすことを好みません。これは、多かれ少なかれ正確な評価を行う前に、まずその原因を理解する必要があるためです。これらの場合、私は彼らがどのように自分のリストにエラーを載せるかを見て、最も重要なものを解決するために各反復のパフォーマンスの特定の割合を単に割り当てました。これがあなたのアプローチでもある場合は、計画されたパフォーマンスを調整して、リリースリリースの計画時にエラーの修正に伴う割り当てられた作業を排除します。

残念ながら、多くの企業が対処する必要があるエラーの重要なリストとともにアジャイルに来ています。彼らの場合、ストーリーとストーリーのリストにエラーを追加しました。それらは、リストの他の記事と同じ方法で評価され、優先順位付けされました。これにより、オーバーヘッドコストが増加しますが、製品に対する累積エラーの影響を制御する必要がある場合には正当化される場合があります。エラーが一覧表示されるため、リリース計画時に通常の計画パフォーマンスを使用できます。それでもかなりの数の新しいエラーがある場合は、各反復の結果として表示される新しいエラーの平均数に関する履歴情報に基づいて、計画されたパフォーマンスを調整できます。もちろん、このような状況にある場合は、明らかに品質の問題があり、プロセスと品質に責任のあるプロセスの品質を改善するためにいくつかの手順を実行する必要があります。

リストにエラーを追加するとともに、Typeという名前の新しいフィールドを追加しました。これは、ユーザーストーリーまたはバグのいずれかで、リストまたはリリースプランを表示するときに区別できるようにします。異なる色を使用することもできます。そのため、後で、その意味に基づいて（たとえば、ユーザーストーリーの場合は緑、エラーの場合は赤）、リリース計画をざっと見て、このリリースの新機能の数を把握できます。

分類とグループ化 -多くの場合、ストーリーのグループは「機能」（ビジネス機能）を構成し、クライアントに新しいリリースから十分な価値を与えるためにまとめる必要があります。関心のある関係者は、これらの「機能」に関するレポートを必要とし、必要なすべてのストーリーがいつ実現するか、グループがすでに何件のストーリーを行ったか、さらに何をすべきかを示します。これを表示するには、「Category」という列を追加するだけです。このレポートの使用に関する問題は、複数または階層的なグループ化が必要な場合に発生します。たとえば、追加のカテゴリ列（カテゴリ1、カテゴリ2またはメインカテゴリ、サブカテゴリなど）を追加して、このような場合にいくつかの簡単なオプションを試すことができます。 1つのフィールドに固定してセパレータを使用することもできますが、Excelでフィルタリングして簡単なレポートを作成するのはそれほど簡単ではありません。

ベースライン -現在のリリース計画が過去と比べてどのように見えるかを尋ねる人が常にいることは驚くことではありません。これは、アジャイルのコアバリューである変更を受け入れることができないことを反映しているため、非常に危険です。あなたがこのような何かを求められたら、私は彼らがなぜこれを知る必要があるのか、そして彼らがこの情報をどうするつもりなのかを理解することを勧めます。ストーリーのリスト（製品バックログ）が変更されることが想定されており、リリース計画は上部の単純なオーバーレイであるため、これも変更する必要があることを意味します。

ビジネス価値と投資収益率（ROI） -ビジネス価値は、ストーリーのリストをソートするための唯一の指標と誤って見なされることがあります。通常、ビジネス価値は具体的なものです。たとえば、「機能」Xを追加すると、次の四半期に顧客数が10％増加し、1,000,000ドルの追加売上につながります。それについて議論することはできません。しかし、「機能」Xの実装の複雑さの見積もりが1,500,000ドルである場合はどうでしょうか。

あまり説得力のない理由で「機能」を実装できる場合もあります。予備（ベータ）リリースのテストに大いに役立つ重要なクライアントがいるかもしれません。彼らは本当に欲しがる「機能」を持っているかもしれませんが、それは顧客（市場）のより広いサークルにとってそれほど必要ではありません。この関係を維持するために、この「機能」を実装することを決定できます。

これは、リストからのストーリーの「値」の定義に含めることができる多くの変数があることを示唆しています。私は、ビジネス価値の評価を与えることは正当であると信じており、一般リストの履歴の優先順位を決定する際の別のパラメーターとして使用します。シンプルに保ち、使用方法を説明してください。 1つの例は、0から1000までの評価です。ここで、1000は最高値です。もちろん、すぐにすべてのストーリーが1000に設定され、ここでガイダンス（説明）が必要になります。たとえば、ストーリーの750から1000の範囲は、次のリリースで実装されない場合、既存または潜在的な顧客を失うことにより、企業に大きな市場シェアをもたらします。

このスケールを使用すると、投資収益率（ROI）の簡単な計算を実行できます。予想される労働投入量によってビジネス価値を分割し、相対的な収益性に関する洞察を得ます。これは投資収益率を計算するための非常に単純化されたアプローチですが、高レベルでは優れています。 1000と推定されるが、20の複雑さの推定では、500の履歴と5の複雑さよりもROIが低いことがわかります。

Habrahabrの主題について他に読むべきこと

他のツールでそれを行う方法

Team Foundation Server で-TFS 11 Betaの柔軟な作業計画と管理について
Redmineで-Redmineの運用計画
at JIRA- アトラシアンツールによる「製品リリース計画」手順の実装

コンセプト記事

柔軟なリリース計画101（Excelベース）