アジャイル環境では、バグ追跡と反復追跡はどのように統合されますか。
このトピックは、- 管理に課せられた滝のようなスケジュール に関する他の質問から生じました。他のスレッドの応答から、私は一般的にアドバイスされていることについてこれだけ集めました：
- 各ストーリーはバグなしで完了する必要があります。すべてのバグが解決されるまで、ストーリーは閉じられません。そこにはニュースはなく、私たちは皆これに同意できると思います。
- 後日、QA（またはさらに悪いことに顧客）がバグを発見した場合、レポートはバグ追跡データベースに送られ、他のすべての作業と同様に優先順位を付けるべきストーリーになります。
これはアジャイル環境でのバグの一般的な処理をまとめたものですか？
はいの場合、私が気になる部分は、チームが2つの異なるシステムで追跡をどのように処理するかです。 （ほとんどのチームが別のシステムを持っていない限り）。
ソフトウェア開発全般、具体的には優れたバグ追跡ツールの重要性に関する多くのアドバイス（Joelのブログを含む）を読みました。アジャイル方法論に関する本を読むと同時に、「純粋な」アジャイルではバグなしでイテレーションを完了するため、それらのどれもこのトピックをカバーしていないようです。どこかに穴があるように感じます。
では、実際のチームはどのように機能するのでしょうか？使用するイテレーション（ホワイトボード、Rally ...）を追跡したり、別の製品セットの何かを使用したりするバグを追跡したり（運が良ければ、HP Quality Centerで立ち往生することさえあります）。 2つの別個のシステムが必要ですか？それらが別々の場合、チームはそれらの間のインポート/同期機能の作成に時間を費やしていますか？あなたはあなたの会社で何をしましたか？バグ追跡ソフトウェアも使用されていますか？それとも、ストーリーを作成するだけですか？
"...バグを発見すると、レポートはバグ追跡データベースに入り、他のすべての作業と同様に優先順位を付けるべきストーリーになります。
問題は、バグ追跡と機能追跡が異なる場合であり、単一のシステムを使用して、反復/マイルストーンなどをスケジュールするだけでなく、両方を行うことができますか？.
「純粋な」アジャイルアプローチの観点から、チームは、自分に合ったツールとプロセスの任意の組み合わせを使用できるようにします。確かに、すべてを行う単一の製品を見つけるかもしれませんが、おそらくそれはあなたが望むようにいくつかのことをしません。複数のシステムを実行している場合は、システムをどの程度統合する必要があるかを判断し、統合が必要な場合は、それを行うための手段を見つけ、複製する必要がある情報の量を決定する必要があります。すべてはコスト/利益の状況に要約されます。そのため、採用されているすべてのシステムは、チームの全体的な効率への影響を考慮する必要があります。
私が作業している場所では、Redmineシステムを使用して、複数のプロジェクトの単一システムのバグと機能を追跡し、依存関係が存在する各プロジェクト間のリンクを設定しています。私たちは、マイルストーンに関連するラベルを作成します。これは、数週間から数か月の範囲に及ぶ効果的な長い反復です。個々のタスクと機能については、反復をあまり厳密に追跡しない傾向があるため、バーンダウンチャート、ホワイトボード、付箋、機能カード、およびそれらすべてについて心配する必要はありません。特定のニーズ、このようなものの一部はやり過ぎです。各機能自体が2〜10日間の小さな反復を効果的に表します。気になる可能性があるものについては、時間の推定値と実際の時間の対比をログに記録して後で分析します。これは少しアドホックに聞こえるかもしれませんが、私たちにとっては機能し、最終的に私たちの実際の測定は一連の時間枠内でコードを機能させることです。
別のより正式に「登録された」方法論を採用することを決定した場合、進捗状況を追跡するのに役立つツールを検討するかもしれませんが、現在の方法に現在投資しているものを使用すると、少なくとも短い機能の説明をフィードするでしょうデータを別のシステムに送信し、誰かがRedmine用にモジュールを開発していない限り、またはreallyが重要になった場合は、厄介な事態を避けるためにRedmineモジュールを自分で作成します。私たちに関係するかもしれない統合の頭痛。
バグが存在しないと100％の確信を持って現実的に言うことはほとんどありません。すべてのテストケースが綿密に考えられ、テストされ、検証されたとしても、誰かが考えていなかった状況が1つあるでしょう。お客様が特定したバグは発生しますが、それは世界の終わりではありませんが、発生した場合は必ずユーザーストーリーで作成し、優先順位を最も高くします。
私はラリーを使用していて、大好きです。通常、スプリント全体を通して、機能のテストはQAリソースによって完了したときに行われます。 QAがバグを発見すると、通常はRallyの不具合としてそれらを記述し、開発者はスプリントが終了する前にすべての不具合を解決しようとします。
理想的にはすべての不具合を解決する必要がありますが、小さなまたは些細な不具合の場合は、ユーザーストーリーを受け入れないようにしてスプリントを抑える必要がない場合があります。 QAが判断を下すべきです。オープンな欠陥があるユーザーストーリーを受け入れますか？
スプリントが受け入れられると、残りの欠陥は次のスプリントのためにユーザーストーリーに昇格できます。
私が気づいたあなたの考えのもう1つの誤りは、開発チームの外部の別のエンティティとしてQAを描写したことです。これは、リリース前に大規模なテスト段階を実行する必要があると想定しているため、本質的にウォーターフォールの考え方です。これはそうであってはなりません。テストは、スプリント中に開発チームと一緒に行われる必要があり、テストケースを準備してテスト結果を解釈する開発者と緊密に連携する必要があります。
アジャイルが正しく行われている場合、スプリントはスプリントの終わりまでに完全に受け入れられ、製品版リリースの準備ができていることを意味します（すべてのスプリントがリリースである必要はありません。それのために生じた必要性）。
私が働いている場所には、ほぼ「信仰の条項」として、反復中に欠陥が発生するのではなく、すべての問題が解決されるまで開発が完了しないという原則もあります。問題は、不足している要件から、テクノロジをコード内の古き良きバグに実装する方法のあいまいさまで、多岐にわたります。真のアジャイル形式では、ユーザーストーリーは仕様ではなく「会話のプレースホルダー」であるため、開発中に製品所有者と要件を確定し、彼らまたは開発者のどちらも事前にソリューションに踏み込むことが有益であると考えられます。要件仕様。
「問題」が特定された場合は、プロジェクトのラジエーターボードとRallyで新しいタスクを作成して追跡することをお勧めします。これは、製品所有者に要件を提供するように通知し、開発者がそれを実装し、QAをテスト計画に組み込むように通知します。開発の期間内に問題に対処できない場合は、問題が新しいストーリーの一部になるか、欠陥として発生するという警告付きでストーリーを受け入れるのは、プロダクトオーナー（QAではない）です。
これはすべて素晴らしいものであり、日常的に顔を合わせてコミュニケーションをとるかなり小規模な同じ場所に配置されたチームによる小規模なプロジェクトでうまく機能します。ただし、私の経験では、サードパーティやオフショアチームが関与する大規模なプロジェクトでは問題が発生します。これは、ボード上またはラリー内のタスクには正式な欠陥レポートの利点がないためです。これらの利点を思い出してください。 1.一意の識別子（番号）を持つ問題の共通の参照フレーム。 2.実際の問題と予想される結果を使用して問題を再現するための手順。これにより、問題が実際に何であるかについて曖昧さがなくなります。 3.既知の問題の検索可能なリポジトリ。これにより、チームメンバーは、発見したとされるバグがすでに報告されているかどうかを常に尋ねることがありません。 4.説明責任。口コミやメールチェーンを使用して問題を報告すると、特に問題が増え始めたときに、見落とされたり、無視されたり、忘れられたりします。
QAとして、私は開発中に問題を追跡するいくつかの方法の余地があると確信しています。しかし、私が仕事でこれを上げようとするときはいつも、私は平手打ちされ、「私はアジャイルを理解していません」とか、そのための言葉を言われました。興味深いことに、そのような異議を唱えるのは通常プログラマーです。プログラマーは多くの問題を報告および追跡する潜在的な頭痛の種がないため、これは理解できます。ですから、この問題についての議論には、BAやプロジェクトマネージャー、さらにQAが関係することをお勧めします。これは、私たち全員が日常的に作業しなければならないことだからです。対照的に、プログラマーの欠陥の経験は、通常、特定のコード領域内で修正する必要のある個別の個別の作業と同じです。