問題タブ [kanban]

私は、大規模な部門の作業とボトルネックを視覚化するための単純な (そして本質的にアジャイルな) 方法を考えようとしています。必要なデータが得られたら、プロセスを徐々に改善するという考えです。

問題は、複数のプロジェクトに取り組んでいる開発者のグループが複数あることです。一部の開発者はクロス プロジェクトであり、一部のプロジェクトはクロス チームです。開発者は自分たちのやり方に固執しています（ペア プログラミング中に C# や Java の開発者に Delphi 6 の学習を強制したくはありません）。

もう 1 つの問題は、非常に小さな QA チームがすべての開発者/プロジェクトで共有されていることです。

かんばん (または同様の) タスクボードを整理して、ストーリーがプロジェクト (またはチーム?) ごとに分類され、WIP 制限がボード全体に適用される方法についてのアイデアが必要です。

また、スタンドアップ ミーティングはどのように行われますか? 全員を 1 回の会議に参加させると、時間がかかりすぎて情報が過負荷になりますが、会議を分割すると、アジャイルが実現する多くの透明性を失うことになります。

そのため、タスクボードやスタンドアップ ミーティングに関連するアイデアは大歓迎です。また、かんばんと同じレベルの処方箋 (つまり、あまり多くない) を備えたかんばんの代替品も大歓迎です。

私は、ソフトウェア部門に何らかの開発プロセス手法を採用させようとしています。開発者は9人だけで、プロジェクトもほぼ同じです。現在、私たちは混沌としてしか説明できません。あるいは、別のSOユーザーがそれを呼んでいるのを見たように、おそらく「危機主導型の開発」です。

かんばんを使用することは、私たちにぴったりのようです。だから私はそれを他のみんなと話し合った、みんなそれはいい音だと思った。しかし、ボードをどのように配置するかについて話し合ったとき、誰もが1人につき1つのボードを作成したいと考えていました。

今、私はかんばんや他の方法論を実際に試したことがありませんが、各自が自分のボードで管理することは、かんばんプロセスが提供するはずの利点を打ち消すような気がします。この概念は私を悲しくさせます、そして「ほんとうにこの考え全体を捨てましょう」と言いたいです。

開発者ごとにかんばんボードを実装することは価値があると思いますか？

カンバン ボードの基本的なフローを考えると、次のようになります。

本/記事/プレゼンテーションを読んだ後、大まかに次のように変換されました

だから私が理解できない質問：

1. バックログ & 入力キュー & 開発キューの関係。PM は、そのリリースのバックログから MMF に優先順位を付け、それらを入力キューに移動します。dev (WIP 制限に基づく) は 1 つを取り、作業を開始します (WIP 列)。Dev Queue は何に使用されますか? PM が Backlog から Dev Queue に移動し、開発者が Dev WIP に移動する必要がありますか、それとも PM が Backlog から Input Queue に移動し、開発者が 1 つを取得して Dev WIP に移動する必要がありますか? かんばんの例で、バックログ、入力キュー、および開発サブキューを持つことについて話している理由がわかりません。それぞれに独自の目的がありますか?

2. 開発者は完了/解決済みの作業項目をどこに移動し、完了と次のキュー列の関係は? QAが不要な場合はどうなりますか? たとえば、開発 WIP が完了したら、それを Dev Done に移動できます。QA はそこから QA WIP にプルします。または、Dev WIP から QA Queue または Deploy Queue へ (QA が不要な場合)。最初のケースでは、説明が技術的すぎたり曖昧すぎたりしても、QAer は Dev Done 列のすべてのチケットを理解して確認する必要があります。2 番目に Dev Done がバイパスされ、QA はデプロイの制御/監視を失います。また、デプロイ キューまたはクローズドが必要ですか? CI のおかげで、デプロイはワンクリックで完了しますが、すべての開発タスクを実行し、クローズドに移動する前にリビジョン番号をデプロイされたばかりのものに一致させるのは負担のように聞こえます...

何か案は？または、実際のかんばんボードとそのフロー設定の詳細な例を知っているでしょうか? 私は実際に存在するフローを計画し、それを時間の経過とともに進化/改善することになっていることを知っています (ボトルネック/問題の出現に対する反応としてのカイゼン)。しかし、新しいチーム/プロジェクトの場合、完璧なフローは何でしょうか?

私は基本的にアジャイル手法とスクラムに精通しています。

しかし、「リーンソフトウェア開発」と「かんばん」とは何ですか？

スクラム、リーン、カンバンはアジャイル手法の実装であると言っても差し支えありませんか？または、リーンとかんばんは異なる方法論ですか？

リーンとかんばんは（アジャイルのような）スケルトン/ガイドラインを提供し、実装をXPやスクラムのような隣接する一連のプラクティスに任せていますか？

スクラムでは、各スプリントの後にデモを作成できることは明らかです。

かんばんにはスプリントの概念がないため、デモを作成する方法がわかりません（間違っている可能性があります）。

かんばんでリリースする方法について教えていただけますか？

助けと時間をありがとう。

かんばん用の TFS プロセス テンプレートを作成することを考えています。興味を計りたかっただけなのに……。

スクラムからかんばんスタイルの開発に移行することを考えていますが、かんばんの下で進捗状況を監視する方法が明確ではありません。

各ストーリーのサイクル時間を監視し、おそらくこの時間を未処理のストーリーの数に適用することで、進捗状況を測定できることを読みました。しかし、これはストーリーのサイズと複雑さに依存しているように思えますが、それはすべて異なる可能性があります.

バーンダウン チャートが使用されているのも見たことがありますが、リリース全体のチャートはありますか? バックログは修正されていないため (スプリント中とは異なり)、保留中のバックログが PO によって修正されるので、それをバーンアップ/ダウンさせますか? リリースに近づくにつれて、バックログの揮発性が低くなり、完了までバーンダウンできるようになると思います。

さらに考えてみると、私の問題は、私たちのマネージャーが、バーンダウン チャートがもたらすコントロールの「錯覚」を好んでいることだと思います。彼らはそれを (私の意見では間違って) スケジュールと見なす傾向があるため、プロジェクトが「スケジュール通り」または「スケジュールより遅れている」などの判断を下すことができます。これがかんばんでどのように複製されるのか、私にはよくわかりません。たぶんそれは良いことです。

私は、ソフトウェア開発プロセスにかんばんを使用している開発チームで .NET 開発者として働いています。現在、ソース管理にチーム ファウンデーション サーバーを使用しており、常にリリース可能なコードを確保するために、機能ごとに分岐する戦略を取っています。

Team Foundation Server にはいくつかの「制限」があるため、より柔軟なツールを入手するために github に移行しようとしています。

複数のソリューション/アプリケーションから使用する必要がある共通のプロジェクトがある場合、git をセットアップする最良の方法は何だろうか? それはそれ自身のリポジトリであるべきですか？

デザインはかんばん方式にどのように適合しますか。デザイン専用の列を配置する必要がありますか、それともストーリーキューからWIPに移動する前に、ストーリーの高レベルと低レベルのデザインを行う必要がありますか？

SW統合でかんばんをどのように使用しますか?

チームの基本的な構成は次のようになります。

• ビルド＆リリースチーム、
• 2つの専門チーム、
• テストチーム。

ビルドは、それらをビルドして自動テストを実行しようとするビルド チームによって外部から受信されます。スペシャリスト チームは、問題 (ビルドの問題、統合の問題、テストで見つかった問題) に対処します。たとえば、問題の原因を特定します。

では、最初のタスクは単に「X のリリース」と呼ばれ、スペシャリスト チーム (他の任務も持つ) のために追加のタスクを生成しますか? 問題は、「リリース」がスペシャリスト チームにとってあまりにも大きなタスクであり、分解しなければならないことです。しかし、「X のリリース」タスクがない場合 (むしろサブタスクのみ)、リリースのステータスをどのように把握するのでしょうか?

b&r チームとスペシャリスト チームに別々のタスク ボードを用意する必要がありますか?