ソフトウェア開発環境でシックスシグマを適用するにはどうすればよいですか？
私はJava開発者ですが、組織の利益を増やすことを目的としてシックスシグマを適用することについて学ぶように求められました。シックスシグマはすべての環境に適用できることを読みましたが、 mソフトウェア開発に適用する際のニュアンスに興味がある。
ソフトウェア開発環境に適用できるシックスシグマの概念と、それらを効果的に適用する方法を教えてください。
私の理解では、シックスシグマは次のことに重点を置いています。
- 欠陥の根本原因の特定と除去
- 製造プロセスまたはビジネスプロセスの適用におけるばらつきを最小限に抑える
これらの概念はソフトウェア開発に適用できるように見えますが、ソフトウェア開発ライフサイクル（SDLC）に効果的に適用できますか？
基本的なシックスシグマアクティビティは、頭字語[〜＃〜] dmaic [〜＃〜]によってキャプチャされ、これはDefine、Measure、Analyze、Improve、Controlの略です。これらを、改善したいプロセスに適用します。プロセスを定義し、測定し、測定値を使用して問題の原因に関する仮説を立て、改善を実装し、プロセスが統計的に「管理されたまま」であることを確認します。
ソフトウェアに関連するため、processはソフトウェア開発ライフサイクル（SDLC）またはその一部です。おそらく、シックスシグマの原則をSDLC全体に適用しようとはしないでしょう（少なくとも、最初はそうではありません）。代わりに、問題があると思われる領域を探します（たとえば、欠陥率が高すぎる、回帰が多すぎる、スケジュールが頻繁にずれている、開発者と顧客の間の誤解が多すぎるなど）。今のところ問題は、毎週生成されるバグが多すぎる（または少なくとも報告されている）ことです。したがって、ソフトウェア開発/バグ作成プロセスを定義します。次に、毎日書かれるコードの行数、要件変更の頻度、各エンジニアが会議に費やす時間数、その他の関連する可能性のある事実などのメトリックの収集を開始します。
次に、データを見て、パターンを識別しようとします。エンジニアリングチームAは、与えられたすべての期限に間に合い、多くの場合、タスクを早期に完了させることさえあることに気付くでしょう。最初は、チームBはボールに関してはそれほどそうではないようです。少なくとも半分の時間で1日か2日遅れて、1週間以上遅れることがあります。経営陣は、チームBを問題の一部と見なしており、状況を一変させようとしています。ただし、データを詳しく見ると、チームBのバグ率はチームAのバグ率よりもはるかに低く、さらに、チームAに起因するバグを修正するようチームBに求められることがよくあります。メンテナンスの時間の。
それで、あなたは何をしますか？収集したデータと実行した分析を使用して、変更を提案します。チームAとチームBはそれぞれ独自のバグを修正します。経営陣の祝福を受けて（そしてチームAの激しい反対に反対して）、その変更を実装します。その後、メトリックの収集を続行し、データを分析して、変更が違いを生んだかどうかを確認します。バグ率が許容できると見なされるまで、この測定/分析/実装サイクルを繰り返します。しかし、あなたはまだ終わっていません。実際、あなたは決して行われていません...バグ率を測定し続け、バグ率が許容範囲内にあることを確認する必要があります。それは統計的に「管理下」にあります。
ここには、改善しているプロセスの詳細、収集するメトリックの種類など、ソフトウェア開発に固有のものは何もないことに注意してください。ソフトウェア開発プロセスを改善するために使用するアクティビティは、開発しているアクティビティと同じですソフトウェア開発はウィジェットの製造とはかなり異なりますが、ウィジェットの製造プロセスに使用します。つまり、プロセスに設定する目標の種類に、常識を適用する必要があります。