私は彼らがスクラムを使おうとした会社で働いていましたが、実際には、非常にアクティブなユーザーベースがあり、1日8時間ソフトウェアを使用していたため、確実なスプリントバックログを作成するのは困難でした。そのため、多くの重大なバグが報告されました。早急な対応が必要でした。
これは私に不思議に思いました...スクラムを使用しながらこの種の計画外のワークロードを解決するための最良の方法は何ですか?スクラムバンとかんばんについて何か見ましたが、それでも、すぐに注意が必要な計画外の作業(バグ)と組み合わせて、特定のスプリント内で完了する機能のある程度適切な見積もりをクライアントに提供する方法がわかりません。
信頼性の低いワークロードに対処できる方法論を探す必要がありますか、それともソフトウェア開発プロセス内の他の段階を調べる必要がありますか?たとえば、品質プロセスが改善されてバグの数が減り、それに伴って計画外の作業が増えることを確認するにはどうすればよいでしょうか。
"[...]は、早急な対応が必要な多くの重大なバグを報告しました"は厄介に聞こえます。
チームが1日に5つのバグを解決でき、数十のユーザーが数十のバグを報告し、それらすべてに早急な対応が必要な場合、彼らが望むことを実行する方法はありません。彼らは単に待つ必要があり、物事を急ぐためのレバレッジが高いほど、それは悪化します。急いでいると、チームがテスト、コードレビュー、またはペアプログラミングを放棄し、より多くのバグにつながるためです。
さらに、バックログをスキップしてタスクを現在のスプリントに直接プッシュすることで、混乱を作成しています。開発者はタスクに取り組んでいました。今、彼らは彼らの仕事を中断し、新しい仕事に取り組まなければなりません。これだけでも生産性が低下するほどイライラしますが、数時間後に前のタスクに戻るのも苦痛です。その人は自分の居場所を忘れている可能性があります。
最後に、タスクのごく一部だけが優先度が高いように見えるように、必ず優先度を割り当てる必要があります。 100のタスクで、30が「早急な対応が必要」、60が「優先度が高い」プロジェクトを見てきました。このような状況では、開発者は、重要なタスクが30、優先度の低いタスクが60、決してない10のタスクがあると単純に考えています。実装されます。
顧客、上司、またはユーザーがバグの解決を求めている場合今、考えられる唯一の答えは次のとおりです。
このタスクをバックログに追加し、優先度の高いタスクに設定しました。現在、4週間から5週間かかる可能性のある68の他の優先度の高いタスクを解決しています。最新情報をお届けします。
バグの重大度(ユーザーがログインできないなど)のために、バグを実際に解決する必要がある場合はどうなりますか?
これが孤立したケースである場合は、 バグ修正の反復を説明する方法は? Gnatが言及したものが適切です。
これがパターンになった場合(1日にいくつかのバグのように)、チームがソフトウェア製品を開発している方法に完全に問題があります。
チームがペアプログラミングまたはコードレビューを使用している場合、ターゲットコードブランチのカバレッジが十分に高い場合、チームの全員が要件を理解している場合、回帰テストを実行している場合(継続的インテグレーションを介して)、展開が自動化されている場合(誰もいじりません)あなたのサーバー)、これは起こらないはずです。
繰り返しになりますが、チームがどれほどうまく仕事をしていても、時々悪いことが起こる可能性があります。しかし、これが定期的に発生する場合、何かが制御不能になります。