On Fri, 17 Feb 2012 21:33:08 +0100, szyk <s...@o...pl> wrote:

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

Ciagle przerobi - tak. Chaos - nie. Nawt ciagle pzrerobki mozna
kontrolowac i planowac.

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

Programwoanie w parch to paranoja. Jedyna forma programwoanai w parach
ktora znam to nie taka ze dwoch pracuje nad tym samym problemem, ale
taka ze jeden pracuje nad dwoma problemami. Gdy koszt programisty jezt
rzedu 200 tysiecy dolarow rocznie (nei wiem ile w Polsce) to za
propozycje programwoania parami mozna dostac kopa w dolna czesc ciala.

Ja kuz mowilem o Agile. Proponuje poczytac na ten temat

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

Nie ma tak dobrze. Zmiana w jednym kawalku mzoe sie propagowac na inne
kawalki
>
>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:
>

Urban legend. Nie da sie uzyskac 0% bledow, w szczegolnosci nie da sie
stwierdzic e jes t0% bledow. Albowiem testowanie moze wykryc tylko
obecnosc bledow a nie nieobecnosc. A metody formalne ciagle jeszcze
nie maja dostatecznej mocy. A z NASA jest tak ze ktorys z "rowerow"
marsjanskich zagwozdil sie po ladowaniu, bo mial nei zainicjowany
pointer. Inna misja malo co nie skonczyla sie fiaskiem bo tworcy
programu nei slyszeli o czyms takim jak "priority inversion".

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

Nom na ten temat mapisano moze ksiazek i stworzono ocena metodologii,
poczynajac od testow jednostkowych. W normalnym przemyslowym
srodowisku programista musi napisac testy jednostkowe do wszystkiego
co robi; w wiekscosci przypadkow to jest okolo 75% kodu ktory
programista pisze. Te testy sa scentralizowane i wykonywan pzrez
osobny personel. U mnie - co noc.

Poza tym, znow polecam Agile w kontekscie jakosci, wszczegolnocis cos
takiego jak "test driven development". Ksiazka jest na ten temat, i to
o ile pamietam, nie jedna

>Ja proponuję podejście od A do Z - czyli: Praca nad jakością na każdym
>etapie. To jest główny cel tej metodologi.
>

No wlasnie, do tego sluza testy jednostkowe, code reviews - zarowno
manualne jak i zautomatyzowane i przeglady projektu. jak rozneiz
osobna grupa testujaca.

>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?
>
W ogole nic nie robic :) Ale o jakie ryzyko chodzi?
>
>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).
>

tak, to sie tlucze w peltli. Starty powstalyby wowczas gdyb owo
"tkuczenie" nie bylo dobrze zorganizowane i dobrze zaplanowane.

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

Indywidualny programista ma miec takie ambicje zeby zrobic to co niego
nalezy w terminie i dobrze. O tym czy to jest "przydatne dla innych"
decydyje management, czyli ci ktorzy mu prace zlecaja

>Kolejną zaletą stosowania metodologi (nawet tak lekkiej jak pół ekranu
>tekstu) jest nabywanie zdolności do tworzenia coraz bardziej
>skomplikowanych systemów.

Nikt nei mowi ze nie tzreba miec metodologii. Owszem, tzreba. Tylko
metodologia Kolegi jest z lat 50tych. teraz sa inne metodologie. Nei
da sie tego opisac na usenecie. Proponuje ksiazki lub kursy.

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

Nie. Zlozonosc problemu wyraza sie przy pomocy roznych miar, ale na
pewno nie przy pomocy metodologii.

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

kazdy ma swoj kawalek. U mnie ludzie pracuja "zadaniowo" - dostaja
problem do rozwiazania. Kazdy jest architektem i programista. Nie ma
"koderow". Facio zna interfejs, a jak zrobi swoj kawalek to juz jego
sprawa. Oczywiscie, jest kontrolowany, ale dosyc ogolnie. Pare osob
kontroluje interfejsy, inne osoby kontroluja wymagania, inne osoby
robia testy. Wszystko ciagle sie zmiena bo ciagle mamy roznych
klientow (i to w tym samym czasie) ktorym tzreba robic rozne zmiany. i
Jakos sie nei wywala. Tak na marginesie, jest ponad setka ludzi i
ponad 50 milionow linii kodu.

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

Nasza metodologie spisane jest na jednej kartce i przypieta pluskiewka
w kuchni. No i nie ma jednej osoby ktora "ma caly system w glowie".
Owszem, rozne osoby maja "system w glowie" ale rozne jego aspekty i na
roznych poziomach hierarchii

Ja bym jednak proponowal poczytac o Agile, spiral development,
adaptive development, unit testing, specjalnie w kontekscie Agile czy
"test driven development". Tyle ze to doscy duzo czytania :)

A.L.