On 2011-12-19, Roman W <b...@g...pl> wrote:
> On Dec 19, 11:55 am, Wojciech Jaczewski <w...@o...pl> wrote:
>> Roman W wrote:
>> > On Dec 18, 11:31 pm, Maciej Sobczak <s...@g...com> wrote:
>> >> Tak to można okienka dialogowe w programie księgowym robić. Systemów
>> >> przemysłowych ani nawet rozrywkowych w ten sposób nie widzę.
>>
>> > Mnie w ogole zastanawia, czemu w "starszych" dziedzinach przemyslu
>> > (np. budownictwo czy petrochemia) koniecznosc stworzenia spojnego
>> > calosciowego projektu jest *oczywista*, natomiast w IT ludziom sie
>> > wydaje, ze mozna tworzyc duze systemy z klockow Lego.
>>
>> Jeśli w budownictwie wyprodukuje się jakiś klocek, to zwykle nie da się go
>> przerobić w klocek nieco inny (bo podczas przymierzania okazało się, że coś
>> jest nie tak).
>
> No popatrz, a jak zmienialem drzwi/okna/pokrycie dachu to poszlo bez
> problemu.

Czekaj, wróć. Okno zmieniłeś w pokrycie dachu, a drzwi w wannę? O_o

> Bo sa rozne standardy, ktore sie egzekwuje na etapie
> projektowania, ktore ludziom niesamowicie ulatwiaja potem prace, jak
> chca cos w konstrukcji zmienic.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Dec 19, 12:43 pm, Roman W <b...@g...pl> wrote:
> On Dec 19, 11:02 am, Andrzej Jarzabek <a...@g...com>
> wrote:
>
> > * Modele funkcjonują jako user stories
>
> To nie sa user stories.

Dlaczego? Pytam poważnie i jak pisałem, nie znam się na tym, więc moje
dalsze dywagacje będą typu "jak mały Jasio sobie wyobraża", więc nie
śmiej się za bardzo, tylko naprostuj mnie błądzącego.

Otóż mały Jasio sobie wyobraża, że masz zasadniczo dwa podejścia do
architektury takiego programu. Pierwsze jest takie, że modele są
bezpośredio wbudowane w program i stanowią jego ficzery. Jeśli program
ma modele A, B i C, a chce się mieć model D, to zespół tworzący
program musi zmienić ten program. W takim przypadku modele funkcjonują
jako user stories - to, że nie mają takiego formatu jak typowe user
stories, że nie są napisane z punktu widzenia "użytkownika" nie ma
większego znaczenia - po prostu taka specyfika branży. Istotne jest
to, że na początku każdego tygodnia możemy wyłożyć na stół listę
modeli, które można zaimplementować (co również oznacza, że mają
odpowiednie stempelki) i zadać pytania "które z nich chcemy
zaimplementować w pierwszej kolejności?" i "ile z nich zdążymy
zaimplementować w tym tygodniu?"

Druga możliwość, którą mały Jasio sobie wyobraża, jest taka, że
program do algo przyjmuje modele zadane przez użytkownika, które mogą
być podane jako jakieś pliki konfiguracyjne, programy napisane w DSL-u
albo jakieś dll-ki pisane przez quantów czy kogo tam w C++ czy w czym
tam. W takiej sytuacji ludzie tworzący modele są użytkownikami
programu, raczej niż jego twórcami. Problem akceptacji konkretnych
modeli przez odpowiednie działy jest problemem owych użytkowników, a
user stories są "chciałbym użyć w modelu danej xyz, ale w tej chwili
nie ma takiego parametru, proszę mi go dodać", "proszę o dodanie do
DSL-a wsparcia dla funkcji eliptycznych", "chciałbym pisać modele w
Javie" itd.

> > * Po stworzeniu modelu koleś od wymyślania zanosi go do product ownera
> > * Product owner zajmuje się tym, żeby złożone u niego modele zostały
> > zatwierdzone gdzie trzeba
>
> Nope. Product owner na ogol jest traderem, ktory nie chce miec nic
> wspolnego z zatwierdzaniem modelu. Co najwyzej moze naciskac
> politycznie, zeby dany model zostal zatwierdzony, z roznym skutkiem.

Nie mam pojęcia, jakie są zadania tradera w takim zespole, ale w
agile'owym żargonie product owner jest osobą, która decyduje o
funkcjonalności programu. Jeśli tą funkcjonalnością są konkretne
modele, to product owner musi decydować, które ze wszystkich modeli
zaproponowanych przez quantów czy kogo tam, zostaną zaimplementowane,
a które nie, i w jakiej kolejności. W związku z tym małemu Jasiowi
wydawałoby się, że taka osoba byłaby w naturalny sposób zainteresowana
tym, które modele będą zatwierdzone a zatem chciałaby decydować, które
i w jakiej kolejności będą zatwierdzane przez dział zatwierdzania.

Jeśli mały Jasio się myli, i to z reguły zadaniem quantów (czy kogo
tam) wymyślających owe modele jest zatwierdzenie ich w odpowiednich
działach, to niewiele zmienia: zainteresowany quant wymyśla model,
dokumentuje go w takim zakresie, jak wymagają tego działy
zatwierdzania, w ciągu tygodnia biega za stempelkami, a przy iteration
planning kładzie na stół te modele, które udało mu się zatwierdzić (i
na których mu jeszcze zależy).

Z drugiej strony jeśli masz zespół złożony z n quantów, którzy sami
wymyślają, co program ma robić, sami zabiegają o zatwierdzenie tego, a
następnie sami to implementują, oraz tradera, którego rolą jest
polityczne naciskanie na to lub owo, to prawdopodobnie stosowanie XP
nie ma sensu. Możnaby się ewentualnie zastanowić nad Scrumem z
odpowiednio dobranymi praktykami.

do góry

On Monday, 19 December 2011 14:04:18 UTC, Stachu &#39;Dozzie&#39; K. wrote:
> Czekaj, wróć. Okno zmieniłeś w pokrycie dachu, a drzwi w wannę? O_o

Gdzie to wyczytales?

RW

do góry

On Dec 19, 1:47 pm, Maciej Sobczak <s...@g...com> wrote:
> On Dec 19, 1:33 pm, Andrzej Jarzabek <a...@g...com>
> wrote:
>
> > > Ale musiałoby ich być dokładnie tyle, ile byłoby tej dokumentacji,
> > > której ma nie być.
>
> > Dokładnie.
>
> Nie tylko. Tych notatek z dyskusji też musi być dokładnie tyle samo
> (bo informacji nie da się zredukować). I tego właśnie nie rozumiem.

Jak byłem na studiach zawsze byli tacy ludzie, którzy na wykładach
notowali pełnymi zdaniami wszystko, co mówił profesor. Ich notatki
były bardzo przydatne na kolokwiach czy egzaminach, które odbywały się
kilka tygodni czy miesięcy po samym wykładzie, i cały rok miał je
skserowane.

Na ogół ludzie, jeśli przychodzą do kogoś z konkretnym problemem,
który trzeba wytłumaczyć, jeśli ten problem jest odpowiednio mały,
tłumaczenie trwa może z 10 minut (jak nie mniej), a wiedzę uzyskaną w
ten sposób zapisuje się w postaci sformalizowanej lub stosuje w
praktyce zaczynając bezpośrednio po samym tłumaczeniu i w ciągu
najwyżej kilku godzin, potrafią zapamiętać z owego tłumaczenia na
tyle, że notowanie dosłownie wszystkiego, co było powiedziane, nie
jest konieczne. Ja na przykład mam przed sobą teraz wynotowane rzeczy,
które mam w kolejce do zrobienia, w taki sposób, że dla osoby, która
nie wie o co chodzi, byłyby kompletnie niezrozumiałe. A dla mnie są
zrozumiałe, bo w ogóle poza tym wiem, co robię. Jeśli komuś co pół
godziny resetuje się kontekst i bez notatek nie wie, czy akurat robi
oprogramowanie do robota przemysłowego, czy do serwisu plotkarskiego
na WWW, to zapewne powinien nie pisać, programów, tylko natychmiast
zapisać sobie na ręce, żeby pójść na badania do neurologa.

> Tradycyjna metoda polega na tym, że się pisze dokumentację, w której
> zawarta jest wiedza nt. działania systemu. W agile piszemy notatki,
> których jest *tyle samo* (nieredukowalność informacji, sorry, nie ja
> stworzyłem świat). A przynajmniej w całej tej dyskusji nie padły żadne
> przesłanki do stwierdzenia, że mogłoby ich być mniej.

Padły.

> I teraz okazuje się, że pomimo faktu, że będzie ich tyle samo i będzie
> do tego potrzebny taki sam wysiłek pisarski, to musimy je koniecznie
> wyrzucić do kosza i to najdalej parę godzin po napisaniu. To bardzo
> ważne. Bo jeśli zapomnimy je wyrzucić i się zaczną nam zbierać, to
> klient zobaczy plik kartek i jeszcze pomyśli, że my tu jakąś
> dokumentację piszemy i okaże się, że król jest nagi a my wcale nie
> jesteśmy agile.

Jak chcesz je sobie kolekcjonować, to twoja sprawa. Tak samo jak
chcesz sobie w weekend zrobić tripa na peyotlu to twoja sprawa. Ale
jak z faktu, że je kolekcjonujesz zrobisz praktykę, że z nich
korzystasz więcej niż tydzień po napisaniu, to "bo tak mam w notatce,
o tutaj, mogę pokazać" jest równie dobrą odpowiedzią na pytanie
"dlaczego to jest tak zrobione", co "bo tak mi powiedział mój duch
totemiczny na tripie peyotlowym".

> Niech mi ktoś wytłumaczy, w czym napisanie notatek i wywalenie ich do
> kosza jest lepsze od napisania ich i spięcia w segretatorze.

Oszczędzasz miejsce na biurku? Mniej trzeba wysiłku i czasu, żeby
wyrzucić kartkę do śmieci, niż żeby ją wpiąć do segregatora? Przede
wszystkim zaleta jest taka, że nie skorzystasz z tej notatki wtedy,
kiedy będzie ona nieaktualna, i kiedy zaimplementowanie tego, co jest
w niej zapisane wprowadzi buga do systemu, którego usunięcie zajmie
kupę czasu i pracy. Oczywiście możesz wpinać te notatki do skoroszytu
i nigdy więcej z nich nie korzystać, ale w takim razie niech mi ktoś
wytłumaczy, w czym spinanie notatek w segregatorze, z których się
nigdy nie skorzysta, jest lepsze od wyrzucania ich do śmieci?

> Pomijając fakt, że w kontekście biznesowym wyrzucanie *czegokolwiek*
> do kosza to czysta głupota i zwykle się srogo mści w późniejszym
> terminie.
> To nie jest żadna metodologia, to jest usankcjonowana
> nieodpowiedzialność.

Tu masz rację. Powinno się wrzucać do niszczarki.

> > Bywa. Dlatego też zasada nie jest taka, że się w ogóle nie produkuje
> > dokumentacji, tylko że dokumentuje się tylko to, czego absolutnie nie
> > da się zapisać w postaci testu lub kodu.
>
> Acha - czyli niektóre notatki zachowujemy w segregatorze. Wyrzucamy
> (koniecznie!) tylko te, dla których udało nam się napisać acceptance
> test.

Nic nie zachowujemy. Tworzymy normalną dokumentację.

> > Zakładając
> > przykładowo, że masz jakiś system, który liczy przejeżdżające
> > samochody na podstawie wejścia z jakichś sensorów, to można budować
> > testy w oparciu o rzeczywiste lub symulowane dane z tych sensorów.
>
> Ale klienta równo wali, czy to liczenie robi program, czy hardware,

Klient jest zamawiającym program.

> czy krasnoludki. I w ogóle jaki sensor?

Toż mówię - brak kontekstu. Przykładowo założyłem sobie, że program ma
liczyć samochody na podstawie danych z sensora. Oczywiście może sobie
liczyć samochody w bazie danych czy cośtam, ale bez kontekstu nie
jestem ci w stanie powiedzieć, jak to się testuje.

> Właśnie w tym jest problem, że systemy przemysłowe opisuje się
> całościowo, bo tylko w całości one są potrzebne. Wydzielanie granicy
> pomiędzy sensorami a programem, jest sztucznym krokiem, który z punktu
> widzenia klienta nic nie wnosi - dlatego nie wierzę, że OSCRowi będzie
> się chciało robić taki test. OSCR tego nie widzi. On widzi samochody.

Masz w takim razie niewłaściwego OSCR-a. Nie wiem jakie standardy są w
tej branży, ale klientem zespołu produkującego oprogramowanie nie
będzie właściciel fabryki samochodów, tylko zespół produkujący sprzęt,
ewentualnie zespół integrujący sprzęt z oprogramowaniem.

> W ogóle mam wrażenie, że agile wraz z całą swoją kulturą testowania
> jest bardzo nakierowany na założenie, że produktem jest jakiś program.

Heloł, bo to jest metodologia tworzenia oprogramowania, a nie
metodologia budowy robotów.

> Pewnie działa to jakość w kontekście np. serwisu internetowego, ale w
> większej skali produktem nie jest program, tylko system, w którym
> granice pomiędzy jego technicznymi składnikami (np. sensor vs.
> program) są niewidoczne dla klienta. I na tym się agile wyłoży.

Nie wyłoży się, tylko ty źle rozumiesz słowo "produkt". "Produkt" to
niekoniecznie jest to, co firma sprzedaje. XP się sprawdza kiedy
zespół produkujący sprzęt zamawia oprogramowanie w innej firmie lub w
dziale software tej samej firmy.

> > Bardzo prosto: dajesz OSCR-owi do odsłuchania ileś tam dźwięków
> > przetworzonym z takim pogłosem, on ci potwierdza, że to brzmi jak
> > odpowiednia filharmonia, piszesz test, który przetwarza dźwięk tym
> > efektem i sprawdza, czy wyjście się zgadza.
>
> Złapałeś się. :-) W przypadku pogłosu z filharmonii wyjście za każdym
> razem się może nie zgadzać (i na tym polega jego urok)

Ja nie mówię, o pogłosie z filharmonii, tylko o programowym filtrze,
który nadaje wejściu brzmienie jak pogłos z filharmonii - bo to
testujemy.

> a stwierdzenie,
> że coś brzmi tak samo jak coś innego jest subiektywne.

Program ci produkuje jakiś waveform, który odtworzony na danym
sprzęcie jakoś tam brzmi. Jeśli ten sam waveform na tym samym sprzęcie
raz brzmi, a raz nie brzmi jak pogłos z filharmonii, to nie jesteś w
stanie na ten sprzęt zrobić programowego filtra, który brzmi jak
pogłos z filharmonii.

Ale wiesz co? Jest odpowiednia metoda na zrobienie tego, o co chodzi:
w ogóle nie robić żadnego oprogramowania, tylko wstawić mniej-więcej
żeby działało parę oporników i kondensatorów, dać złote styki,
przegrzane kable, tytanową obudowę, hebanowe pokrętła, nóżki z rogu
nosorożca, dać egzemplarz albo dwa recenzentowi z odpowiedniego
czasopisma w zamian żeby napisał "zamknąłem oczy i poczułem się
zupełnie jakbym stał w słynnej sali imienia Pimcickiego w filharmonii
w Koluszkach" i jeszcze koniecznie "aksamitne basy i jedwabiste
soprany" - sukces murowany. Testowanie faktycznie niepotrzebne.

> Ten problem nie
> dotyczy tylko akustyki, jest cała masa takich miejsc. Np. ekspres do
> kawy ma robić dobrą kawę. Znowu nie ma jak zrobić acceptance testu.

No sorki, może się nie znam, ale program do ekspresu do kawy nie jest
żadną sztuczną inteligencją z zaszytym systemem ekspertowym "koneser
kawy" i wykrywaczem nastroju właściciela na podstawie "flucutation of
the pupil" i "involuntary dilationof the iris", tylko coś, co leci
przez jakiś prosty program, odmierza tyle a tyle wody, podgrzewa przez
tyle a tyle czasu itd. Jeśli przy tym samym programie i tych samych
warunkach wejściowych program robi raz dobrą, a raz niedobrą kawę, to
raczej nie z oprogramowaniem jest problem.

> > Nie znam się na tym, ale chętnie dowiem się dlaczego
> > tak uważasz.
>
> Właśnie dlatego, że w takich systemach ich działanie opisuje się
> całościowo.

Znaczy nie ma takiego etapu, gdzie określa się, jak się ma zachowywać
oprogramowanie w kategoriach sygnałów sterowania sprzętem?

> Agile jest za bardzo intruzywny i za bardzo zakłada, że
> klient będzie chciał być zaangażowany (poprzez OSCRów) w definiowanie
> tak drobno określonch szczegółów implementacyjnych.

Agile nie zakłada przede wszystkim, że "klient" to jest ten, co kupuje
coś w przedsiębiorstwie produkującym oprogramowanie.

> > Jeśli chodzi o "rozrywkowe", to na pewno wiem, że testy automatyczne,
> > jak i różne metodologie agile, stosuje się przy tworzeniu gier
> > komputerowych - chyba się kwalifikują jako 'rozrywka'?
>
> A tutaj to akurat ja się nie znam. Może profesor fir będzie wiedział.

Fir ma wiedzieć, co masz na myśli pisząc "systemy rozrywkowe"?

do góry

On Dec 18, 11:18 pm, Maciej Sobczak <s...@g...com> wrote:
> On Dec 18, 5:54 pm, Andrzej Jarzabek <a...@g...com>
> wrote:
>
> > Jeśli wynotowanie sobie czegoś podczas rozmowy na kartce papieru to już
> > "dokumentacja" to się nie zrozumieliśmy.
>
> To kiedy coś jest "dokumentacją"?
> Czy napisanie czegoś na wiki się liczy?

Co za różnica?

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

> > i nie ma wpinania
> > notatek do segregatora.
>
> A jak się rozsypią?

Jedna kartka ma się rozsypać?

> > Notatki służą do tego, żeby pomiędzy rozmową z
> > OSCR-em a zakodowaniem uzyskanej informacji rozmawiający nie zapomniał.
> > Ten czas, to bardzo rzadko więcej niż dzień, nigdy więcej niż 3-4 dni.
>
> Sorki, ale to nie działa. W 3-4 dni to sobie można okienko dialogowe
> napisać a nie określić działanie większego systemu w jakimkolwiek jego
> pionowym wycinku.

Pojedyncza user story to nie jest koniecznie kompletny kawałek
funkcjonalności. Dodatkowo, jak najbardziej można dopisać kompletną (w
sensie już użyteczną) nową funkcjonalność w 3-4 dni. Okienko dialogowe
(bez funkcjonalności) to raczej robota na minuty.

> > Jeszcze raz - nie masz takiego etapu, że przez ileś tygodni czy miesięcy
> > piszesz dokumentację (jakkolwiek nazwaną). User stories zaproponowane
> > przez OSCR-ów są priorytetyzowane na początku każdej iteracji
>
> Zaraz, zaraz. Czyli OSCRy muszą *najpierw* zaproponować te user
> stories, żeby mogli je priorytetyzować.

Tak.

> Powiedzmy, że tych historyjek jest Bardzo Dużo (tm). Ile czasu trwa ich
> "zaproponowanie"?

Tyle czasu, ile się wyznaczy. Tzn. jeśli OSCR ma Bardzo Dużo
historyjek, to się go prosi o własną priorytetyzację, bo na danym
zebraniu ma tylko zaproponować te, które będą możliwe do wykonania w
ciągu jednego tygodnia. Niech przedstawi od najważniejszych do
najmniej ważnych, przy czym historyjki zależne od innych historyjek
ustawi za nimi, i niech przedstawia w takiej kolejności - dajmy na to
po pięciu minutach będzie można spokojnie powiedzieć: "wystarczy, w
tym tygodniu i tak więcej nie zrobimy".

> Czym się
> różni "zaproponowanie" dużej ilości historyjek od napisania dużej
> ilości use-casów (na przykład) w formie dokumentacji? Nadal jest to N
> miesięcy, tyle że się fajniej nazywa.

Nie ma N miesięcy, bo OSCR musi przedstawić swoje historyjki na
pierwszym zebraniu planowania iteracji, czyli powiedzmy najdalej dwa
tygodnie po rozpoczęciu projektu. Oczywiście OSCR może sobie
utrzymywac backloga tak długiego, jak chce, ale co tydzień musi i tak
określić, jakie są najważniejsze rzeczy do zrobienia _teraz_, co
wymaga w tym samym tygodniu, w którym dana historia jest
implementowana, potwierdzenia przez żywą osobę, że to jest nadal ważne
i nadal ma być zrobione tak, jak sobie to wcześniej obmyśliła.
Naturalnym jest, że w trakcie tygodnia, w którym trwa implementacja
jednych historii, następują zmiany, czy zadawane są pytania, czy
podejmowane są decyzje, które powodują, że niektóre z tych Bardzo
Wielu historyjek nigdy nie zostaną zaproponowane, albo okażą się
znacznie ważniejsze, lub mniej ważne, albo przyjmą zupełnie inną
postać, niż to zakładał OSCR, kiedy sobie pisał owe Bardzo Dużo
historyjek.

> I nadal te user stories razem
> wzięte (chyba jednak lepiej je spiąc do segregatora) to jest
> dokumentacja.

To nie jest dokumentacja. Jeśli OSCR zepnie sobie wszystkie user
stories, które ma do zaproponowania w segregator, to jest to jego
prywatny segregator, a nie dokumentacja, która kogokolwiek interesuje.

Historyjki, które są zaplanowane na kolejną iterację, oraz te, które
zostały już odhaczone,

> No, chyba że OSCRy strzelają po kilka historyjek co tydzień i tak aż
> do końca projektu. Nadal jednak będzie tego M stron i nadal ich
> napisanie zajmie N czasu, nawet jeśli się je zaraz po napisaniu
> wyrzuca do kosza.
> Dlatego nie widzę postępu.

Postęp jest taki, że w trakcie tworzenia programu zdobywa się
dodatkowe informacje o tym, co jest ważne, co jest trudne, co i jak
można uprościć itd.

> Czyli co tydzień OSCR może zmienić ogólną wizję i doprowadzić do
> stworzenia produktu, który jest zbiorem niepowiązanych ze sobą
> funkcjonalności. Coś jak odkurzacz z odtwarzaczem mp3 i ekspresem do
> kawy.
> W przypadku napisania dokumentacji z góry jest szansa to dostrzec.

Ale dlaczego nie ma szansy tego dostrzec w kolejnym tygodniu? Poza tym
poza iteracjami jest jeszcze coś takiego jak release plan, na którym
ustala się funkcjonalność potrzebną do pierwszego release. Jeśli nagle
OSCR zaczyna zgłaszać funkcjonalność, która nie jest z tym związana,
to można zweryfikować, czy faktycznie to jest koniecznie potrzebne
klientowi i czy klient rozumie, że to opóźni dostarczenie gotowego
produktu. Jeśli klient to potwierdzi, albo po otrzymaniu odkurzacza w
wersji 1.0 stanowczo potwierdzi, że wersja 1.1. ma się różnić przede
wszystkim tym, że będzie miała odtwarzacz mp3, to już jest decyzja
klienta, a nie zespołu programistycznego.

> > Przede wszystkim czas - czas życia notatki mierzony jest raczej w
> > godzinach,
>
> Nie bardzo. Wtedy nie ma szansy dostrzec, że robimy odkurzacz z mp3,
> bo przy pisaniu notatki o mp3 poprzednia historyjka o odkurzaniu jest
> już w koszu. A potem OSCR powie, że nic takiego nie mówił. I jak mu
> udowodnić, że pieprzy, skoro sami powyrzucaliśmy wszystkie notatki do
> kosza?

Ta rozmowa z OSCR-em odbywa się podczas pracy nad konkretną
historyjką. Jeśli OSCR mówi rzeczy, które nie są z tą historyjką
związane, to się mu mówi, że owszem, skoro sobie życzy, ale to
zupełnie inna historyjka, i w ogóle funkcjonalność nie przewidziana na
ten release, więc decyzja klienta, czy chce dostać jak najszybciej
release z taką funkcjonalnością, jaką zaplanowano przy planowaniu
release-u, albo czy chce zmienić plan.

> Sorki, ale nie widzę tej teorii w praktyce.

Otóż nie wiem, czy cię zaskoczę, ale to nie jest coś, co właśnie sobie
wymyśliłem, tylko coś, co jest stosowane w praktyce przez bardzo wiele
projektów i produkuje sporo działającego oprogramowania.

> Nawet nie chciałbym się w
> czymś takim znaleźć, ani jako wykonawca, ani jako klient.

Z tym nie będę polemizował.

do góry

On Dec 19, 10:03 am, Roman W <b...@g...pl> wrote:
>
> Mnie w ogole zastanawia, czemu w "starszych" dziedzinach przemyslu
> (np. budownictwo czy petrochemia) koniecznosc stworzenia spojnego
> calosciowego projektu jest *oczywista*, natomiast w IT ludziom sie
> wydaje, ze mozna tworzyc duze systemy z klockow Lego.

Bo stosujesz złą analogię. W inżynierii oprogramowania spójnym i
całościowym projektem jest kod źródłowy w językach wysokiego poziomu,
a spawają roboty.

do góry

On 18/12/2011 23:18, Maciej Sobczak wrote:
>
> Czyli co tydzień OSCR może zmienić ogólną wizję i doprowadzić do
> stworzenia produktu, który jest zbiorem niepowiązanych ze sobą
> funkcjonalności. Coś jak odkurzacz z odtwarzaczem mp3 i ekspresem do
> kawy.
> W przypadku napisania dokumentacji z góry jest szansa to dostrzec.

Jeszcze jedno pytanie, bo mnie to trochę zafascynowało. Załóżmy
powiedzmy, że pracujesz 40h tygodniowo, od poniedziałku do piątku. W
poniedziałek przychodzisz do pracy nad nowym projektem, dostajesz
grubaśny dokument ze specyfikacją wymagań, i tam pierwsze zdanie
pierwszego rodziału brzmi jakoś tak "Opisywany produkt jest
oprogramowaniem do odtwarzacza MP3". Zakładając, że od tego momentu
pracujesz jako developer nad stworzeniem tego oprogramowania. Ile czasu
zajmie ci, zanim zapomnisz nad czym pracujesz i będziesz musiał
sprawdzić czytając jeszcze raz to pierwsze zdanie dokumentacji? Przez
weekend zapomnisz? Przez noc? Może wystarczy, że pójdziesz zaparzyć kawę
albo odbierzesz telefon?

do góry

On Monday, 19 December 2011 16:50:16 UTC, Andrzej Jarzabek wrote:
> On Dec 19, 10:03 am, Roman W <b...@g...pl> wrote:
> >
> > Mnie w ogole zastanawia, czemu w "starszych" dziedzinach przemyslu
> > (np. budownictwo czy petrochemia) koniecznosc stworzenia spojnego
> > calosciowego projektu jest *oczywista*, natomiast w IT ludziom sie
> > wydaje, ze mozna tworzyc duze systemy z klockow Lego.
>
> Bo stosujesz złą analogię. W inżynierii oprogramowania spójnym i
> całościowym projektem jest kod źródłowy w językach wysokiego poziomu,
> a spawają roboty.

W takim razie mowimy o tworzeniu projektu projektu. Kwestia definicji.

RW

do góry

On Dec 19, 7:11 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> Jeszcze jedno pytanie, bo mnie to trochę zafascynowało. Załóżmy
> powiedzmy, że pracujesz 40h tygodniowo, od poniedziałku do piątku. W
> poniedziałek przychodzisz do pracy nad nowym projektem, dostajesz
> grubaśny dokument ze specyfikacją wymagań, i tam pierwsze zdanie
> pierwszego rodziału brzmi jakoś tak "Opisywany produkt jest
> oprogramowaniem do odtwarzacza MP3".

Mówi się trudno, ale można to wziąć na klatę, jak się teraz w polityce
mawia.

> Zakładając, że od tego momentu
> pracujesz jako developer nad stworzeniem tego oprogramowania. Ile czasu
> zajmie ci, zanim zapomnisz nad czym pracujesz i będziesz musiał
> sprawdzić czytając jeszcze raz to pierwsze zdanie dokumentacji?

To pierwsze zdanie sądzę, że bym zapamiętał. Natomiast na pewno
zapomniałbym większość z następnych zdań, bo pewnie wyglądałyby tak
jak tutaj:

http://en.wikipedia.org/wiki/Mp3

Poproś kogoś, żeby Ci to przeczytał na głos. A potem niech Cię z tego
przepyta.

Uwaga: ten artykuł nawet nie próbuje udawać, że jest szczegółowy.
Szczegółowe są podlinkowane na dole. Z nimi też można spróbować.

> Przez
> weekend zapomnisz? Przez noc? Może wystarczy, że pójdziesz zaparzyć kawę
> albo odbierzesz telefon?

Poproś kogoś, żeby do Ciebie zadzwonił w trakcie, jak ten pierwszy
ktoś będzie Ci ten artykuł czytał.

Właśnie dlatego, gdybym miał pisał soft do mp3, to zacząłbym od
papierów.

A tak na serio, to naprawdę nie wyobrażam sobie, żeby ktoś napisał
dekoder mp3 na podstawie słownej opowieści OSCRa, zwłaszcze jeśli ta
opowieść miałaby tykający stoper w tle.

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

do góry

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

(W praktyce 160 1-godzinnych spotkań zajmie *znacznie* więcej, niż 160
godzin, ale nie komplikujmy rozważań, bo się zaplączemy w
złośliwościach.)

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.

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

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ą. 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 (dodatkowo można to zrobić też
w drugą stronę - pozwolić "domenowcom" pisać kod, który się potem
integruje w całość). Właśnie w takim środowisku spędziłem ostatnie 6
lat (surprise! ;-) ) i w pełni rozumiem potrzebę ścisłej współpracy,
którą agile próbuje zrealizować przez szeroko pojęty gęsty feedback.
To ma sens.

Ale żadna metoda prowadzenia projektów nie może opierać się na
"nierobieniu" czegoś.
Dlatego naprawdę bez sensu jest twierdzić, że w agile chodzi o to,
żeby nie robić dokumentacji. O nic takiego tam nie chodzi i nie może,
z powodów fundamentalnych, czyli z nieredukowalności informacji, która
prowadzi do tego, że przekazywania wiedzy nie da się skrócić. Można
ten proces rozstrzelić i posiekać na tysiąc kawałków przemieszanych z
klepaniem kodu i można nawet ustalić limity, że jeden kawałek nie może
zająć dłużej niż dwie minuty, ale sumaryczny koszt nie zniknie - on
się rozłoży w czasie całego projektu.
Może być przez to mniej nużący. Ale nie zniknie.

Nierobienie dokumentacji jest bez sensu, podobnie jak wyrzucanie do
kosza jakichkolwiek artefaktów projektowych - również notatek.
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.

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

do góry