ユーザーストーリー
ユーザー ストーリーは、開発中のソフトウェアの要件を述べる効果的な方法です。このようなストーリーには、ソフトウェアのユーザーを代表する簡単なアドバイスが含まれています。
スクラム方法論では、目標の設定は通常、顧客またはソフトウェア所有者の特権であるため、開発プロセスに影響を与える主な方法とみなされます。各ユーザー ストーリーには、テキストの量とプレゼンテーションの複雑さに制限があります。歴史は小さな紙に書かれることがほとんどですが、それ自体が量を制限します。
ユーザー ストーリーのおかげで、クライアントの要望を文書化し、市場の要求に迅速に対応できます。
ユーザー ストーリーには受け入れテスト手順が含まれていないため、要件の単純化された尺度として考慮する必要があります。ユーザーストーリーの編集は、入会手続きに準拠する必要があります。これにより、ユーザー ストーリーが確実に目標を達成できるようになります。
ストーリー構造は次のようになります。「ユーザー <ユーザー タイプ> として、<結果> を取得するために <アクション> を実行したい」 (プロダクト所有者としては ...)。このような構造は単純であるだけでなく、誰にでも理解できるものです。
ユーザー ストーリーを使用する利点:
- ストーリーは小さく、簡単に作成できます。
- すべての関係者がプロジェクトの取り組みとそのサポートについて話し合うのを支援します。
- 定期的なメンテナンスを必要としません。
- 使用される場合にのみ関連します。
- クライアントとの対話を改善します。
- それらのおかげで、プロジェクトを小さな段階に分割することができます。
- 要件が十分に理解されていないプロジェクトの作業を促進します。
- タスクの評価を簡素化します。
ユーザーストーリーのデメリット:
- 事前の合意がなければ、手続きが合意の根拠として使用することが困難になる可能性があります。
- これらを使用するには、プロジェクト全体を通じてクライアントと緊密に連絡する必要があり、ワークフローが困難になる場合があります。
- 大規模なプロジェクトを拡張する場合には欠点があります。
- 開発者のプロフェッショナルレベルに直接関係します。
- ディスカッションを開始するために使用されますが、ディスカッションを終了することはできず、システムのドキュメントには使用されません。
やり残し
プロダクト バックログは、現在のタスクを優先順位に従ってリスト形式でまとめたものです。このリストは、プロジェクトのロードマップ（ロードマップ）とその中で定められたポイントに基づいて作成されます。通常、最も重要なタスクはリストの一番上にあります。これは、どの作業を最初に実行する必要があるかを理解するために必要です。
開発チームは、顧客の希望に関係なく、顧客の資格と過去のスプリントの経験に基づいて、バックログ タスクを完了する速度を選択します。プログラマーを「調整」することは非常に望ましくありません。チーム自体が、独自の考慮事項と能力に従ってバックログからタスクを選択します。実行は中断なし (カンバン) または複数の反復 (スクラム) なしで行われます。
2 つの重要なバックログ条件
製品バックログの中核は、ロードマップ、提案、実行条件で構成されます。エピックには条件とユーザーストーリーが含まれます。典型的なロードマップの例を詳しく見てみましょう。
「Teams in Space」Web サイトの作成は、ロードマップの最初の提案です。エピック(図では緑、青、ターコイズ色で示されています) と各エピックのユーザー ストーリーに分割する必要があります。
ソフトウェアの顧客は、複数のユーザー ストーリーから 1 つのリストを作成します。必要に応じて、開発者が最初に最も重要なエピックの 1 つ (左) を処理したり、割引チケットの予約がどのように機能するかを確認したりできるように、ストーリーの実行順序を変更できます。これを行うには、エピックからストーリーを実装する必要があります (右)。両方のオプションを以下に示します。
顧客はどの要素に基づいて優先すべきでしょうか?
- ユーザーとの関連性。
- フィードバックの存在。
- 開発の複雑さ。
- タスク間の関係 (「B」を完了するには、まず「A」を実行する必要があります)。
作業の優先順位は顧客が決定しますが、他の関係者もこれについて意見を表明できます。バックログの成功は、とりわけ、顧客とプログラマーの意見に依存します。これらを連携することで、より良い結果を達成し、最終製品をタイムリーに納品できるようになります。
バックログを維持する方法
バックログがすでに作成されている場合は、その後の作業の過程で定期的にバックログを変更する必要があります。ソフトウェアの顧客は、新しい反復計画を立てる前に、バックログが適切にコンパイルされていることを確認する必要があります。これは、最後の反復の分析後に優先順位を明確にしたり、何かを変更したりするのに役立ちます。アジャイルにおけるバックログの調整は、「グルーミング」、「改良」、または「バックログのメンテナンス」と呼ばれることもあります。
バックログがすでに比較的大きい場合、顧客は短期および長期の実行ごとにタスクをグループ化する必要があります。短期の割り当てには、このステータスが与えられる前に精査する必要があります。ユーザーストーリーを作成し、チーム内のあらゆるニュアンスを見つけ出す必要があります。
長期的なタスクについては、開発者が評価することが非常に望ましいです。こうすることで優先順位を付けやすくなります。おそらく何かが変わるかもしれませんが、チームはタスクに対する理解を深め、仕事をより速く完了できるようになります。
バックログは、顧客とプログラミング チームの間の重要な要素です。お客様は、フィードバック、予測、または新しい要件に基づいていつでも優先順位を変更できます。
操作中に直接変更を加えることは避けることをお勧めします。これは、ワークフローやプログラマーの精神状態に悪影響を及ぼします。
スプリント
スプリントは、事前に合意された量の作業を完了する必要がある短い期間です。スプリントはスクラムとアジャイルの方法論に基づいています。適切なスプリントを選択すると、アジャイル チームが高品質のソフトウェアを開発するのに役立ちます。
「スクラムを使用すると、明確な期間を持つ複数の反復、つまりスプリントで製品を開発できます。大規模なプロジェクトを小さなタスクに分割するのに役立ちます」とアトラシアンの Jira リード、ミーガン クックは言います。
スクラムはどのようにしてスプリントを計画し、実行するのでしょうか?
スクラム方法論の作成者によると、将来のスプリントを計画するには、全員が別の会議に集まる必要があります。このイベントでは、チーム メンバーは 2 つの主要な質問に対する答えを見つける必要があります。それは、このスプリントで何を行う必要があるのか、そしてそれを行う最善の方法は何なのかということです。
ソフトウェア顧客、スクラムマスター、およびプログラマーは、作業タスクのリストの決定に関与します。顧客はスプリントの目標とバックログのタスクについて説明します。
次に、チームはスプリント内のタスクを完了するための計画を作成します。この計画は、選択した作業項目とともに、スプリント バックログと呼ばれます。計画会議の後、チームは作業を開始します。開発者はバックログからタスクを選択し、作業が完了すると、各タスクのステータスが「進行中」から「完了」に変わります。
スプリント中、チームは毎日スクラム ミーティング (スタンドアップ) を開催して、現在の問題や進捗状況について話し合います。このようなミーティングは、スプリントの完了に影響を与える可能性がある問題を特定するために必要です。
スプリントが完了すると、チームは結果のレビューで作業の結果を示します (デモ)。プロジェクトの各参加者は結果を知ることができます。完成したコードを運用環境にマージする前に、習熟を行う必要があります。
振り返りによりスプリントのサイクルが完了します。それに基づいて、チームは将来のスプリントで改善する必要がある領域を特定します。
注意すべきこととしてはいけないこと
ほとんどの若いチームは、ワークフローにスプリントを初めて導入するのが難しいと感じています。問題を回避するために、優先的に注意が必要なアクションのリストを確認することをお勧めします。
やらなければいけないことは何：
- チームがスプリントの目的とそれがどのように成功するかを理解していることを確認してください。これは、全員が協力して成功した結果に向かって進むために必要です。
- 明確でわかりやすいバックログが必要です。バックログが正しく維持されていない場合、ワークフローに損害を与える可能性のある問題が発生する可能性があります。
- 夏休みやその他の要因を考慮して、仕事のペースの見積もりが正しいことを確認してください。
- スプリント計画に積極的に参加します。チームメンバーにストーリー、バグ、課題の計画を拡張するよう奨励します。
- 開発者が依存関係の問題を解決できないタスクは拒否します。
- 計画が承認されたら、プロジェクト管理プログラム (Jira カードなど) へのデータ入力を担当する従業員を任命します。
避けるべきこと:
- 大量のストーリーを使いすぎず、作業のペースを冷静に評価し、スプリントで完了するのが難しいタスクを割り当てないでください。
- 自分の仕事の質に注意してください。品質管理とコードのバグ修正に十分な時間があるかどうかを確認してください。
- チームメンバー全員がスプリントの内容を明確に理解していることを確認してください。スピードを追求しないでください。チーム全体が一緒に動かなければなりません。
- 開発者に余分な作業を負担させないでください。もうすぐ別のスプリントが始まります。
- チームが作業量や期限について懸念を表明した場合は、チームの意見を考慮する必要があります。問題に対処し、必要に応じて修正します。
スクラムボード
スクラム ボードは、スクラム チームの作業がどのように行われるかを示すツールです。このようなボード上の情報は、紙、壁、または電子形式 (JIRA、Trello) で表示できます。
スクラム ボードには、To Do、In Progress、Done の少なくとも 3 つの列があります。以下にボードの例を示します。
スクラム ボードには、以前に計画のために承認されたバックログからのすべての情報が含まれています。原則として、ビジネス タスク カードは上から下に優先順位に従ってボードに固定されます。それらを特定の種類の作業 (コード、デザインなどの作業) に分割できます。
作業の一部が完了したら、カードはボード全体で次の列に移動されます。チームの作業の進捗を可視化するには、バーンダウン チャート上の日別の「残りの作業」が役に立ちます。
フリップチャート ボードを使用することもできます。そこに作品名を紙シールに書いてボードに貼り付けます。作業が完了すると、ステッカーはすぐに別の列に移動されます。
バーンダウンチャート
バーンダウン チャートには、完了した作業量と残っている作業量が表示されます。毎日更新され、すべての関係者が利用できます。グラフは、スプリントの作業の進行状況を示すために必要です。
グラフには次の 2 種類があります。
- スプリントでの作業の進行状況を示すバーンダウン チャート。
- 製品のリリースまでの作業の進行状況を示すバーンダウン チャート (データは複数のスプリントから要約されています)。
チャートの例:
この例では心理学を使用しています。グラフには完了したタスクの数ではなく、残っている (未完了の) タスクの数が表示されます。
つまり、チームが 100 件中 90 件のタスクを完了した場合、すべての準備が完了したという誤った感覚が生じる可能性があります。結局のところ、タスクが 90 から 100 に進んでも実際には何も変わりません。
残りのタスクの数を表示すると、毎回タスクが減っていくのがわかります。これにより、プロジェクト参加者は無意識のうちに目標をより早く達成するよう促され、ボード上に未完了のタスクがあってはなりません。