私は、ソフトウェア部門に何らかの開発プロセス手法を採用させようとしています。開発者は9人だけで、プロジェクトもほぼ同じです。現在、私たちは混沌としてしか説明できません。あるいは、別のSOユーザーがそれを呼んでいるのを見たように、おそらく「危機主導型の開発」です。
かんばんを使用することは、私たちにぴったりのようです。だから私はそれを他のみんなと話し合った、みんなそれはいい音だと思った。しかし、ボードをどのように配置するかについて話し合ったとき、誰もが1人につき1つのボードを作成したいと考えていました。
今、私はかんばんや他の方法論を実際に試したことがありませんが、各自が自分のボードで管理することは、かんばんプロセスが提供するはずの利点を打ち消すような気がします。この概念は私を悲しくさせます、そして「ほんとうにこの考え全体を捨てましょう」と言いたいです。
開発者ごとにかんばんボードを実装することは価値があると思いますか？
多数のボードが必要な場合は、開発者ごとにボードを作成するよりも、プロジェクトごとにボードを作成する方がよいのではないでしょうか? プロジェクトの自然なグループ化 (したがって、取締役会の統合) がやがて現れるかもしれませんが、そうではないかもしれません。
ボードの目的の 1 つは、「情報ラジエーター」として機能することです。カタツムリのペースで進行している多数のプロジェクト委員会は、「私たちは非常に過負荷です」および/または「誰かがいくつかの優先順位を設定する必要があります」というメッセージをブロードキャストします。多数の開発者ごとのボードは、「ここではチームワークを行っていません」というメッセージを放っています。
開発者ごとにボードを持つことは間違いではありません。ボードは作品を視覚化するためにあります。開発者が異なるプロジェクトで作業している場合、プロジェクト固有の作業を別々のボードで視覚化する方が簡単です (通常はそうです)。開発者が別々のプロジェクトで作業する場合、開発者は別々のプロジェクトで作業します。技術的には、彼らは実際には単一のチームではなく、「練習」のようなものです。そういう意味では、別々のボードで運営する方が自然かもしれませんね。
私が個人的なプロジェクトに取り組むときは、今でも平準化ボックスを使用しています。これは、西側のソフトウェア開発者がよく (誤って) 「かんばんボード」と呼んでいるものです。これは、作業を視覚化し、作業のスケジューリングを行い、数を制限するのに役立ちます。私が一度に取り組んでいることの。
かんばんをプロセスに適用する最も重要な 2 つの理由は、そのプロセスを視覚化し、進行中の作業 (WIP) を制限することです。
開発者ごとに 1 つのボードがある場合、それはより個人的なかんばんメカニズムになり、一度に 1 人の WIP を視覚化して制限することができますが、チーム レベルでの概要はありません。
プロジェクトまたはチームごとに 1 つのボードがある場合、共有リソース (つまり、複数のプロジェクトまたはチームで作業している人々) があるかどうかによって異なります。もしそうなら、複数のボードに表示されているものに取り組んでいる人がいる場合、WIP を制限することによる概要と利点の一部が失われます。F.ex。ボトルネックが見えにくくなります。
あなたのグループともう一度議論する価値があると思います。どんな種類の新しいテクニック/プラクティス/方法論を採用する前に、なぜそれを採用したいのか、どのような問題を解決しようとしているのかについて、非常に目を向けるべきです. かんばんボードに出くわし、何の問題を解決しようとしているのかよくわからないまま、かんばんボードを採用したいと思っているように思えます。
私のアドバイスは、環境で発生した問題についてもう少し考えたり分析したり、可能であれば根本原因の分析 (5 つの理由のようなもの) を行ってから、解決に役立つプラクティスを見つけてみることです。それらの問題。
あなたのグループの人々が開発者ごとのボードを使用することを提案したというまさにその事実は、私にそれを意味します。彼らは抱えている問題の種類と、あなたが解決しようとしている問題を理解していません。b. かんばんボードが何を達成しようとしているのか理解していません。つまり、あなたの問題はかんばんボードを使用しても解決しないようなものです。
オペレーションの自動化を行うチームにかんばんを実装しました (ほぼ半分が運用作業で半分が開発作業です)。以下は、私たちのチームにとって最も効果的であることがわかったものです。INBOX/バックログ用の共通の列があります。次に、「開発中」の列は、開発者ごとに 1 つ、開発者ごとの WIP 制限がある 5 つのセクションに分かれています。次に、「統合する」ための別の共通の列、最後に「本番環境へのリリース」のための共通の列です。
Kanban の利点は、WIP 制限により、開発者が自分のしていることに集中できることです。この場合、各開発者はプロジェクトにかなり自律的に取り組んでいますが、開発者が新しいタスクを引き出すことができる INBOX の共通の列があります。そして、チームリーダーが残りのステップを通じて変更を先導することに関与する「統合」/「生産」の場合。
したがって、私の推奨事項は、いくつかの共通の列 (おそらくバックログとリリース) と、開発者ごとの列 (「開発中」など) をいくつか持つことです。このようにして、各開発者は自分が取り組んでいるものを管理でき、同時に、ボードはパイプラインを流れているすべての作業の状態を視覚化するのに役立ちます.
かんばんは、実際にはシステム内の流れを制限するためのシステムです。そのため、かんばんボードには WIP (進行中の作業) 制限があり、人は一度に 1 つのジョブしか実行できないため、これはうまくいかないと思います。
開発者ごとに 1 つのボードを使用しても、実際には何の利点もありません (実際にはカンバンではないと私は主張します)。プロジェクトごとに 1 つのボードを使用することをお勧めします。
その後、別の開発者がいくつかのタスクに参加した場合でも、プロジェクトの全体的な進行状況を確認できます。
私の考えでは、開発者ごとに1つのボードを使用するよりも、すべての開発者タスクを含む1つのかんばんボードを使用する方がよいと思います。理由これは、かんばんはすべてのチームメンバーにとって視覚的なツールであるという考えであり、各開発者が独自のボードを持っている場合、その考えを少し見逃していると思います。
サブノート
Microsoft TFSを使用している場合は、Telerik WorkItemManagerを使用できます。私はこれを自分で使用しました、そしてそれは素晴らしいです。各開発者は自分のPCでツールのコピーを実行し、視覚的なタスクボードで自分の作業項目を表示できます（カラーポストイット付き）。このボードはさまざまな方法でグループ化およびフィルタリングできるため、開発者は自分のすべてのタスクを表示できますが、フィルターを変更してプロジェクトのすべてのタスクを表示できます。
（TFSを使用していない場合は、興味のないサブノートをお詫びします:)
実際、少なくとも 2 つまたは 3 つのチームを作成し、各チームに 1 つのプロジェクトのみを影響させ、プロジェクトごとに 1 つのボードに影響を与えます。次に、プロジェクトのステータスを管理する別のボード。
再開するには: プロジェクトごとにタスクごとに、プロジェクトのステータスを追跡することで、開発者だけでなく、マネージャーとのコミュニケーションにも役立ちます。