問題タブ [agile-processes]

開発環境にアジャイル手法を実装しようとしています。ストーリーには開始日と終了日が必要ですか、それとも純粋にスプリントに適用できますか?

-アラン-

しばらくの間、ユニットテストと機能テストについて読んでいます。

徹底的な機能テストを作成すると、その下にあるユニットもカバーされ、ユニット テストが冗長になるのではないでしょうか?

私たちはアジャイルに従い、機能の「スライス」が完了するとすぐに、WebDriver を使用して機能テストを作成します。これには通常 2 ～ 4 週間のスプリント時間がかかります。

私が理解しているように、アジャイルは多かれ少なかれオープンで柔軟なプロセスに似ています。つまり、ステークホルダーの急速な変化を予期し、期待しています。

しかし、これのビジネス面はどうでしょうか。利害関係者が製品に対して特定の予算を持っている場合はどうなりますか?

変更が指定された予算を超えた場合はどうなりますか?

「アジャイル契約」という用語はありますか?

プロセス レベルでのユーザー ストーリーの受け入れ基準の変更に、人々がどのように対処しているかを知りたいと思っています。

例：

機能 XYZ の受け入れ基準を含むユーザー ストーリーを作成します。そのユーザー ストーリーは、リリース 1.0 のスプリントで実装されます。しばらくして 1.2 リリースの製品所有者は、受け入れ基準を変更することを望んでいます (たとえば、30 秒ではなく 1 分間のタイムアウト)。

この変化をどのように処理しますか? 元のユーザー ストーリーのステータスはどのように変化しますか? 私たちは JIRA/JIRA アジャイルを使用しています。たとえば、閉じたユーザー ストーリーを再開して、新しいスプリントでそれらに取り組んでいるかどうかを聞くことに特に興味があります。

Confluence を使用して製品仕様を記述し、PS のユーザー ストーリーはクエリを介して JIRA から直接読み込まれます。元のユーザー ストーリーの受け入れ基準を変更して再度開く場合、バージョン 1.0 の製品仕様が変更されないようにするにはどうすればよいでしょうか?

編集：

プロセスについてさらに情報を追加する必要があります。すべてのユーザー ストーリーには、受け入れ基準と同様に、これらの基準をテストするために使用できるいくつかの手順があります。これらの手順は、すべての製品仕様が適切に実装されていることを確認するために使用される検証/テスト プロトコルを生成するために使用されます。

つまり、ユーザー ストーリーへの変更は、データが jira クエリを介して読み込まれるため、既にレビューされ、承認された製品仕様とテスト プロトコルに直接影響を与えることを意味します。これは、コンテンツを Confluence にプルする適切な方法ではない可能性があると思います。より永続的な方法をお勧めします。

これらの直接/動的クエリを使用していなかったとしても、この質問は有効です: 要件/承認基準の変更はユーザー ストーリーにどのように影響しますか?

Team Foundation Server のアジャイル プロセスを使用します。

前回のスプリントの各ユーザー ストーリーについて、元の推定作業量と実際にかかった合計作業量を示すレポートを取得したいと考えています。

それを取得できる簡単な方法はありますか、それともカスタム レポートを作成する必要がありますか?

ありがとう

スクラム テンプレート (Microsoft Visual Studio Scrum 2013.4) でバグ WIT のカスタム ワークフローを実装しようとしています。

私たちのビジネス プロセスでは、「コミット済み」と「承認済み」は必要ありません。実際、これらを再利用して、いくつかの新しい状態を追加するだけでなく、「テストの準備完了」および「テスト進行中」と呼ばれる他の状態を表すこともできます。

既存の「コミット済み」および/または「承認済み」状態を変更すると ([TFS] > [ツール] > [プロセス エディター] > [作業項目の種類] > [サーバーから WIT を開く] を使用)、それを保存し、Web ページ経由でバックログを再度開くと、エラー メッセージが表示されます。

エラー メッセージに記載されている「構成」とは何ですか?! 最初は、かんばんボードがこれらの既存の状態に何らかの形で配線されているのではないかと思いましたが、どこを見ればよいかわかりません (または、それでさえある場合)?

大規模なテンプレートをゼロから作成するのではなく、既存のテンプレートをハックします。アドバイスをお願いします。