On Dec 20, 2:51 am, Andrzej Jarzabek <a...@g...com>
wrote:

> > No przecież ja nie oczekuję, że cały system, który normalnie ma
> > kilkaset stron opisu, znajdzie się w jednym user story. Oczekuję, że
> > tych stories będzie np. kilkaset.
>
> Ale clou jest takie, że nie robisz notatek na setki user stories do
> przodu, tylko do tej jednej, nad którą akurat pracujesz.

Jasne. Ale tydzień później będę robił drugą notatkę. Potem trzecią i N-
tą. W sumie napiszę tyle samo. Zdaje się, że to uzgodniliśmy, bo.

> Zgadza się, to nie na tym się oszczędza.

No i bingo, przyklejamy to na ścianę, żeby się nam w przyszłości nie
pomyliło.
Ale:

> Problem polega na tym, że
> prawdopodobnie po spędzeniu np. 1 miesiąca na pisaniu dokumentacji nie
> skończy się na tym, że ktoś tę dokumentację zaimplementuje i będzie
> super, tylko że w trakcie implementacji okażą się różne rzeczy, które
> spowodują że spędzisz kolejne dwa miesiące na zmienianie dokumentacji, a
> developerzy spędzą ileś czasu na implementowanie dokumentacji, która już
> w tym momencie będzie nieaktualna.

Ależ nie ma najmniejszego powodu, żeby ona była niekatualna.
Przecież jeśli klient sobie coś nowego przypomni, to się poprawia
dokumentację i robi się z tej poprawionej.

Uwaga: trwa to dokładnie tyle samo, ile pisanie notatki.
Można jeszcze rozważać, czy jest sens coś pisać wcześniej tylko po to,
żeby to poprawić, ale spodziewam się, że poprawka (jeśli w ogóle jakaś
jest) będzie inkrementalna a nie całościowa. Uwaga: inkrementalność
jest dzięki temu, że niczego nie wyrzuciliśmy do kosza.
Np. na początku klient chciał czerwony odkurzacz a w połowie projektu
jednak stwierdził, że ma być zielony. Zmienia się jedno słowo w
istniejącym dokumencie a nie pisze całe story od nowa.

I znowu - nie ma powodów sądzić, że ten sposób pracy jest wolniejszy,
niż pisanie notatek na bieżąco.

Natomiast jeśli dziedzina jest eksploracyjna i w ogóle na początku nie
wiadomo, jaki ma być odkurzacz, to się tego nie pisze w dokumentacji,
bo nie ma po co. I w ten sposób dochodzimy do sytuacji, że *nie trzeba
całej dokumentacji pisać na początku*, bo system może powstawać po
kawałku a nie big-bangiem.
Tak czy siak dokumentacja powstaje.

Możesz to sobie nazwać DDD - Documentation Driven Development. Nie
jest to w żaden sposób sprzeczne z agile.

Ciekawa uwaga: Ty przyznałeś, że nie oszczędza się na pisaniu
dokumentacji a ja przyznaję, że nie trzeba jej pisać w całości na
początku.
I zaraz wyjdzie, że w ogóle nie ma sprzeczności między tym, co
opisujemy.

> > [...] gdy mamy podejrzenia, że wymagania będą się zmieniać w
> > czasie jazdy

> Tak, przy czym dochodzi jeszcze jedna rzecz: w rzeczywistości takie
> sytuacje są normą, a nie wyjątkiem.

Zależy od dziedziny?

> > W przypadku skrajnym
> > najlepszym rozwiązaniem jest w ogóle rezygnacja z outsource'owania
> > projektu i stworzenie lokalnego zespołu programistów,

> Być może tak bywa, ale jest też z takim podejściem kilka poważnych
> problemów:
> 1. Przekazywanie wiedzy w ten sposób, że ktoś najpierw kilka miesięcy
> słucha wykładów,

Ale przecież nikt nie twierdzi, że to ma być kilka miesięcy - bo jak
już napisałem, nie trzeba całości opisywać z góry. Opisuje się to, co
jest w danym momencie znane i co można zrealizować. Projekt może mieć
tyle etapów, ile trzeba - co nawet ułatwia sferę rozliczeniowo/
kontraktową.

> 2. I tak musisz mieć kogoś, kto będzie prowadził te szkolenia,

Tak.

> 3. Opóźniasz rozpoczęcie projektu,

Nie. Projekt rozpoczyna się od porozumienia się stron co do faktu, że
projekt w ogóle ma być. Nic tu się nie opóźnia.

> 4. Przeszkoleni na szybko programiści równie szybko dotrą do granic
> swojego zrozumienia i utkną,

Nieprzeszkoleni są poza tymi granicami przez cały czas. :-D

> 5. Zrzucenie na programistów śledzenia zmieniających się wymagań
> biznesowych może przynieść nienajlepsze skutki.

Nikt im tego nie każe robić.

> > (dodatkowo można to zrobić też
> > w drugą stronę - pozwolić "domenowcom" pisać kod, który się potem
> > integruje w całość).
>
> Znowu - może są dziedziny i projekty, w których się to sprawdza dobrze,
> ale w ogólności masz spore ryzyko, że kod stworzony przez "domenowców"
> będzie miał duże problemy z niezawodnością i będzie trudny w utrzymaniu.

Ale powstanie szybciej i szybciej można go zwalidować - czy nie o to
chodzi w agile?

> > Ale żadna metoda prowadzenia projektów nie może opierać się na
> > "nierobieniu" czegoś.
>
> Pełna zgoda!

No to o co chodzi...

> > Dlatego naprawdę bez sensu jest twierdzić, że w agile chodzi o to,
> > żeby nie robić dokumentacji.
>
> Znowu zgoda! Ale chwileczkę - czy ktoś tak twierdził?

I tym akcentem powoli należy zwijać wątek, bo idą święta i trzeba się
zabrać za bigos.

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com