On Monday, December 19, 2011 11:21:55 PM UTC, Maciej Sobczak wrote:
> 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 moim srodowisku pracy to sie robi tak, ze sie bierze kolesia A po matematyce albo
fizyce, kaze mu przeczytac pare ksiazek i sporo artykulow z dziedziny, po czym sadza
sie kolo kolesia B ktory ma zarabiac pieniadze przy uzyciu modeli tworzonych przez
kolesia A, po czym B tak dlugo bije i zniewaza A az ten a) nauczy sie pisac
przyzwoitej jakosci kod C++ (rzadziej Java) i b) zaimplementuje kod ktory zarabia na
pensje i premie obydwu. Moze to nie jest Agile, ale czasami jest bardzo "extreme".

RW

do góry

On 19/12/2011 22:20, Roman W wrote:
> 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.

W starszych dziedzinach przemysłu chyba niekoniecznie się tworzy projekt
projektu. W niektórych pewnie tak, ale w takiej sytuacji trzeba się
zacząć zastanawiać, czy programy projektuje się tak, jak domy, czy tak,
jak kanalizację, czy może tak, jak kopalnie miedzy, and then you're just
being silly.

do góry

On 19/12/2011 22:41, Maciej Sobczak wrote:
> On Dec 19, 7:11 pm, Andrzej Jarzabek<a...@g...com>
> wrote:
[...]
>> 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.

Och, jeśli masz z tym jakiś problem, może być coś innego. Podstaw sobie
na przykład "...bazą danych szlauchów i kaloszy".

> To pierwsze zdanie sądzę, że bym zapamiętał. Natomiast na pewno

Naprawdę? Bo z tego, co pisałeś, wynikało, że jest realna szansa, że
zapomnisz i bez tej dokumentacji nagle się okaże, że zrobiłeś
oprogramowanie do ekspresu do kawy.

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

Wiesz co, pewnie się orientujesz, że nie było to moim zamiarem, ale jak
już chcesz rozpatrywać konkretnie ten przykład, to rozważ, że tworząc
takie oprogramowanie:
a) prawdopodobnie nie będziesz robił własnej implementacji dekodera MP3,
tylko weźmiesz/kupisz istniejącą,
b) nawet jeśli będziesz taką implementację tworzyć, to nie potrzebujesz
do tego dokumentu opisującego formatu MP3 i algorytmów (de)kompresji -
takie dokumenty już istnieją,
c) dekodowanie MP3 będzie tylko małą częścią funkcjonalności programu,
d) nie jest całkiem absurdalnym założeniem, że okaże się, że częścią
pożądanej funkcjonalności będzie na przykład funkcja budzika,
komunikacja przez wifi albo platforma do odpalania aplikacji.

do góry

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?

do góry

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

do góry

On 12/19/2011 02:16 PM, Andrzej Jarzabek wrote:
>> > Bo sensowność mi umyka. Zwłaszcza, że wyrzucamy
>> > pracowicie zrobiony projekt i nie kodujemy wg jego założeń, ale
>> > wg tego, co druga grupa z nami konsultuje.
> Jaki projekt? Jeśli chodzi o ten projekt, na którym narysowano
> prostokąt i napisano w nim powiedzmy "interfejs do systemu SWIFT", to
> niby dlaczego zespół robiący interfejs do systemu SWIFT miałby go
> wyrzucić?
>
> Uprzedzając: zanim napiszesz, że "czasem się nie da bez zrobienia
> dużego, szczegółowego projektu, stwierdzić, jak można sensownie
> podzielić system na komponenty tworzone przez autonomiczne zespoły",
> to odpowiem - być może czasem się nie da. W takich przypadkach po
> prostu nie należy stosować XP. Z mojego doświadczenia wynika, że w
> bardzo wielu przypadkach się da, a nawet że często jest to i tak
> robione, nawet jeśli nie stosuje się żadnej metodologii agile. To
> raczej monolityczne zespoły z 50 programistami są rzadkością, nawet
> przy tworzeniu względnie dużych systemów.

Jaka jest rola architektów w Agile? Pytam, bo nie wiem.

Co do dużych zespołów - x >> 50, powiedzmy 500 - też się stosuje Agile,
nie ma takiego wymagania, żeby komponenty były autonomiczne. To znaczy,
w pewnej mierze są: projektuje się na różnych poziomach (to chyba
te skróty LLD, HLD), programista zazwyczaj też projektuje to, co ma
napisać, tyle, że tak się tego zazwyczaj nie określa. Więc nawet nie
jeden team to projektuje, każdy swoje i wespół w zespół, przynajmniej z
takim modelem się zetknąłem, pomimo tego, że role są jak najbardziej
określone. A Agile wydaje mi się pod tym względem słaby.

Mam wrażenie, że dyskusja jest pomiędzy "projektem określającym
sekwencję ruchów palców programisty" a Agile, co jest trochę bez sensu.
Bez sensu imo jest też to:

> narysować na
> tablicy pięć prostokątów, reprezentujących logiczne komponenty
> projektowanego systemu, wypunktować w każdym w kilku punktach po
> jednym zdaniu czym te komponenty mają się zajmować, i ewentualnie
> połączyć je jakimiś kreskami czy strzałkami oznaczającymi zależności,
> to tak, należy "zaprojektować dobrze i poprawnie". Ale też właśnie XP
> (i Agile jakoś tam w ogólności) twierdzi, że takie projektowanie jest
> właśnie dobre i poprawne i tak należy robić.

Z mojego doświadczenia właśnie tak nie należy robić. To jakaś epoka
kamienia łupanego. Projekt można wyrazić słowami, UMLem, rysunkami,
czymkolwiek, można wyrazić zarówno ogólną konstrukcję, jak i niektóre
rzeczy bardzo szczegółowo, jeżeli jest taka potrzeba. Nie czaję,
dlaczego musi być "tylko szkic komponentów i koniec" i zero
elastyczności. Akurat pod tym względem dla mnie nie ma żadnej różnicy,
czy to Agile czy Up Front, to raczej kwestia kultury organizacyjnej,
rozumienia ról swoich i innych.

Edek

do góry

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

do góry

On Dec 20, 9:42 pm, Edek <e...@g...com> wrote:
> On 12/19/2011 02:16 PM, Andrzej Jarzabek wrote:
>
> Jaka jest rola architektów w Agile? Pytam, bo nie wiem.

Bez powtarzania disklejmerów po raz dziesiąty: nie jest określona. W
XP w zespole nie ma takiej roli, w Scrum masz rolę "członka zespołu" -
zespół organizuje się sam i podział pracy w zespole wyznaczany jest
wewnętrznie i jeśli sobie taki zespół wytypuje kogoś, do robienia
"architektury" (cokolwiek by to nie znaczyło), to będą mieli.

Oczywiście zespoły agile mogą funkcjonować w kontekście istnienia
architekta poza zespołem - jeśli np. jest kilka zespołów tworzących
różne "produkty", architektem można nazwać kogoś, kto decyduje ite
tych "produktów" ma być i w jaki sposób funkcjonalność będzie dzielona
między nimi, jak również może decydować o rzeczach typu Unix czy
Windows, Oracle czy Sybase itd.

> Co do dużych zespołów - x >> 50, powiedzmy 500 - też się stosuje Agile,

500-osobowy zespół? Stosujący agile? Masz jakieś przykłady? Jakie
metodologie się w tych zespołach stosuje?

> nie ma takiego wymagania, żeby komponenty były autonomiczne. To znaczy,

W XP i XP-podobnych wariantach Scrum jest takie wymaganie.
Oragnizacyjnie, nie może być tak, że zespół nie może zrefaktoryzować
swojego kodu i wywalic np. jakieś funkcje czy klasy, bo inny zespół z
nich korzysta. Każdy komponent musi tylko udostępniać dobrze
zdefiniowane i obwarowane acceptance testami interfejsy, i ci, którzy
korzystają z tych interfejsów to "klienci" danego zespołu.
Implementacja tych interfejsów jest własnością zespołu i zespół musi
mieć na tyle autonomii, żeby sobie tę implementację móc zmieniać
według potrzeb. To miałem na myśli pisząc "autonomiczne komponenty",
oczywiście nie chodzi o to, żeby każdy z nich mógł być używany bez
pozostałych.

> w pewnej mierze są: projektuje się na różnych poziomach (to chyba
> te skróty LLD, HLD), programista zazwyczaj też projektuje to, co ma
> napisać, tyle, że tak się tego zazwyczaj nie określa. Więc nawet nie
> jeden team to projektuje, każdy swoje i wespół w zespół, przynajmniej z
> takim modelem się zetknąłem, pomimo tego, że role są jak najbardziej
> określone. A Agile wydaje mi się pod tym względem słaby.

Może faktycznie jest słaby pod względem działania w 500-osobowym
zespole. W życiu się z takim kołchozem jednak nie spotkałem.

> Mam wrażenie, że dyskusja jest pomiędzy "projektem określającym
> sekwencję ruchów palców programisty" a Agile, co jest trochę bez sensu.
> Bez sensu imo jest też to:
>
> > narysować na
> > tablicy pięć prostokątów, reprezentujących logiczne komponenty
> > projektowanego systemu, wypunktować w każdym w kilku punktach po
> > jednym zdaniu czym te komponenty mają się zajmować, i ewentualnie
> > połączyć je jakimiś kreskami czy strzałkami oznaczającymi zależności,
> > to tak, należy "zaprojektować dobrze i poprawnie". Ale też właśnie XP
> > (i Agile jakoś tam w ogólności) twierdzi, że takie projektowanie jest
> > właśnie dobre i poprawne i tak należy robić.
>
> Z mojego doświadczenia właśnie tak nie należy robić. To jakaś epoka
> kamienia łupanego. Projekt można wyrazić słowami, UMLem, rysunkami,
> czymkolwiek, można wyrazić zarówno ogólną konstrukcję, jak i niektóre
> rzeczy bardzo szczegółowo, jeżeli jest taka potrzeba. Nie czaję,
> dlaczego musi być "tylko szkic komponentów i koniec" i zero
> elastyczności.

Bo w ten sposób pilnujesz tego, żeby projekt na każdym poziomie był
prosty. Żeby np. pilnować abstrakcji w ten sposób, że każdy komponent
projektowany jest w oderwaniu od tego, jakie są jeszcze inne
komponenty. Metoda jest ogólnie taka, że po stworzeniu nieformalnego
projektu (w co sę wlicza również UML) wykonać formalny projekt, który
przyjmuje postać kodu źródłowego programu i testów. Mając w ten sposób
sformalizowany zapis projektu całości, można się zająć projektowaniem
i implementowaniem poszczególnych części.

do góry

On 12/21/2011 06:40 PM, Andrzej Jarzabek wrote:
> On Dec 20, 9:42 pm, Edek<e...@g...com> wrote:
>> On 12/19/2011 02:16 PM, Andrzej Jarzabek wrote:
>>
>> Jaka jest rola architektów w Agile? Pytam, bo nie wiem.
>
> Bez powtarzania disklejmerów po raz dziesiąty: nie jest określona. W
> XP w zespole nie ma takiej roli, w Scrum masz rolę "członka zespołu" -
> zespół organizuje się sam i podział pracy w zespole wyznaczany jest
> wewnętrznie i jeśli sobie taki zespół wytypuje kogoś, do robienia
> "architektury" (cokolwiek by to nie znaczyło), to będą mieli.
>
> Oczywiście zespoły agile mogą funkcjonować w kontekście istnienia
> architekta poza zespołem - jeśli np. jest kilka zespołów tworzących
> różne "produkty", architektem można nazwać kogoś, kto decyduje ite
> tych "produktów" ma być i w jaki sposób funkcjonalność będzie dzielona
> między nimi, jak również może decydować o rzeczach typu Unix czy
> Windows, Oracle czy Sybase itd.

O kurde. Mamy inne doświadczenia.

>
>> Co do dużych zespołów - x>> 50, powiedzmy 500 - też się stosuje Agile,
>
> 500-osobowy zespół? Stosujący agile? Masz jakieś przykłady? Jakie
> metodologie się w tych zespołach stosuje?

30MLOC to ile osób? Tak naprawdę to źle użyłem słowa zespół: dział,
albo i większa struktura. Scrum, CI, reszta bardzo różnie. Podobno
ze swoimi 30MLOC doszli do cyklu godzinnego CI i drugiego "przez noc".
Pomijam już, że na poziomie gry słów Agile + 30MLOC = zwinne sterowanie
lotniskowcem.

>
>> nie ma takiego wymagania, żeby komponenty były autonomiczne. To znaczy,
>
> W XP i XP-podobnych wariantach Scrum jest takie wymaganie.
> Oragnizacyjnie, nie może być tak, że zespół nie może zrefaktoryzować
> swojego kodu i wywalic np. jakieś funkcje czy klasy, bo inny zespół z
> nich korzysta. Każdy komponent musi tylko udostępniać dobrze
> zdefiniowane i obwarowane acceptance testami interfejsy, i ci, którzy
> korzystają z tych interfejsów to "klienci" danego zespołu.
> Implementacja tych interfejsów jest własnością zespołu i zespół musi
> mieć na tyle autonomii, żeby sobie tę implementację móc zmieniać
> według potrzeb. To miałem na myśli pisząc "autonomiczne komponenty",
> oczywiście nie chodzi o to, żeby każdy z nich mógł być używany bez
> pozostałych.

To w specyficzny sposób wspiera tezę z mojego pierwszego posta: dzięki
Agile odkryliśmy abstrakcję API. Kiedyś odkryjemy, że API to jeszcze nie
wszystko i warstwy muszą działać razem. I różne techniki
testowania, też dzięki Agile. Oh, well.

>
>> w pewnej mierze są: projektuje się na różnych poziomach (to chyba
>> te skróty LLD, HLD), programista zazwyczaj też projektuje to, co ma
>> napisać, tyle, że tak się tego zazwyczaj nie określa. Więc nawet nie
>> jeden team to projektuje, każdy swoje i wespół w zespół, przynajmniej z
>> takim modelem się zetknąłem, pomimo tego, że role są jak najbardziej
>> określone. A Agile wydaje mi się pod tym względem słaby.
>
> Może faktycznie jest słaby pod względem działania w 500-osobowym
> zespole. W życiu się z takim kołchozem jednak nie spotkałem.

Większość znam nie z własnych doświadczeń; są kołchozy i kołchozy.

>
>> Mam wrażenie, że dyskusja jest pomiędzy "projektem określającym
>> sekwencję ruchów palców programisty" a Agile, co jest trochę bez sensu.
>> Bez sensu imo jest też to:
>>
>>> narysować na
>>> tablicy pięć prostokątów, reprezentujących logiczne komponenty
>>> projektowanego systemu, wypunktować w każdym w kilku punktach po
>>> jednym zdaniu czym te komponenty mają się zajmować, i ewentualnie
>>> połączyć je jakimiś kreskami czy strzałkami oznaczającymi zależności,
>>> to tak, należy "zaprojektować dobrze i poprawnie". Ale też właśnie XP
>>> (i Agile jakoś tam w ogólności) twierdzi, że takie projektowanie jest
>>> właśnie dobre i poprawne i tak należy robić.
>>
>> Z mojego doświadczenia właśnie tak nie należy robić. To jakaś epoka
>> kamienia łupanego. Projekt można wyrazić słowami, UMLem, rysunkami,
>> czymkolwiek, można wyrazić zarówno ogólną konstrukcję, jak i niektóre
>> rzeczy bardzo szczegółowo, jeżeli jest taka potrzeba. Nie czaję,
>> dlaczego musi być "tylko szkic komponentów i koniec" i zero
>> elastyczności.
>
> Bo w ten sposób pilnujesz tego, żeby projekt na każdym poziomie był
> prosty. Żeby np. pilnować abstrakcji w ten sposób, że każdy komponent
> projektowany jest w oderwaniu od tego, jakie są jeszcze inne
> komponenty. Metoda jest ogólnie taka, że po stworzeniu nieformalnego
> projektu (w co sę wlicza również UML) wykonać formalny projekt, który
> przyjmuje postać kodu źródłowego programu i testów. Mając w ten sposób
> sformalizowany zapis projektu całości, można się zająć projektowaniem
> i implementowaniem poszczególnych części.

Dziękujemy o Agile za odkrycie warstw abstrakcji i testów. Ja tu nie
widzę żadnej różnicy pod względem metodyki, ale to pewnie zależy od
punktu, z jakiego się startuje zmieniając religię na zwinniejszą.

Edek

do góry

On 12/20/2011 12:56 AM, Roman W wrote:

>
> W moim srodowisku pracy to sie robi tak, ze sie bierze kolesia A po
> matematyce albo fizyce, kaze mu przeczytac pare ksiazek i sporo
> artykulow z dziedziny, po czym sadza sie kolo kolesia B ktory ma
> zarabiac pieniadze przy uzyciu modeli tworzonych przez kolesia A, po
> czym B tak dlugo bije i zniewaza A az ten a) nauczy sie pisac
> przyzwoitej jakosci kod C++ (rzadziej Java) i b) zaimplementuje kod
> ktory zarabia na pensje i premie obydwu. Moze to nie jest Agile, ale
> czasami jest bardzo "extreme".

Z ciekawości: dlaczego po matematyce lub fizyce, a nie po informatyce?
Rozumiem, że łatwiej nauczyć matematyka informatyki niż odwrotnie,
ale informatyka w Polsce może być zarówno informatyką chemii spożywczej
jak i stosowaną ekonometrią.

Inaczej mówiąc, nie widzę ja akurat powodu dlaczego ktoś ze znajomością
metod numerycznych nie miałby napisać szybciej i lepiej kodu wg. modeli,
który koleś B mu podsunie. Jak to jest?

Edek

do góry