jesli o mnie chodzi to nie uzywam takich planow, zakladam
ze jak opanuje temat to trzasne wszystko malym palcem i
opanowuje temat (niesie to ze soba problemy zwiazane z
zaniedbywaniem humanistycznych watkow w zyciu)


--
Wysłano z serwisu Usenet w portalu Gazeta.pl -> http://www.gazeta.pl/usenet/

do góry

On Fri, 17 Feb 2012 17:40:07 +0000, Bronek Kozicki <b...@s...net>
wrote:

>On 17/02/2012 16:36, A.L. wrote:
>> On Fri, 17 Feb 2012 13:58:07 +0100, szyk<s...@o...pl> wrote:
>>
>>> * zasady OOP (Obiektowo Orientowane Projektowanie) - ściąga z tych
>>> zasad: brak duplikacji kodu, enkapsulacja, operowanie na interfejsach
>>> zamiast na implementacji, preferowanie kompozycji zamiast dziedziczenia,
>>> atomowa odpowiedzialność klas, klasy otwarte na rozbudowę ale zamknięte
>>> na modyfikacje, sensowne dziedziczenie
>>
>> Tak na marginesie, polecam ksiazke
>>
>> Skunk Works: A Personal Memoir of My Years of Lockheed
>> Ben R. Rich, Leo Janos
>>
>> To tak ogolnie na pemat projektowania.
>>
>> A tak powaznie, to model Kolegi pachnie mi "waterfall model". Tak sie
>> od dawna nie robi. Programy sie raczej pisze iteracyjnie. Trudno od
>
>zastanawiam skąd to się bierze, u początkujących (moje wrażenie sądząc
>po początu wątku), w 21 wieku. Nauka ze starych podręczników? Procedura
>do własnych studenckich projektów?
>

Moze chec do uporzadkowanai wszystkiego? Zeby bylo klarowne, jasne i
zdeterminowane?

"Waterfall methodology" nie jest zreszta cakiem bezuzyteczna. Sprawdza
sie doskonale przy budowie domow i mostow, na przyklad. Ale software
ma nieco inna nature...

A.L.

P.S. Tak na marginesie, tam jest pare innych rzeczy: wiara w moc
wzorcow projektowych, wiara w To Co Powiedzial Guru (cytat:
"operowanie na interfejsach zamiast na implementacji" i dalej)
niezaleznei od tego czy Guly ma tak zwane "clue" czy nie.

Niedawno mialem ostra dyskusje z "mlodym miszczsem" na temat
implementacji hashCode() w Javie. Miszcz upieral sie ze jego
implementacja jest jedynie sluszna. Argument: "Bo skopiowalem to z
ksiazki Effectiva Java, a jak tam jest napisane to znaczy ze tak
tzreba robic". Z dalszej dyskusji wyniklo ze jezeli sie robi inaczej
niz w tej ksiazce, to na pewno robi sie zle. O tym ze w konkretnym
przypadku ta implementacja ma sensu, nei dalo sie miszcza przekonac.

do góry

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.

do góry

On 2012-02-17 21:33, szyk 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:
> ...
> 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.

http://en.wikipedia.org/wiki/Spiral_model

--
MB

do góry

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.

do góry

On 17/02/2012 21:55, A.L. wrote:
>
> 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.

Nie mam dużego doświadczenia w programowaniu w parach, ale na podstawie
tego, co piszą ludzie, którzy to praktykują i z mojego doświadczenia
wynika, że w odpowiednich warunkach i sensownie zrobione może to mieć
duży sens.

Przede wszystkim mogę zaobserwować, że fizyczne klepanie kodu zajmuje
bardzo niewielki wycineek mojego czasu. Wiele z innych czynności mogłoby
być znacznie przyspieszone przez programowanie w parach, albo jest i tak
dublowaniem tego, co bym robił programując w parze z kimś innym, tylko
mało efektywnie (transfer wiedzy).

Moje doświadczenie wskazuje na przykład, że w przypadku takich czynności
jak projektowanie albo znajdowanie problematycznych bugów, naradzenie
się z drugą osobą, która również "siedzi w temacie" jest często
wielokrotnie (więcej niż dwukrotnie, nierzadko znacznie więcej) szybsze,
niż siedzenie i głowienie się samemu. Tyle że w typowej sytuacji, w
której pracuję, w zespole nie ma takiej osoby.

Z drugiej strony wygląda to tak, że ktoś zgłasza się do mnie z prośbą o
pomoc lub wytłumaczenie czegoś. Ponieważ ja akurat robię zupełnie coś
innego, to po pierwsze sama zmiana kontekstu zaburza moją produktywność
w tym, co robię, po drugie muszę poświęcić ileśtam czasu na zrozumienie
problemu mojego kolegi, w dodatku do czasu poświęconego na samo
tłumaczenie. W końcu wszelkie problemy w komunikacji mogą powodować, że
kolega, który coś źle zrozumiał, zrobi źle, więc nie tylko część
poświęconego czasu była zmarnowana, ale to, że zrobił źle, potencjalnie
zmarnuje jeszcze więcej czasu innych ludzi. Z kolei ja, pracując nad
czymś innym, nie mam ani głowy, ani obowiązku ani konkretnej motywacji,
żeby sprawdzić, czy to, co tłumaczyłem przełożyło się na prawidłowe
wykonanie.

I skoro już o tym mowa - defekty są sporym problemem. Pomijając już
koszta związane z ich manifestacją w systemach produkcyjnych, to samo
diagnozowanie, znajdowanie i usuwanie ich pochłania wiele czasu wielu
ludzi, w tym również owych cennych programistów. Jeśli para programistów
produkuje kod z mniejszą ilością defektów niż pojedynczy programista (na
co również wskazują różne dane), to oszczędność czasu na samym tym może
znacznie przewyższać potencjalną stratę na tym, że dwóch programistów
siedzi nad jednym problemem.

W końcu jest ten subtelny psychologiczny aspekt "satysfakcji z pracy".
Oczywiście menedżment może przyjąć punkt widzenia taki, że w pracy się
nie siedzi dla przyjemności, a dla firmy są ważne zyski i straty a nie
zadowolenie pracowników - a jam sam z kolei mogę byc oskarżony o to, że
mam własny interes w tym, żeby mieć satysfakcję z pracy, nawet kosztem
zyskó pracodawcy. Ale też mam pewne wsparcie w literaturze twierdząc, że
satysfakcja pracowników (w szczególności developerów) ma bardzo
konkretne przełożenie na pieniądze: na ten przykład Tom DeMarco i
Timothy Lister "Peopleware".

Z jednej strony moje doświadczenie jest takie, że utknięcie na jakimś
problemie i niemożność obgadania go z kimś jest frustrująca. I że im
bardziej frustrująca praca, tym szybciej się ją zmienia na inną, a
programista, który cośtam potrafi nie tylko nie będzie miał z tym
problemów, ale nawet będą do niego regularnie dzwonić headhuntery i
podsuwać mu propozycje. DeMarco i Lister twierdzą, że wymiana
pracownika, nawet jeśli natychmiast znajdzie się nowego pracownika o
podobnych kwalifikacjach na jego miejsce, kosztuje mniej więcej tyle, co
półroczny koszt zatrudnienia tego pracownika - niekiedy mniej, ale
niekiedy znacznie więcej. Wydaje mi sie to sensownym oszacowaniem.

Druga strona medalu jest taka, że programowanie parami może pomagać w
integrowaniu zespołu, tym, co DeMarco i Lister nazywają "jelling".
Twierdzą oni, z czym również się zgadzam, że takie "jelled" zespoły
osiągają radykalnie lepsze rezultaty, co oczywiście też się przekłada na
pieniądze.

Oczywiście prawdziwość tego wszystkiego, a co za tym idzie skuteczność
programowania w parach zależy mocno od tego jak jest to robione i jak w
ogóle działa cały zespół. Ale też w XP wprost zakłada się, że
poszczególne praktyki działają w kontekście innych praktyk, i dlatego
programowanie parami powinno być połączone co najmniej z TDD,
rozbudowanymi coding standards, collective ownership, daily stand-up itd.

> Ja kuz mowilem o Agile. Proponuje poczytac na ten temat

Aglie jako takie jest raczej ogólnym podejściem, "duchem", niż jakąś
konkretną metodologią. Można jednak zauważyć, że:
1. XP jest uważane za metodologię agile,
2. Zespoły praktykujące agile, nawet jeśli nie stosują XP, często
programują parami,
3. Zgodnie z założeniami agile m. in. o tym, czy progrmauje się parami,
czy pojedyczno, jak również o wielu innych rzeczach, decyduje sam
zespół, a nie kierownictwo. Jeśli jest się w sytuacji, w której nie
można uprawiać programowania parami ze względu na brak zgody
kierownictwa, to nie da się również uprawiać agile, niezależnie od tego,
czy z programowaniem parami, czy bez - zespół po prostu ma za mało
autonomii.

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

Personel? U nas to robi maszyna :)

> 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

Bardzo polecam - Steve Freeman, Nat Pryce "Growing Object Oriented
Software Guided By Tests".

do góry

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

do góry

On Sat, 18 Feb 2012 03:06:21 +0000, Andrzej Jarzabek
<a...@g...com> wrote:

>On 17/02/2012 21:55, A.L. wrote:
>>
>> 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.
>
>Nie mam dużego doświadczenia w programowaniu w parach, ale na podstawie
>tego, co piszą ludzie, którzy to praktykują i z mojego doświadczenia
>wynika, że w odpowiednich warunkach i sensownie zrobione może to mieć
>duży sens.
>

Qrde, a ja pracuje w firmie a nie ejstem studentem, i wiem jak sie
oglada kazdego dolara i jaka jest zajebista procedure jak sie chce
kogos zatrudnic.

Wiec prosze mi tu nie opowiqdac dyrdymolow o "programowaniu parami".
Takie cos mozliew byloby w zaawansowanym socjalizmie, ale z tym
systemem dawno sie, mam nadzieje, pozegnalismy. A jak dwoch bedzie
pracowac nad tym samym, to na ogol jeden bedzie zasuwal a drugi bedzie
sie opierdalal. Zwlaszca ze parca programisty, jako myslowa, jest
jednooosobowa.

A co na ten temat mowia "gurus"?... A gu...wno mnie to obchodzi

A.L.

do góry

Dnia Fri, 17 Feb 2012 22:27:02 -0600, A.L. napisal:

> On Sat, 18 Feb 2012 03:06:21 +0000, Andrzej Jarzabek
> <a...@g...com> wrote:
>
>>On 17/02/2012 21:55, A.L. wrote:
>>>
>>> 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.
>>
>>Nie mam dużego doświadczenia w programowaniu w parach, ale na podstawie
>>tego, co piszą ludzie, którzy to praktykują i z mojego doświadczenia
>>wynika, że w odpowiednich warunkach i sensownie zrobione może to mieć
>>duży sens.
>>
>>
> Qrde, a ja pracuje w firmie a nie ejstem studentem, i wiem jak sie
> oglada kazdego dolara i jaka jest zajebista procedure jak sie chce kogos
> zatrudnic.
>
> Wiec prosze mi tu nie opowiqdac dyrdymolow o "programowaniu parami".
> Takie cos mozliew byloby w zaawansowanym socjalizmie, ale z tym systemem
> dawno sie, mam nadzieje, pozegnalismy. A jak dwoch bedzie pracowac nad
> tym samym, to na ogol jeden bedzie zasuwal a drugi bedzie sie
> opierdalal. Zwlaszca ze parca programisty, jako myslowa, jest
> jednooosobowa.
>
> A co na ten temat mowia "gurus"?... A gu...wno mnie to obchodzi

Najwyraźniej Pan się nie nadaje do pracy w parach, kto by chciał
pracować z kimś w parze, jeżeli nie można liczyć na chociażby cień
uznania dla osławionego guru X (nie mylić z guru Y).

Edek

do góry

W dniu 2012-02-17 22:55, A.L. pisze:
> programista pisze. Te testy sa scentralizowane i wykonywan pzrez
> osobny personel. U mnie - co noc.

Jaki soft jest używany do takich testów i na jakim systemie operacyjnym
to śmiga?

do góry