W moim przedostatnim wpisie o tym dlaczego projekty się opóźniają nie powiedziałem o jednym! Projekty opóźniają się też dlatego, że nie można odpowiednio szybko zobaczyć konkretnych efektów.

To jest siła Agile. Za każdym sprintem/iteracją mamy otrzymywać gotowy do uruchomienia produkt. Czyli zadania powinny być zakończone i gotowe do wdrożenia.

Najczęstszy przypadek jaki znam jest taki, że zadania są zakończone, ale nie do końca. Działają, ale nie są przetestowane, albo nie można ich przetestować bo … nie ma na czym ich przetestować.

Duże projekty mają to do siebie, że opierają się na wielu warstwach abstrakcji. Za często na zbyt wielu. Programista pisze funkcje, których działania nie jest nawet w stanie sobie wyobrazić.

Fajny przykład to wszelkiego rodzaju integracje. Napisanie kodu wg. specyfikacji to z moich obserwacji 20% czasu. Pozostałe 80% czasu to … testy, poprawki, dopasowywania, hacki i czekanie na dane testowe.

Dane testowe, rzetelne, odpowiadające produkcyjnym są potrzebne wszędzie:

  • ucinane przez błędne style napisy –  bo nikt nie przewidział, że nazwy produktów będą takie dłluuuuuugie,
  • źle zaprojektowana nawigacja bo nie było wiadomo jaka głęboka będzie prawdziwa struktura kategorii,
  • źle walidowane numery zamówień – bo nie było wiadomo jaki format numeracji będzie finalnie zastosowany

Te i wiele innych przykładów programiści znają z codziennej pracy. Często w ogóle nie można pracować bez przykładowych danych i wyników jakie mamy uzyskać.

Często dane testowe przygotować jest bardzo trudno. Trzeba zdobyć testowe dostępy do usług sieciowych, stworzyć przykładowe pliki XML, wygenerować testowe dane w bazie danych. To się jednak za każdym razem opłaca, mimo, że w pierwszej chwili wydaje się krokim w bok a nie do przodu.

Prawda jest taka, że ludzie potrafią myśleć abstrakcyjnie ale bardzo często abstrakcje różnych osób nie są ze sobą zgodne.

Dlatego potrzebne są konkretne przykłady, konkretne dane które szybko będzie można zweryfikować. Za mało czasu jest poświęcane na taką konkretyzację przed rozpoczęciem prac, a moim zdaniem oszczędzałoby to w niektórych przypadkach setek godzin programowania.

Przechodźmy do konkretu jak najprędzej. To co robimy to nie poezja, tylko oprogramowanie :-)