On May 17, 3:35 pm, "Przemek O." <p...@o...eu> wrote:
> W dniu 2011-05-17 15:05, Andrzej Jarzabek pisze:
>
> >>> Ile projektów prowadziłeś stosując Agile, że się z tym zgadzasz?
>
> >> Nie prowadziłem żadnego, ale robiłem w takich, w których robiono
> >> design up front,
> > [...]
>
> > Aha, jeszcze, jeśli chodzi o samo pisanie programów bez robienia
> > najpierw projektu, to jak najbardziej sporo takich napisałem.
>
> To były raczej notatniki niż ERP? Co?

Powiedzmy że gdzieś pomiędzy.

> Ale na poważnie, jak już ktoś napisał, Agile wcale nie zakłada braku
> projektu.

Żeby rozwiać niejednoznaczności, uściślijmy może, że chodzi o
tworzenie dokumentu projektowego, na podstawie którego tworzony jest
kod. Oczywiście kod, który piszę, posiada ostatecznie i na każdym
etapie "projekt" w sensie jakiejś struktury konceptualnej. Również,
jeśli jest takie wymaganie, mogę ten projekt udokumentować ex post, co
się dzieje np. po release albo przed hand-offem.

Natomiast twierdzę, i Agile tak twierdzi, że można (a niekiedy nawet
należy) pisać program bez dokumentu projektowego up front, czyli
takiego, który dokumentuje nieistniejący jeszcze kod, który będzie w
dalszej kolejności pisany według tego projektu.

Oczywiście jedna z rzeczy, do której projekt jest potrzebny, to
koordynacja równoległej pracy wielu programistów nad tym samym
projektem. Jak rozumiem Agile (powiedzmy konkretnie XP) zakłada tu
dwie możliwości: albo zaczyna się od tego, że w pierwszym dniu/
tygodniu kod produkcyjny tworzy jedna para programistów, podczas gdy
reszta konfiguruje source control i build machine, robi research,
rozmawia z customerami albo przestawia biurka. Druga możliwość jest
taka, że zespół robi zebranie i ustala nieformalny bardzo ogólny
projekt up front, który pozwoli im na dalszy podział pracy. W każdym
przypadku projekt jest formalizowany nie do dokumentu projektowego,
tylko do zestawu unit testów, które w sposób jednoznaczny określają
jakie komponenty mają istnieć, jakie interfejsy udostępniac i jaką te
interfejsy mają mieć funkcjonalność.

> Poza tym, jest pewien poziom skomplikowania, od którego
> dokumentacja projektowa jest niezbędna do powstania produktu końcowego.

Nie zgodzę się. Dokumentacja projektowa może być potrzebna jeśli np.
zespół po zakończeniu projektu ma być rozwiązany lub przeniesiony do
innego projektu, a maintenance ma robić ktoś inny (co jest sensownym
scenariuszem, bo zespół agile powołany do tworzenia projektu ab initio
nie będzie najlepszym zespołem do jego maintainowania po zredukowaniu
ilości bieżącej pracy.

W drugiej kolejności dokumentacja może być potrzebna firmie jako
dupochron na wypadek, gdyby jakaś większa liczba członków zespołu
zechciała sobie pójśc gdzie indziej.

I w końcu jeśli zakładasz, że będzie duża rotacja pracowników w czasie
trwania projektu, dokumentacja projektowa jest potrzebna, ale jeśli
będzie duża rotacja, to prawdopodobie nie powinieneś stosować Agile.

> Dodatkowo jest jednak delikatna różnica pomiędzy pisanie programu który
> się samemu wymyśliło dla siebie (lub wyimaginowanego klienta) niż dla
> realnego zleceniodawcy. W pierwszym przypadku można improwizować,
> najwyżej się zmieni, w drugim nie ma miejsca na improwizację, bo produkt
> końcowy jest określony poprzez wymagania zleceniodawcy a nie własne
> widzimisie.

Projekt to projekt, a wymagania to wymagania. Nawet jeśli dostraczenie
dokumentu projektowego jest w wymaganiach, to raczej się nie wymaga,
żeby dostarczyć go up front - przed napisaniem programu. No chyba że
pracodawca/zleceniodawca ma też takie wymaganie, ale wtedy nie
praktykujesz agile, tylko narzucony z góry proces waterfall lub
iterative.

Jeśli chodzi o same wymagania, to XP ma takie podejście, że od
udokumentowanych wymagań lepszy jest customer w zespole. Oczywiście
musisz tego customera mieć, w dodatku musi być kompetentny i mieć
realną możliwość podejmowania decyzji i brak tego jest poważną
obiektywną przeszkodą w stosowaniu XP. Z drugiej strony oczywiście
należy do tego przyłożyć zdrowy rozsądek - podejście to nie oznacza
zakazu istnienia dokumentów z wymaganiami, istotne są natomiast dwie
rzeczy: po pierwsze, że realne wymagania będą się zmieniać w miarę
pracy z customerem i w związku z tym dokument z wymaganiami nie może
być wiążącą umową, a po drugie że jak programista będzie miał
jakiekolwiek problemy, uwagi czy propozycje co do tego, co wyczytał w
dokumentacji wymagań, to będzie mógł usiąść z customerem i wypytać się
go, czego on naprawdę chce. Jeśli te warunki nie moga być spełnione,
to jest to kolejna obiektywna przeszkoda w stosowaniu XP.

Jeśli chodzi o moje osobiste doświadczenie, to mam właśnie takie:
dokument z wymaganiami się szybko dezaktualizuje, możliwość szybkiego,
częstego i osobistego kontaktu z człowiekem, który rozumie wymagania i
będzie je mógł wyjaśnić - jest niezastąpiona. Sytuacja, w której
wymagania są kontraktem, w którym każdą zmianę trzeba negocjować jest
szkodliwa dla jakości tworzonego oprogramowania - prędzej czy później
nastąpi któraś z poniższych sytuacji:
- nagle się okaże, że jakiś feature opisany w wymaganiach jest Bardzo
Trudny do zaimplementowania i trzeba renegocjować kontrakt albo
ponosić ryzyko (np. opóźnień). Z drugiej strony ten sam feature może
wcale nie być tak istotny dla klienta, lub być łatwy do zastąpienia
czymś, co dla klienta ma prawie taką samą wartość, a jest trywialne do
zrobienia. Sam overhead renegocjonowania umowy może być w tym
przypadku gigantyczny w porównaniu do wysiłku podjęcia decyzji co do
wartości tego feature'a i zamiplementowania go w tej czy innej
postaci.
- okaże się, że wymaganie interpretowane w pewien sposób (powiedzmy -
rozumiane dosłownie, np. tak, jak by zrozumiał je pedantyczny
programista o matematycznym umyśle, nie mający szczególnie dużej
wiedzy o zastosowaniach wymaganego feature'a) jest jednocześnie
kosztowne w realizacji i kompletnie niepotrzebny, a nawet absurdalny.
To doprowadza do jescze gorszej sytuacji, gdzie programista pokaże
paluchem że jest napisane, że działać ma właśnie tak i tak właśnie
działa, zleceniodawca powie, że nie tego chciał i nie o to chodziło w
tym punkcie umowy i powstaje kwas na zasadzie czy to zleceniodawca źle
wyspecyfikował i powinien podpisać odbiór, a jak chce, żeby inaczej
działało, to niech negocjuje umowę na enchancement i przygotuje się,
żeby słono zapłacić, czy jednak jest to bug, który wykonawca musi
naprawić na własny koszt i ewentualnie nawet ponieść konsekwencje
(dodatkowego) opóźnienia. Zauważ, że w tym przypadku może chodzić o
kluczowy element programu, od którego masa innych rzeczy jest zależna
i którego przerobienie, żeby było tak, jak ma być, to poważny effort,
np. przepisanie na nowo 1/3 kodu.