完成した機能とプロジェクトの初期要件を比較する公式/非公式の手段はありますか? 具体的には、私の目標は、プロジェクトの早い段階で見逃された要件を特定することです。多くのアジャイル/スクラム方法論の記事や本を調べた結果、これを行う 1 つの方法は「スプリント レビュー」中の要件レビューですが、他にテクニック/ツールがあるかどうか疑問に思っていました。
ありがとう、
1510 次
4 に答える
3
完成した機能とプロジェクトの初期要件を比較する公式/非公式の手段はありますか?
あなたが探している言葉は「完了基準」です。アジャイルの世界では、言葉そのものよりも深い意味があります。それが見つからない場合、アジャイル組織で最初に修正されることがよくあります。以下 (最後) は、それをより詳細に説明する記事へのリンクです。
ほとんどのアジャイル チームは、ユーザー ストーリーを「初期要件」として使用します。ユーザー ストーリーは、チームを開始するのに十分な最初の要件になります。使用される尺度は、ほとんどのチームが「完了基準」と呼ぶものでなければなりません。すべてのユーザー ストーリーには、完了基準が必要です。たとえば。バックログを完了したと呼ぶには、これらのリストを完了させる必要があります。これを設定している間は、どのように行うかは気にせず、何をする必要があるかだけを考えます。
スプリント レビュー中に、チームは動作中のソフトウェアを見せて説明し、それが完了基準を満たしている場合、PO は正式に完了としてマークされることを承認する必要があります。
もちろん、特に新しいチームやプロジェクトでは、ユーザー ストーリーの完了基準が変更されることがありますが、それはまったく正常なことです。優れたユーザー ストーリーの兆候は、それが交渉可能であることです。チームの承認を得た後、完了基準をわずかに変更できます。変更によって実行する作業の複雑さが劇的に増加しない限り、チームがこれらを不承認にすることはめったにありません。
要約すると：
初期要件、つまり、ユーザー ストーリーには「何を」完了基準が必要です。スプリント中に何かが見落とされて発見された場合、PO はチームからの承認を得た後、ユーザー ストーリーの完了基準を変更できます。
スプリント レビュー中に、動作中のソフトウェアを完了基準に照らして測定できます。それが測定された場合、ユーザー ストーリーは完了したと見なすことができます。
http://scrumalliance.org/articles/105-what-is-definition-of-done-dod
于 2010-12-29T06:39:59.923 に答える
1
アジャイルなアプローチでは、要件の変更が予想され、健全であると見なされます。変化への対応は、計画に従うことよりも重要であると考えられています。
スプリント レビューは、フィードバックと新しい要件を収集する 1 つの場所です。ユーザビリティテストも役に立ちます。しかし、最も役立つのは、QA チームや実際のユーザーによるソフトウェアの多用です。
JIRA と GreenHopper を使用して (ストーリーとして) 要件を管理している場合は、特定の日付以降に作成されたストーリーを検索すると役立つ場合があります。変更された要件を見つけることは、より興味深いでしょう。
于 2010-12-28T16:10:48.363 に答える
1
ソフトウェアは完成していますか? 明らかに、完全性の真のベンチマークは、ソフトウェアが何をすべきかについての誰かの心の視点です。
人の精神的イメージを測定しようとすることは、最終的には困難であり、正式な方法で実際にうまくいくことはありません. あなたが測定できる唯一のものは、彼らがあなたに与える要件です. 対処されていない要件を見ることはできますが、彼らが教えてくれなかったことのギャップを測定することはできません。
私がアジャイル派から得たメッセージは、完全性を測定するのは一種の時間の無駄だということです。それは本当に間違った質問です。
たとえば、スクラムでは、すべての要件の優先順位を付けたバックログを作成し、リストを下に進めていきます。お金/欲望が尽きたら...あなたはやめます。
于 2010-12-28T16:11:59.153 に答える
0
あなたが示唆するように、アジャイル/スクラム ルートに進む場合は、通常、プロジェクトを小さな個別の作業単位に分割する必要があります。プロジェクトにはエピック (またはエピック) が含まれ、エピックにはストーリーが含まれ、ストーリーにはタスクが含まれます。(タスクは理想的には 4 時間から 8 時間の作業である必要があります。誰かが 1 日の勤務時間内に実行できるものです。)
各ストーリーが完成したら、テストして検証する必要があります。ストーリーの他のタスクが完了するまで、ユーザーは 1 つのタスクをテストできないことが多いため、これは通常、タスクに対しては行われません。ユーザーが「注文をデータベースに永続化するメソッドを記述する」ことをテストすることは期待できませんが、代わりに「このボタンをクリックすると、注文がデータベースに永続化され、ユーザーには更新されたショッピング カートが表示されます。税金と配送料を再計算しました。」
このテスト/検証は、開発者によって行われません。製品/プロジェクトの担当者またはその代理人によって確認する必要があります。開発者は当然、自分が書いた通りにテストし、そのように動作することを期待します。要件で何かが誤解された場合、それは再び誤解されるだけです。
各ストーリーが完成したことが確認されると、それはプロジェクトの完了に向けた個別の測定可能なステップになります。(関連するタスクの数と、合計に対してどれだけの作業が完了したかによって測定できます。)
このような測定値は、スプリントごとに変わる可能性があることに注意してください。上層部がプロジェクトの最後に至るまでの完全なステップを含む単一のロードマップを探している場合、彼らはアジャイル開発の基本的な概念を誤解している可能性があります。それ以降のストーリーは、まだ完全には定義されていません。直近のストーリーで行われた開発 (および変更) に基づいて、当初の見積もりよりも多かれ少なかれ作業が必要になる場合があります。
流動的なストーリーと変化する要件の概念にアプローチしようとする 1 つの方法は、「プロジェクト」ではなく、エピックとストーリーだけで考えることです。これらの個別のユニットは、それ自体で完全に機能し、テストできる必要があります (もちろん、前提条件として他のユニットを持つものもあります)。優先順位を変更すると、ストーリーを自由に動かすことができます。優先度が変更された場合、「プロジェクト」を「保留」する必要はありません。そのストーリーは、他のストーリーの代わりにバックログに移動するだけです。
目的地のリストを提供し、正しい順序で目的地に到着することを期待するだけでなく、管理者が次に行く場所を操縦しているという考えです.
この意味で、「プロジェクト」の「完全性」はほとんど意味を失います。どの程度「完全」であるかは、製品/プロジェクトの所有者次第です。自由に追加したり削除したり、優先順位を簡単に変更したりできます。それは彼ら次第です。途中の各ステップに含まれる作業量の見積もりを彼らに与えました。あなたが仕事を提供している間に、そこに到達するための最良の方向であると彼らが考えるものに舵を切るのは彼ら次第です.
于 2010-12-28T16:08:57.510 に答える