Die grundlegenden Six Sigma-Aktivitäten werden unter dem Akronym DMAIC erfasst , das für Define, Measure, Analyze, Improve, Control ( Definieren, Messen, Analysieren, Verbessern, Steuern) steht . Sie wenden diese auf den Prozess an, den Sie verbessern möchten: Definieren Sie den Prozess, messen Sie ihn, verwenden Sie die Messungen, um Hypothesen über die Ursachen von Problemen zu erstellen, implementieren Sie Verbesserungen und stellen Sie sicher, dass der Prozess statistisch "unter Kontrolle" bleibt.
In Bezug auf Software ist der Prozess Ihr Software Development Lifecycle (SDLC) oder ein Teil davon. Sie würden wahrscheinlich nicht versuchen, die Six Sigma-Prinzipien auf die gesamte SDLC anzuwenden (oder zumindest nicht anfangs). Stattdessen sollten Sie nach Bereichen suchen, in denen Sie der Meinung sind, dass Sie ein Problem haben (z. B. unsere Fehlerquote ist zu hoch, zu viele Rückschritte, unser Zeitplan rutscht zu oft ab, zu viele Missverständnisse zwischen Entwicklern und Kunden usw.). Nehmen wir zunächst einmal an, dass das Problem darin besteht, dass jede Woche zu viele Bugs produziert (oder zumindest gemeldet) werden. Sie definieren also den Softwareentwicklungs- / Fehlererstellungsprozess. Dann beginnen Sie mit der Erfassung von Metriken wie der Anzahl der täglich geschriebenen Codezeilen, der Häufigkeit von Anforderungsänderungen und der Anzahl der Stunden, die jeder Ingenieur in Besprechungen verbringt.
Als Nächstes betrachten Sie die Daten und versuchen, Muster zu erkennen. Vielleicht stellen Sie fest, dass das Engineering-Team A jeden angegebenen Termin einhält und Aufgaben oft sogar vorzeitig erledigt! Anfangs scheint Team B nicht ganz so auf dem Ball zu sein - sie verpassen ihre Deadlines mindestens zur Hälfte um ein oder zwei Tage und sind gelegentlich um eine Woche oder länger zu spät. Das Management sieht Team B als ein Problem und versucht, die Dinge durcheinander zu bringen. Ein genauerer Blick auf die Daten zeigt jedoch, dass die Fehlerrate von Team B viel niedriger ist als die von Team A, und außerdem wird Team B häufig gebeten, Fehler zu beheben, die Team A zuzuschreiben sind, da das Management der Ansicht ist, dass Team A zu wertvoll ist, um viel Geld auszugeben der Zeit für die Wartung.
Also, was machst du? Unter Verwendung der von Ihnen gesammelten Daten und der von Ihnen durchgeführten Analyse schlagen Sie eine Änderung vor: Team A und Team B beheben jeweils ihre eigenen Fehler. Mit dem Segen des Managements (und gegen die vehemente Opposition von Team A) setzen Sie diese Änderung um. Anschließend erfassen Sie weiterhin Messdaten und analysieren die Daten, um festzustellen, ob Ihre Änderung einen Unterschied bewirkt hat. Wiederholen Sie diesen Mess- / Analyse- / Implementierungszyklus, bis die Fehlerrate als akzeptabel erachtet wird. Aber du bist noch nicht fertig. Tatsächlich bist du nie fertig ... Sie müssen die Fehlerrate weiterhin messen und sicherstellen, dass die Fehlerrate innerhalb des akzeptablen Bereichs bleibt, dh sie ist statistisch "unter Kontrolle".
Beachten Sie, dass es hier nichts gibt, das für die Softwareentwicklung spezifisch ist, außer die Besonderheiten des Prozesses, den Sie verbessern, die Arten von Metriken, die Sie sammeln usw. d Verwendung für einen Widget-Herstellungsprozess, obwohl sich die Softwareentwicklung erheblich von der Widget-Herstellung unterscheidet. Das bedeutet nur, dass Sie bei den Zielen, die Sie für Ihren Prozess festlegen, einen gesunden Menschenverstand anwenden müssen.