フィードバック
ヘルプをお求めですか?CA Agile Central コミュニティは、セルフサービスとサポートのワンストップ ショップです。CA Agile Central サポートにフィードバックを送信したり、答を見つけたり、他のユーザとのコラボレーションには CA Agile Central コミュニティ にご参加ください。
アジャイル プロジェクトではソフトウェアを段階的に作成します。変化するビジネス要件に開発を合わせるために、通常では 1 ~ 4 週間の短いイテレーションが適用されます。
単一パスではなく、すべての要件とリスクを事前に予測する 6 ~ 18 か月のリリース
アジャイルでは、1 ~ 4 週間のイテレーションごとに実用的なテスト済みコードを納入して、頻繁なフィードバックに順応します。
スクラム マスタは、チームがコミットしてそれを達成できるようにアジャイル開発方法に忠実であり続けることを支援する世話役の奉仕型リーダーです。次のような職責があります。
プロダクト オーナーは、ビジネスの観点からの製品を推進します。次のような職責があります。
アジャイル チームは、イテレーションで作業を実施して、ユーザ ストーリーを実現させます。
チームは、各ストーリーのバックログ優先順位付けとサイズに基づいて、ストーリーをイテレーションに計画します。
チームはキャパシティ(タスクの実行に費やすことができる理想的な時間数)を使用して、どのくらいのスコープをイテレーションに計画するのかを決定します。
ストーリー ポイントを考慮する必要がある理由
ユーザ ストーリーは、ユーザが必要としている機能を定義する要件です。これは以下の 2 つの形式を取ります。
リリースの計画では、ポイントなどの相対的なスケールを使用して、ユーザ ストーリーのおおよそのサイズが見積もられます。
イテレーションの計画では、ストーリーがタスクに分割されます。
アジャイルでは、実用的で現実的な見積もりを作成することが厳格に求められます。
ユーザ ストーリーは、ユーザの要望を定義する what–it の説明です。
タスクは、機能を実装する方法です。ストーリーはタスクによって実現されます。実際の作業は、ストーリーよりも詳細になります。各ストーリーは実質的にはタスクの集合体です。
ストーリーをタスクに分割するのは、ストーリーが現在のイテレーションに計画されるまで待ちます。イテレーションの直前に詳細を検討することで、知見とフィードバックを活用できるからです。
タスクは時間数で見積もられます。通常の規模は 2 ~ 12 時間です。
ストーリーは受け入れテストで検証されます。
チームは何をもって「完了」とするのかを決定します。次のような基準を適用できます。
チームは「完了」を定義して、それぞれのイテレーションでその定義がすべてのストーリーによって満たされるようにすることをコミットします。
機能がプロダクト オーナーまたは顧客によって承認されるために必要な機能、動作、およびパフォーマンスを定義する基準。
承認基準の役目は、ストーリーが完了したときに開発チームがそのことを認識できるように、「完了」とは何であるのかを定義することです。定義を開発チームに任せたくないストーリー領域がある場合は、承認基準を記述します。たとえば、エラー メッセージの文言についてこだわりがある場合は、エラー メッセージの形式と文言を説明するための設計ドキュメントを提示したり、エラー メッセージを生成する可能性がある各ストーリーの承認基準を作成してメッセージの文言を指定したりすることができます。
ユーザ ストーリー、承認基準、およびストーリーを実現するタスクとして定義されます。
ヘルプをお求めですか?CA Agile Central コミュニティは、セルフサービスとサポートのワンストップ ショップです。CA Agile Central サポートにフィードバックを送信したり、答を見つけたり、他のユーザとのコラボレーションには CA Agile Central コミュニティ にご参加ください。