イテレーション計画とリリース計画の確立
アジャイルおよびその他の反復型手法は、イテレーションとリリースの概念を基盤としています。 この記事では、計画時のイテレーションとリリースの割り当ての概要について説明します。 この割り当てによってタイムラインが明確になり、クラウド戦略チームのメンバー間の対話が容易になります。 また、割り当てにより、実装中にクラウド導入チームが管理できるように技術的なタスクが調整されます。
イテレーションの確立
反復型アプローチによる技術的実装では、何度も繰り返す時間ブロックを中心にして技術的作業を計画します。 イテレーションの期間は通常 1 週間から 6 週間です。 多くのクラウド導入チームでの平均的なイテレーションの期間は 2 週間と言われています。 ただし、選択するイテレーションの期間は、技術的作業の種類、管理上のオーバーヘッド、チームの優先事項によって異なります。
タイムラインの作業調整を開始するには、6 から 12 か月続くイテレーションのセットを定義することをお勧めします。
ベロシティの把握
イテレーションとリリースに向けて取り組んでいくには、ベロシティを把握する必要があります。 ベロシティとは、各イテレーションで完了できる作業量です。 初期計画時のベロシティは見積もり値です。 数回のイテレーションを経て、ベロシティはチームが確実に実施できるコミットメントの重要な指標となります。
ベロシティはストーリー ポイントなどの抽象的な単位で測定できます。 また、時間数などの具体的な単位でも測定できます。 ほとんどの反復型フレームワークでは、精度や認識の点で課題が生じないように、抽象的な測定値を使用することをお勧めします。 この記事の例では、ベロシティをスプリントごとの時間数で示します。 これを示すことにより、トピックがより普遍的に理解されます。
例: 5 人のクラウド導入チームが、2 週間のスプリントに取り組んでいます。 ミーティングや他のプロセスのサポートなど、現在の責務を考えると、各チーム メンバーは一貫して週に 20 時間を導入作業に充てられます。 このチームのベロシティの初期見積もりは、スプリントあたり 100 時間です。
イテレーション計画
イテレーションを計画するときは、最初に、優先順位を付けたバックログに基づいて技術的タスクを評価します。 クラウド導入チームは、各種のタスクを遂行するために必要な作業を見積もります。 その後に、これらのタスクが最初のイテレーションに割り当てられます。
イテレーション計画中に、クラウド導入チームは見積もりを評価して修正します。 使用可能なベロシティがすべて特定のタスクに合わせて調整されるまでこれを行います。 このプロセスは、優先順位を付けたワークロードごとに、すべての作業が予測されたイテレーションに合うまで続けられます。
このプロセスでは、次のスプリントに割り当てられたタスクをチームが検証します。 チームは、各タスクに関するチームの協議に基づいて見積もりを更新します。 次に、チームは、使用可能なベロシティに達するまで、見積もった各タスクを次のスプリントに追加します。 最後に、チームは追加のタスクを見積もり、次のイテレーションに追加します。 チームは、そのイテレーションのベロシティも使い切るまで、これらの手順を行います。
前記のプロセスは、すべてのタスクがイテレーションに割り当てられるまで続けられます。
例: 前の例を基にしてみましょう。 各ワークロードの移行に 40 のタスクが必要であると仮定します。 また、各タスクは平均して 1 時間かかるものとして見積もることにします。 見積もりを合わせると、ワークロードの移行に約 40 時間を要します。 優先度の高い 10 個のワークロードすべてでこの見積もりが一貫している場合、それらのワークロードには 400 時間かかります。
前の例で定義したベロシティから、最初の 10 個のワークロードの移行に 4 回のイテレーション (カレンダー時間で 2 か月間) が必要であることがわかります。 最初のイテレーションは 100 個のタスクからなり、結果として 2 つのワークロードが移行されます。 次のイテレーションでは、同様の 100 個のタスクのコレクションで 3 つのワークロードが移行されます。
警告
前のタスク数と見積もり値は、あくまで例として使用されます。 技術的タスクが均一であることはほとんどありません。 この例を、ワークロードの移行に必要な時間数が反映されたものであると見なさないでください。
リリース計画
クラウドの導入では、ビジネス プロセスが中断されるリスクに見合うだけの十分なビジネス価値を生み出す一連の成果物としてリリースが定義されます。
ワークロードに関連した変更を運用環境にリリースすると、ビジネス プロセスに対する変更が少し発生します。 これらの変更がシームレスに行われ、サービスに大きな混乱が生じることなく変更の価値がビジネスに反映されれば理想的です。 ただし、どのような変更においてもビジネスが中断されるリスクがあるため、軽視しないようにする必要があります。
予想される利益による変更を確実に正当化するには、クラウド戦略チームがリリース計画に参加する必要があります。 タスクがスプリントに配置されると、チームは、各ワークロードが実稼働リリース可能となるおおよそのタイムラインを特定することができます。 クラウド戦略チームは、各リリースのタイミングを確認します。 次に、チームはリスクとビジネス価値の転換点を見極めます。
例: 前出の例の続きとして、クラウド戦略チームがイテレーション計画をレビューしました。 このレビューによって 2 つのリリース ポイントが特定されました。 2 回目のイテレーションで、合計 5 つのワークロードが移行可能な状態となります。 この 5 つのワークロードは、大きなビジネス価値をもたらし、最初のリリースがトリガーされます。 次のリリースはあと 2 回のイテレーションを経てトリガーされます。このときに、次の 5 つのワークロードがリリース可能となります。
イテレーション パスおよびタグの割り当て
Azure DevOps でクラウド導入計画を管理する場合は、各タスクとユーザー ストーリーにイテレーション パスを割り当てることで前出のプロセスが反映されます。 また、各ワークロードに特定のリリースをタグ付けすることもお勧めします。 このタグ付けと割り当てによって、タイムライン レポートに自動的にデータが取り込まれます。
次のステップ
タイムラインを見積もって予測を適切に伝えます。