Geo とディザスタリカバリ - アジャイル作業項目の階層

このセクションでは、Geo チームが要件をエンジニアが実装ワークフローを通じて進める作業中の項目に分解するアプローチについて説明します。

まず、共通の業界用語と整合性を持たせるために一般的なアジャイル作業項目の用語を説明します。次に、これらの一般的な用語を GitLab が使用する具体的な作業項目の用語にマッピングします。

最後に、新しい項目を作成する際のガイドラインと適切な粒度を選択するためのヒントを提供します。

アジャイル用語

以前の経験によっては、アジャイル開発環境での作業項目を参照するさまざまな用語に慣れているかもしれません。ただし、通常はプロジェクトの作業をますます大きなスコープのグループに整理するために階層構造が整備されています。

この階層の一般的な内訳は次のとおりです:

ユーザーストーリー

まず、ユーザーストーリーの定義から始めます。これは、システムのユーザーに提供される低粒度の機能またはビジネス価値の一部の説明です。できる限り技術的な専門用語やドメイン固有の用語を使わない平易な表現で記されることが多いです。

ユーザーストーリーの要点は、完全な機能の一部でありながら、スコープができるだけ小さいことです。つまり、より小さな作業に分割することが難しい状態を意味します。さらに分割した場合、ユーザーの観点からはテストが難しくなったり不完全に感じられたりします（つまり、それ自体では実際の価値を提供しません）。

ユーザーストーリーを GitLab での Minimal Valuable Change（MVC）の概念と混同しないでください。MVC は製品の単一のイテレーションで提供される機能のスコープを定義するために使用され、ユーザーストーリーは開発者がその部分の作業が完了したことを知るための方法で個々のビジネスロジックを記述するためのテクニックまたはテンプレートです。つまり、MVC は複数のユーザーストーリーで構成される場合があります。

ユーザーストーリーは通常、ストーリー自体と受け入れ基準のリストの組み合わせで表現されます。ストーリーの構造は次のようになります:

**<ロール>として、<アクション>を行いたい、それは<結果および/または動機>**のためです。

受け入れ基準は、ユーザーがユーザーストーリーが説明するタスクを完了できるようにする方法でシステムがどのように動作し、入力を検証するかを説明する箇条書きのリストです。

例:

ウェブサイトのお問い合わせフォームを構築しているとします。ストーリーと受け入れ基準は次のようになります: ユーザーストーリー: ウェブサイト訪問者として、ウェブサイト管理者に連絡先情報を送信したい、それは管理者がメールで私の質問に答えられるようにするためです。

受け入れ基準:

• フォームはトップメニューの「お問い合わせ」リンクからアクセスできる
• フォームは独自のページに読み込まれる
• フォームには 3 つのフィールドがある: 名前、メール、説明
• 説明フィールドは基本的なテキスト書式設定（太字、斜体、箇条書き）を許可する
• フォームはすべてのフィールドを必須として検証する
• ユーザーがフォームを送信すると、送信された情報を含むメールが [email protected] に送信される
• フォームが送信されたことを確認するメッセージが画面に表示される

この例から、各基準を個別のユーザーストーリーに分離しようとすることができますが、ユーザーに完全な価値を提供しなくなることがわかります。例えば、送信できないメニュー項目からアクセスできるフォームは、ユーザーにとってあまり役に立ちません。

機能（Feature）

この文脈での機能は、共通の目標または類似したテーマを共有するユーザーストーリーのグループ化要素です。これらのストーリーのコレクションは、システムのユーザーが実行する上位レベルの仕事に対処します。機能には、この上位レベルのスコープでの説明があり、個々のユーザーストーリーがどのように連携して機能要件を満たすかを説明します。

例を続けると、機能は「サポートリクエスト」で、お問い合わせフォームは、ウェブサイト訪問者がサポートを依頼できるさまざまな方法の 1 つのユーザーストーリーに過ぎません。この機能の他のユーザーストーリーには、FAQ を検索したり、チャットボットと連携したり、カスタマーサービス担当者とのライブチャットセッションを開始したりすることが含まれる場合があります。

Epic

Epic は、作業の別のグループ化エンティティです。これははるかに高いレベルのものであり、サブシステム全体を提供する複数の機能を含めることができます。あるいは、横断的な仕事を提供する複数のサブシステムの機能を含めることもできます。

Epic の例として、ドキュメントを閲覧する機能、他のお客様と交流するフォーラム、および上記のサポートリクエスト機能を備えたウェブサイト全体であるカスタマーサポートポータルの開発が挙げられます。

タスク

逆方向に進むと、タスクはユーザーストーリーよりも細かい粒度を提供します。タスクは多くの場合、実際には技術的な性質を持ち、ユーザーストーリーの受け入れ基準を満たすために実行する必要がある実装手順を説明します。通常、エンジニアはシステムが作業を完了したと見なすために必要な変更をまとめたタスクの内訳を作成します。

お問い合わせフォームの例では、タスクにはフィールドをレイアウトするための HTML の記述、フォームをスタイリングするための CSS の追加、フィールドを検証して送信するための JavaScript の記述、フィールドを処理してメールを送信するバックエンドスクリプトの記述などが含まれる場合があります。

バグ

これはほとんど説明不要です。バグは、製品の意図した機能の欠陥、またはシステムのパフォーマンス、ユーザーエクスペリエンス、または使いやすさを低下させる問題です。バグは通常、階層の下位にあり、ユーザーストーリーに割り当てられることが多いです。ただし、特に最初のユーザーストーリーや機能がすでにデプロイされた後に本番環境で検出された場合は、プロジェクト内の独立した作業になることもあります。

バグ項目には次の内容が必要です:

• バグが適用される前提条件またはコンテキスト
• 問題を再現するための具体的な手順
• 現在の結果とそれが問題である理由
• バグが解決されたと見なされる期待される結果

GitLab 作業項目へのマッピング

GitLab（プラットフォーム）は、開発方法論に依存しないプロジェクト管理アプローチを持っており、多くの柔軟性を提供します。ただし、これは前のセクションで提示された作業項目の階層をより明示的な方法で表す機会が少ないことを意味します。

このテーブルは、階層の概念と GitLab の実際の機能との間のマッピングを提供することを目的としています。

* タスクについては、いくつかの選択肢があります。Issue の説明で Markdown を使用してタスクリストを使用するか、GitLab 独自の作業項目タイプである正式なタスクを作成することができます。

ガイドラインとヒント

新しい作業項目の作成

• ほとんどの場合、純粋に新しい機能はプロダクトマネージャーが作成します
• 誰でも作業項目を作成できます。ただし、そのような項目の一般的な定義を遵守し、適切に使用してください。
• エンジニアの場合、新しい作業項目は Planning Breakdown ワークフローで作成し、詳細を肉付けして工数の見積もりを提供する必要があります。その時点で、Ready for Dev ステージに移す前に PM および/または EM と優先順位についてディスカッションを行ってください。
• 詳細が肉付けされ、見積もりが完了するまで、新しい項目を Ready for Dev に移動しないでください。

適切なスコープと粒度の使用

• 達成しようとしていることに適した概念と作業項目のタイプを使用してください。
• 一般的に、ユーザーストーリーから始めて、単一の項目に対して大きすぎると思われる場合はスコープ階層を上に移動する（つまり、機能や Epic に）のが良いルールです。
• 実行する必要がある技術的なタスクを特定した場合、そのための Issue を作成する前に、技術的なタスクが対応するユースケースを考えてみてください（PM からのユーザーストーリーによってすでに指定されていない場合）。これに基づいて、タスクを完了することで解決されるユーザーストーリーを作成します。言い換えると、PM の帽子をかぶり、常にユーザー中心の観点から物事を説明します。そして、技術的なタスクをユーザーストーリーに追加します。

実行のための計画

• Epic や機能については、常に一般的な説明を提供し、項目の完全な階層を作成していることを確認してください。
• Epic や機能の計画にはかなりの労力がかかるため、内訳を始めて Issue を肉付けする前に、提案する作業が PM と議論され、短期的な製品の見通しと整合していることを確認してください。そうでない場合は、実行に近い時期に肉付けできるよう、PM にバックログ項目や機能リクエストとして残しておく方が良いです。
• Epic が開始したら、スコープへの追加を控える方が良いです。機能や Epic にさらにスコープを追加する前に必ず PM に確認してください。
• Epic には実行前に見積もられた項目があるはずなので、完了の期待値を設定するために Epic の期日を使用してください。作業が進むにつれて必要に応じてこの期日を更新してください。
• Epic はすべての作業項目が完了したときにクローズする必要があります。実行する必要がある新しいスコープの作業を発見した場合は、追加のスコープが文書化され、将来のイテレーションに向けて計画できるように適切に新しい作業項目を開いてください（徹底的に議論され、正当化されない限りスコープクリープを避けてください）。

ページのソースコードを見る - ページの編集 - please contribute.