SW統合でかんばんをどのように使用しますか?
チームの基本的な構成は次のようになります。
ビルドは、それらをビルドして自動テストを実行しようとするビルド チームによって外部から受信されます。スペシャリスト チームは、問題 (ビルドの問題、統合の問題、テストで見つかった問題) に対処します。たとえば、問題の原因を特定します。
では、最初のタスクは単に「X のリリース」と呼ばれ、スペシャリスト チーム (他の任務も持つ) のために追加のタスクを生成しますか? 問題は、「リリース」がスペシャリスト チームにとってあまりにも大きなタスクであり、分解しなければならないことです。しかし、「X のリリース」タスクがない場合 (むしろサブタスクのみ)、リリースのステータスをどのように把握するのでしょうか?
b&r チームとスペシャリスト チームに別々のタスク ボードを用意する必要がありますか?
かんばんボードでカバーすべき厳密なルールはありませんが、経験則として次のように言えます。
これは、すべてのチームに対して単一のボードを目指すことを意味し、専門チームによって行われる他のタスクも含めようとするでしょう。
次に、理事会の組織です。アイデアの 1 つは、非常に単純なプロセス (実行中、進行中、完了) を持ち、ボード上でさまざまなタスクを組み合わせることです。たとえば、リリースで自動テストをビルドして実行する、手動テストを実行するなどです。その後、何か問題が発生するたびに、スペシャリスト チームのタスクなので、1 つ追加します。このようにして、問題がまだ発生している限り、リリースに関連する新しいタスクを生成します。
問題は、リリースが完了したかどうかをどのように判断できるかです。おそらく、リリースごとに 1 つずつ、複数の異なる色の付箋を使用できます。「黄色」のリリースにはまだ未解決の問題がいくつかありますが、「緑色」のリリースはすべて完了しており、「オレンジ」のリリースは開始したばかりであると言えます。リリースが終わったら、簡単に色を再利用できます。
また、特定のリリースで発生した問題の数を示す簡単なビジュアルも表示されます。同じ色の付箋が多いほど、問題が多いことを意味します。