Planuje przedsięwzięcie programistyczne

Dlaczego tak

Cel SMART mówi, co dokładnie ma powstać, po czym poznać sukces i do kiedy: tu jest konkretny produkt, mierzalny wskaźnik 500 klientów i termin 30 czerwca. Sformułowanie „nowoczesna aplikacja poprawiająca wizerunek” nie daje się zmierzyć ani rozliczyć. „Najlepsza na rynku” jest nieosiągalna i niemierzalna, a cel bez terminu — określony „gdy zespół znajdzie czas” — nie pozwala zaplanować harmonogramu.

Dlaczego tak

Najpierw trzeba ustalić, czego potrzebuje klient (analiza wymagań), następnie zaplanować, jak to zbudować (projekt architektury, danych i interfejsu), potem napisać kod, sprawdzić go testami i dopiero przetestowany system wdrożyć u klienta, po czym następuje utrzymanie. Projektowanie przed analizą wymagań oznacza projektowanie czegoś, czego zakresu jeszcze nie znamy. Wdrożenie przed testowaniem przenosi wykrywanie błędów na użytkowników.

Dlaczego tak

Etap utrzymania zaczyna się po przekazaniu systemu do użytku i obejmuje usuwanie błędów wykrytych w eksploatacji, dostosowywanie do zmian środowiska i drobne usprawnienia; często jest najdłuższym i najdroższym etapem cyklu życia. Testowanie odbywa się przed wydaniem, więc nie dotyczy programu używanego od pół roku. Wdrożenie to jednorazowa instalacja i uruchomienie systemu u klienta wraz ze szkoleniem użytkowników.

Dlaczego tak

Zespół trzech osób pracujących po 8 godzin daje 3 · 8 = 24 osobogodziny dziennie, więc 120 / 24 = 5 dni roboczych. Wynik 15 otrzymuje się, dzieląc 120 tylko przez 8, czyli zakładając, że pracuje jeden programista, a 40 — dzieląc 120 tylko przez 3, jakby każdy pracował jedną godzinę dziennie. W praktyce do takiego wyniku dolicza się zapas na komunikację w zespole i nieprzewidziane problemy.

Dlaczego tak

Priorytetyzacja, np. metodą MoSCoW, wyznacza funkcje niezbędne do działania produktu; z nich buduje się minimalną wersję (MVP), którą klient może wcześnie używać i ocenić, a kolejne wydania dodają resztę. Jedno wydanie po trzech miesiącach daje klientowi wartość dopiero na końcu i odkłada wykrycie nieporozumień. Kolejność według łatwości technicznej może zostawić na koniec funkcje, bez których aplikacja jest bezużyteczna.

Dlaczego tak

Limit WIP (work in progress) ogranicza liczbę zadań wykonywanych równocześnie, aby praca płynęła do końca, a nie gromadziła się w połowie. Gdy limit jest osiągnięty, Kanban zaleca „kończyć, zanim się zacznie”: pomóc przy zadaniach w toku, np. w przeglądzie kodu lub testach, albo usunąć blokadę. Doraźne podnoszenie limitu lub praca poza tablicą zespołu ukrywa wąskie gardło, które limit miał właśnie ujawnić.