問題タブ [kanban]

正式なプロジェクト管理システムを必要としている 4 人の開発チームがあります。スクラムとカンバンについては大まかに理解していますが、実際に試してみるまで真に理解することは困難です。1 つを数週間試してから別のものに切り替えるという贅沢はないので、同じような状況にある誰かが、どちらがより効果的で、その理由について考えてくれることを望んでいました. また、開発を管理するための他のシステムがうまく機能した場合は、ぜひお知らせください。

別の注意: もちろん、チームが成長する可能性があるため、適切に拡張できるシステムが必要になります。

さらに別の注意: 私たちは、Windows で 3 つの別々のソフトウェア アプリケーションに取り組んでいます。これらはすべて、私たちが作成した中央ライブラリに基づいています (つまり、4 つのプロジェクトと言えるでしょう)。

私のチームは、スクラムからリーン/かんばんに移行し、ますます正式なプロセスが少なくなる軽量な方法論を徐々に採用しています。ある時点で、Cowboy Coding に戻ります。確かに、私たちはすでに境界線にいるのではないかと心配しています。

非常に軽量なリーンおよびアジャイル プロセスとアナーキーの境界線はどこにあるのでしょうか? 一線を越えたことをどうやって知ることができるでしょうか。どうすれば一線を越えないようにできるでしょうか。

この質問は、「ムダを排除しようとするリーンの意欲の中で、安全に排除できないプロセスはどれか」と言い換えることもできます。

私はリーン/かんばんにまったく慣れていませんが、過去数週間にわたってオンラインリソースを使い果たしており、適切な答えが見つからない質問を思いついています。リーン/かんばんは、それ以外の点では、すでにスクラムを使用している当社には非常に適しているようですが、その方法論の中でいくつかの制限に達しています。ここの誰かが私に良いアイデアをくれたらいいのにと思います。

私が見ているように、ウォーターフォールに対するスクラムの最大の利点の1つは、スプリントの使用です。14日ごとにすべてを準備することで、短いフィードバックサイクルが得られ、頻繁にリリースできます。ただし、リーンについて読んだことから理解したように、これにはいくつかのコストがかかります（たとえば、スプリント計画会議、チームコミットメント会議、およびスプリントの最後にすべての人に役立つものを見つけるための問題）。

リーン/かんばんはこれらの廃棄物を取り除きますが、14日ごとに放出できないという犠牲を払うだけです。それとも私は重要なポイントを逃しましたか？かんばんでは、どのようにして新しい開発タスクに取り組み、同時にリリースすることができますか？途中でしか出荷されていないものを出荷しないようにするにはどうすればよいですか？そして、どうすればそれを適切にテストできますか？

これまでの私の最高の「解決策/アイデア」は次のとおりです。

• 頻繁にリリースせず、新しい開発タスクの不足に関連する無駄を許容します。しかし、実際には、尋ねられた質問に対する解決策ではありません。
• ブランチで開発してから、メイントランクにマージします。内部で少なくとも2つのブランチを継続的にサポートする必要があります。
• 一部のスマート自動ラベル付けシステムを使用して、特定の完了したタスクのみを自動的に作成し、他のタスクは作成しません。

要約すると、私の質問は次のとおりです。リーン/かんばんを使用する場合、無駄を導入せずに頻繁にリリースできますか？または、リリースはリーン/かんばんの一部ではないことがよくありますか？

私の会社に固有の追加情報：Team Foundation System＆Source Controlを使用しており、以前は分岐とマージに関していくつかの悪い経験がありました。この分野の専門知識を取り入れることで、これを解決できるでしょうか。

かんばんを管理するためのどのツールをお勧めしますか？

スクラムとかんばんを少し調べた後、最終的にこの回答を読み、スクラムから何かを選んでかんばんを使い始めることにしました (私はほとんど一人で作業していることに注意してください。この質問とその回答を読んだことがあります)。

さて、私の質問は次のとおりです。開始するのに最適なツールはどれですか?

1. ホワイトボードとポストイット
2. agilezen.com
3. グリーンホッパーとのJIRA
4. スプレッドシート (おそらく Google ドキュメント)
5. brightgreenprojects.com
6. アギロ
7. 対象プロセス
8. その他（具体的にご記入ください）

それぞれについての注意:

1. 私はホワイトボードに傾倒しますが、いくつかの欠点があります (たとえば、自動チャート、時間測定、メトリクスを作成することはできません。また、最も必要な場所である自宅で仕事をすることもあり、持ち運びには便利ではありません :-)

2. 別のユーザー名/パスワードを覚えたくない (OpenID 対応サービスにのみサインアップすることを約束した)

3. 私の雇用主は JIRA を持っていますが、私のグループはそれを使用していません。アカウントを要求し (別のパスワードは必要ありません)、後でグループの他のメンバーを巻き込む可能性があります。しかし、彼らが greenhopper を使用しているかどうか、それをインストールするのが大したことであるかどうかはわかりません。

4. 私は一般的にスプレッドシートが嫌いです

5. 多分やり過ぎ？

6. ローカルホスト インスタンスがあれば嬉しいのですが、グループ全体 (ネットワーク/ファイアウォールごと) へのアクセスを許可するのは問題になる可能性があります。

これから何を得たいですか？

• より生産的であること
• 特定のタスクに費やした時間を追跡し、場合によっては上司と問題について話し合う
• 私を最も頻繁に「ブロック」するものを追跡する
• 自分のスケジュールと比べて自分がどこにいるかすぐにわかる
• 長い ToDo リストをより適切に管理する (たとえば、「次に何をすべきか」という質問にすばやく答える)

何か提案はありますか？

scrumish タグに関する注意: Henrik Kniberg の PDFを読んでください。彼は最初にスクラミッシュの定義を 9 ページで紹介しました。

チームにかんばんを実装したばかりで、アイテムの状態を経時的に追跡し始めました。このシステムの下で最初のリリースを出荷しようとしている段階になりました。完成した作業項目をどうするかについて質問があります。

顧客が受け入れて出荷する準備が整った作業項目を表す「完了」状態があります。アイデアは、アイテムが出荷されたとき、または「完了」と見なされたときにボードから完全に削除することです（インフラストラクチャタスクなどの場合）。ただし、アイテムを完了から削除すると、CFD は大幅に低下します (たとえば、現在 11 個の完了済みアイテムがあるのに対し、「アクティブ」状態 (未処理) のアイテムは 14 個あります)。いつリリースが行われるかが明確に示されているので、これを行っても問題ありませんが、これを行う公開された CFD は見たことがありません。私が見たすべての CFD は、永遠に上昇傾向にあるようです。

CFD から項目を削除することに賛成または反対する何らかのコンセンサスまたは「ベスト プラクティス」(その用語が意味するすべての注意事項を含む) はありますか? エンジニアリングとエンド ツー エンドのサイクル タイムの目的で、出荷済み/クローズ済みのアイテムを追跡していることは注目に値しますが、これらの指標は個別に追跡されています。

かんばんボード上の Trac バグ追跡システムからチケットを提示/管理するためのプラグイン/アプリはありますか? たとえば、Trac チケットをボード上でドラッグ アンド ドロップしてステータスを変更できるようにしたいと考えています。AgileZen などのスタンドアロン ツールをいくつか試しましたが、それらを Trac に統合する方法が見つかりませんでした。

他の人が自分の会社の物理的なかんばん/スクラムボードに何を使用しているかについて興味があります。機密性の高いビジネス情報のため、ボードの写真を提供できない場合があります。私はあなたのボードがどのように見えるか、そしてユーザーストーリーとタスクが典型的なスプリント/イテレーションを移動するときにどのように整理するかを調べていますか？

通常、私はそれぞれで次のようにボードを整理する場所で働いてきました

要約すると、次のようになります。

• UC-001のタスクは、チームの1人のメンバー（Bob）によって進行中です。Todo列では、他の人が取得するタスクのリストが待機していますが、これは、作業を完了するためにボブと調整するチームの別のメンバーが取得できます。
• UC-002の場合、支払いサービスタスクが完了し、QAの自動テストハーネスが完了して、UIなしでサービスをテストできるようになりました。テストが失敗した場合、バグが発生し、支払いサービスタスクとともにQAフェーズに戻ります
• UC-003のすべてのタスクが完了し、QAの準備ができました。
• Uc-004とUC-005のすべてのタスクが完了したため、ユーザーストーリーは[完了]に移動しました。

これは、各タスク/ユーザーストーリー（付箋として表されます）と対話する人々を含む具体的なホワイトボードとして機能します。電子バージョンは、スプリント/イテレーションの前に作成され、現在の状況に対応するスプリント/イテレーションの最後にのみ更新されます。コメントや批評を歓迎します:)

ソフトウェア開発管理にかんばん方式を使用した人はいますか？

私はかんばんを技術として評価していますが、実際にそれを実際に適用した人から、それがどれほど効果的であるかを聞いてみたいと思います。is-anyone-using-kanban、kanban-vs-scrum、apply-kanban-in-an-agile-teamのような質問を見たことがありますが、それらは私の懸念に対処していません。

私が特に興味を持っているのは：

1. ボトルネックを動的に特定するという点で、クレームが実際に利点を提供しますか？
2. 実際に実行するのは簡単ですか、それとも管理する必要のあるロジスティック上の課題がありますか？
3. 多くの並行作業ストリームと多くの開発者がいるプロジェクトチームにうまく対応できますか？
4. クリティカルパス分析（MS Projectで実装されている）とどのように比較されますか？どのように異なりますか？
5. かんばんを適用すると、他にどのようなメリットがありますか？

ありがとう。