agile - 完了のスクラム定義

Question

スクラムは理論的には簡単で、実践するのは難しいですが、完了の定義を聞きたかったのです。つまり、製品に「完了」というラベルを付ける前に、製品が通過しなければならないゲート (単体テスト、コード カバレッジ > 80%、コード レビュー、負荷テスト、perf.test、機能テストなど) は何か。

Answer 1

TargetProcess では、ユーザー ストーリーに次の Done の定義を使用します。

1. 短い仕様が作成されました
2. 実装済み/単体テスト作成済み
3. 受け入れテストが作成されました
4. 100% 受け入れテストに合格
5. プロダクトオーナーのデモ合格
6. 既知のバグが修正されました

Answer 2

それはあなたのチーム次第だと思います。プロダクトオーナーと話してください。理想的には、ストーリーが制作中で使用されているときに行われます。ただし、ストーリーの開発が完了してからライブになるまでには時間差があります。ストーリーの展開にかかった時間を追跡するのが難しくなります。

私のチームでは、完了の定義は、開発者がストーリーを完成させ、チームの残りのメンバー (テスター、製品所有者) に「ショー アンド テル」を行い、全員が満足すれば、Subversion トランクに移動することです。

さらなるテストは、トランクからの自動ビルドから行われます。

Answer 3

完璧な世界では、製品はすべての反復の最後に出荷可能な状態になります。

これは実際には製品、市場、顧客によって異なり、不可能な場合もあります。

これを達成できない場合は、次の計画期間であるリリースが適用されます。チームは全体として、製品を出荷するために必要なものを決定し、それに応じて計画する必要があります。

ここで役立つのは、タスク レベルで「完了」を定義することです。ここでの完了の定義は、はるかに単純です。あるタスクは、別のタスクを開始できるときに完了します。すべてがテストされ、統合されます。チームは、この状態を定義することもできます: 文書化済み、レビュー済み、自動ビルドに含まれている、既知の問題がない、オンサイトの顧客によって承認されている...

すべてのタスクを本当に「完了」させ、すべてのツアー バックログ アイテム (またはユーザー ストーリーと呼びます) を実際に「完了」させると、イテレーションごとに「完了」できるようになり、製品を出荷可能または展開可能な状態に保つのに役立ちます。

Answer 4

ScrumAlliance の Web サイトには、 Mitch Lacey、Dhaval Panchal、Mayank Guptaによる 3 つのすばらしい記事があります。

---

編集:基本的に要点は、チームによってプロジェクトごとに完了が定義されるということです。基本的な必要性は、定義が何であるかではなく、定義に同意することです。

Answer 5

「安定化期間」 (つまり、コードの凍結からクライアントへのリリースまでに必要な作業) を短縮するすべてのもの。