アジャイル スクラム アーティファクト

アーティファクトという言葉は多くの場合、考古学的な遺跡や古代遺物に関連しますが、ソフトウェア開発では、製品の開発中に必要な重要な情報を指します。

アジャイルには、ソフトウェアをビルドするための計画、開発、追跡、およびタスクのイテレーションといったスクラム エクスペリエンスから生じる、独自の特定の副産物があります。

アジャイル スクラム アーティファクトとは、開発中の製品、製品作成のための活動、およびプロジェクトで行われている活動を説明するためにスクラム チームと関係者が使用する情報です。これらのアーティファクトは、スプリントのパフォーマンスについてインサイトを得るためのメタデータ ポイントを提供します。透明性、検査、適応といったスクラムの核となる属性を有効にするため、すべてのスクラム チームにとって不可欠なツールです。

アーティファクトは、スクラム スプリントの主な活動において作成されます。

• 作業と将来の目標を計画する
• これらの目標を達成するためのタスクを作成する
• 優先順位と依存関係に基づき、タスクをスプリントに整理する
• タスクを実行する
• 目標と比較するために、結果をレビューし分析する
• この手順を繰り返す

アジャイル スクラムの主なアーティファクトはプロダクト バックログ、スプリント バックログ、およびインクリメントです。

プロダクト バックログは、製品のビルドに必要な新機能、機能強化、バグ修正、タスク、または作業要件のリストです。顧客サポート、競合他社の分析、市場の需要、一般的なビジネス分析などの入力ソースから収集されます。

プロダクト バックログは「ライブ」なアーティファクトであり、新しい情報が利用可能になると要求に応じて更新されます。プロダクト バックログはスプリント サイクル間や任意の新しいアイデアが出たときに、プロダクト所有者が維持し、編集するバックログで複数のチームが利用します。これには、以前はアクティブ スプリントにあったもので、優先順位が変わったためにバックログに移されたタスクが含まれています。

スプリント バックログは、次の製品のインクリメント中に開発すべくプロダクト バックログから移された一連のプロダクト バックログ タスクです。スプリント バックログは、将来のインクリメントのための成果物を計画し、インクリメントの作成に必要な作業を説明するために、開発チームによって作成されます。

スプリント バックログは、プロダクト バックログからタスクを選択し、より小さく作業可能なスプリント項目にそのタスクを細分化することによって作成されます。多くの設計と開発のサブタスクを必要とする「ショッピング カート ページの構築」のようなタスクを例にとって考えてみましょう。プロダクト バックログにはプライマリー タスクを置きますが、「ショッピング カートのビジュアル デザイン モックアップの作成」や「ショッピング カートのセッションをプログラムする」といったサポート タスクは、スプリント バックログに置きます。

スプリント バックログは、スクラムのスプリント計画段階で更新されます。小さなスプリント タスクは、設計と開発のような関連するチームに割り当てられます。チームにすべてのスプリント タスクを実行するキャパシティがなければ、残りのスプリント タスクは将来のスプリント用のスプリント バックログで待機します。

製品のインクリメントは、スプリント中にプロダクト バックログ タスクを完了することによって生成された顧客への成果物です。また、すべての過去のスプリントのインクリメントも含みます。各スプリントには常に 1 つのインクリメントがあり、インクリメントはスクラム計画段階において決定されます。インクリメントはチームが顧客へのリリースを決定するかどうかに関わらず発生します。製品のインクリメントは非常に便利で、バージョンの追跡において CI/CD を補完し、必要であればバージョンのロールバックにも役立ちます。

チームは、すべての作業をバックログ項目に並べておくことでメリットを得ます。たとえば、ブランチを作成し、バックログ項目ごとにビルドします。バージョン管理ツールと CI/CD ツールをスクラム追跡ソフトウェアに統合して使用するチームは、作業の進捗状況をよりよく理解するためにこれらのツールからの情報を活用できます。また、どのバックログ項目がデプロイされ顧客にリリースされるかについて判断することもできます。これにより、チームはコミットを逆から検討し、それらをスクラム インクリメントに結び付け、そのコードの履歴と計画を確認することもできます。

これまで説明した正式なスクラム アーティファクトに加えて、拡大アーティファクトやメタ アーティファクトもあります。正式なスクラム ガイドラインでは、正式なものとみなされていないこれらの拡大アーティファクトは、スクラム サイクルに価値とインサイトを追加します。

スプリント バーンダウン (またはバーンアップ) チャートは正式なスクラム アーティファクトではありませんが、多くのチームがスプリント期間中のスプリント目標に関する進捗状況の伝達と追跡に使用しています。バーンダウン チャートは、スプリントの期間中に完了したタスクを表示するグラフです。バーンダウン チャートは、チームのアクティブな実行ベロシティを測定するのに非常に役立ちます。これを見れば、チームは計画された作業を完了できるのか、スプリント タスクの優先順位を見直す必要があるのかがわかります。

スプリント計画中、チームは過去のバーンダウン・チャートを見て、次のスプリントで完了できそうな現実的なタスク数について見当をつけられます。チームは進行中のバーンダウン・チャートを検討し、スプリントを完了するために目標どおりに進んでいるかどうかを確認できます。また、スプリント・レビュー中に、チームはバーンダウン・チャートを見直して、期待どおりに進んだ箇所、失敗した箇所を見つけられます。時間が経過するにつれ、バーンダウン・チャートは、チームがスクラムの計画段階で見積もりをより適切に改善するのに役立つようになります。

チームが明確な「完了」の定義を持つことは重要です。この定義は文書化し、共有すべきもう 1 つのアーティファクトとなりえます。開発チーム向けの完了の定義例は、コードが仕様に一致する自動テストの対象となり、本番環境にデプロイされるといったことです。明確な完了の定義を持たないチームは、スプリント レビューでしばしば「これで完了なのだろうか?」と自問することになります。これはオープンなスクラム タスクをレビューする場合に起こります。

完了の定義はインクリメントの境界の定義に役立ちます。インクリメントは以前のインクリメントの追加である完全で利用可能なパッケージで提供されなければなりません。完了はまた、タスクが終了し、バーンダウン追跡を終了できるタイミングも定義します。

スクラム アーティファクトはチームのより効率的な運用に役立つ強力な支援手段です。そのため、すべてのチームがアーティファクトにアクセスして確認できることが重要です。プロダクト所有者とスクラム マスターは、開発チームとともに定期的にアーティファクトをレビューし、議論する必要があります。これにより、チームは運用上の非効率な部分を常に認識し、ベロシティを向上させるための創造的な方法を生み出すことができます。