On 19/12/2011 23:21, Maciej Sobczak wrote:
> On Dec 19, 5:48 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>
>>>> Nie, nie ma żadnych N miesięcy na pisanie notetek
>>> A jak nie zdążą?
>> Jak nie zdążą w jeden dzień, to ewentualnie mają następny dzień, ale
>> to już jest sygnał, że trzeba naprawić proces. Jeśli coś, co miało być
>> zrobione w jeden dzień okazuje się robotą na wiele miesięcy, to się to
>> wycofuje z bieżącej iteracji i robi się repriorytetyzację na kolejnym
>> iteration planning. Jeśli coś jest robotą na wiele miesięcy, to nie
>> powinno być opisane jako jedna user story.
>
> 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. Jak ta stoy
będzie odhaczona (zgodnie z "definition of done") to notatki do niej nie
są już potrzebne, a wtedy dopiero zaczniesz prosić OSCR-a o
wytłumaczenie następnej i robić następne notatki.

> I wtedy się okaże, że ich przekazanie (oraz napisanie odpowiednich
> notatek) zajmie *w sumie* tyle, ile napisanie całości. Bo chyba
> wszędzie jest tak, że całość jest sumą swoich składników, i nic tu się
> nie da zaoszczędzić.
> Czyli jeśli zamiast spędzenia np. 1 miesiąca na pisaniu dokumentacji
> mam to zrobić w czasie 160 1-godzinnych spotkań, to żadna różnica - to
> nadal jest *w sumie* 160 godzin.

Zgadza się, to nie na tym się oszczędza. 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.

> Jeszcze raz: nie podałeś jeszcze żadnego powodu, dla którego
> *sumaryczny* czas spędzony na przekazywaniu wiedzy ma być w agile
> mniejszy. Różnica jest taka, że ten czas jest wpleciony w czas trwania
> całego projektu, ale nie ma powodu, żeby był *w sumie* krótszy.

Zgadza się, ale też nigdy nie twierdziłem, że sumaryczny czas będzie
krótszy.

> Widziałem kiedyś prezentację nt. agile i facet na samym początku
> powiedział coś takiego:
>
> ***
> Wielu ludzi błędnie sądzi, że agile jest po to, żeby projekt
> powstał szybciej. Jest to bzdura i bywa nawet, że trwa to dłużej.
> Agile powstało po to, żeby lepiej reagować na zmieniające się
> wymagania projektowe - i *to* jest właśnie powód, żeby go stosować.

Mądrze mówi (dać mu wódki)

> Myślę, że to jest sedno naszego nieporozumienia. Nie mam najmniejszej
> wątpliwości, że jako sposób prowadzenia projektów agile jest bardziej
> odpowiedni, gdy mamy podejrzenia, że wymagania będą się zmieniać w
> czasie jazdy - czy to z powodu uwarunkowań dziedzinowych, czy też z
> powodu niezrównoważenia klienta, czy nawet z takiego, że cała
> dziedzina ma eksploracyjny charakter i nie jest do końca poznana i
> można się spodziewać, że wiele rzeczy wyjdzie dopiero w praniu.
> Naprawdę - w pełni się zgadzam, że w takiej sytuacji istotna jest
> ciągła współpraca między klientem a wykonawcą.

Tak, przy czym dochodzi jeszcze jedna rzecz: w rzeczywistości takie
sytuacje są normą, a nie wyjątkiem. Wyjątkiem jest raczej dekoder MP3,
gdzie masz specyfikację, wiesz, że jest ona poprawna i wiesz, że format
się nie zmieni.

> W przypadku skrajnym
> najlepszym rozwiązaniem jest w ogóle rezygnacja z outsource'owania
> projektu i stworzenie lokalnego zespołu programistów, który będzie
> temat rozwijał in-house - wtedy w ogóle nia ma sensu wyodrębniać
> takiej roli jak OSCR, tylko się szkoli programistów tak, żeby sami
> stali się specjalistami danej dziedziny

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, a potem dopiero próbuje zastosować to, czego się
nauczył jest mocno suboptymalne. Wręcz bym powiedział, że masz spore
ryzyko, że owym programistom po kilku miesiącach będzie się wydawać, że
rozumieją problem, a jak zaczną próbować przekładać go na kod, to się
jednak okaże, że nie rozumieją go wystarczająco dobrze (i tak, nawet
jeśli to nie jest kilka miesięcy tylko jeden, to problem nadal występuje),
2. I tak musisz mieć kogoś, kto będzie prowadził te szkolenia,
3. Opóźniasz rozpoczęcie projektu, przez co na dzień dobry programiści
zaczynają już z nieaktualną wiedzą. Z kolei jednoczesne szkolenie kogoś
w danej problematyce i wprowadzanie na bieżąco zmian w wymaganiach do
programu szkolenia wprowadza zamęt,
4. Przeszkoleni na szybko programiści równie szybko dotrą do granic
swojego zrozumienia i utkną,
5. Zrzucenie na programistów śledzenia zmieniających się wymagań
biznesowych może przynieść nienajlepsze skutki.

Nie mówię, że te problemy wystąpią zawsze i wszędzie, ale w wielu
przypadkach trzeba się z nimi liczyć.

> (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 żadna metoda prowadzenia projektów nie może opierać się na
> "nierobieniu" czegoś.

Pełna zgoda!

> Dlatego naprawdę bez sensu jest twierdzić, że w agile chodzi o to,
> żeby nie robić dokumentacji.

Znowu zgoda! Ale chwileczkę - czy ktoś tak twierdził?

> Nierobienie dokumentacji jest bez sensu, podobnie jak wyrzucanie do

Jeszcze raz, bo chyba się nie rozumiemy: "nierobienie" w sensie że masz
metodę polegającą na nierobieniu jest bez sensu. Natomiast możesz mieć
sensowną metodą, w której robisz inne rzeczy, i w związku z tym możesz
nie robić (części) dokumentacji, którą byś musiał robić w innej
metodzie. Jeśli używasz takiej metody, to nierobienie jest sensowne, bo
skoro już i tak tyle samo (albo więcej) czasu poświęcasz na zapisywaniu
tej wiedzy w innej postaci, to zapisywanie tego samego w dokumentacji
jest redundantne.

> kosza jakichkolwiek artefaktów projektowych - również notatek.

Notatki to nie są artefakty projektowe, to narzędzie mnemotechniczne
służace do tego, żeby nie zapomnieć istotnych szczegółów między rozmową
z OSCR-em (or compatible) a przepisaniem uzyskanej wiedzy "na czysto".
Wyrzucasz je, żeby nie zginąć w nawałnicy śmieci.

> Z biznesowego punktu widzenia nierobienie dokumentacji jest bez sensu
> z kilku powodów. Raz, że wszystko może się przydać przy rozstrzyganiu
> konfliktów. Dwa, że wszystko może się przydać, gdy... sprzedaje się
> technologię lub całą firmę.
> Wtedy lepiej jest mieć równo poukładane segregatory, bo OSCR już
> poszedł do domu.

Chyba jeszcze lepiej mieć działający (najlepiej u klientów) produkt?