Podstawowe działania Six Sigma są przechwytywane przez akronim DMAIC , który oznacza: Definiuj, Mierz, Analizuj, Ulepsz, Kontroluj . Stosujesz je do procesu, który chcesz ulepszyć: zdefiniuj proces, zmierz go, użyj pomiarów, aby sformułować hipotezy dotyczące przyczyn problemów, wdrożyć ulepszenia i upewnić się, że proces pozostaje statystycznie „pod kontrolą”.
W przypadku oprogramowania proces ten obejmuje cykl życia oprogramowania (SDLC) lub jego część. Prawdopodobnie nie próbowałbyś zastosować zasad Six Sigma do całego SDLC (a przynajmniej nie początkowo). Zamiast tego szukałbyś obszarów, w których uważasz, że masz problem (np. Nasz wskaźnik wad jest zbyt wysoki; zbyt wiele regresji; nasz harmonogram przepada zbyt często; zbyt wiele nieporozumień między deweloperami a klientem itp.). Powiedzmy na razie, że problem polega na tym, że co tydzień produkuje się (lub przynajmniej zgłasza) zbyt wiele błędów. Zdefiniuj więc proces tworzenia oprogramowania / tworzenia błędów. Następnie zaczniesz zbierać dane, takie jak liczba wierszy kodu pisanych każdego dnia, częstotliwość zmian wymagań, liczba godzin spędzanych przez każdego inżyniera na spotkaniach,
Następnie patrzysz na dane i próbujesz dostrzec wzorce. Być może zauważysz, że zespół inżynierów A dotrzymuje każdego wyznaczonego terminu, a często nawet kończy zadania wcześniej! Początkowo drużyna B nie wydaje się całkiem taka na piłce - nie dotrzymuje terminów o dzień lub dwa co najmniej o połowę czasu, a czasami spóźnia się o tydzień lub dłużej. Zarząd postrzega zespół B jako problem i stara się go zmienić. Jednak bliższe spojrzenie na dane pokazuje, że wskaźnik błędów w zespole B jest znacznie niższy niż w zespole A, a ponadto zespół B jest często proszony o naprawienie błędów, które można przypisać zespołowi A, ponieważ kierownictwo uważa, że zespół A jest zbyt cenny, aby wydać dużo czasu na utrzymanie.
Więc co robisz? Korzystając z zebranych danych i przeprowadzonej analizy, sugerujesz zmianę: zespół A i zespół B naprawią swoje własne błędy. Z błogosławieństwem kierownictwa (i przeciwko gwałtownej opozycji drużyny A) wprowadzacie tę zmianę. Następnie kontynuujesz zbieranie danych i kontynuujesz analizę danych, aby sprawdzić, czy zmiana coś zmieniła. Powtarzaj ten cykl pomiaru / analizy / wdrożenia, aż wskaźnik błędów zostanie uznany za akceptowalny. Ale jeszcze nie skończyłeś. W rzeczywistości nigdy nie skończyłeś ... musisz ciągle mierzyć współczynnik błędów i sprawdzać, czy wskaźnik błędów pozostaje w dopuszczalnym zakresie, tj. Jest statystycznie „kontrolowany”.
Zauważ, że nie ma tu nic, co byłoby specyficzne dla rozwoju oprogramowania, poza specyfiką ulepszanego procesu, rodzajami zbieranych danych itp. Działania, których używasz do ulepszania procesu tworzenia oprogramowania, są takie same jak te, które „ d używać do procesu produkcji widgetów, mimo że tworzenie oprogramowania różni się znacznie od produkcji widgetów. Wszystko to oznacza, że musisz zachować zdrowy rozsądek w rodzajach celów wyznaczonych dla twojego procesu.