「メイン」機能のバックログと並行した「バイトサイズ」タスクのバックログ？
高度にサイロ化された「一匹狼」の開発部門構造で2年以上働いた後、アジャイルスクラムを採用しています。すごい。私はアジャイルが好きです。開発者として、無数の利害関係者が昨日プロジェクトを終えた後、プロジェクトをスローダウンすることなく、集中して忙しく生産的になります。 しかし、現在の「モデル」と対比してSCRUMに移行する側面が1つあり、開発部門以外の人は少しでも好きになれないと思います。それが、「待機中」に小さな変更を行う現在の能力です。私たちの開発の大部分は、社内での消費のみを目的としており、ほぼ全員が同じ建物内にいます。そのため、他の部門のリーダーまたはマネージャーが特定のアプリケーションの「コードベースの所有者」に来て、小さなものを要求することは長年にわたって一般的な慣習でした（それほど小さくはありませんが、これらの「ドライブバイ」に基づいた週プロジェクト）。私たちの上司でさえ、彼に持ち込まれたものをこのように中継することがあります。非常に頻繁に、その時点で問題のコードベースで作業している場合、ソースファイルをポップアップ表示するだけで、 基本的なアジャイルSCRUM方法論では、これらの調整は、欠陥（以前に消費したストーリーで指定された要件を満たしていない）または新しい小さなストーリー（記載されているすべての要件を満たしましたが、それらの要件は不完全、曖昧、または不正確でした） 、またはユーザーが新機能を見た後に配信後に変更されました）。どちらにしても、大半はないがほとんどゼロで、1-ポインタとなり、比較的低い優先度（システムは、現在の状態で使用可能ですが、それは次のようになりそうならば...ずっとクーラー）であることが、彼らがそうなって、バックログをトップダウンで操作するときにスプリントに持ち込まれます。 この可能性は、他の部門によるアジャイルプロセスへの積極的な反対の源として開発者会議で提起されました。これはIMOにとって有効な懸念事項です。POの背後にある利害関係者は、すべてが同じ視点を持っているわけではないため、最も重要なことについて常に同意するわけではありませんが、最終的な決定を下すのは通常マネージャーだけです。製品バックログに表示されます。 その後、暫定的に「キャンディジャー」と呼ばれる解決策が提案されました（別の用語は「グレービーボート」でした）。さまざまな部門の「リトルガイ」によって要求された小さな調整。既存のストーリーの欠陥ではなく、チーム内のコンセンサスまたは称賛により、開発者の1日の半分以下で済むと推定されます。エンドユーザーの意見では、ユーザーエクスペリエンスに対する即時の重要なプラスの影響が、プライマリバックログと並行してリストに追加されます。それらは「ストーリー」として識別されますが、優先順位付けの対象となる「大きな」ストーリーの主要なバックログとは別に保持されます。スプリントの通常の進行中にいつでも、これらの調整のいずれかを行うことができるシステムの領域で作業している場合、微調整を簡単にすることで、スプリントに微調整を加え、より大きなストーリーと一緒にコーディングできます。これをする大きなストーリーやその他のコミットされた作業の完了を危険にさらしてはなりません。POはこのリストにもアクセスでき、微調整を含む基本機能に触れる今後のユーザーストーリーに取り組んでいる場合、要件としてストーリーに組み込むことができます。その他。これにより、微調整がより早く実行される可能性が高くなると考えられていました。 これにより、スクラムマスターによる「ええと」のトレーニングが行われ、私たちの間に反応が生じました。バックログが1つあります。2つのバックログは、どの＃1アイテムが本当に最も重要であるか、どのリストのアイテムが実際の速度を決定するか、2つのバックログのうちどちらが実際に属するかという問題を紹介しますどちらか一方に勝手に）。「プロセスを機能させる」と私たちは言いました。変更がエンドユーザーにとって本当に重要な場合、彼らは部門長が時間/お金の決定を行うのに十分な騒ぎをし、バックログのトップに対する開発チームの意識にぶつかるでしょう。 私は床に質問を投げかけると思った：あなたの意見では、「一口サイズ」の物語の平行リストは、小さく、有用であるが最終的には優先度の低い変更をより速くすることに価値があるか、それとも全体的に良い決定ですか？それらをメインのバックログに組み込み、スプリントへの組み込みを基本プロセスで管理するにはどうすればよいですか？