基本的なシックスシグマアクティビティは、定義、測定、分析、改善、制御を表す頭字語DMAICによってキャプチャされます。これらを改善したいプロセスに適用します。プロセスを定義し、それを測定し、測定値を使用して問題の原因に関する仮説を立て、改善を実装し、プロセスが統計的に「管理」されていることを確認します。
ソフトウェアに関連するプロセスは、ソフトウェア開発ライフサイクル(SDLC)またはその一部です。おそらく、シックスシグマの原則をSDLC全体に適用しようとは思わないでしょう(少なくとも、最初はそうではありません)。代わりに、問題があると思われる領域を探します(たとえば、欠陥率が高すぎる、回帰が多すぎる、スケジュールが頻繁にずれる、開発者と顧客の間の誤解が多すぎるなど)。今のところ、問題は毎週あまりにも多くのバグが生成されている(または少なくとも報告されている)ということです。したがって、ソフトウェア開発/バグ作成プロセスを定義します。次に、毎日書かれているコードの行数、要件の変更頻度、各エンジニアが会議に費やす時間数などのメトリックの収集を開始します。
次に、データを見て、パターンを識別しようとします。エンジニアリングチームAが与えられたすべての締め切りに達し、タスクを早期に完了することさえあることに気づくかもしれません!当初、チームBはボール上ではそれほどそうではないようです。少なくとも半時間は1日か2日遅れており、1週間以上遅れることもあります。経営陣は、チームBを何か問題と見なし、物事を揺さぶろうとしています。ただし、データをよく見ると、チームBのバグ率はチームAのバグ率よりもはるかに低く、さらに、チームBはチームAに起因するバグを修正するように求められることがよくあります。メンテナンスの時間。
それで、あなたは何をしますか?収集したデータと実行した分析を使用して、変更を提案します。チームAとチームBはそれぞれ独自のバグを修正します。経営陣の祝福(そしてチームAの激しい反対に反対)で、あなたはその変化を実行します。その後、メトリックの収集を続け、データの分析を続けて、変更が違いを生むかどうかを確認します。バグ率が許容可能とみなされるまで、この測定/分析/実装サイクルを繰り返します。しかし、まだ完了していません。実際、これで終わりではありません ...バグ率を測定し、バグ率が許容範囲内にあること、つまり統計的に「管理されている」ことを確認する必要があります。
ここには、改善するプロセスの詳細、収集するメトリックの種類など以外に、ソフトウェア開発に固有のものはないことに注意してください。ソフトウェア開発プロセスを改善するために使用するアクティビティは、あなたと同じです。 dソフトウェア開発はウィジェットの製造とはかなり異なりますが、ウィジェットの製造プロセスに使用します。つまり、プロセスに設定する種類の目標に常識を適用する必要があるということです。