Masz 100% rację, że czasem takich elementów wymaga sam klient, ale wtedy przecież wszystko jest dużo łatwiejsze, bo skoro klient żąda biblioteki, to prosto jest stworzyć user stories opisujące elementy takiej biblioteki (choćby metody odpowiednich klas odpowiadające poszczególnym usługom tej biblioteki). Prezentacja takich user stories mogłaby polegać nawet na pokazaniu kodu testów jednostkowych - tam widać zarówno sposób użycia jak i poprawność działania.

A wracając do iteracji zerowej i silników, czyli w moim rozumieniu pewnych podstawowych/kluczowych elementów systemu wynikających z jego architektury, to chodzi o to, że skoro czujemy konieczność zbudowania ich na początku, to niech się to stanie w iteracji zerowej. Zaznaczam, że mam tu na myśli implementację absolutnie najpotrzebniejszych elementów, bez których nie da się iść dalej. Nie należy starać się zaimplementować od razu pełnego rozwiązania, bo nie ma to sensu. Już kolejna iteracja dowiedzie, że jednak warto coś zmienić. Osobiście nie udało mi się jeszcze w iteracji zerowej napisać czegoś co można by nazwać czymś więcej niż tylko prototypem/eksperymentem, a co podlegałoby ciągłym zmianom w kolejnych iteracjach i w momentach kiedy tylko było to potrzebne. Jednak wielokrotnie co do idei i podstawowego szkieletu, taki silnik z iteracji zerowej nie podlegał już znacznym przebudowom, bo jego wysokopoziomowa budowa wynikała z przyjętej architektury (też na ogólnym ideowym poziomie).

Także jestem tego samego zdania - iteracja zerowa, to przede wszystkim miejsce na eksperymenty i weryfikację pewnych podstawowych pomysłów. Chodzi tylko o to, żeby postarać się mimo wszystko dać na końcu także coś klientowi.

Jeżeli klient silnika nie zamówił to nie będzie go weryfikował oddzielnie i co chwilę trzeba sobie zadawać pytanie jak duży i elastyczny “silnik” jest potrzebny. Jeżeli jednak zamówił, to jest w stanie określić coś w rodzaju user stories (use-cases) z których można wyprodukować testy akceptacyjne.

Produkcja wewnętrznych bibliotek w iteracji zerowej? Naprawdę tak wcześnie jesteście w stanie coś sensownego urodzić? Ja bym się skłaniał do nazywania tego zarysami bibliotek, wstępnym grupowaniem podobnych elementów, które potem można organizować w coś reużytkowalnego.

Iterację zerową i ogólnie początek projektu lepiej wykorzystać na robienie prowizorki - prototypów, zaślepek na interfejsy, rysunków, szukanie problemów i ogónie badanie tematu.

Oczywiście wszystko zależy od sytuacji :)

Jeśli chodzi o iterację zerową, to mam jeszcze następujące spostrzeżenia:

1. Warto w iteracji zerowej umieści chociaż jedno czy dwa user stories tak, żeby był mimo wszystko jakiś namacalny dla użytkownika efekt na koniec.

2. Nawet przy okazji implementacji silnika niekoniecznie trzeba go zbudować z najdrobniejszymi szczegółami. Aktualnie też mam taki projekt, który skoncentrowany jest wokół takiego silnika. Na iterację zerową przyjmuję kilka najistotniejszych elementów jego architektury i jak najwcześniej staram się przypuścić na niego “atak” przy pomocy funkcjonalności z user stories. Każda implementacja user story potwierdza słuszność przyjętych w silniku rozwiązań lub też szybko wskazuje na jego niedociągnięcia i braki.

3. Przy implementacji takiego silnika zakładamy, że powinien się on sprawdzić we wszystkich user stories. Tylko problem polega na tym, że wiele z user stories nie jest do końca jasnych na początku projektu. I tak jeszcze wielokrotnie taki silnik będziemy podrasowywać i refaktoryzować. Więc to też jest dla mnie powód do skracania tej wstępnej iteracji.

W przytoczonej przeze mnie książce Cohn twierdzi, że na pierwszą iterację (jeśli “zgadujemy” velocity) powinno się przyjąć wartość pomiędzy jedną trzecią a połową faktycznego czasu. Czyli dla dwóch osób w dwutygodniowej iteracji (20 dni roboczych) przyjmujemy wartość 7-10 dni idealnych. Potem można to zwiększyć.

W małych projektach (3-4 miesięcznych) dla 1-2 osób wychodziła mi wydajność na poziomie ok. 3/4, ale to dopiero pierwsze eksperymenty z mierzeniem tego współczynnika. Generalnie równie ważne jak samo uchwycenie velocity wydaje mi się wspólne szacowanie w zespole. W każdym z tych elementów gdzieś te szacunki się uśredniają i zbliżają do rzeczywistości. Samo velocity raczej traktuje jako pewien współczynnik kontrolny dla stanu “środowiska” projektu, tzn. ważniejszą informacją dla mnie są jego zaburzenia niż wartość średnia.

Wykonanie testów funkcjonalnych dla aplikacji trzeba szacować osobno boi możliwe że magiczny współczynnik będzie inny.

Jeżeli mamy tylko oszacowany koszt wykonania funkcjonalności (obejmującej również dokumentację), w godzinach idealnych, to można zacząć od pomnożenia tego przez dwa - koszt testu (inspekcji). Dopiero potem można zaaplikować współczynnik wydajności zespołu.

pozdrawiam,
Jacek

Pracowałem kiedyś przy implementacji systemu backoffice do zarządzania fragmentem działalności firmy. Wizję i wymagania przedstawiał w głównej mierze sam prezes i ew. jego bezpośredni podwładni (czyli kierownicy działów). Jak łatwo się domyśleć kiedy doszło do wdrożenia, w ciągu pierwszego tygodnia okazało się, że szeregowi pracownicy narzekają, bo ich praca wygląda zupełnie inaczej niż to, w jaki sposób wyobrażał to sobie prezes. Efekt był taki, że system zamiast ułatwiać początkowo utrudniał im wykonanie codziennych czynności.

Dlatego tak ważne jest dotarcie do faktycznych użytkowników systemu. Wydaje mi się też, że prezentacje produktu po iteracjach bardzo pomagają w uniknięciu takich nieporozumień. Kiedy pokażemy takiemu prezesowi jakiś element systemu do akceptacji (bo to przecież ma na celu taka prezentacja - test akceptacyjny), to zwykle żeby zabezpieczyć się przed pomyłką poprosi on o wryfikację faktycznego użytkownika. Dużo łatwiej klientowi, który nie jest użytkownikiem opowiadać o wymaganiach, niż je później zweryfikować i się pod tym podpisać. Więc po iteracjach zyskujemy naturalne punkty kontrolne, w których jest duża szansa dopadnięcia użytkowników :-)

Pozdrawiam,
Marcin