On Dec 20, 12:16 pm, Maciej Sobczak <s...@g...com> wrote:
> On Dec 20, 2:51 am, Andrzej Jarzabek <a...@g...com>
> wrote:
>
> > 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.

Modulo to, że notatka, z której zaczynasz korzystać tego samego dnia,
a kończysz korzystać w tym samym tygodniu, może być znacznie krótsza
niż dokument, notatka czy cokolwiek, z czego zanczniesz korzystać za
miesiąc.

> 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.

Powód nazywa się natura ludzka. Jeśli nie ma aktywnej weryfikacji
aktualności wymagań w czasie, to fakt, że cośtam, co się zmieniło albo
okazało powoduje, że cośtam, co kilka miesięcy wcześniej zostało
zapisane w dokumencie jest nieaktualne i powinno zostać usunięte lub
zrewidowane, może łatwo umknąć uwadze.

> Uwaga: trwa to dokładnie tyle samo, ile pisanie notatki.

No więc niekoniecznie. Na przykład notatka, którą teraz mam przed
oczami brzmi tak: "załączniki!"
Wpisane do dokumentacji byłoby to bezużyteczne, ale dla mnie w
aktualnej sytuacji jest wystarczające.

> 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.

Po pierwsze poprawki mogą być faktycznie rozległe i skomplikowane:
jedna zmiana może się rozlewać na inne obszary, gdzie udokumentowana
funckjonalność staje się nieaktualna itd.

> 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.

...a po drugie jeśli od zapisania wymagania do realizacji mijają
miesiące, to ten kolor może być modyfikowany wielokrotnie.

> 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.

To idzie trochę dalej. Dokumentowane w klasycznym sensie są user
stories, ale one są znacznie bardziej ogólne i nie zawierają wielu
informacji, które trafiają do 'klasycznej' dokumentacji. W
szczególności user story z założenia może nie zawierać wszystkich
informacji, które są potrzebne programiście do zaimplementowania danej
funkcjonalności. Jak sama nazwa mówi, to jest typowo pisane z punktu
widzenia użytkownika, gdzie użytkownik mówi, co chciałby zrobić i po
co, z założeniem że nie musi tłumaczyć swojego problemu komuś, kto nie
zna dziedziny. Z kolei szczegóły są opisane w testach, które powinny
być napisane tak, żeby nir tylko się wykonywały, ale też były łatwe do
przeczytania i zrozumienia dla człowieka. Więc oczywiście też można je
nazwać "dokumentacją". W dodatku podobnej czytelności wymagasz od
samego kodu programu - nazwy zmiennych, funkcji typów powinny
informować w rozsądnym zakresie szczegółów, do czego służą, eliminując
część potrzeby utrzymywania dokumentacji kodu. Jeśli jakiejś istotnej
właściwości nie da się zapisć ani strukturą i nazwami w kodzie, ani
testem i nie jest odpowiednią informacją do user story, to można
udokumentować w bardziej klasyczny sposób - w dokumencie albo w
komentarzu w kodzie. Łącznie w tych formach powinno się znaleźć co
najmniej tyle informacji, ile byś miał w klasycznej dokumentacji, i
oczywiście stworzenie tego wszystkiego nie będzie trwało krócej niż
stworzenie klasycznej dokumentacji - nie po to się też to robi.

> > > [...] 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?

Zależy, ale dziedziny, w których jest inaczej są wyjątkami :)

Tzn. do tego jest taki argument, który możesz nazwać ideologicznym: że
jak masz proces, który źle reaguje na zmiany, to będzie tendencja do
nie doceniania tego, jak ta reakcja na zmiany jest potrzebna.
Powiedzmy, dostarczasz program w wersji 1.0 na czas, w którym jest
zrobione wszystko, co było w dokumentacji wymagań, dostajesz wymagania
do wersji 1.1. i się cieszysz, że ci proces działa dobrze. Tymczasem
być może wiele rzeczy, które byy w wymaganiach do wersji 1.0 ma niską
lub żadną wartość, i gdybyś co tydzień odbywał rozmowę "program robi
już to-i-to. Czy można go zrelease-ować, a jeśli nie, to jaka jest
najważniejsza rzecz, której jeszcze nie robi" - to być może wersja 1.0
wyszłaby wcześniej i/lub miała bardziej wartościową funkcjonalność.
Podobnie, jeśli klient podyktował do wymagań, a potem mówi, że ta
rzecz, która działa tak, jak sobie tego wcześniej zażyczył, nie działa
tak, jak tego rzeczywiście chce, to możesz powiedzieć "klient
kapryśny, nie wie czego chce, jego problem" - w rzeczywistości jest to
normalne. Jeśli wychodzisz z założenia, że klient powinien wiedzieć,
robisz dużą dokumentację z góry i zabezpieczasz się przez zmienianiem
wymagań ze strony klienta (np, każąc mu dodatkowo płacić i/lub
renegocjować umowę), to klient będzie może wolał przez pewien czas
pochodzić w trochę niewygodnych butach zamiast narzekać - a ponieważ
nie będzie narzekać, wywnioskujesz, że jest zadowolony. I tak dalej i
tak dalej - może być całem mnóstwo racjonalizacji, które można
zastosować do uzasadnienia, że wcale nie musisz być "agile" w
momencie, kiedy właśnie obrywasz po pupie z powodu, że nie jesteś -
"analityk zawinił", "niewystarczająco
rygorystycznie przestrzegamy procesów", "za mało czasu poświęciliśmy
na analizę wymagań" itd. Agile, jako podejście mówi, że w bardzo wielu
dziedzinach potrzeba reagowania na zmiany jest w rzeczywistości
większa, niż się początkowo wydaje przez optykę takich racjonalizacji.
Ocvzywiście, jak każde ideolo, trudno takie stwierdzenie obiektywnie
zweryfikować - albo się to kupuje, albo nie.

> > 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ć.

Tego nadal może być sporo. Ale jeśli podzieslisz problem na
odpowiednio małe kawałki, to uważaj, bo zaczynasz być agile :)

> > 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

Ale mają OSCR-a, na którym mogą się oprzeć.

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

Ktoś to musi robić. Po to masz właśnie role OSCR-a i product ownera.

> > 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?

Nie do końca. Po pierwsze jeden z istotnych prblemów, do których
odnosi się agile jest to, że powstawanie oprogramowania jest procesem
ciągłym. Trzeba się liczyć z tym, że jeśli program odniesie
jakikolwiek sukces, to będzie potrzeba robienia kolejnych wersji,
dodawania kolejnych ficzerów i tak dalej. Więc nawet jeśli wersja 1.0
powstanie trochę szybciej, to niekoniecznie równoważy problem taki, że
wersję 1.1. szybciej będzie napisać od nowa.

Po drugie jeśli program ma problemy z niezawodnością, czytaj bugi, to
prawdopodobie przynajmniej znaczną ich część trzeba będzie usunąć
przed wdrożeniem go do produkcji. Im więcej ma bugów, tym więcej
trzeba będzie ich usunąć, a im gorzej jest napisany, tym ma nie tylko
więcej bugów, ale też tym dłużej trwać będzie naprawienie każdego z
nich. I tym częściej naprawianie jednego buga spowoduje wprowadzenie
następnego albo i dwóch. Widzisz chyba problem?

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

Ano ano. Coś chyba za bardzo nam się świąteczny nastrój udziela i jadu
brakuje do podtrzymania flejma...