ソフトウェアエンジニアリングプログラムのボトルネックを特定する方法は何ですか？
私は金融サービスのソフトウェア開発プログラムに参加しています-100人の開発者、テスター、BA、PM、その他のサポートスタッフがいます。
Lean Software Developmentの実装 と The Phoenixプロジェクト を読みました。どちらもフローのボトルネックを特定し、それを最適化することについて説明しています。 （プロジェクトのクリティカルパスとのいくつかの類似点）。
直感的に、テスト環境の数、回帰テストに必要な時間と労力、モノリスのサイズ、開発者の数などとして、ボトルネックを特定できます。私たちがやろうとしていることは、それを他のすべてのものを保持している1つのボトルネックにまで煮詰めることです。 （製造プロセスフローと同様）。
リーンソフトウェア開発の適用では、バリューストリーム分析について説明しますが、システム全体にとって重要な1つのブロッカーを特定するのに十分ではありません。
私の質問は次のとおりです：ソフトウェアエンジニアリングプログラムの主要なボトルネックを特定する方法は何ですか？
編集：追加の前提条件：
私の環境では、特定の日に配信されるスコープの大きなチャンクに資金が割り当てられています。本質的に、品質、範囲、時間は事前に固定されています。 （絶対に必要な場合は、範囲と時間に多少の差異があります）。
これは、「システム内を移動する小さな断片」という概念がないことを意味します。ストーリーがたくさんある大きなプロジェクトだけがあります（60以上のストーリー-それぞれに10日間の作業がある）。
これは、いくらか滝のような環境（Sarbanes Oxleyが規定するのと同じくらい）で、システム統合テストとユーザー受け入れテストのフェーズが別々になっています。
最も重要なボトルネックを特定する1つの方法は、作業項目が通過するステージを視覚化することです。
最初に、いくつかの作業項目（新機能、バグ、改善など）を追跡し、項目がチームに認識されてから本番環境に正常にデプロイされるまでの完全なサイクルを実行してください。本番環境への完全なパスを通過するために必要な手順と、他の誰かが作業を続けるのを待つか、または他の理由で待機するためにチケットが山に置かれる可能性がある場所を書き留めます。
これは、かんばんボードを使用してすべて表示できます。最も単純な形式のかんばんボードは、開発プロセスの作業段階と待機状態、および作業項目の付箋を表す多数の列で構成されます。
各付箋は、開発プロセスのどこにあるのか、または何を待っているのかに応じて、全面的に移動します。
かんばんボードを使用すると、列にチケットが山積みになるのを見たり、新しいチケットが入ってくるよりも早くチケットが列から引き出されたりするのを見て、ボトルネックを特定できます。
- 待機列がそのチケットが削除されるよりも早く満杯になる場合は、チケットが待機しているリソースが過負荷になっていることを示しています。
- 「作業を行う」列に、作業できるチームメンバーよりもかなり多くのチケットが含まれている場合、それはチームが同時に多くのことに取り組んでいる（コンテキストの切り替えにより非効率になる）か、待機していることを示しています状態を逃しました。
- 待機列が定期的に完全に空になる（チケットが入ってくるよりも早く出る）場合は、それらのチケットをプルしているチームが十分に活用されていないか、人員が多すぎることを示しています。
重要なボトルネックは、これらの効果が最も強く見える列です。
Bart van Ingen Schenauの答え はとても良いと思います。基本的には、リアルタイムのバリューストリームマップです。しかし、私はその答えの上にあなたを助けるかもしれない他のいくつかの提案があります。
まず、タスクの各状態の時間を追跡することを検討してください。ツールはこれを提供できるはずです。ツールが対応していない場合、または物理的なボードを使用している場合は、各カードに移行日を書き込むことができます。これにより、平均時間を取得し、長時間かかるフェーズを特定できます。ただし、キャプチャする必要があるのは、待機時間とアクティブ時間です。繰り返しになりますが、カードにメモをとることはこれに役立ち、サイクルの最後に、カードからの時間を何かに入れて分析することができます。
次に、活動の規模を検討します。 Bartが提案したようなカンバンボードを使用している場合は、より細かい列にするか、列内で発生することに対してバリューストリームマップを作成することを検討してください。
あなたの時間を知ったら、最初に最も長い時間を最適化します。最初に、「無駄」時間、つまりアクティブな状態ではない時間を減らすことを試みます。次に、処理時間を短縮しようとすることを検討します。