On 18/12/2011 11:44, Roman W wrote:
> On Dec 18, 11:04 am, Andrzej Jarzabek<a...@g...com>
> wrote:
>
> Ja tu widze kilka praktycznych problemow:
> - co robia programisci, kiedy OSCR jest chory/poszedl na urlop i nie
> ma zastepstwa?

Możesz mieć więcej niż jednego OSCR w zespole. Jeśli np. masz jednego
rzeczywistego przedstawiciela faktycznego klienta, to drugi OSCR może
być wewnętrznie zatrudnionym BA pełniącym taką rolę - jeśli zna się na
temacie i na codzień pracuje z faktycznym przedstawicielem klienta, to
powinien mieć wystarczająco dużo informacji, żeby pociągnąć projekt
przez tydzień czy dwa (jeśli nie dłużej).

> - co sie robi w sytuacji, kiedy OSCR jest, well, glabem? jezeli mam
> problem z dokumentem (jest niekompletny, niejasny, zawiera
> sprzecznosci) moge go w miare bezpiecznie skrytykowac. Jezeli moim
> biezacym zrodlem wiedzy jest czlowiek przyslany przez klienta, to
> napisanie maila "X nie rozumie o co biega w projekcie/nie umie
> wyjasnic o co biega" jest politycznie trudniejsze niz napisanie
> "dokumentacja jest niekompletna, prosze uzupelnic", bo krytykujesz
> osobe a nie rzecz.

W przypadku dokumentu też przecież będzie tak, że jeśli w twojej krytyce
nie napiszesz "autor jest głąbem, proszę dać do napisania komuś innemu",
to dadzą dokument do poprawienia temu samemu głąbowi i on znowu napisze
nie to, czego potrzeba. Jak będziesz konsekwentnie walić krytyką, to w
momencie, w którym wymienią autora może to już w praktyce niewiele się
różnić od skrytykowania osoby.

Oczywiście zgodzę się, że takie niuanse są istotne i jeśli faktycznie
masz kulturę, gdzie trudno krytykować nawet ewidentnych głąbów, to może
rzeczywiście nie powinieneś adoptować metod opartych na bezpośśredniej
komunikacji.

Jeśli chodzi o rozwiązanie - jeśli już musisz pracować z głąbem i z
powodów politycznych nie da się z tym nic zrobić, to można go jeszcze
unieszkodliwić np. zatrudniając go do pisania dokumentacji, a do
pełnienia rzeczywistej roli OSCR-ów przyjąć ze dwóch dobrych BA.

> - bez formalnej dokumentacji jest trudniej sledzic, na jakim etapie
> kto zazyczyl sobie zmian w projekcie, kto odpowiada za dane
> rozwiazanie, itd. OSCR moze na flipczarcie narysowac programistom cos
> co mu akurat przyszlo do glowy, programisci zuzyja X roboczogodzin na
> implementacje jego fantazji, a kiedy kupka uderzy w wiatraczek, to
> OSCR sie moze wyprzec ze kiedykolwiek o tym mowil - bo przeciez nikt
> nie bedzie lazil do OSCR z dyktafonem w kieszeni, nie?

To trochę nie tak działa. Każda większa część funkcjonalności jest
dokumentowana w postaci user story i planowana na konkretną iterację.
Objaśnienia OSCR-ów w trakcie developmentu dotyczą szczegółów stories
już zaakceptowanych na daną iterację. Oczywiście podczas samego
planowania stories są tworzone, dokumentowane, i wtedy OSCR tłumaczą co
się z nimi wiąże - developerzy w tym momencie mają dowiedzieć się na
tyle, żeby ocenić złożoność implementacji. OSCR-om nie wolno w trakcie
iteracji dokładać nowych kawałków funkcjonalności. Jeśli natomiast
okazuje się, że złożoność uzgodnionej wcześniej story została poważnie
niedoszacowana, na tyle żeby zburzyć istniejący plan iteracji, to się
idzie z tym do product ownera i decyduje się, co robić. Jeśli np.
uproszczona wersja też ma sens, to można ustalić, że uproszczoną wersję
robimy teraz, a full-blown wersję zapiszemy jako osobną story. Jeśli się
tak nie da, to trzeba zmienić plan, i albo wyrzucić story do kolejnej
iteracji, albo zredukować scope aktualnej iteracji przerzucając inne
stories na kolejną. Tak czy inaczej, wszystkie stories, plany iteracji,
plany release'ów i zmiany tych planów są dokumentowane i zatwierdzane
przez odpowiednie strony.

do góry

On Dec 18, 12:49 pm, Andrzej Jarzabek <a...@g...com>
wrote:

[snip]

Sumaryczna odpowiedz:

1. Koniecznosc zatrudnienia OSCR fizycznie dostepnego dla programistow
moze byc kosztem nie do zaakceptowania. Jjezeli ten koles ma byc
podstawowym zrodlem informacji dla programistow, to musi byc dla nich
caly czas dostepny, czyli bedzie siedzial w biurze programistow i sie
nudzil kiedy programisci akurat nie beda mieli do niego pytan -- ergo,
klient oddeleguje do programistow najmniej uzyteczna osobe, czyli
jakiegos glaba. Natomiast dokumentacje moze napisac najlepszy spec po
stronie klienta, oddac ja programistom, zajac sie czym innym a od
czasu do czasu odpowiadac na ich pytania, ew. umowic sie na spotkanie.
Programisci, majac dobra dokumentacje, nie musza miec pod reka
fizycznej osoby 40h/tygodniu. IMHO pisemna dokumentacja to bardziej
efektywne wykorzystanie czasu ludzi, ktorzy najlepiej wiedza co
projekt ma dostarczyc.
2. Zawsze latwiej jest krytykowac efekt czyjejs pracy niz besposrednio
autora.

RW

do góry

On Dec 18, 12:49 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> To trochę nie tak działa. Każda większa część funkcjonalności jest
> dokumentowana w postaci user story i planowana na konkretną iterację.
> Objaśnienia OSCR-ów w trakcie developmentu dotyczą szczegółów stories
> już zaakceptowanych na daną iterację. Oczywiście podczas samego
> planowania stories są tworzone, dokumentowane, i wtedy OSCR tłumaczą co
> się z nimi wiąże - developerzy w tym momencie mają dowiedzieć się na
> tyle, żeby ocenić złożoność implementacji. OSCR-om nie wolno w trakcie
> iteracji dokładać nowych kawałków funkcjonalności. Jeśli natomiast
> okazuje się, że złożoność uzgodnionej wcześniej story została poważnie
> niedoszacowana, na tyle żeby zburzyć istniejący plan iteracji, to się
> idzie z tym do product ownera i decyduje się, co robić. Jeśli np.
> uproszczona wersja też ma sens, to można ustalić, że uproszczoną wersję
> robimy teraz, a full-blown wersję zapiszemy jako osobną story. Jeśli się
> tak nie da, to trzeba zmienić plan, i albo wyrzucić story do kolejnej
> iteracji, albo zredukować scope aktualnej iteracji przerzucając inne
> stories na kolejną. Tak czy inaczej, wszystkie stories, plany iteracji,
> plany release'ów i zmiany tych planów są dokumentowane i zatwierdzane
> przez odpowiednie strony.

IMHO to dziala w przypadku systemow ktore sa na tyle proste, ze mozesz
je wytlumaczyc czlowiekowi na tablicy, on/ona chwile popatrzy, pomysli
i bedzie mial/a w glowie pelne zrozumienie problemu. Wtedy taka
procedura ma szanse dzialac. Jezeli projektuje sie bardziej zlozony
system, to niestety ludzie musza wziac napisany dokument, zaparzyc
sobie kawy, siasc i go przetrawic w skupieniu. Inaczej nie beda
rozumieli co robia.

RW

do góry

On Dec 18, 12:14 pm, Andrzej Jarzabek <a...@g...com>
wrote:

> Co do problemu 50 programistów, to XP i (w mniejszym stopniu) Scrum
> skalują się na wielkość zespołu do powiedzmy 12-16 programistów. Da się
> je zastosować do większych projektów, pod warunkiem, że da się podzielić
> zespół. To nie jest takie hop-siup, które można zrobić mechanicznym
> dzieleniem, bo każdy zespół musi mieć pewną autonomię i być właścicielem
> swojego codebase: w praktyce musi tworzyć oddzielny "produkt"
> (komponent), i w takiej sytuacji jeden zespół jest "klientem" drugiego,
> albo ma się zespół zajmujący się integracją systemu i ten zespół pracuje
> z końcowym klientem i podaje wymagania zespołom wykoującym poszczególne
> komponenty. Czasem jest to niemożliwe albo niepraktyczne, i w takich
> sytuacjach po prostu nie należy stosować tych metodologii.

Mi to przypomina metode dzialania programistow rzadu federalnego w
"Snow Crash" Stephensona - zadania byly podzielone tak drobno, ze nikt
nie wiedzial, nad czym wlasciwie pracuje ;-)

RW

do góry

On 18/12/2011 13:03, Roman W wrote:
> On Dec 18, 12:49 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
>
> [snip]
>
> Sumaryczna odpowiedz:
>
> 1. Koniecznosc zatrudnienia OSCR fizycznie dostepnego dla programistow
> moze byc kosztem nie do zaakceptowania.

Może tak być. No i trudno - XP w ogóle ma wiele wymagań upfron które
trzeba spełnić, bo inaczej prawodopodobnie nie da się sensownie zastosować.

> Jjezeli ten koles ma byc
> podstawowym zrodlem informacji dla programistow, to musi byc dla nich
> caly czas dostepny, czyli bedzie siedzial w biurze programistow i sie
> nudzil kiedy programisci akurat nie beda mieli do niego pytan -- ergo,
> klient oddeleguje do programistow najmniej uzyteczna osobe, czyli
> jakiegos glaba.

Po pierwsze należy klientowi delikatnie uświadomić, że jeśli oddeleguje
głąba, to znacząco redukuje swoje szanse dostania dobrego produktu w
dobrym czasie.

Po drugie OSCR, w momencie kiedy nie odpowiada na pytania programistów,
jest bardzo dobrze usytuowanym żeby wykonywać exploratory testing -
siedzieć na maszynie, na której zainstalowane jest ostatnie demo, i
próbować go używać.

Poza tym obowiązkiem OSCR jest również wymyślanie kolejnych user stories
i zastanawianie się nad ich wartością - co prawdopodobnie też się będzie
wiązać z kontaktowaniem się z odpowiednimi ludźmi w macierzystej
organizacji i omawianiem z nimi tych problemów - być może w postaci
tworzenia i przesyłania dokumentacji.

W końcu - oprócz odpowiadania i tłumaczenia, OSCR może/powinien brać
też udział w tworzeniu acceptance tests.

> Natomiast dokumentacje moze napisac najlepszy spec po
> stronie klienta, oddac ja programistom, zajac sie czym innym a od
> czasu do czasu odpowiadac na ich pytania, ew. umowic sie na spotkanie.
> Programisci, majac dobra dokumentacje, nie musza miec pod reka
> fizycznej osoby 40h/tygodniu. IMHO pisemna dokumentacja to bardziej
> efektywne wykorzystanie czasu ludzi, ktorzy najlepiej wiedza co
> projekt ma dostarczyc.

IMHO z taką dokumentacją jest cały szereg problemów, poczynając od tego,
że jeśli osoba znająca się na czymś dobrze pisze dokument, który będzie
czytać ktoś, kto się na tym zna słabo lub wcale, to jest gigantyczny
potencjał, żeby czytelnik źle zrozumiał dokument, i w związku z tym
zaimplementował funkcjonalność, która w jego mniemaniu jest zgodna z
dokumentem, natomiast jest w mniejszym lub większym stopniu niegodna z
intencją autora dokumentu. Moim zdaniem interaktywne przedstawianie tej
wiedzy, w połączeniu ze względnie krótkimi cyklami
tłumaczenie-implementacja-tłumaczenie-implementacja w dużej mierze
niwelują ten problem.

Czy marnowanie czasu na implementowanie błędnej funkcjonalności i potem
na znajdowanie i poprawianie tych błędów jest mnie lub bardziej
nieefektywne od trzymania najlepszego speca od strony klienta on site
40h/tygodniu - tego nie wiem. Moim zdaniem, również w świetle tego, co
napisałem powyżej o roli OSCR-a to bardziej się opłaca mieć tego speca
na miejscu - ale to może zależeć od specyfiki projektu, klienta, wielu
innych rzeczy. Dodatkowo pomiędzy głąbem a najlepszym specem można
jeszcze rozważyć OSCR-a pośredniego, który nie jest głąbem i zna się na
temacie, a dodatkowo ma gorącą linię do najlepszego speca i kilka godzin
tygodniowo poświęca na omawianie z nim tego, co jest i będzie robione,
jak to powinno być robione i tak dalej. Taki OSCR jak dla mnie jest
zdecydowanie bardziej wartościowy niż dokumentacja napisana przez
najlepszego speca.

> 2. Zawsze latwiej jest krytykowac efekt czyjejs pracy niz besposrednio
> autora.

Nawet jeśli, to nie zawsze najlepiej zrobić to, co zrobić najłatwiej.

Poza tym w przypadku OSCR-a też krytykujesz efekty pracy: "pan Iskiński
próbuje nam wytłumaczyć, co jak program ma się zachowywać, ale efekty
jego pracy są mizerne, bo to, co mówi nie trzyma się kupy" :)

do góry

On 18/12/2011 13:06, Roman W wrote:
> On Dec 18, 12:49 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
[XP]
> IMHO to dziala w przypadku systemow ktore sa na tyle proste, ze mozesz
> je wytlumaczyc czlowiekowi na tablicy, on/ona chwile popatrzy, pomysli
> i bedzie mial/a w glowie pelne zrozumienie problemu. Wtedy taka
> procedura ma szanse dzialac. Jezeli projektuje sie bardziej zlozony
> system, to niestety ludzie musza wziac napisany dokument, zaparzyc
> sobie kawy, siasc i go przetrawic w skupieniu. Inaczej nie beda
> rozumieli co robia.

To działa również w przypadku skomplikowanych systemów, które można
przedstawić w uproszczony sposób przez abstrahowanie od szczegółów.
Wydaje mi się, że z większością, jeśli nie ze wszystkimi złożonymi
problemami można i należy tak sobie radzić.

do góry

On Sun, 18 Dec 2011 12:14:48 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

>On 17/12/2011 22:43, A.L. wrote:
>>
>> Nie ma sie Pan co obawiac. To jest "metodologia Agile". Ponoc jedynie
>> sluszna.
>>
>> Ciekawe jak "agilowcy" wyobrazaja sobie projekt w ktorym pracuje,
>> powiedzmy, 50 programistow, i owi programisci nigdy nie kontaktuja sie
>> z przyszlym uzytkownikiem systemu?
>
>Po pierwsze, nie ma czegoś takiego jak "metodologia Agile". Można
>ewnetualnie rozpatrywać konkretne metodologie jak XP czy Scrum, albo
>zastanawiać się nad ogólnym podejściem Agile do tego tematu - ale w tym
>drugim przypadku trzeba wziąć pod uwagę, że istnieją metodologie czy
>procesy, które mieszczą się nadal w ogólnym nurcie Agile, ale stosują
>pewne rozwiązania spoza tego nurtu.
>
>Więc po pierwsze temat kontaktów z przyszłym użytkownikiem: generalnie
>nie jest konieczny. XP zaleca, żeby w miarę możliwości "on-site
>customer" był przedstawicielem typowego użytkownika systemu, ale nie
>jest to jedyna możliwość. Podstawą jest to, żeby ludzie występujący w
>rolach "customer representative" albo "product owner" rozumieli potrzeby
>użytkownika, ewentualnie mieli możliwość szybkiego dowiedzenia się jakie
>one są w szczególnym przypadku.
>
>Co do problemu 50 programistów, to XP i (w mniejszym stopniu) Scrum
>skalują się na wielkość zespołu do powiedzmy 12-16 programistów. Da się
>je zastosować do większych projektów, pod warunkiem, że da się podzielić
>zespół. To nie jest takie hop-siup, które można zrobić mechanicznym
>dzieleniem, bo każdy zespół musi mieć pewną autonomię i być właścicielem
>swojego codebase: w praktyce musi tworzyć oddzielny "produkt"
>(komponent), i w takiej sytuacji jeden zespół jest "klientem" drugiego,
>albo ma się zespół zajmujący się integracją systemu i ten zespół pracuje
>z końcowym klientem i podaje wymagania zespołom wykoującym poszczególne
>komponenty. Czasem jest to niemożliwe albo niepraktyczne, i w takich
>sytuacjach po prostu nie należy stosować tych metodologii.

No. Rozumiem ze Kolega ma wielkei doswiadczenie w prowadzeniu takich
prac w ktorych jest 50 i wiecej programistow.

A.L.

do góry

On Sun, 18 Dec 2011 10:41:42 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

>On 18/12/2011 02:58, A.L. wrote:
>>
>>> Jeśli chodzi o opis działania samego algorytmu, to programiści dysponują
>>> znakomitym narzędziem właśnie do tego, jakim są wysokopoziomowe języki
>>> programowania.
>>
>>
>> Dupy zawracanie. Oczywiscie, latwo bedzie odcyfrowac taka rzecz jak
>> "algorytm pivotingu" algorytmu Simplex przegladajac 150 tysiecy linii
>> C jego implemenatcji.
>
>Nie powiedziałbym, że C jest szczególnie dobrym przykładem języka
>wysokiego poziomu. Co do przeglądania tysięcy linii kodu, to po to w
>języku (nawet w C) są mechanizmy abstrakcji, żeby to nie było konieczne.
>
>> Drodzy Panowie, znow obracacie sie kolo paradygmatu "bazki danych
>> szlauchow i kaloszy" i "systemow" pisanych pzrez jednego programiste w
>> pare wieczorow. Jeszcze raz: w duzych projektach programista nei
>> rozmawia z klientem, w ogole nie widzi go na oczy, a "klient" to nie
>> pojedyncza osoba a duza na ogol organizacja.
>
>XP nie jest metodą tworzoną pod kątem jednego programisty piszącego dla
>jednego klienta przez kilka dni. Jest zaprojektowany pod kątem zespołu z
>6-12 programistami, tworzącego oprogramowanie dla klientów
>instytucjonalnych przy czasie trwania projektu liczonym co najmniej w
>miesiącach.
>
>> Bez odpowiedniej
>> formalizacji procesu projektowania i dokumentowania wymagan dla
>> programisty ow programista nei mialby zielonego pojacia co
>> programowac, a projekt skutkowalby tym samym czym skutkowala proba
>> bucowy Wiezy Babel
>
>Otóż jednak istnieją inne sposoby na to, żeby programista miał pojęcie.

Dyc o tym pisze. DOKUMENTACJA. Juz pisalem, ze w jednym z projektow w
ktorych biore udzial, same "requitements" maja ponad 3000 stron

A.L.

do góry

On 18/12/2011 15:27, A.L. wrote:
> On Sun, 18 Dec 2011 12:14:48 +0000, Andrzej Jarzabek
> <a...@g...com> wrote:
[...]
>> sytuacjach po prostu nie należy stosować tych metodologii.
>
> No. Rozumiem ze Kolega ma wielkei doswiadczenie w prowadzeniu takich
> prac w ktorych jest 50 i wiecej programistow.

Tutaj opieram się na literaturze. Ale nie rozumiem, z czym kolega ma
problem - przecież właśnie przyznałem koledze, że do takich projektów
XP, Scrum i chyba większość innych metodologii agile się nie nadaje.

do góry

On Sun, 18 Dec 2011 11:52:26 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

>On 17/12/2011 22:51, Maciej Sobczak wrote:
>> On Dec 17, 4:58 pm, Andrzej Jarzabek<a...@g...com>
>> wrote:
>>
>>> Tak, generalnie polega to na tym, że programista rozmawia z OSCR tak
>>> długo, żeby zrozumieć co program ma robić,
>>
>> I to jest właśnie problem tej metodologii, bo zakłada ciągłość tego
>> procesu.
>>
>> Otóż ja mam taki defekt[*], że jak ktoś coś do mnie mówi, to już po
>> kilku minutach nie pamiętam, o czym mówił na początku. Radzę sobię z
>> krótką listą zakupów, ale dłuższe opisy mi się urywają.
>>
>> [*] Z obserwacji wynika, że nie tylko ja mam ten defekt. Akurat mamy
>> weekend - stań przed jakimś kościołem i zapytaj wychodzących ludzi o
>> czym było kazanie. Pamiętaj, że wszyscy słuchali tego samego, ale
>> zapytaj kilka różnych osób.
>> Dobre, nie?
>>
>> Pytanie: jak długa jest rozmowa z tym - jak mu tam - OSCR, żeby
>> przekazać równoważnik kilkuset stron tekstu? Krócej, niż kazanie, czy
>> dłużej?
>
>Ale moment, ty to sobie wyobrażasz na zasadzie "kazanie" - programiści
>siadają wszyscy w sali i klient im mówi od początku do końca jak program
>ma działać, po czym bierze walizeczkę i idzie do domu?

W projektach wiekszych niz jednoosobowe klient nic nie mowi do
programistow. Podobnie jak osoba zamawiajaca budowe mostu przez Wisle
nic nie mowi do spawaczy. Most projektuje architekt, na podsatwie
wymagan klienta ktorym to klientem sa wladze miasta, potem projekt
bierze inzynier budowlany i okreska szczegoly konstrukcji - sposob
realizacji przesel, grubosc belek itede oraz organizacje procesu
budowy. Na podstawie tego powsztaje dokumentacja i dopiero wtedy
spawacze (czytaj: programisci) dostaja polecania aby zepsawac to z
tamtym.

Dokladnie tak samo wyglada realizacja pzredsiewziec programistycznych.
Programista ma niewielki wplyw na postac produktu koncowego, bo to nie
programista decuduje jak ten produkt bedzie wygladal. Z wyjatkiem
pierdykniecia bazki danych szlauchow i kaloszy.

Jezeli Kolega powtarza to co Kolege nauczyli na studiach, to powinien
Kolega poprosic o zwrot kosztow edukacji. Jezeli zas kolega jest
praktykiem, to w celu uwierzytelnienia Kolegi pogladow - to znaczy ze
Kolega do nich doszedl na podstawie wlasnej praktyki - proponuje aby
Kolega opublikwoal swe resume z lista projektow i ich szczegolowa
charakterystyka.

Inaczej mi to wyglada jak przyslowiowe opowiesci slepego o kolorach.

A.L.

do góry