Reguła dziewięćdziesiąt dziewięćdziesiąt w praktyce

Pierwsze 90 procent kodu stanowi pierwsze 90 procent czasu programowania. Pozostałe 10 procent kodu stanowi pozostałe 90 procent czasu programowania.

- Tom Cargill, Bell Labs

Co to dokładnie znaczy w praktyce? Że programiści wykonują znaczną ilość pracy i że dają z siebie 180% lub?

Wyobraź to sobie tak: Kiedy zaczynasz pracę nad oprogramowaniem, możesz napisać ogromne ilości kodu w stosunkowo krótkim czasie. Ten nowy kod może dodać ogromną liczbę nowych funkcji. Problem polega na tym, że często ta funkcjonalność jest daleka od „ukończenia”, mogą występować błędy, niewielkie zmiany (małe w biznesie małe) i tak dalej. Oprogramowanie może więc wyglądać na gotowe (90% zrobione), ponieważ obsługuje większość przypadków użycia. Ale oprogramowanie nadal wymaga pracy. Chodzi o to, że pomimo tego, że oprogramowanie wydaje się prawie gotowe, ilość pracy związanej z doprowadzeniem tego oprogramowania do prawidłowego działania jest tak duża, jak osiągnięcie tego stanu „prawie ukończonego”. Jest tak, ponieważ naprawianie błędów jest często czasochłonne, ale nie generuje dużo kodu.

Problem polega na tym, że większość deweloperów ocenia, że ​​oprogramowanie jest w stanie „prawie ukończonym”, ponieważ jest to stosunkowo proste w porównaniu z faktycznym oszacowaniem całkowitego wysiłku, jaki oprogramowanie to zrobi.

Jest to odniesienie do wspólnego scenariusza, który niestety wciąż występuje dzisiaj:

1. Zespół jest proszony o oszacowanie (tj. Odgadnięcie) ilości pracy wymaganej do napisania całego kodu,
2. Projekt podlega licznym naciskom wewnętrznym i zewnętrznym, aby „dotrzymywać terminów i budżetu”,
3. Tak więc w przypadku znacznego odsetka projektu zgłaszane jest „docelowe”. Często komplikuje się to, wybierając najpierw proste zadania, aby zapewnić dobry postęp.
4. Następnie na pewnym etapie osiąga się punkt krytyczny, w którym rzeczywistość musi zostać zaakceptowana: projekt nie zostanie ukończony na czas, a data premiery zostanie przesunięta (często wiele razy).

„90%” jest liczbą arbitralną, ale dobrze to rozumie: szacunki są domysłem i prawdopodobnie będą błędne (często bardzo błędne), a natura ludzka zapewnia, że ​​prawie zawsze jesteśmy niedoszacowani, więc sprawy się przekraczają.

Słyszałem inną wersję tego (zwaną także „regułą 90–90”), która wygląda następująco:

Po zaimplementowaniu 90% funkcjonalności nadal muszę zaimplementować pozostałe 90% .

Obie wersje odnoszą się do trudności z prawidłowym oszacowaniem wysiłków związanych z opracowywaniem oprogramowania i typowych pułapek, w które ludzie wpadają:

• publikowanie statystyk tam, gdzie wymagane są oszacowania, i zgadywanie („jestem w 80% gotowy”)
• skupić się na złożoności algorytmicznej kodu, który ma zostać napisany, ze szkodą dla ilości pracy (nie doceniając wymaganego wysiłku przy wykonywaniu typowych zadań)
• brakujące kroki („poza zasięgiem wzroku, poza zasięgiem umysłu”)
• niedocenianie wysiłków na rzecz utrzymania i zmiany istniejącego kodu
• niedoszacowanie wysiłku wymaganego dla kodu płyty kotła / „kleju”

Ta reguła uzupełnia zasadę 80-20. Istnieje wiele różnych interpretacji reguły 80-20, ale dwie najbardziej mi się podobają:

1. Pierwsze 80% opracowanie produktu zajmuje 20% wysiłku.
2. 80% błędów dotyczy 20% kodu.

W praktyce oznacza to: rozwój rozpocznie się i będzie trwał do pewnego momentu, w którym zauważone zostaną pierwsze opóźnienia. Opóźnienia mogą mieć różny charakter:

• Słaba kontrola jakości, powodująca błędy
• Dodatkowe wymagania, które klient wymyślił po drodze (a przyczyny tego mogą być również liczne)
• Niejasne wymagania od samego początku, które powodują odrzucanie części poprzedniego rozwoju (co może również powodować błędy regresji)
• Początkowe niedoszacowanie z powodu niejasnego zakresu, błędu ludzkiego lub nieprzewidzianych okoliczności. Te nieprzewidziane okoliczności to zwolnienia chorobowe, rezygnacje, awarie sprzętu lub, w skrajnych przypadkach, wybuchy wulkanów (kiedyś musieliśmy opóźnić projekt, ponieważ nie mogliśmy latać na miejscu z powodu erupcji wulkanu na Islandii).

Najważniejsze jest to, że o wiele łatwiej jest zbliżyć się do celu niż faktycznie go osiągnąć.

Uważam Wikipedia wyjaśnienie dość pouczające:

To sumuje się do 180%, co jest bardzo aluzją do rozgłosu projektów tworzenia oprogramowania, które znacznie przekraczają ich harmonogramy (patrz szacowanie nakładów na opracowanie oprogramowania). Wyraża zarówno przybliżony przydział czasu na łatwe i trudne części projektu programistycznego, jak i przyczynę spóźnienia wielu projektów jako brak przewidywania trudnych części. Innymi słowy, wykonanie projektu wymaga więcej czasu i więcej kodowania niż oczekiwano.

Co to dokładnie znaczy w praktyce? Że programiści wykonują zastępczą ilość pracy i że dają z siebie 180% lub?

Nie, programiści zawsze wykonują taką samą pracę na jednostkę czasu. Oferta dotyczy niedoszacowania kosztów i przekroczeń. 180% to czas i pieniądze, które projekt kosztuje.

Z grubsza oznacza to „Zajmie ci to dwa razy tyle, ile myślisz” i „Będziesz myślał, że dobrze sobie radzisz, dopóki nie będzie już za późno (termin jest bliski)”.

W praktyce oznacza to, że ludzie okłamują samych siebie.

Jeśli programista powie „skończyliśmy w 90%”, oznacza to, że 90% wysiłku na rzecz zbudowania funkcji zostało wydane.

Jeśli kierownik projektu powie „skończyliśmy w 90%, potrzebuję tylko kogoś, kto to dokończy”, oznacza to, że jest to 90% z budżetu (i prawdopodobnie 50% zrobione). To klient bez pieniędzy, wysokich oczekiwań i złego nastawienia.

Różnica polega na tym, że ukończenie projektu wymaga więcej wysiłku niż funkcji kodowania: qa, poprawki błędów, kopiowanie edycji, wdrożenie.

Tymi rzeczami należy zarządzać w projekcie, a odpowiedzialność za nie ponosi kierownik projektu. Często zaskakuje to nowych premierów, którzy wybierają „ukończenie 90% funkcji”, tylko po to, aby zdać sobie sprawę, że są w połowie drogi do „projektu zakończonego”.