Praktyki bez kontekstu

Znasz regułę 1:10:100, która mówi, że defekt znajdowany wcześnie jest 100 razy tańszy niż ten znajdowany na produkcji? Jeśli jeszcze jej nie poznałeś/aś, to wiedz, że uznaje się ją za uzasadnienie koncepcji wczesnego zaangażowania. Mówi ona, że wczesne eliminowanie defektów to powstrzymywanie ich propagacji, a im szybciej uda się znaleźć problem, tym mniejsze straty będzie on powodował. Ta definicja ma problem wynikający z powierzchowności jej analizy. Mało kto potrafi ją w pełni wyjaśnić, a jeśli nie wiesz, czym jest, zapewne nie jesteś w stanie jej poprawnie zastosować. Przyjrzyjmy się więc dokładnie, co stoi za kolejnymi cyferkami.

• 1 - jednokrotność oznacza pierwszy koszt. Robimy założenie, że rozmawiamy o defektach, które zostają wprowadzone do projektu wytwarzania oprogramowania w fazie definiowania wymagań. Jeśli ten defekt zostanie znaleziony w tej fazie, to jego poprawienie to właśnie „1”. Jest to abstrakcyjna wartość pokazująca bazę, do jakiej odnosimy się później. Przy okazji warto nadmienić, że znalezienie i poprawienie defektu w tej samej fazie projektowej nazywamy powstrzymaniem fazowym i jest to wartościowa praktyka, którą jest rozwinięciem „przesunięcia w lewo”, ponieważ odnosi się ona do każdej czynności projektowej, a nie jedynie do  tych pierwszych w projekcie.
• 10 – dziesięciokrotność. Jeśli opisany wcześniej defekt nie zostanie powstrzymany, to znalezienie go w fazie kodowania sprawi, że koszt jego naprawienia będzie dziesięć razy większy, niż gdyby udało się go powstrzymać w fazie zbierania wymagań klienta. 
• 100 – stukrotność, czasami występuje jako wartość bliska 270-krotności. Jest to koszt tego samego defektu, którego nie udało się wykryć w fazie wymagań, ale został znaleziony w fazie wdrożenia. Jego eliminacja będzie nas kosztowała stukrotnie więcej, niż gdybyśmy go naprawili tam, gdzie został wprowadzony. 

Żadna dobra prezentacja o jakości i jej kosztach nie może się obejść bez tej metryki i jej wizualizacji. Jest to jednak piękna bajka dla niedoinformowanych miłośników modelu kaskadowego. Jest wiele powodów, dla których nie powinieneś/aś w nią wierzyć, poczynając od tego, że bazuje na danych projektowych sprzed ponad 40 lat (Barry Boehm „"Software Engineering Economics”", 1981). Gdy przyjrzeć się realiom projektowym lat osiemdziesiątych ubiegłego wieku, to można by powiedzieć, że wytwarzanie iteracyjne, jak i szybka pętla zwrotna były w głębokich powijakach. To, co stanowi dziś główną praktykę SDLC, wtedy było jedynie sporadycznie stosowaną eksperymentalną praktyką. Kiedy Boehm zajmował się ekonomią inżynierii oprogramowania, to powszechnie stosowanym modelem był model kaskadowy (ang. waterfall), a on sam zaproponował pierwszy model o połączonych cechach kaskady oraz iteracyjności (model spiralny). Co więcej, pracował on w zupełnie innym kontekście projektowym. Ten amerykański profesor badał wielkie projekty informatyczne Stanów Zjednoczonych. Nie możemy zapominać, jakie języki wtedy królowały – ADA, Pascal czy ASM. Był to zupełnie inny świat.

Szukanie relacji między tym, jak Ty dziś tworzysz oprogramowanie, a o jakich programach pisał Boehm, jest próbą porównania katapulty do wyrzutni rakiet. Znajdziesz cechy wspólne i nawet metryki, ale już konkretne wartości będą miały ze sobą niewiele wspólnego. 

Bezkrytyczna wiara w zasadę 1:10:100 blokuje nas w realnym wyliczeniu tych proporcji bazując na tym jak dziś wytwarzamy oprogramowanie. Skrócił się czas od zdefiniowania wymagania do jego odebrania, mamy ciągle obecnych właściciel produktu i zupełnie inne metody prowadzenia projektów. Samo to jest wydaje się być wystarczającym uzasadnieniem, by wyrzucić zasadę do śmietnika. O dziwo nie jest to jednak jedyny przypadek, gdy stosujemy reguły z przeszłości. Kierownicy projektów ciągle budują swoje zespoły, bazując na regule 1:5 czy bezkrytycznie podchodzą do zasady Pareto 80/20. W pierwszym przypadku mamy do czynienia z tzw. optymalną relacją liczby testerów do programistów w zespole, a w drugiej z założeniem, które często w informatyce pokazywane jest jako „20% kodu zawiera 80% defektów”. Są to jednak kolejne prawdy objawione niemożliwe do udowodnienia.

Z moich rozmów z członkami zespołów wynika, że zbyt często wierzą oni, że liczba defektów w jednej wersji oprogramowania dąży do nieskończoności. Uzasadniają to tym, że nie jesteśmy w stanie udowodnić, że defektów nie ma. Musi być ich więc tam tak wiele, że nawet nieskończone testowanie nie doprowadzi do znalezienia ich wszystkich. Jednak matematyczne podejście lub logika pokazują, że jesteśmy w stanie udowodnić, że w oprogramowaniu równie dobrze może być 0, 1 lub wiele defektów, ale w żadnym przypadku, że jest ich tam nieskończoność. Argumentem opowiadającym się za tą regułą może być stwierdzenie, że skoro analitycy, architekci i programiści mają skończony czas swojej pracy, to nie mogą się pomylić nieskończenie wiele razy i wprowadzić nieskończenie wiele defektów do oprogramowania. 

Od wielu lat w świecie IT słychać krytykę i próbę wyeliminowania tzw. najlepszych praktyki (ang. best practises). Uznajemy, że nie ma jakieś zasady, która sprawdzi się w każdym kontekście, a jedynie, że są praktyki, które mogą mieć dla nas większą wartość w naszym projekcie. Podobnie powinniśmy wyzbyć się już tych dobrych zasad ilościowych próbujących definiować liczbę, koszty defektów czy jakości, odwołując się do historycznych badań i danych, które współcześnie nie mają żadnej wartości.