メンテナンスとレガシーコードの改善にスクラムをどのように適用しますか? [closed] 質問する

基本的に、計画外のタスクや見積りが非常に難しいタスクをスクラム プロセスで克服するにはどうすればよいでしょうか。それとも、この環境に間違ったプロセスを適用しているだけなのでしょうか。

この環境には間違ったプロセスを使用しています。必要なのは、計画/見積もられた SCRUM 開発プロセスとは別のスタック/キュー管理プロセスです。

その理由は単純で、次の 2 つです。

1. 投稿で述べられているように、保守タスクを見積もるのは、特にレガシー システムが関係する場合、非常に難しいことがよくあります。保守タスク全般、特にレガシー システムは、「複雑な」問題に関係したり、長い「テール」を持つ傾向があり、一見単純な修正でも、別のコンポーネントに少し難しい変更が必要になり、その結果、一部のサブシステムの動作を徹底的に見直す必要があり、その結果... 要点はおわかりでしょう。

2. メンテナンス作業を行う際には、見積もりが終わる頃には、問題の解決も終わっているこれにより、見積もりの​​プロセスは計画ツールとして不要になります。保守タスクの問題解決から見積もりを分離することを主張する人は、単に不必要なオーバーヘッドを追加しているだけです。

簡単に言えば、キュ​​ーイング システムが必要です。キューイング システムには次のコンポーネントが含まれます。

• 注意が必要であると特定されたタスクの「プール」。新しく発生した項目は、キューではなく、常にプールに入れられます。
• これらのタスクをプールからキューに移動するプロセス。通常、ビジネスと技術の知識の組み合わせが必要です。
• キューの処理を担当する開発者がキューの先頭から簡単に選択できるように、タスクのキューが明確に順序付けられます。
• キュー内のアイテムを移動する（優先順位を変更する）方法。重要なアイテムや緊急のアイテムを「キューから外す」ことを可能にします。
• キューのサービスを中断せずに完了したアイテムを配信する方法。メンテナンス アイテムを配信するオーバーヘッドは通常、開発作業よりも大幅に低いため、これは重要です。メンテナンス チームがバグ修正を配信するたびに、ビルド チームとテスト チームから OK が出るまで 1 日中待機することは望ましくありません。

キュー管理には他にも微妙な違いがありますが、これらを適切に行うことで正しい方向に進むことができます。