古いケースとアジャイルプラクティスのバランスを取る
私のチームは、アジャイルプラクティス（かんばんを選択）を開発、テスト、設計チームに統合し始めたばかりですが、古いシステムから残ったユーザーストーリーに書かれていないバグケースや機能ケースがたくさんあります。バグを処理するための良い方法を見つけようとしますが、それでも、頭を下げて集中する必要がある開発者を維持します。今のところ、バグ修正に割り当てられた新しい開発者がいるので、残りは新しい機能に取り組むことができますが、チームを構成する正しい方法を探しています。 7人の開発者、2人のテスター、2人のデザイナーがいます。
助けてくれてありがとう:)
バグアイテムを他のすべてと同じように（もちろん優先順位に従って）かんばんボードに配置し、キュー内の次のアイテムを誰が実装するかをチームに決定させます。
チームは、特定のチームメンバーにアイテムを配布するよりも、これを処理する方法を最もよく知っていると思います。少なくともそれは彼らに自己組織化する機会を与えるでしょう。これはアジャイルであり、すべてです。
おそらく不足しているのは、明らかに優先順位が付けられたバックログおよび適切なWIP制限（進行中の作業制限）です。
まず、3つの状態（オープン/バックログ、進行中、完了）の使用を開始すると仮定すると、チームは、製品の所有者が設定した優先順位に従って、バックログからアイテムをプルする方法を用意する必要があります。これらがアジャイル前の時代からの残り物であるかどうかは関係ありません。すべてを他のすべてよりも優先する必要がありますよね？したがって、バックログを組み立てて、チームがバックログの先頭から選択できるようにします。また、アイテムが大まかなスケッチのバグの説明であるか、完全に吹き飛ばされたストーリーであるかは関係ありません。重要なのは、チームが作業できる製品所有者のアイデアのある種の視覚化された表現があることです。途中でこれらの願いを定義するより正式な方法に移行します（最終的に適切なバグとストーリーのみが表示されるまで）。バグはソフトウェア開発において現実のものであるため、優先順位を付けるときはバグをストーリーとして扱ってください。
次に、同時に進行させたいアイテムの最大数を考え出すようにチームに指示し、これを最初のWIP制限として定義させます。この値は、それがあなたのためにうまくいく方法に応じて、時間をかけて調整することができます。
また、チームが作業を整理する方法を最もよく知っていると思うようです（バグに新しい開発者を1人割り当て、他の開発者を集中させます）。私は以前にこの種の行動を見たことがあり、通常それは機能不全の行動の兆候です。チームは、チームとして行動し、考えるという条件で、かんばんボードの項目をどのように解決するかを最もよく知っている必要があります。このようにして、スループットを最大化し、全員を最大限に活用することができます。外部からの干渉（マイクロマネジメントなど）は、チームを傷つける可能性があります。とはいえ、チームは成長する必要があり、アジャイルプラクティスが効果的に機能する特定の品質を達成するには適切なガイダンスが必要になる可能性があるため、ストーリーには常に2つの側面があります。作業の分割に問題がある場合、これは、たとえば作業の分散などを改善するために不可欠な回顧/フィードバックループの一部として対処できるものです。
かんばんは、アイテムをチームにプッシュするのではなく、チームにプルさせることに基づいていることを忘れないでください。最後に、1つの大きなチームアプローチで失敗した場合、あなたとあなたのチームは常に、チームをいくつかの小さなチームに分割することを検討できます。各チームは、特定のチームのニーズに合わせて調整された、個別のボードを備えた独自のKanbanプロセスとワークフローを持っています（バグ修正チームなど）。 、機能チーム、テスターチーム）。結局、あなたとあなたの開発チームはプロセスを管理しなければならず、その逆ではありません。
いつものように古いバグケースと機能リクエストを終了し、新しいバグケースと機能リクエストが入ってくると、ゆっくりとかんばんシステムの実装を開始します。
[〜＃〜]または[〜＃〜]
先に進む前に、オフィスの開発者や他の人に古いバグのユーザーストーリーを作成してもらいます。