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:

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

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.


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:

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

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?


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

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

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.

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.