スプリント バックログの作業項目として含めて追跡できるタスクの種類は何ですか?
(ユーザー ストーリーの) 分析、レビュー、および単体テストを含めることはできますか? または、コア コーディング タスクのみを含めてスプリント バックログに追跡することはできますか?
基本的に、私はユーザー ストーリーを技術的なタスクに分割してスプリント バックログを更新しており、コーディング以外の役割を持つタスクをスプリント バックログで更新および追跡できるかどうかを知りたいと考えています。
5908 次
5 に答える
7
作業項目として追跡したいこれらのタスクがあります。これを行うには注意してください。
なんで？プロセスを具体化し始めています。ここは滑りやすい坂道です。プロセスの具体化を開始するとすぐに、実際にはアジャイルではなくなり、必須の連続ステップの柔軟性のないウォーターフォールを作成し始めます。
これらのことが非常に重要であり、書き留めておかなければ開発者が忘れてしまうと考える場合、開発者にアジャイルであるという責任や独自の決定を下す権限を与えていません。
あなたはそれらを信頼できないものとして扱っています。
ユーザーストーリーの分析。とにかく彼らはこれをするつもりです。なぜそれを書き留めるのですか？彼らは忘れますか？ポイントは理解です。ドキュメントではありません。時間管理ではありません。
コードのレビュー。あなたは彼らにこれをしてもらいたいのです。これが行われ、結果がやりがいのある文化を作成する必要があります。
コード レビューの結果が「あなたのコードはダメだ、やり直せ」だった場合、誰も参加せず、法定通貨以外は完了しません。
コード レビューの結果が「誰もが学べる新しいベスト プラクティス」であり、さらに「おそらく他のベスト プラクティスに従ってこれを再考する必要がある」場合は、人々が参加する可能性があります。
単体テストは、質問や議論のないスプリントの一部です。
実際、それはおそらくスプリントの最も重要な部分です。単体テストは、他のほとんどのコードよりも先に行われます。これを言う必要はありません。実際、それを言う行為は、開発者がテストすることを信頼できないという主張になります。
プログラマーのためにタスクを書き留めたいという衝動に駆られたときは、その理由についても考えなければなりません。
なぜこれを書き留める必要があるのですか？彼らは何をしていないのですか？
ここが重要な部分です。
そもそもなぜ彼らはこれをやらないのですか？
彼らは分析していませんか？なぜだめですか？分析を難しくしていませんか？ユーザーは自分自身を利用可能にしていませんか?
彼らはコードレビューをしていないのですか? なぜだめですか？コードレビューへの障害は何ですか? 時間が足りない？協力が足りない？報酬が足りない？彼らを止めているのは何ですか？
彼らは単体テストを行っていませんか？なぜだめですか？テストへの障害は何ですか? 時間が足りない？柔軟性が足りない？最初にテストを行うための十分な肯定的なフィードバックがありませんか?
開発者を「制御」および「強制」する必要性を感じるのはなぜですか? なぜ彼らはこれを自分たちでやらないのですか？
于 2010-10-22T12:23:38.023 に答える
4
スプリント バックログの作業項目として含めて追跡できるタスクは何ですか?
スクラム ガイドに従って -> 計画会議パート 2 で、チームはタスクを特定します。これらのタスクは、製品バックログを機能するソフトウェアに変換するために必要な詳細な作業です。タスクは、1 日以内に実行できるように分解されている必要があります。このタスク リストはスプリント バックログと呼ばれます。したがって、上記のガイドラインを満たすタスクはすべて含める必要があります。
(ユーザー ストーリーの) 分析、レビュー、および単体テストを含めることはできますか? または、コア コーディング タスクのみを含めてスプリント バックログに追跡することはできますか?
はい、バックログを動作するソフトウェアに変換することにつながる場合は、含めることができますし、含める必要があります。スクラムは、スプリント バックログにコーディング タスクのみを含めることを決して提案しません。実際、スクラムはチームにクロスファンクショナルであることを要求します。
基本的に、私はユーザー ストーリーをスプリント バックログを更新するための技術的なタスクに分割しており、コーディング以外の役割を持つタスクをスプリント バックログで更新および追跡できるかどうかを知りたいと考えています。
これは私には疑わしいように思えます。タスクを分解するのは「あなた」だけですか？計画会議の第 2 部では、チーム全体でタスクを分類する必要があります。ここでも、コーディング以外のタスクをスプリントに含めることができます。現実的な例を挙げると、私の Web 開発チームでは、典型的なバックログに次のタスクがありました。1. 定義と発見 2. テスト マトリックスの設計と作成 3. テスト マトリックスへの単体テストの作成 3. 単体テストをパスするためのコード 4. テスト 5. 回帰テスト 6. デバッグこれが PO が望んでいるものであることを確認するため)
編集
タスクについてもう1点。計画中に追加されたタスクは、必要に応じて常に分割/更新/名前変更する必要があります。これの全体的なポイントは、やるべきことを分解した透明なセットを追加することです。これが完全に完了すると、最終的には、最も効率的かつ効果的に QA 基準に従ってソフトウェアが動作するようになります。これらのタスクは、機能横断的に取り上げて取り組む必要があり、チーム メンバー間でブロックされるべきではありません。
お役に立てれば！
于 2010-10-22T16:05:32.227 に答える
1
各ユーザーストーリーで分析、コーディング、レビュー、テストなどのタスクを作成すると、スクラムフォールと呼ばれるものに近づきます（各反復はウォーターフォールステージに分割されます）。スクラムの匂いのひとつです。基本的に、このようなアクティビティは単一のタスクに含める必要があります。「何かを行う」とは、「何か」を完了するために必要なすべてのことを行うことを意味します。
それは一般的なケースです。実際にタスクを「アクティビティ」に分割する必要がある場合もありますが、最初に共通のプロセスから始めて、本当の理由がある場合にのみこのツールを使用する必要があります。たとえば、1回の反復でのスパイクタスクと2回目の反復での実際のタスクです。
編集：私はタスクをアクティビティに分割することを一度使用しました。TDDは実行しませんでしたが、タスクの完了後にテストが作成されました。そのため、各開発タスクをテストタスクと組み合わせて、別の開発者が実行できること、場合によっては開発と並行して実行できることを示しました。しかし、別の開発者によるテストの責任はチームの決定であり、複雑なタスクについては実際にそれを行いました。
于 2010-10-22T15:57:59.487 に答える
1
簡単に言えば、あなたのチームと問題のユーザー ストーリーに最も適したものを選択してください。
たとえば、ユーザー ストーリーの一部としてコードの一部をリファクタリングする作業を行っている場合、最初にそれをテストすることを処理する別のタスクを分割することがあります。しかし、それが新しい開発である場合は、プロセスの一部としてテスト中 (通常は TDD で行われる) であると推測されます。
他の例には、調整とコーディング、外部ベンダーとの統合テストなどに費やされた時間をカバーするための別のタスクを分割することが含まれます。基本的に、その特定のストーリーを構成するのに役立つ目立たない測定可能なタスク (あなたが持っているいくつかの例を含む)上記に含まれます）。
要するに、すべてのストーリーに何を持たせるかについて決まった公式があるわけではなく、各ストーリーの個々のニーズに基づいてタスクを調整するということです (これらのタスクはコードに関連していません)。
于 2010-10-22T12:26:12.980 に答える
0
タスク追跡に適用しているすべての努力を、ストーリーをより小さく分割することに集中すると (1 ～ 3 ポイント)、より機敏になるように取り組むことができます。小さなストーリーでは、タスク レベルの見積もりや追跡はほとんど必要ありません。PO は、より小さな機能セットに優先順位を付けることができるという利点を得ることができ、明確な手順を繰り返し文書化する代わりに、価値を提供することに集中することができます。確かに、チームが合意した標準的なプラクティスをストーリーごとに時間単位で追跡することは、まったく役に立ちません。
于 2010-10-22T19:20:18.967 に答える