私の現在の立場では、QAがボトルネックになっています。残念なことに、QAがテストを終了できるように、現在のビルドから除外された機能が発生しています。つまり、開発中の機能は、開発者がすでに移行してから2〜3週間テストされない可能性があります。開発者がQAをより速く進めると、この時間ギャップはさらに大きくなるだけです。
私はコードコンプリートのコピーをめくって、欠陥を修正するコストが存在するほど指数関数的に増加することを示す「ハードデータ」スニペットを探しています。誰かがこの概念を裏付けるいくつかの研究を私に指摘できますか?私は、QAのボトルネックは、彼らが思っているよりもはるかにコストがかかるということを、権力に納得させようとしています。
IMHO、リファレンスは必要ありません。これはあなたができることです(むしろすべきです):
遅延のコストを定量化!機能のテストに1週間かかると仮定しましょう。 2〜3週間の遅延は、少なくとも4週目まで機能が利用できないことを意味します。そして、それも100%の成功を前提としています。約5週間の遅延になるように、もう1週間の修正時間を追加します。
さて、可能であれば、プロジェクト/機能の予想される締め切りにアクセスしてください。クライアントはいつまでにそれを期待しますか?滑りますか?そうでない場合、結果として他の人はスリップしますか?それで、結果として「リリース」はどれくらい遅れますか?
そのリリースの「会社にかかるコスト」はどれくらいですか?つまり、クライアントはそのリリースからどれくらいの利益を期待できるでしょうか?彼らがそのリリースから5200ドル/年の利益を期待している場合、毎週スリップすると、失われた収益に100ドルがかかります。それがクライアントの見解です。このデータにアクセスできる場合とアクセスできない場合がありますが、考慮に入れて、遅延が関係にどのように影響するかを説明することは価値があります。
さて、開発者にとっての損失は何ですか?開発者が他の機能に移行したら、開発者に彼らのサイクルを断ち、以前の機能を「修正」するように依頼します。時間/労力の損失は何ですか?結果として無駄になる1時間ごとに給与を倍数として使用して、会社のコストに変換します。これを使用して、廃棄物が「食べている」「利益/収益」の量を表すことができます。
偶然見つけたものは、「コストオブディレイ」を使用して簡単に定量化できます。これは、製品開発フローのDon Reinersteinと、アジャイルソフトウェア要件のDean Leffingwellによって提唱されています。あなたは、経済的要因によってそのようなすべての主張を裏付けて、主要言語が$$である「より高い力」を納得させる必要があります-あなたはmust彼らを納得させるために彼らの言語を話します:)
運の獣! (しゃれ意図:)
ここではCode Completeが適切なリソースだとは思いません。これはコードの問題ではなく、プロセスの問題であり、おそらく管理の問題です。
プロセスの一部が特に弱い場合は、 Theory of Constraints :
制約を特定します。
これは、プロセス全体の中で最も遅い、または最も非効率的な部分を見つけることを意味します。あなたの場合、それはテスト中です。しかし、テストのどの部分?それは...ですか:
これらはすべて非常に異なる問題であり、異なる解決策が必要です。どちらが最もコストがかかる/重要かを判断する必要があります。上記の活動はすべて時間がかかる(別名:お金)ため、付加価値時間に過ぎないので、経営陣にそれを正当化することは難しくありません。
制約を利用します。
つまり、制約プロセスをaround最適化します。テスターをアイドル状態にしないでください。これは基本的に次のようになります。
この段階では、テストプロセス自体を(まだ)最適化するのではなく、オーバーヘッドを減らすことが重要です。テスターの時間を無駄にしないでください。本当に無駄な時間(= /// =)をなくすことも、管理者にとって容易な売りです。
その他の制約に従属するアクティビティ
この時点で、テスターはそれ自体で可能な限り生産性が高いので、他の領域から生産性を借り始める必要があります。
制約を引き上げます。
テスターが生産性と最小限のオーバーヘッドの両方の面でフル稼働していて、それでもまだ十分に速くない場合は、テストへの投資を増やす必要があります。
手順1に戻ります。
これはすべての常識ですが、残念ながら、少なくともほとんどの組織ではそうではありません。管理から多くの抵抗を得ている場合、非常に貴重な手法は Value Stream Mapping (無駄のない製造からの手法)です。これは、どれだけの時間を示すために使用できるため、実際にすべてのお金が無駄になっていますリリース候補者が次のステージに移動できない日。機会費用を理解するのは難しいですが、これは、それを視覚化して実証するために私が見つけた最良の方法の1つです。
そして、なしが機能する場合...多分あなたは機能不全の会社にいるかもしれませんが、手遅れになる前に出てください!
しかし、マネージャーの机に数枚の紙を落とし、問題にお金を投げるように依頼するだけでは、この問題を解決できません。彼らは、(正しく)お金を投げても実際には解決しない可能性があり、それはさらに悪い。 solutionsを提供する必要があります。それがこの答えです。 「より多くのテスターが必要」ではなく、「コスト/メリットの降順でこの問題を解決する方法のリストをここに示します」として問題を紹介すると、より多くの成功を収めることができます。
29と30ページには、探しているデータがあるかもしれませんが、フォローアップが必要な場合があります。
30ページのこの文で言及されている調査を調べます。
何十社もの企業が、プロジェクトの後半ではなく早期に欠陥の修正に集中するだけで、開発コストとスケジュールを2倍以上削減できることを発見しました(McConnell 2004)。
ところで、本を手に取り直して更新したのはあなたの質問でした:-)
あなたが説明しているのは、プロセスのボトルネックです。リーン理論は、プロセスには常にボトルネックがあると述べていますが、その重大度は大きく異なる可能性があります。 QAがさらに1人雇った場合、開発がボトルネックになる可能性があります。
コストを理解するために、次の状況を想像してみてください。開発者の1人を選びました。彼の仕事は決して品質保証されることはありませんが、常に無期限にキューに入れられます。想像してみてください。これは、QAが残りの開発者の作業をタイムリーに品質保証でき、遅延によるコストが発生しないことを意味します。
そのシナリオでは、遅延のコストは、開発者の仕事が無駄になるため、開発者の給与のコストです。
プロセスによって生み出された価値ではなく、コストの観点から私が議論する理由は、プロセスの価値ははるかに優れているとはいえ、それを文書化することは困難だからです。
私はコードコンプリートのコピーをめくって、欠陥を修正するコストが存在するほど指数関数的に増加することを示す「ハードデータ」スニペットを探しています。誰かがこの概念を裏付けるいくつかの研究を私に指摘できますか?
バグを発見するための指数コストは NIST調査 に基づいているようです。この調査は、明確な滝の段階を想定した調査でした。
Software Development Stage | Cost
-----------------------------------+------
Requirements and Design | 1X
Code and Unit Testing | 5X
Integration and System Testing | 10X
Beta Testing | 15X
Post Release | 30X
( ここからここにテーブル )
アジャイルソフトウェア開発方法論の目的の1つは、これらの個別の段階を削除し、これらのコストを削減することです。ウォーターフォールに他の方法を使用する場合、この数値は適用されません。
問題はQAにありません。実際、QAがテストを行っている場合、遅延はほとんど心配する必要はありません。もう一度説明させてください(繰り返しになりますが、これはプログラミング業界ではよくある誤解です)。QA要件(多分以前)から、開発、検証、リリース、サポートまで、SDLC全体を監視することにより、製品の品質を保証します。テストでは、コードに明らかな欠陥がないことを確認します。非常に大きく重要な違いがあります。真のQAが得られた場合、彼らはテスト/ V&V部門全体で、なぜリリースに遅延してビジネス時間(したがってお金)がかかるのか、プロジェクト管理全体でプロジェクトのスケジュールを適切に管理しているか、またはすべての管理を行っているのかを尋ねます。生成されるコードなどに十分なテスターがいることを確認してください...
したがって、QAであなたが本当にテストを意味していると仮定すると、元の質問に戻ります。コードコンプリートはそれを正しく理解しました-欠陥のコストは挿入から修正までの時間です。早期検出は、早期に修正する場合にのみ役立ちますが、ほとんどの人の解釈は間違っています。
(注:私はここでデビルズアドボケイトを演じていますが、あなたの状況は何も知らないので、これを文字どおりに受け取らないでください)テスト部門による遅延の原因は代償ですが、もしそうなら、私は尋ねなければなりません彼らがあなたの欠陥を見つけるのを待っています、あなたは何をしています-あなたはあなた自身の欠陥を見つけてはいけませんか?おそらく、彼らの仕事が少ない(あなたからの欠陥が少ない高品質の入力による)場合、遅延はそれほど大きくなく、コストも低くなります-マネージャーとして、提供するコードの欠陥を減らす方法を尋ねます(あなたの議論に基づいて)テストによって発見された場合、それらの欠陥はあなた自身よりもコストがかかるので、テストします。
また、あなたのマネージャーとして、私はテストの仕事があなたの欠陥を見つけることではないと述べるかもしれません、彼らの仕事は欠陥がないことを見つけることです-あなたが彼らに欠陥を見つけることを期待しているなら、おそらくあなたの仕事を十分に行っていないかもしれません。
これへのアプローチ方法に注意してください。問題の解決策がない場合は、2番目に優れている可能性があります。