🕠 😀 🧝🏾 アトラシアンのツールによる「製品リリース計画」手順の実装 🏀 👼🏾 👩🏽‍🤝‍👨🏼

これは、2017年3月1日付けのモスクワアトラシアンユーザーグループのミートアップからの私のレポートです。

コンテキストとタスク

同社は、ビジネスユニット（顧客）のニーズに合わせてソフトウェア（製品）を独自に開発しています。一部の製品は顧客に提供され、会社はその洗練、開発に取り組んでいます。

各製品のタスクの一般的なリストがあります（製品バックログ）。毎月、一部の製品の新しいリリースがリリースされます。

目標は、どの製品をリリースする必要があるか、どのクライアントリクエストが各リリースに含まれるかという質問に答えることです。

その結果、次の生産サイクルの開発計画が作成されます（スプリントバックログ）。次のサイクルでリリースされる製品リリースのリスト。

ビジネスロジック

各製品は製品所有者に割り当てられます。各ビジネスユニットは、ITビジネスパートナー（クライアントマネージャー）に割り当てられます。クライアントマネージャーは、可能な開発順序（ユーザーストーリー）で製品マネージャーに連絡します。製品マネージャーが「顧客の痛み」と「要求された薬」を理解している場合、製品にオプションを実装することの実現可能性とおおよその複雑さを評価するよう開発チームのヘッド（チームリード）に依頼します。評価結果に基づいて、顧客は注文の確定を拒否するか、拒否します。これにより、製品開発のリクエストのリストが作成されます（製品バックログ）。

改善を求めるクライアント要求の複雑さは、実動サイクルでの実行に使用可能なリソースの量を超えています。まず最初にどのような種類のリクエストを行うべきかを理解するために、プロダクトマネージャーはクライアントマネージャーを呼び出して、顧客のリクエストのリストに優先順位を付け、次の開発サイクル（スプリント）の結果としてどのリクエストを受け取りたいかを示します。そのため、次のサイクルの開発計画の最初のバージョンが表示され、クライアントマネージャーから通知されたリクエストで構成されます。

各製品は、開発チームの1つにも割り当てられます。製品マネージャーは、開発チームに将来のサイクル（スプリントキャパシティ）の利用可能な開発時間を要求します。

製品マネージャーは、プライマリプランの複雑さと利用可能なチーム力を比較します。クライアントマネージャーの希望が利用可能なリソースを超える場合、プロダクトマネージャーは会社の収益性の基準のふるいを通してタスクをふるいにかけます。出力では、サイクルごとにチームの対応する能力を実装する複雑さを伴う会社にとって最も有利な要求を伴う開発計画の2番目のバージョン。

計画内の要求は製品（リリース）ごとにグループ化され、リリース内での実装の順序が設定されます（再優先順位付け）。これは、どのクエリをどの順序で実装するかをチームに伝えます。結果の計画（スプリントバックログ）はクライアントマネージャーに伝達され、内部ポータルに投稿されます。

アトラシアン製品ファミリの技術的な実装

Jira Software

ITソリューション全体のプラットフォームとして機能します。製品の開発と完成のリクエストを会計するためのビジネス機能の実装を提供します。

JIRA標準機能を使用して、リクエストに関する情報を保存および処理するためのカスタムフィールドを追加します。

計画のために、次のフィールドを追加する必要があります。

顧客優先
実現可能性調査：期待される収入の節約
実行可能性調査のデータ：回収期間
次の開発サイクルの結果として受け取る意欲の印
開発サイクルに関する情報

リクエストの画面形式で表示する必要があるもの：作成、編集、表示。これは、画面管理パネルを介して行われます。

カスタムフィールドを含むクエリ編集画面の例。

ジェクセル

名前が示すように、これはExcelに似ています。これは、基本機能にない選択リストで作業できるJIRAプラグインです。

この場合、次の2つの機能が必要になります。

JIRAにアクセスせずにクエリを編集する

1つのページで、クライアントマネージャーはすべてのクライアントリクエストを表示し、優先度と次のリリースで表示するクライアントリクエストを表示できます。
列と選択したセルの合計

製品マネージャーは、次のスプリントのリクエストの全体的な複雑さを確認します。彼はどのくらいのリソースを持っているかを知って、開発サイクルの要求、次のものに含まれるもの、次のものに含まれるものを分散させます。

JExcelの作業ツールはワークブックであり、JIRAプロジェクトまたは保存されたフィルターに基づいて作成されます。 Jira Query Language（JQL）で記述されたフィルターはまだ理解していません。追加の設定は必要ありません。

JExcel Lite-無料、JExcel Pro-有料の2種類があります。

marketplace.atlassian.com/plugins/com.moresimp.jexcel/server/overview

moresimp.com/jexcel-lite

テンポプランナー

これは、リソースの保守、作業の詳細な計画、および可用性の計算の機会を提供するJIRAプラグインです。

従業員と曜日のスプリントタスクを計画できます。

休日や就業日、および特定の期間にわたって従業員が100％在籍していない場合のチームの従業員の在籍率を考慮に入れます。

このプラグインは、そのデータに基づいて開発チームのヘッドによって使用され、次の開発サイクルでのリソースの可用性に関する情報をプロダクトマネージャーに提供します。

プラグインは有料です。

marketplace.atlassian.com/plugins/com.tempoplugin.tempo-planner/cloud/overview

tempo.io/products/tempo-planner

合流点

これは独立した製品です。内部ポータルと会社のナレッジベースを構築するためのエコシステムとして機能するプラットフォームです。計画のコンテキストでは、次のサイクルの開発計画と過去に何が起こったのかに関する最新情報を必要とするすべての人のショーケースとして使用されます。

これは、Confluenceページでのスプリントバックログと毎月のリリース計画の様子です。

ConfluenceのJIRAに保存されたフィルターを表示する標準のJira Issue / Filterマクロが使用されます。これは、ページ上のフィルター表示を設定するための画面です。

JIRAで情報が更新されるとConfluenceで更新されるようになっているため、計画ページは計画の現在のステータスを監視するためにも使用されます。

JIRAと同様に、Confluenceは有料製品です。

計画プロセスを開発するための3つの基本的なアイデア

アイデア1

通常、状況は次のようになります。製品、それを作成するチーム、絶えず更新される製品バックログがあります。特定の日にプロジェクト/クライアント（ユーザーストーリー）の改善が必要なプロジェクトマネージャー、セールス/クライアントで補充します。マネージャーはリソースをめぐって競争し、これは次の事実につながります。

オプション番号1：チーム作業の優先順位は定期的に変更されます。マネージャーはガイドに行き、優先順位を上げて、より重要なプロジェクト、注文、またはより説得力のあるマネージャーが現れるまで、一定期間チームリソースを割り当てます。
オプション番号2：全員にリソースチームの小さな部分が与えられます。

その結果、チームは、1つのストーリーの作業を完了せずに、次のストーリーに切り替わります。新しい製品リリースのリリースは定期的に延期されます。これは、いずれの改善も準備ができていないためです。

図は、3つのクライアントストーリーがあり、1か月ごとの複雑さから、1つの開発チームになることを示しています。ストーリー間の絶え間ない切り替えにより、追加の切り替えコストが発生するため、3ストーリーすべてが4か月目にレンタルされます。

この図は、ストーリーに優先順位を付けて順次実装すると、作業を整理する従来の方法よりも速くストーリーが実装されることを示しています。上の緑の四角は、完了した注文に対する顧客からの収入の受け取りを示します。

特定のチームのリソースは、スプレーよりも集中する方が適切であり、最初のウサギが捕まるまで、2番目のウサギを追いかけないでください。

アイデア2

製品の開発期間が長くなるほど、この期間中に顧客の要件が「腐敗」する可能性が高くなり、クライアントによる彼らの実現、参照条件の変更、作業量の増加、そして開発期間の延長または耐えるためのリソース要件の増加につながります期間。この間ずっと、クライアントは当社製品なしで動作し、その恩恵を受けず、製品の最終コストが増加します。クライアントが当社に満足せず、製品が成長するリスク。

要件が「悪化」せず、クライアントが満足するように、できるだけ早くクライアントが支払いを希望する製品をリリースする必要があります。そのためには、クライアントの要件を自己完結型のブロックに分割する必要があります。最初のブロックをリリースし、2番目のブロックに着手することにより、クライアントに製品を使用して経験を積み、そのメリットを享受し、3番目のブロックの要件を明確にし、クライアントが以前に考えなかった、または必要なものを知らなかった新しい要件を注文する機会を与えます。

1か月でクライアントに役立つ1つの機能を備えたリリースは、1ダースの機能を備えたリリースよりも優れていますが、6か月または1年です。

アイデア3

各リリースには、有用な機能の開発コストに加えて、リリースの条件付き固定コストがあります。リリースアセンブリ、テスト環境の展開、および回帰テストです...

4つの製品があり、6か月ごとに各製品の新しいリリースをリリースする前に、リリースをリリースするためのコストは従来の4ユニットに等しいと想像してください。たとえば、アイデアNo. 2に基づいて月に一度リリースする場合、リリースのリリースにかかるコストは従来の24ユニットに相当します。

これにより、次のことがわかります。

以前に1つの有用な関数のリリースに1ユニットのオーバーヘッドがあった場合、現在は6ユニットになります。
20個の追加リリースを確実にリリースするには、追加のリソースが必要です。ありますか？

これらのコストを削減するには、DevOpsツールを実装する必要があります。

リリースのリリース頻度を決定するとき、現在物理的にリリースできる月あたりのリリース数と、開発された製品機能の最終コストがどのように変化するかを計算する必要があります。

まとめ

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

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

in Excel- リリース101の柔軟なリリース計画（Excelベース）
Team Foundation Server で-TFS 11 Betaの柔軟な作業計画と管理について
Redmineで-Redmineの運用計画

コンセプト記事

ビデオを報告する

アトラシアンのツールによる「製品リリース計画」手順の実装