W artykule Robert Mays opisuje swoje doświadczenia i sugestie związane z zapobieganiem defektom. Artykuł ukazał się w IBM Systems Journal w 1990 roku (niestety adres URL jest już nieaktualny).
Zapobieganie defektom składa się z czterech elementów włączonych w proces tworzenia oprogramowania:
- spotkania w trakcie których dokonywana jest szczegółowa analiza przyczyn (root cause) błędów i sugerowane są akcje prewencyjne
- wdrożenie akcji prewencyjnych w zespole
- spotkania przed pracą mające na celu zwrócenie uwagi programistów na sprawy jakości
- zbieranie i śledzenie danych
Autor wskazuje, że efektywniej jest zapobiegać pojawianiu się błędów niż je wyszukiwać (inspekcje, testowanie). Wtedy czas przeznaczany typowo na wyszukanie błędów można spożytkować w inny sposób (np. pracując nad kolejnym produktem).
Prewencja błędów opiera się na ciągłej analizie przyczyn błędów i usuwanie tych przyczyn poprzez poprawę procesu, metodyki pracy, technologii i narzędzi. Przy analizie przyczyn korzysta się z diagramów przyczynowo – skutkowych (czasami zwanych diagramami Ishikawy od nazwiska twórcy).
Proces ten zakłada włączenie różnych aktywności związanych z jakością do codziennej pracy zespołu.
Analiza wykrytych błędów
Podstawową aktywnością w projekcie jest spotkanie poświęcone analizie wykrytych błędów. Zespół próbuje znaleźć przyczyny (root cause) zaistniałych błędów i następnie proponuje wprowadzenie modyfikacji w procesie produkcyjnym, by zapobiec powstaniu takich błędów w porzyszłości. Dla każdego błędu stawiane są następujące pytania:
- Jaka jest kategoria tego błędu: komunikacja, przeoczenie, brak wiedzy, literówka?
- W jaki sposób błąd został wprowadzony?
- W której fazie tworzenia systemu powstał?
- W jaki sposób można zapobiec powstaniu takiego błędu w przyszłości? W jaki sposób podobne błędy mogą być usunięte z innych części systemu (o ile istnieją a nie zostały jeszcze wykryte przez inne techniki)?
Celem spotkania jest uzyskanie sugestii co do zapobiegania poszczególnym błędom. Nie powinno ono utknąć w zbyt szczegółowych rozważaniach (nie może być za długie). Przy końcu spotkania osoba prowadząca powinna zadać następujące pytania:
- Czy w analizowanych błędach widać trend, który może oznaczać szerszy problem?
- Co poszło dobrze podczas poprzedniej fazy? Co przyczyniło się do oszczędzenia czasu?
- Co poszło źle podczas poprzedniej fazy? Co stanowiło największy problem?
- Czy można w jakiś sposób poprawić techniki detekcji błędów, narzędzia, komunikację, edukację w stosunku do stanu aktualnego?
Obecność na takim spotkaniu programistów, którzy pracują nad systemem jest konieczna, ponieważ osoba, która wprowadziła błąd może najlepiej określić przyczynę wprowadzenia błędu.
Wprowadzenie korekt w procesie
Zespół wykonawczy (action team) odpowiada za wprowadzenie w życie akcji prewencyjnych zdefiniowanych w trakcie spotkania. Zespół ten typowo obsługuje wszystkie projekty prowadzone w ramach organizacji. Zwykle każdy członek zespołu odpowiada za jeden segment (definicja procesu, dokumentacja, narzędzia, edukowanie, projekt, programowanie, testowanie).
Oto możliwe rodzaje akcji zapobiegawczych:
- Zmiany w procesie produkcyjnym
- Utworzenie nowych narzędzi
- Szkolenie pracowników (seminaria, techniczne opisy niektórych aspektów produktu, artykuł na temat powtarzających się błędów)
- Zmiany w produkcie (systemie informatycznym), które ułatwiają wykrywanie błędów
- Usprawnienie komunikacji np. automatyczne powiadamianie o zmianach w projekcie dla wszystkich zainteresowanych osób
Mniejsza skala projektów
Opisane w artykule praktyki stosowane są w projektach dużej skali (kilkadziesiąt, kilkaset osób). Naturalnie pojawia się pytanie czy techniki zapobiegania defektom można stosować w projektach mniejszych (kilka, kilkanaście osób) lub w takich, gdzie struktura zespołu jest rozproszona (coraz częściej zdarza się, że zespół jest rozproszony geograficznie).
Według mnie jest to jak najbardziej możliwe. Oczywiście należy dopasować działanie do wielkości i charakteru zespołu:
- Analizę błędów można przeprowadzić przy użyciu kanału e-mail. Jest to mało absorbująca forma kontaktu (nie wymaga obecności w jednym czasie wszystkich członków zespołu)
- Rolę zespołu wykonawczego muszą przejąć członkowie zespołu wraz z automatycznym sprawdzaniem przyjetych reguł w kodzie (analizatory statyczne)
Uważam, że w każdej wielkości projektu korzyści wynikające z zapobiegania defektom są warte poświęconego czasu. Łatwiej jest problem usunąć raz niż wielokrotnie łatać powstałe w jego wyniku skutki na etapie testowania produktu.
Opisana metoda pasuje jak ulał do IBM’a
Mega-korporacja, w której każdy programista to nie więcej niż trybik w dużej maszynie. Trochę się jednak od roku 1990 zmieniło i zdano sobie sprawę, że programowanie to trochę co innego niż praca przy taśmie montażowej. Takie sformalizowanie procesu usuwania defektów, jakie opisałeś, wydaje się bardzo uciążliwe. Metodologie, procedury… wszystko to ma na celu wyeliminować błędy, a czego ubocznym skutkiem jest tak naprawdę obniżenie wydajności i jakości wyników pracy:
a) tego typu procedury zabierają czas, który można poświęcić na programowanie
b) są uciążliwe, więc programiści tracą ochotę do pracy
W procesie produkcji oprogramowania mamy tak naprawdę dwa zasoby: ludzi i narzędzia. Jeśli defekt powstał w narzędziach, można go wyeliminować szybko i jednorazowo, bez konieczności angażowania dużej ilości ludzi. Jeśli źródłem defektu jest człowiek, to w chwili kiedy się o nim dowie już prawdopodobnie wyciągnął wnioski i nauczył się postępować na przyszłość (jeśli się nie nauczył to należy się zastanowić czy jest odpowiednią osobą na danym stanowisku.)
Comment by Michał Paluchowski — 14/09/2009 @