カンバンを使っている人はいますか?[閉まっている]

Question

アジャイル管理の実践にカンバン (またはスクラムバン) を使用している人はいますか?カンバンを使用した経験は何ですか?ウォーターフォール プロジェクトに依存する大規模で複雑な環境ではどのように機能するのでしょうか?

Answer 1

BBCがそれをかなり広範囲に使用していることは知っています。詳細については、David Joyce のブログを参照してください。http://leanandkanban.wordpress.com/

彼はそこにふるいにかけるためのかなり重いスライドデッキを持っています。

リーン思考で覚えておくべきことは、バリュー ストリームを全体として考慮する必要があるということだと思います。カンバンなどの手法を使用して開発チームを超最適化することはできますが、十分な成果を得るには上流 (管理/分析) と下流 (QA/展開/サポ​​ート) の両方を組み込むことがより重要です。

したがって、これが (個人的な影響を超えて) ウォーターフォールまたは複雑なプロセスにどのように適合するのかを尋ねるのは、まったく正しい質問ではありません。さらに重要な問題は、どのようにして価値の流れ全体に影響を与え始めることができるかということです。これは宗教的なリーン熱意の始まりのように聞こえるかもしれませんが、これはリーン プロセスの真の価値を理解する方法です。

たとえば、典型的なプロジェクトの次のシナリオを考えてみましょう。

• 分析時間:18ヶ月
• 開発時間:9ヶ月
• QAとリリース時間:4ヶ月
• お客様による導入と再作業:12ヶ月

合計：43ヶ月

開発プロセスにリーンを適用すると、開発時間が 100% 向上します。つまり、開発時間は 4.5 か月となり、新たに合計 38.5 か月かかります。この場合、価値の流れの合計は 10% 強しか増加しません...取るに足らない!!

あなたは戦いを開始し、リーン思考を上層部に伝え、本当の成功がどこにあるのかを証明する必要があります...それはプロセス全体の再設計にあります。

リーンは開発プロセスではなく、ビジネスのあらゆる側面に適用できることを忘れないでください。

この議論を開発チームの枠を超えて取り上げる方法については、次のような興味深い書籍がいくつかあります。

• リーン思考
• 予算を超えて
• スループットアカウンティング
• トヨタウェイ
• 指揮統制からの自由
• 無駄のない製品とプロセスの開発
• 無駄のないソフトウェア開発の実装:コンセプトから現金まで

Answer 2

まず、ソフトウェア開発におけるカンバンが解決しようとしている次の問題を認識することが重要です。

• マルチタスク/仕事の過負荷。Kanbanは、ジャストインタイムおよびキューシステムによってこれらに対処します。キューには、すべての人を忙しくしておくのに十分ですが、過負荷ではありません（これには、推定と効率的な速度監視が伴います）。そして、JITは、人々がマルチタスクをする必要がなく、したがって生産性が低下することを保証します。
• 予測できないダウンストリームリリース. 。あなたが大規模なソフトウェア組織で働いている場合、あなたが開発している部分は、並列した大規模なソフトウェアの中の 1 つにすぎないかもしれません。したがって、あなたの機能を待っている下流チームが存在する可能性があります。Kanban のキュー システムとタイムボックス化された配信スケジュールにより、リリースにはある程度の予測可能性が確保されます。

ほとんどの場合、他のアジャイル実践でも、異なる手法を使用して同様の問題を解決しようとしています。

ウォーターフォール プロジェクトに依存する大規模で複雑な環境

これにより、アジャイルに従っていないプロジェクトに依存している場合、入力キューが予測できなくなるため、困難になります。非アジャイル プロジェクトがあなたに依存している場合、問題は少なくなるかもしれませんが、消費できる以上のものを生み出すことになる可能性があります (無駄のない用語で「ムダ」)。したがって、理想的には、カンバン自体ではないにしても、すべての依存プロジェクトが少なくともいくつかのアジャイル プラクティスに従う必要があります。

カンバン、フロー、ケイデンスに関する素晴らしい記事が見つかります。 ここ.

Answer 3

  

アジャイルマネジメント実践のためのかんばんを使用して、誰（またはscrumban）ですか？

はい、私が使用している： - ）

  

どのようにそれは滝のプロジェクトの依存関係を持つ大規模な複雑な環境で動作しますか？

私たちの環境では、> 500人の開発者を持っているので、それは非常に大きいです。私のチームは、主に保守作業のために、かんばんを使用して、現在開発のためにこれ、最初でした。他の依存のチームは、古典的な開発および管理手法を以下し、彼らは言っていますので、私たちの毎日の仕事は（彼らはまだやる）、非常に大変だったにのプッシュの仕事とカンバンを約のある。

私たちのアプローチは、私たちの仕事を透明にできる限り多くを伝えることだったが、我々は内部の仕事に焦点を当てた環境の抵抗に起因します。 WIPの制限は、私たちは集中し、我々は現時点では何をやっている人を知っていた視覚化のワークフローと一緒に役立っています。

かんばんの前に私たちのスループットは、（10件のアイテムが入って来たとき、我々はわずか9を届け、他の言葉で）、およびかんばん後、我々は100.4パーセントを持っていたし、それが増加して90％でした。追加の結果として、他のチームはによって来て、彼らは我々の結果を好きで、自分のかんばんシステムを実装したかったので、カンバンについて質問し始めました。現時点では私は、私たちの組織内カンバンを開始し、約5チームを知っています。

HTH、

ジョルト