Dnia Fri, 17 Feb 2012 21:33:08 +0100, szyk napisal:

> Kilkukrotnie pojawiło się stwierdzenie, że ta procedura przypomina
> niesławny model "waterfall" oraz stwierdzenie, że tak się już nie robi
> ze wskazaniem na model iteracyjny. Nasuwają się pytania takie:

Model "agile" zdecydowanie usuwa sporo wad modelu "waterfall".

Ja bym tylko chciał zwrócić uwagę na inny aspekt sprawy: menedżerowie
są potrzebni. Ogólnie wiadomo, że sami programisci często pogrążeni
sa w codziennym rozwijaniu kodu i jakoś tak jest, że w grupie musi
być jakiś leader, który wprowadzi może nie tyle dyscyplinę, co
przypomni, upomni, powie "no bardzo fajna implementacja, ale nad
testami może warto jeszcze trochę czasu spędzić", albo co najmniej
ma ostatnie słowo w kwestii "czyją wizję realizujemy".

Pracowałem w b. dużych zespołach i widziałem Waterfall zrobiony dobrze,
gdzie ilość WTFków była mocno ograniczona, projekty były na tyle
dopracowane, że miały od początku do końca sens, cykl Waterfalla
(bo tak to było, dla programistów jak jedna faza implementacji się
kończyła to już sprawdzali projekt kolejnej, bo byli "o to męczeni")
- ten cykl nie był za długi w porównaniu do rozmiaru całości.

Widziałem też Waterfall zrobiony źle. Procedur wszyscy niby
przestrzegali, ale: architekci mieli głowę trochę za wysoko, żeby
zniżać się do sprawdzenia, czy projekt ma sens, programiści robili
co mogli, ale dostosowywali się do sytuacji, menedżerowie dbali
co najwyżej o PR wewnętrzny, a testerzy nie wiedzieli, co się dzieje,
bo całość wysypywała się artystycznie za każdym razem w innym miejscu
niezależnie od tego, czy kampania testów się zaczynała czy kończyła.

Oba przechodziły na Agile, ten udany nadal był udany, temu drugiemu
cyhba to niewiele pomoże.

>
> 1. Jakie są wady i zalety modelu iteracyjnego?
> Ja pisałem programy właśnie zgodnie z "modelem iteracyjnym" i według
> mojego pojęcia była to kompletna partyzantka: gdy tylko jedno kończyłem
> dostawałem nowe wytyczne i musiałem znowu pół programu przewalać by
> zaimplementować "nowy ficzer". Słowem chaos i ciągłe przeróbki. Stąd
> moje poszukiwania systematycznej metodologi. Muszę też przyznać, że na
> temat "sprytnych" podejść do procesu wytwarzania to czytałem jedynie
> "Programowanie ekstremalne" ale uznałem to za nie praktyczne w moim
> przypadku i nie do przeforsowania w robocie (np. programowanie w
> parach).

Programowania w parach jeszcze nie widziałem. Testy, review, ogólne
wytyczne itd. istnieją i w Agile i w Waterfall; Agile przede wszystkim
skraca cykl, ale nie zmienia wbrew pozorom podstawowych zasad. W praktyce
programiści do Agile przystosowywali się całkiem szybko, gorzej z
menedżerami projektów, którzy nagle dostali cioty, bo nie wiedzieli,
jaką mają mieć rolę i czy w ogóle są potrzebni.

Jeden z coachów Agile ujął to tak, że jeden z ważniejszych aspektów Agile
polega na tym, że wszystko od razu widać, nie zamiata się pod dywan,
nie odkłada na później. Poza tym: bizness as usual.

>
> 2. Czy ten przedstawiony w tym wątku model da się przetransformować na
> iteracyjny?
> Moim zdaniem tak. Przy każdej zmianie wymagań trzeba zaczynać od punktu
> 1 i kończyć na punkcie 9 bez dotykania tych części systemu jakie się nie
> zmieniają w nowej wersji.

Jak najbardziej tak, tyle że to będzie inaczej wyglądać.

>
>
> Druga sprawa jaka jest pomijana przez dyskutantów, to kwestia
> zapewnienia jakości oprogramowaniu. Wiem np. że poprzez odpowiednie
> metodologie w NASA redukuje się błędy w oprogramowaniu do 0,0% (wymienia
> się systemy rzędu 500k linii kodu). Więc nasuwa się pytanie:

There Is Always One More Bug.

>
> Jak waszym zdaniem powinno wyglądać zapewnienie jakości?

To o czym każdy wie: testy. Innymi czynnikami dysponują architekci i
programiści takich bardziej "core'owych" części, dobry projekt jest
tak napisany, żeby był odporny na błędy. To brzmi może jak abstrakcja,
ale często ma duży wpływ na unikanie wielu problemów, które można
przewidzieć. Nie mówiąc już o tym, że cokolwiek się wybierze,
mam na myśli ogólny schemat czy cokolwiek w tym rodzaju, każdy
będzie po tym jechał, bo nie ma idealnych rozwiązań. Więc lepiej
nie generować zbyt wielu problemów.

Same testy to temat sam w sobie, programiści sami testują,
ale potem i tak potrzebni są testerzy, w dużych firmach to osobne
i liczne zespoły, plus czasem tak zwany "pierwszy klient", czyli
zespół, który dostaje finalną wersję.

>
> Ja proponuję podejście od A do Z - czyli: Praca nad jakością na każdym
> etapie. To jest główny cel tej metodologi.
>
> Kolejna sprawa: Metodologia to jeden z trzech znanych mi sposobów
> ograniczania ryzyka (drugi to zakup czegoś co już działa, trzeci to
> zatrudnienie ludzi co już coś takiego stworzyli). Więc:
>
> Jak waszym zdaniem ograniczać ryzyko?

Ktoś chyba już pisał: nic nie robić. Ryzyko trzeba oszacować i sobie z
nim radzić. To nie jest rolą programisty, tylko kogoś, kto trzyma
kasę, nawet tą wirtualną. Ograniczanie ryzyka polega głównie na tym,
żeby go nie olać, resztę się zrobi.

>
>
> Kolejna sprawa: metodologia wprowadza ekonomię sił, i ograniczanie
> szamotaniny marnującej i wytracającej energię (tłuczenie w pętli zmian
> specyfikacji, kodu i testów).

Od tego są menedżerowie, żeby nie było szamotaniny
ani innych przykrych spraw, które prędzej czy później się pojawią.
http://c2.com/cgi/wiki?FixBrokenWindows

>
> Jak chcecie ograniczać ilość iteracji? Jak nie metodologią?

Nie rozumiem idei "ograniczania ilości iteracji" samej w sobie.
Agile robi wręcz odwrotnie. Podejrzewam, że problem leży gdzie indziej.

>
> Interesujące było by jakie mielibyście rozwiązanie uwzględniające tą
> "ekonomię sił" w kontekście pracy indywidualnego programisty który ma
> ambicję stworzyć coś co było by przydatne dla innych.

Robić swoje i współpracować z innymi. Również z tymi, co mają inne
zdanie.

>
> Kolejną zaletą stosowania metodologi (nawet tak lekkiej jak pół ekranu
> tekstu) jest nabywanie zdolności do tworzenia coraz bardziej
> skomplikowanych systemów.
> Tak właśnie mnie naszło, że rozmiar projektu nie wyraża się w ilości
> linii kodu czy ilości klas, ale w metodologi jakiej on wymaga. Jak cały
> projekt trzyma się w główce i nie ma problemu podczas tworzenia
> programu/systemu to raczej taki projekt jest mały (przynajmniej dla tego
> co pisze). Większe projekty jakich się już indywidualnie nie ogarnia w
> szczegółach (bo np. tyle się w nich dzieje jednocześnie, albo mają tak
> dużo modułów) dalej można realizować poprzez metodologię małych kroków.
>
> A Wy jaki macie przepis na tworzenie coraz poważniejszych systemów?
> Zatrudnianie kolejnych "geniuszy"? dla których ten kolejny system będzie
> mały, więc będą oni mogli go sobie trzymać w główce i "będzie git". Moim
> zdaniem to nie jest podejście inżynierskie tylko siłowe i w końcu trzeba
> będzie się oprzeć na metodologi.

Nie mam przepisu. Dobrym menedżerom za to właśnie się płaci, bo tak poza
tym, po co komu menedżer?

Od strony inżynierskiej to już zależy od wymagań. Inaczej robi się
strony dla picu, inaczej bankowe, inaczej oprogramowanie medyczne,
inaczej wewnętrzne narzędzia (np. potrzebne do testów).

A co do "geniuszy", to to określenie o mniej popularnych konotacjach.
Ale programiści są lepsi i śrdniejsi, trzeba tym lepszym dawać właśnie
te części, które tego wymagają. Nie da się też pracować bez kiespkich
programistów, każdy jest przydatny z zupełnie nie inżynierskich względów.

Edek

PS. Dajcie ulgę przy ocenianiu wynurzeń ze względu na porę nocy... ;)