On 20/05/2011 16:08, Michal Kleczek wrote:
> Jędrzej Dudkiewicz wrote:
>
>> Owszem, natomiast mam złe doświadczenia z genialnymi projektantami,
>> którzy potrzebują czasu, bo projekt musi wszystko przewidzieć z góry.
>> Jestem gorącym zwolennikiem projektowania, ale, na Boga!, nie
>> wszystkiego na raz!
>
> Wszystko zalezy, co sie rozumie przez "wszystko" :)
> Przeciez to nie jest tak, ze na papierze pisze sie program w jezyku C, a
> potem sie to po prostu daje maszynistce do przepisania.
>
> Jest duzo waznych rzeczy, ktore mozna (i trzeba) zrobic zanim sie usiadzie
> do komputera - chociazby podzial na moduly/komponenty (co oczywiscie nie
> oznacza ze to sie nie zmieni na jote w przyszlosci

Wszystko zależy, co się zorumie przez "trzeba". W wielu wypadkach
spokojnie można rozpocząć programowanie bez takiego podziału

> - aczkolwiek jak zle to zrobisz, to naprawienie tego pozniej bedzie
> b. kosztowne).

Odpowiem w stylu argumentów przeciw agile: będzie bardzo kosztowne,
jeśli jesteś niekompetentnym wykonawcą zatrudniającym niekompetentnych
programistów. Kompetentny programista potrafi refaktoryzować kod na
bieżąco i stanowi to niewielki ułamek kosztów developmentu.

do góry

On 20/05/2011 09:26, Maciej Sobczak wrote:
> On 20 Maj, 09:35, Michal Kleczek<k...@g...com> wrote:
>
>>> Oczywiście, że każda iteracja jest testowana od A do Z. Automatycznie.
>>
>> Sek w tym, ze to jest tylko _udawanie_ testowania.
>
> Zgadzam się.
>
> Wydaje mi się, że agile/xp opiera się na założeniu, że test jest tani.
> Tak tani, jak build albo nawet pojedynczy commit w repozytorium.

Źle ci się wydaje.

> Dlatego pojawiają się absurdalne pomysły, żeby te rzeczy łączyć.

To nie są absurdalne pomysły. To jest bardzo dobry pomysł, żeby mieć
suitę testów, która leci przy każdym buildzie - z powodzeniem stosuje
się to nawet w procesach, które tak poza tym nie są agile.

Jeśli chodzi o to, jaki jest koszt testu, to trzeba wliczyć następujące
czynniki:
* koszt stworzenia frameworku do testów - może być niebanalny, ale
rozkłada się na wiele testów. Tutaj masz moduł do unit testów, ale też
automatyzację testów integracyjnych, czyli np. stworzenie skryptu, który
ci bierze daily build, robi automatyczny deployment w środowisku
testowym, odpala skrypty testowe i rozsyła wyniki.
* koszt przeprowadzania zautomatyzowanych testów, w co wchodzi
utrzymanie środowiska testowego i związany z tym czynnik czasowy: w
pełni automatyczne testy mogą być wykonywane przez noc lub nawet 24
godziny na dobę, ale jeśli przestaje wystarczać czasu w dobie, to
wchodzi dodatkowy koszt powiększenia środowiska testowego. Można też
podzielić testy na te, które wykonywane są na każdym nightly buildzie,
pełen zestaw, który jest robiony raz na iterację.
* koszt napisania automatycznych testów: TDD zakłada, że znacząca część
wysiłku programistycznego idzie w pisanie testów.
* koszt wykrycia tego, jakie testy trzeba mieć w skrypcie. Tutaj wchodzi
exploratory testing, czyli generalnie testowanie ręczne, tylko że nie
jest to ręczne wykonywanie testów "od A do Z", tylko odkrywanie, że
trzeba jeszcze dopisać Ź, Ż i Ń.

To ostatnie to jest koszt testerów i ich stanowisk w takiej ilości, jak
potrzeba. Kwestia tylko taka, że exploratory testing nie dotyczy w
szczególny sposób wersji demo/release, tylko jest robione na codziennych
buildach.

> Problem w tym, że tanio to można przetestować bezstanowe funkcje typu
> największy wspólny dzielnik (ale ironicznie, jeszcze łatwiej je
> udowodnić) - wystarczy jednak że w systemie pojawia się współbieżność
> albo efekty pamięciowe (cache) i testy "z automata" można sobie
> wsadzić.

Podaj może przykład, jak ręcznym testowaniem zapobiegasz powyższym
problemom, z którymi nie mogłyby sobie poradzić testy automatyczne.

do góry

On 20/05/2011 09:12, Przemek O. wrote:
> W dniu 2011-05-20 02:45, Andrzej Jarzabek pisze:
>
>> Nie mylę, tylko zwraqcam uwagę na wieloznaczność pojęcia "częściowa
>> funkcjonalność". Funkcjonalność jest częściowa lub nie częściowa
>> względem czegoś, co arbitralnie uznajesz za kompletną funkcjonalnośc.
>> Jeśli przyjmiesz Office 2010 zqa kompletną funkcjonalność pakietu
>> biurowego, to Office 1.0 ma funkcjonalność częściową.
>
> Tak z punktu widzenia wersji 2010. Jednak wersja 1 miała wszystko to co
> było zaplanowane dla wersji 1, a kolejne wersje są jej rozwojem a nie
> dodawaniem funkcjonalności które były zaprojektowane w momencie
> projektowania wersji 1. Czy uważasz że projektując Office'a 1 mieli w
> planach ribbona dodanego w wersji 2007? Jednak mylisz pojęcia.

Uważam, że prawdopodobnie mieli w planach mnóstwo rzeczy, które nie
znalazły się w wersji 1.0, a z których część znalazła się w kolejnych
wersjach, część w międzyczasie została odrzucona bo stały się obsolete,
albo doświadczenia użytkowników z eksploatacji wersji 1.0 wykazały, że
są one niepotrzebne, a część być może nawet teraz jest w planach dla
kolejnej wersji Office.

>> w mniej więcej takim czasie, więc możemy razem zaryzykować, gdzie
>
> Interesów nie robi się "mniej więcej".

Oczywiście, że się robi. Przecież te wszystkie analizy, plany i co tam
jeszcze nie dają 100% pewnych i 100% dokładnych odpowiedzi. Dają
oszacowania, "estimates", a to właśnie znaczy potoczne określenie "mniej
więcej".

>> Przecież nie chodzi o to, że trzeba udowodnić, tylko że zleceniodawca
>> przewiduje takie straty, więc nalega na wpisanie ich do umowy. Tak jak
>> piszesz, w praktyce to się nie dzieje, ale to dlatego, że w praktyce
>> zleceniodawca zwykle bierze część ryzyka na siebie i ewentualnie ponosi
>> część kosztów opóźnień bądź wycofania się z projektu.
>
> Po pierwsze, prowadzenie biznesu jest ryzykiem samym w sobie.

No właśnie!

> Po drugie nikt nie przewiduje strat na podstawie patrzenia w szklaną
> kulę i swojego widzimisie. Więc bajek się do umowy nie wpisuje.

Różne są sposoby przewidywania strat, widzimisię odpowiedniej osoby może
być warte tyle, co miesiące analiz. Ostatecznie oczywiście żadna metoda
nie daje gwarancji poprawnego przewidywania.

>>> Jeśli ma doświadczenie to potrafi to ustalić. Jak nie potrafi to znaczy
>>> że nie ma.
>>
>> Ogólnie to nieprawda, chociaż nie będę się kłócił, że być może w twojej
>> branży tak właśnie jest.
>
> Kurcze facet, bzdurzysz niemiłosiernie. Jeśli ktoś pisał np. kalkulator
> i zajęło mu to x tygodni i kosztowało Y pieniędzy, to napisanie takiego
> samego kalkulatora tylko z różowymi przyciskami zajmie mu tyle samo

No to właśnie mówię: jeśli masz branżę taką, że piszesz takie same
kalkulatory różniące się kolorami przycisków, to być może właśnie tak
jest, jak piszesz.

> czasu + czas na implementacje różowych przycisków i będzie kosztować Y +
> wartość implementacji różowych przycisków.

W znanych mi branżach raczej by się wzięło tamten wcześniej zrobiony
kalkulator, zmieniło kolor przycisków, zrobiło build i wysłało do
testowania/uzupełnienia dokumentacji itd.

> I w każdej branży tak jest, a przewinąłem się przez kilka firm robiących
> oprogramowanie dla różnych branży, od usługowych poprzez produkcyjne do
> handlowych.
> Sytuacja o której piszesz, może być jedynie w sytuacji gdy firma
> specjalizująca się w oprogramowaniu księgowym weźmie zlecenie na np.
> ERP. Fakt, mając ogóle doświadczenie w tworzeniu oprogramowania i zerowe
> w zakresie zarządzania produkcją nie ma możliwości poprawnego
> oszacowania kosztów i czasu.

Być może w branży programów do ERP czy do księgowości robi się tak, że w
kółko pisze się od nowa programy o prawie takiej samej funkcjonalności,
ale tam, gdzie ja pracowałem w takiej sytuacji raczej wykorzystuje się
istniejący program, a development polega na tworzeniu nowej
funkcjonalności, w której (z wyjątkiem szczególnych przypadków) nikt nie
ma doświadczenia, bo istniejące oprogramowanie firmy takiej
funkcjonalności, jakby, nie ma.

Podam ci przykład: pracowałem w firmie tworzącej oprogramowanie dla
instytucji finansowych, kiedy została ogłoszona, a potem weszła w życie
unijna dyrektywa MiFID. Dyrektywa ta miała duży wpływ na działanie wielu
produktów firmy, wymuszając zmiany, ale też dając okazję dodania nowej
funkcjonalności, która wcześniej nie była możliwa. I co się okazało:
nikt nie miał doświadczenia we wdrażaniu funkcjonalności związanej z
MiFID, bo w ogóle nikt na świecie nie miał takiego doświadczenia, jako
że ta dyrektywa wcześniej nie istniała.

Co więcej, do momentu wejścia w życie tej dyrektywy, a nawet już po tym
momencie, żadni analitycy nie byli w stanie przewidzieć wszystkich
konsekwencji MiFID.

>> Tylko koniec końców klient konkurencji miał większe korzyści, bo przez
>> te 9 miesięcy zarobił więcej kasy, niż ty przez swoje dwa.
>
> To wszystko jest gdybanie zależne od funkcjonalności która dostarczył
> ten pierwszy po 9 miesiącach. Jeśli ta funkcjonalność była wystarczająca
> do zarabiania (jak to piszesz) to reszta jest w ogóle niepotrzebna.

Bo jak już ktoś zarabia milion, to po co mu jeszcze kolejne 3 miliony,
prawda?

>>> Pewnie, wszystko można spierniczyć, ale bez projektu jest to
>>> zdecydowanie prostsze.
>> Nie zgodzę się.
>
> Jesteś fenomenem. Łatwiej trafić do celu z mapą czy bez?

Zależy. Na pewno mapa rysowana przez kogoś, kto sam do tego celu nie
dotarł i bez żadnych informacji od kogokolwiek, kto dotarł, może mieć
wątpliwą wartość.

>> No i tak samo wiarygodne estymaty czasu i budżetu programu z danym
>> zestawem wymagań dadzą ci tylko ci, którzy robili program z dokładnie
>> takim samym zestawem wymagań.
>
> No a o czym ja cały czas pisze? Różne hipotezy są do siebie niepodobne
> (czyli nie mają wspólnych cząstkowych - tak przynajmniej zakładam, bo
> się na tym nie znam) więc nikt nie robił niczego podobnego, stąd nikt
> nie jest w stanie nawet w przybliżeniu podać tych wartości.

Dlaczego? Oczywiście, że istnieją podobne do siebie hipotezy. I czasem
jest tak, że podobna hipoteza daje się udowodnić w dwa miesiące, a
udowodnienie tej właściwej zajmuje 300 lat

> Natomiast jeśli ktoś robił oprogramowanie zarządzające produkcją w
> firmie X, to z dużym prawdopodobieństwem poda realne terminy wykonania i
> koszty zarządzania produkcją dla firmy Y, gdzie wymagania różnią się
> jedynie specyfiką ścieżki produkcji.

Nie znam się kompletnie na oprogramowaniu zarządzającym produkcją. Mam
natomiast doświadczenie z tym, że buduje się nowe systemy albo
rozbudowuje istniejące o jakościowo nową funkcjonalność, często taką,
jakiej dana firma nigdy nie tworzyła.

>> To ty sobie poczytaj o tym, co robiło Apple w momencie, kiedy im
>> pokazano Xerox PARC Alto. I wytłumacz mi, jak to się mogło stać, że
>> Xerox, w końcu poważna spółka akcyjna, zainicjowała i przeprowadziła
>> development nowego projektu nigdy nie zdając sobie sprawy, że siedzą na
>> żyle złota. Czyżby nie potrafili wykonać prostej analizu potrzeb rynku?
>
> Inna sytuacja gospodarcza, inny poziom rozwoju technologii. My piszemy o
> sprawach dla nas oczywistych, gdzie oprogramowania jako takiego jest na
> pęczki. Komputerów na tamten moment (lub maszyn "podobnych") było tyle,
> że można było na palcach policzyć.

Ale weź naprawdę cokolwiek o tym przeczytaj, zanim będziesz dalej brnąć
w te bzdury. Choćby stronę w Wikipedii.

Prawdą jest oczywiście, że poziom rozwoju technologii jest inny, ale też
dzisiaj raczej nie tworzy się od zera GUI o funkcjonalności Xerox Alto.
Tworzy się nowe programy, robiące nowe rzeczy, które często bywają
nieoczywiste.

> Tak samo jak w czasach dzisiejszych
> wielka korporacja zbudowałaby teleport wielkości hangaru, za kwotę 9
> zerową - raczej interesu na tym by nie zrobiła, ale jak jakiś Woźniak
> zrobiłby coś podobnego wielkości garażu i za kwotę 5 zerową, to nawet
> jeśli teleportowałby 9 / 10 osób (ta jedna by nie wracała) to jeśli
> byłby popyt na tego rodzaju sprzęt to zarobiłby ogromną kasę.
> I celowo piszę tu o fantazji typu teleport, bo mniej więcej tym samym
> dla przeciętnego człowieka w tamtych czasach był komputer.

To może przypomnij mi, na czym Apple się tak rozrosło, że w 1980 roku
weszło na giełdę?

>> Jakich odpowiedników? Mówisz o tabletowych pecetach, które były na rynku
>> przed iPadem, czy wchodzącej narynek fali tabletów imitujących iPada?
>
> Tablety mają o wiele większą funkcjonalność i nie porównuję do nich.

iPad to jest tablet.

> I tak, po części piszę o tych, jak to nazywasz "imitacjach".

Zauważ zatem, że zanim iPad wszedł na rynek, to tych imitacji nie było.
A teraz nagle każdy i jego stryjek wypuszcza swojego tableta imitującego
iPada na rynek. Jak to się zatem stało, że tylko Apple było w stanie
przewidzieć zapotrzebowanie na tego typu produkty, skoro analiza rynku
to ujawnia?

> Szkoda tylko,
> że "imitacje" są na wyższym poziomie technologicznym, a do tego są o
> połowę tańsze. Szkoda też za Apple zerżnęło design zarówno urządzenia i
> systemu pierwotnego (iPhone) z Samsunga. No ale cóż, lepszy marketing i
> logo obgryzionego jabłka zobowiązuje.

Może jednak rozważysz możliwość, że pewne istotne aspekty ci umykają.

>> Bardzo prosto. Apple po prostu zrobiło analizę potrzeb rynku, na co nikt
>> inny nie wpadł, zapewne dlatego, że firmy próbujące wprowadzać wcześniej
>> tablet PC są kiepsko zarządzane.
>
> Tablet PC i iPad jest kierowany do innego klienta docelowego.

No i co? Żadna z firm produkujących tablet PC nie przeprowadziła analizy
potrzeb rynku, która by wykazała do jakiego klienta trzeba kierować żeby
zarobić?

>>> Z każdym następnym projektem lepiej.
>>
>> To może u was w firmie, bo jeśli chodzi o całość branży to nie jest tak
>> fajnie, czego efektem modele iteracyjne i również agile.
>
> Model kaskadowy też jest w wersji iteracyjnej.

Nie chcę się z tobą kłócić, co oznacza "model kaskadowy", ale określenia
"waterfall" często używa się właśnie do modelu bez iteracji.

>> Ale to tylko przenosi ryzyko na zleceniodawce. Zleceniodawca szuka więc
>> wykonawcy do programu, który mu jest potrzebny, więc robi analizę u
>> pierwszego wykonawcy i dostaje cenę nie do przyjęcia, robi u drugiego
>> wykonawcy i dostaje termin nie do przyjęcia, robi u trzeciego i dostaje
>> propozycję kar za opóźnienie nie do przyjęcia, robi u czwartego i
>> czwarty proponuje formy konktraktów nie dające odpowiednich gwarancji.
>> Stwierdza więc, że nie chce jednak zamawiać tego programu, a tymczasem
>> stracił już x milionów na te wszystkie analizy.
>
> Nie, bo analiza jest własnością zleceniodawcy. Tak więc robi się ja
> tylko raz.

No to masz odpowiedź, jak można w takiej sytuacji stosować agile. Masz
klienta, który zgodzi się zapłacić za analizę która by trwała np. dwa
miesiące, zakładając że jakaś wizja już na tym etapie istnieje (bo
przecież uzgadniacie czego ma to być analiza). Uzgadniasz z klientem, że
udostępni ci swoich przedstawicieli na potrzeby wynokania tej analizy, i
wokół tego zaczynasz budować zespół agile: na tym etapie będziesz
potrzebował analityków i programistów. Bierzesz wszystkich do kupy,
przedstawiasz wizję i zaczynasz planować iteracje. Po dwóch miesiącach
masz nie tylko analizę, ale już masz "working software", masz
programistów, którzy rozumieją co program ma robić, którzy mieli okazję
zapoznać się z poszczególnymi zidentyfikowanymi kawałkami
funkcjonalności, zidentyfikować część potencjalnych problemów
implementacyjnych, których analityk mógłby nie zauważyć (choćby dlatego,
że nie rozumie co to jest "złożoność wykładnicza"), masz gotową
infrastrukturę (source control, integration server, stanowiska,
narzędzia). Masz wymagania spisane przez analityków, w które też wchodzi
cenny feedback z użytkowania prototypów przez customerów, massz
zidentyfikowane MMF, customer representatives mają w tym momencie dobrą
orientację co do ważności features/stories, a twoi programiści co do
tego, jak trudne te fragmenty będą do zaimplementowania. Masz wyznaczone
velocity, a to znaczy, że w ostatniej fazie możesz zrobić planowanie
release'ów mając dobre estymaty co do scope i czasu wykonania dla dwóch
pierwszych wersji.

Co więcej, dzięki feedbackowi między zleceniodawcą, customer
representatives i tobą, zleceniodawca wie, że masz koncepcję produktu (w
postaci działającego demo), która mu się podoba, wie jaki masz proces,
wie że i w jaki sposób są uwzględniane uwagi jego customer
representatives, wie, że starasz się zrozumieć jego potrzeby i jak do
tego podchodzisz. W skrócie - o ile nie spierdoliłeś sprawy - masz
zbudowaną relację zaufania.

do góry

On 20/05/2011 08:35, Michal Kleczek wrote:
> Andrzej Jarzabek wrote:
>
>> Oczywiście, że każda iteracja jest testowana od A do Z. Automatycznie.
>
> Sek w tym, ze to jest tylko _udawanie_ testowania. Nie da sie _dobrze_
> przetestowac niebanalnego oprogramowania w czasie jednej iteracji (o
> dlugosci proponowanej przez "agile").

Dlatego testuje się przez _wszystkie_ iteracje. Np. jeśli masz release
po trzech miesiącach od rozpoczęcia kodowania, to to, co masz w tym
release jest już testowane od trzech miesięcy.

Problem z testowaniem "od A do Z" polega na tym, że metaforycznie masz
swoje A, swoje Z i jakieś literki pomiędzy, ale nie wiesz ile w ogóle
jest literek w alfabecie. W dodatku alfabet zmienia się w miarę rozwoju
oprogramowania. Dlatego też wszystkie literki, o których wiesz,
testujesz automatycznie za każdą iteracją, a może nawet codziennie, ale
cały czas masz równolegle tesowanie ręczne polegające na szukaniu, czy
są jeszcze jakieś literki między A i Z, o których się nie pomyślało.

> Co wiecej - trzeba sobie zdac sprawe z tego, ze _prawdziwe_ testowanie b.
> duzo kosztuje (nie tylko ze wzgledu na czas, lecz takze ze wzgledu na
> zasoby, ktore sa potrzebne do tego).

Jasne.

> I dalej - ze wzgledu na te koszty nie
> mozna sobie pozwolic na to, zeby robic to zbyt czesto

Jak się robi porządnie, to się ma przeznaczone zasoby tylko do
testowania danego produktu. Jak go nie testujesz, to te zasoby leżą
odłogiem i kosztują z grubsza tyle samo.

> - stad stosuje sie metody pozwalajace _unikac_ bledow (a nie je wykrywac i
> poprawiac) - to jest po prostu tansze i - co wiecej - pozwala osiagnac
> jakosc, ktorej nie da sie osiagnac testujac/poprawiajac.

Jak najbardziej. Z tym że jednak wykrywać i poprawiać należy również.

Ale w Agile jak najbardziej zwraca się bardzo dużą uwagę na praktyki
pozwalające na unikanie błędów: coding standards, refactoring, simple
design itd.

> Tyle, ze te metody prowadza - mniej lub bardziej - do modelu kaskadowego

Właśnie niekoniecznie.

> (ew. do powaznego wydluzenia iteracji).

Też niekoniecznie. Shore&Warden proponują iteracjęę trwającą tydzieeń i
rygoorystyczne trzymanie się tego.

> Np. unikanie bledow w rozpoznaniu wymagan polega na _dokladniejszym_
> wyspecyfikowaniu tych wymagan i _dokladniejszej_ weryfikacji specyfikacji

Agile proponuje dokładniejszą specyfikację uzyskać w ten sposób, że
programista jak nie wie co dalej robić, to rozmawia z customerem (lub
analitykiem) i on mu to specyfikuje. Jako metodę dokładniejszej
weryfikacji proponuje się pokazanie customerowi działającego prototypu i
spytanie czy właśnie o to chodziło.

> - nie oplaca sie robic oprogramowania _zanim_ sie skonczy specyfikacje,
> bo to strata czasu i pieniedzy na robienie czegos, co potencjalnie
nie jest
> nikomu potrzebne.

Przecież to, co jest w specyfikacji też potencjalnie nie jest nikomu
potrzebne. Na szybko z co najmniej dwóch powodów:
a) było potrzebne w momencie tworzenia specyfikacji, ale już nie jest
b) nigdy nie było potrzebne, ale analityk popełnił błąd i wpisał, bo
uznał że potrzebne.

W agile masz tę zaletę, że najdalej na początku danej iteracji, w której
to coś jest implementowane, customer potwierdził że tak, na pewno jest
potrzebne, a co więcej jest to jedna z najważniejszych rzeczy, jakie
zostały do zrobienia.

> I to, ze w ramach analizy wymagan robi sie prototypy, nie powoduje
> automatycznie, ze te prototypy staja sie gotowym produktem

Co to znaczy "stają się"? Że są w takiej postaci releasowane? Nikt tego
nie postuluje. Staje się, w sensie że jest wykorzystywany do tworzenia
produktu, owszem. Przy wszystkich krytykach do agilee, że to czy tamto
jest wyrzucaniem pieniędzy, to pisanie działającego programu, który robi
to co trzeba, po to, żeby go wyrzucić i napisać to samo od nowa też jest
jednak marnowaniem pieniędzy.

> - a to znowu z
> tego powodu, ze prototypy robi sie najtaniej jak mozna i ich jakosc jest
> daleka od jakosci oczekiwanej od produktu koncowego. Nie ma tez sensu nawet

Tu jest trochę fałszywe założenie, że taniej jest pisać kod niższej
jakości od kodu wysokiej jakości. Może być tańsze tylko o tyle, że
możesz do tego wykorzystywać słabszych programistów którym gorzej
płacisz, ale to raczej nie jest szczególnie dobre podejście do agile.

Poza tym do wyrównywania (w górę) poziomu kodu masz takie praktyki jak
coding standards, collective code ownership i pair programming (lub code
review).

Są też co prawda sytuacje, gdzie ma sens pisanie throwaway code, bo z
jakichś tam powodów łatwo jest zrobić jakiś prototyp, a trudno go
będziee wcielić do produktu końcowego (bo jest np. wykonany w jakiejś
niekompatybilnej technologii). I metodologie agile przecież też tego nie
zabraniają, co najwyżej lekko zniechęcają (na zasadzie jeśli nie masz
realnych problemów, żeby zrobić inaczej, to zrób raczej tak, żeby się
nadawało do produkcji albo przynajmniej do refaktoryzacji).

> probowac, by te prototypy mialy konstrukcje i jakosc produktu koncowego, bo

Oczywiście, że nie. Po to masz refactoring.

> U podstaw "metodyk agile" lezy (mniej lub bardziej jawne) zalozenie, ze da
> sie tak robic oprogramowanie, ze koszt jego modyfikacji nie wzrasta w miare
> jego rozrastania sie. Co jest zalozeniem po prostu absurdalnym - jezeli np.
> na poczatku podejmiemy decyzje o tworzeniu tego oprogramowania dajmy na to w
> C# (bo zespol uznal, ze tak najlepiej) a potem okaze sie, ze klient
> zapomnial nam powiedziec o tym, ze to ma dzialac na Solarisie (z jakichs tam
> powodow), to jak niby mamy zrobic "refaktoring" nie przepisujac tego
> oprogramowania w calosci???

No moment, ale pracujemy przecież cały czas z klientem. Czyli jest
powiedzmy wczesne zebranie zespołu, na którym siedzi customer
representative, i jest rozmowa o tym, w jakiej technologii wykonać.
Jeśli pada propozycja C#, to raczej padnie pytanie, czy można na pewno
założyć, że produkt będzie pod .NET, a .NET jest tylko pod Windows
(istnienie Mono na potrzeby dyskusji pominiemy). Od przedstawiciela
klienta raczej będzie się w tym momencie wymagało potwierdzenia, że
można takie założenie poczynić no i oczywiście trafia to do bieżącej
dokumentacji projektu. Jeśli klient potem zmieni zdanie, to mu można w
tej sytuacji powiedzieć, że nie zrobimy albo że trzeba będzie to z
punktu widzenia terminów i kosztóww potraktować jako robienie od nowa.

do góry

Andrzej Jarzabek wrote:

> On 20/05/2011 08:35, Michal Kleczek wrote:
>> Andrzej Jarzabek wrote:
>>
>>> Oczywiście, że każda iteracja jest testowana od A do Z. Automatycznie.
>>
>> Sek w tym, ze to jest tylko _udawanie_ testowania. Nie da sie _dobrze_
>> przetestowac niebanalnego oprogramowania w czasie jednej iteracji (o
>> dlugosci proponowanej przez "agile").
>
> Dlatego testuje się przez _wszystkie_ iteracje. Np. jeśli masz release
> po trzech miesiącach od rozpoczęcia kodowania, to to, co masz w tym
> release jest już testowane od trzech miesięcy.

Jak mozesz miec "juz przetestowana" calosc skoro wlasnie zakonczyles n-ta
iteracje i dolozyles funkcjonalnosc. To sie da tak robic jak twoj zestaw
testow da sie wykonac w ciagu 15 minut. Taki zestaw testow to sobie w dupe
mozna wsadzic. _Realne_ testowanie to jest takie, ze _automatyczne_ (nie
manualne) testy trwaja na tyle dlugo, ze nie da sie tego robic "na biezaco",
bo wstrzymywaloby to zbyt dlugo prace programistow (np. kilka dni).
Jezeli takie testy maja sie odbywac "non stop", to oznacza, ze release'y
musisz robic w cyklach rownych dlugosci trwania testow. A jesli trafi ci sie
blad tzw. "krytyczny", ktory stopuje testowanie w polowie, to co robisz?
Masz dwa wyjscia:
1) Czekasz na kolejny release (co oznacza, ze przestajesz testowac _ten_
release)
2) Robisz galaz rownolegla do biezacego developmentu i poprawiasz ten blad i
odpalasz testy od poczatku. Tyle, ze wtedy albo
a) nastepna iteracja nie jest testowana (bo pojawia sie zanim testy
poprzedniej sie skoncza) - co de facto oznacza po prostu wydluzenie iteracji
(a co jesli w drugim podejsciu znajdziemy drugi taki blad)
b) testujesz rownolegle dwie (lub wiecej) iteracje-releasy (jesli to w ogole
mozliwe) ze wszystkimi konsekwencjami utrzymywania wielu galezi, mergy,
regresji itd - i tak sie robi, ale zeby nie zapanowal chaos releasy nie moga
byc zbyt czesto

>
> Problem z testowaniem "od A do Z" polega na tym, że metaforycznie masz
> swoje A, swoje Z i jakieś literki pomiędzy, ale nie wiesz ile w ogóle
> jest literek w alfabecie.

To do cholery jak przygotujesz testy jak nie wiesz co masz testowac?

> W dodatku alfabet zmienia się w miarę rozwoju
> oprogramowania. Dlatego też wszystkie literki, o których wiesz,
> testujesz automatycznie za każdą iteracją, a może nawet codziennie,

Patrz wyzej - nie da sie tego porzadnie zrobic "codziennie".

> ale
> cały czas masz równolegle tesowanie ręczne polegające na szukaniu, czy
> są jeszcze jakieś literki między A i Z, o których się nie pomyślało.
>
>> Co wiecej - trzeba sobie zdac sprawe z tego, ze _prawdziwe_ testowanie b.
>> duzo kosztuje (nie tylko ze wzgledu na czas, lecz takze ze wzgledu na
>> zasoby, ktore sa potrzebne do tego).
>
> Jasne.
>
>> I dalej - ze wzgledu na te koszty nie
>> mozna sobie pozwolic na to, zeby robic to zbyt czesto
>
> Jak się robi porządnie, to się ma przeznaczone zasoby tylko do
> testowania danego produktu. Jak go nie testujesz, to te zasoby leżą
> odłogiem i kosztują z grubsza tyle samo.

Normalnie (nie "agile") tobi sie to tak, ze masz oddzielny zespol tzw. QA
(moze byc nawet outsourcing), ktory obsluguje ci kilka produktow. Taki QA
nie kiwnie nawet palcem, jak mu nie dasz analizy wymagan, bo niby na jakiej
podstawie ma przygotowac testy?

>
>> - stad stosuje sie metody pozwalajace _unikac_ bledow (a nie je wykrywac
>> i poprawiac) - to jest po prostu tansze i - co wiecej - pozwala osiagnac
> > jakosc, ktorej nie da sie osiagnac testujac/poprawiajac.
>
> Jak najbardziej. Z tym że jednak wykrywać i poprawiać należy również.
>
> Ale w Agile jak najbardziej zwraca się bardzo dużą uwagę na praktyki
> pozwalające na unikanie błędów: coding standards, refactoring, simple
> design itd.
>
>> Tyle, ze te metody prowadza - mniej lub bardziej - do modelu kaskadowego
>
> Właśnie niekoniecznie.
>
>> (ew. do powaznego wydluzenia iteracji).
>
> Też niekoniecznie. Shore&Warden proponują iteracjęę trwającą tydzieeń i
> rygoorystyczne trzymanie się tego.
>
>> Np. unikanie bledow w rozpoznaniu wymagan polega na _dokladniejszym_
> > wyspecyfikowaniu tych wymagan i _dokladniejszej_ weryfikacji
> > specyfikacji
>
> Agile proponuje dokładniejszą specyfikację uzyskać w ten sposób, że
> programista jak nie wie co dalej robić, to rozmawia z customerem (lub
> analitykiem) i on mu to specyfikuje.

O! pojawia sie analityk... Czy to nadal jeszcze "agile"?
A skad "analityk" wie, co chce klient? Pewnie robi "analize"? To ja zapytam
- kiedy robi te analize? Bo przeciez musi byc "on site" z programistami,
zeby mogl z nimi "rozmawiac" - znaczy "analize" wykonal wczesniej. Cos mi
pachnie "kaskada".

> Jako metodę dokładniejszej
> weryfikacji proponuje się pokazanie customerowi działającego prototypu i
> spytanie czy właśnie o to chodziło.
>

To "prototypu", czy tez "produktu"? Bo jezeli "prototypu" to po ch... tracic
pieniadze na np. "pair programming" zeby go przygotowac?

> > - nie oplaca sie robic oprogramowania _zanim_ sie skonczy specyfikacje,
> > bo to strata czasu i pieniedzy na robienie czegos, co potencjalnie
> nie jest
> > nikomu potrzebne.
>
> Przecież to, co jest w specyfikacji też potencjalnie nie jest nikomu
> potrzebne. Na szybko z co najmniej dwóch powodów:
> a) było potrzebne w momencie tworzenia specyfikacji, ale już nie jest
> b) nigdy nie było potrzebne, ale analityk popełnił błąd i wpisał, bo
> uznał że potrzebne.
>

Obydwa przypadki sprowadzaja sie do tego, ze popelniono blad w trakcie
analizy wymagan. Oczywiscie - zdarza sie. Ale to nie jest tak, ze skoro
analiza wymagan jest trudna, to po prostu nie robmy analizy wymagan, za to
"robmy produkt i zobaczymy czy bedzie dobry" (co jak rozumiem proponuje
"agile").

> W agile masz tę zaletę, że najdalej na początku danej iteracji, w której
> to coś jest implementowane, customer potwierdził że tak, na pewno jest
> potrzebne, a co więcej jest to jedna z najważniejszych rzeczy, jakie
> zostały do zrobienia.

I projekt trwa bez konca... Ew. konczy jak c2 (tak, tak - pierwszy projekt
XP) - czyli przychodzi ktos z gory i go brutalnie przerywa.

>
>> I to, ze w ramach analizy wymagan robi sie prototypy, nie powoduje
>> automatycznie, ze te prototypy staja sie gotowym produktem
>
> Co to znaczy "stają się"? Że są w takiej postaci releasowane? Nikt tego
> nie postuluje. Staje się, w sensie że jest wykorzystywany do tworzenia
> produktu, owszem. Przy wszystkich krytykach do agilee, że to czy tamto
> jest wyrzucaniem pieniędzy, to pisanie działającego programu, który robi
> to co trzeba, po to, żeby go wyrzucić i napisać to samo od nowa też jest
> jednak marnowaniem pieniędzy.
>

Jest roznica, miedzy "prototypem" i "dzialajacym programem". Wytworzenie
"prototypu" jest nieporownywalnie _tansze_ niz wytworzenie "dzialajacego
programu".

>> - a to znowu z
>> tego powodu, ze prototypy robi sie najtaniej jak mozna i ich jakosc jest
>> daleka od jakosci oczekiwanej od produktu koncowego. Nie ma tez sensu
>> nawet
>
> Tu jest trochę fałszywe założenie, że taniej jest pisać kod niższej
> jakości od kodu wysokiej jakości.

Drozej jest?

> Może być tańsze tylko o tyle, że
> możesz do tego wykorzystywać słabszych programistów którym gorzej
> płacisz,

Albo, ze dobry programista robi "na kolanie" prototyp w 15 min, zeby go
pokazac i omowic, po czym wyrzucic.

> ale to raczej nie jest szczególnie dobre podejście do agile.
>
> Poza tym do wyrównywania (w górę) poziomu kodu masz takie praktyki jak
> coding standards, collective code ownership i pair programming (lub code
> review).

Ale po co je stosowac do czegos, co i tak zaraz przepiszemy od nowa?

[ciach]
>
> Oczywiście, że nie. Po to masz refactoring.
>
>> U podstaw "metodyk agile" lezy (mniej lub bardziej jawne) zalozenie, ze
>> da sie tak robic oprogramowanie, ze koszt jego modyfikacji nie wzrasta w
>> miare jego rozrastania sie. Co jest zalozeniem po prostu absurdalnym -
>> jezeli np. na poczatku podejmiemy decyzje o tworzeniu tego oprogramowania
>> dajmy na to w C# (bo zespol uznal, ze tak najlepiej) a potem okaze sie,
>> ze klient zapomnial nam powiedziec o tym, ze to ma dzialac na Solarisie
>> (z jakichs tam powodow), to jak niby mamy zrobic "refaktoring" nie
>> przepisujac tego oprogramowania w calosci???
>
> No moment, ale pracujemy przecież cały czas z klientem. Czyli jest
> powiedzmy wczesne zebranie zespołu, na którym siedzi customer
> representative, i jest rozmowa o tym, w jakiej technologii wykonać.
> Jeśli pada propozycja C#, to raczej padnie pytanie, czy można na pewno
> założyć, że produkt będzie pod .NET, a .NET jest tylko pod Windows
> (istnienie Mono na potrzeby dyskusji pominiemy). Od przedstawiciela
> klienta raczej będzie się w tym momencie wymagało potwierdzenia, że
> można takie założenie poczynić no i oczywiście trafia to do bieżącej
> dokumentacji projektu. Jeśli klient potem zmieni zdanie, to mu można w
> tej sytuacji powiedzieć, że nie zrobimy albo że trzeba będzie to z
> punktu widzenia terminów i kosztóww potraktować jako robienie od nowa.

To byl tylko przyklad _jednej_ decyzji, ktora musisz podjac. Problem nie
lezy w tym, ze kazdy taki problem jest trudny, tylko ze tych problemow jest
duzo.

Bo takich decyzji projektowych, ktore trzeba podjac na poczatku (zeby w
ogole mozna bylo zaczac programowac) i ktorych odwrocenie bedzie pozniej
kosztowne jest cale multum. Czynnikow, ktore je determinuja tez jest cale
multum.
Wiara w to, ze mozna je wszystkie podjac na podstawie lub w czasie
polgodzinnej "rozmowy" z "customerem" jest doprawdy naiwna.

--
Michal

do góry

> sporo); ilu moze byc programistow w polsce - ze sto tysiecy moze?
> na swiecie? kilka milionow?


na świecie sądze że około 45 463 352

w polsce 1/3 społeczeństwa, wszyscy myślą że sa programistami

Rf

do góry

W dniu 2011-05-18 11:04, Andrzej Jarzabek pisze:
> On May 18, 7:02 am, Zenek1234<z...@1...pl> wrote:
>> W dniu 2011-05-18 01:58, R. P. pisze:
>>
>>> Dodam, że duża część ludzi zatrudnionych w Google to właśnie lauraci
>>> takich konkursów algorytmicznych jak "Potyczki" itp. A jak wiemy google
>>> jest nielichą firmą i tworzy nieliche rzeczy. To tak na popracie mojej
>>> tezy.
>>
>> Jaka jest średnia wieku ludzi zatrudnianych przez G. ?
>
> Nie wiem.
>
>> Podobno b. niska, nie przekraczająca 30 lat.
>> I co się dalej z nimi dzieje?
>
> Co to znaczy "dalej"? Jakoś nie słyszałem, żeby Google zwalniało ludzi

Bo niby od kogo miałbyś usłyszeć? :)
Google jak i żadna inna korporacja się tym nie chwali.
Dlatego nasunęło mi się takie pytanie.

> z powodu wieku, myślę też, że jak ktoś pracował w Google jako
> programista, to nie będzie miał po odejściu problemów ze znalezieniem
> pracy.

"Dalej", czyli po zakończeniu kariery w firmie, która poszukuje zwykle
młodych i dynamicznych.


>> Jaka w ogóle jest średnia wieku programisty?
>
> Kto to wie?

Ściślej, programisty czynnego zawodowo.
Dla porównania: w Polsce i w cywilizowanym świecie, np. USA. ;)



>> I jak się kształtuje najczęściej ścieżka kariery takiego
>> programisty po 50-tce?
>
> Zgadywałbym, że najczęściej kosi grubą kasę jako jeden z nielicznych

Jeśli jeden z nielicznych, to nie najczęściej. :)

> specjalistów od jakiejś egzotycznej technologii czy produktu,
> ewentualnie kieruje zespołem, ewentualnie odłożył kasę i założył swoją
> firmę.

Nieliczni.

>> Czy zastanawialiście się, co będziecie robić w tym wieku?
>
> W jakim celu?

Choćby po to, żeby zastanowić się nad sensem życia i tego, czy spełniamy
się zawodowo, wykonując taki oto zawód.


Z.

do góry

W dniu 2011-05-21 09:27, Rafal(sxat) pisze:
>> sporo); ilu moze byc programistow w polsce - ze sto tysiecy moze?
>> na swiecie? kilka milionow?
>
>
> na świecie sądze że około 45 463 352
>
> w polsce 1/3 społeczeństwa, wszyscy myślą że sa programistami

programista - to brzmi dumnie

do góry

On 21 Maj, 00:29, Andrzej Jarzabek <a...@g...com> wrote:

> > Problem w tym, że tanio to można przetestować bezstanowe funkcje typu
> > największy wspólny dzielnik (ale ironicznie, jeszcze łatwiej je
> > udowodnić) - wystarczy jednak że w systemie pojawia się współbieżność
> > albo efekty pamięciowe (cache) i testy "z automata" można sobie
> > wsadzić.
>
> Podaj może przykład, jak ręcznym testowaniem zapobiegasz powyższym
> problemom,

Nie zapobiegam im ani testami z automata ani ręcznymi.

Bo się nie da. Przynajmniej nikogo w tym nie oszukuję, ani siebie, ani
klienta.

Temat na anegdotę: w projekcie YAMI4 wszystkie (ok, oprócz jednego)
bugi wykryte po wersji 1.0.0 były w kodzie, który był pokryty przez
unit-testy. Tzn. ta konkretna linijka, w której był błąd, była
wykonana co najmniej raz przez jeden z testów, które są częścią
projektu. Te testy można odpalać "z automata".

Co to znaczy? To znaczy, że te testy były do dupy i dawały wszystkim
fałszywe poczucie bezpieczeństwa - dlatego miara pokrycia testów nie
ma żadnej użytecznej interpretacji[*].

Wybij sobie z głowy taki pomysł, że jakakolwiek (pseudo)metodologia
pozwoli niedoświadczonym ludziom robić dobre projekty. Dotyczy to
każdej dziedziny inżynierskiej, nie tylko IT. Doświadczenia nie da się
niczym zastąpić a jeśli już to doświadczenie jest, to należy z niego
skorzystać przy planowaniu co i jak należy zrobić.
Zysk z dobrego planowania jest większy, niż z testowania przy
porównywalnym wkładzie pracy i właśnie dlatego bardziej cenię sobie
dobrze przemyślany projekt (wspomniany już "papier" jako faza
wstępna), niż testy.
Testy, oczywiście, są. Ale jak już pisałem - bywa, że są do dupy i
dają fałszywe poczucie bezpieczeństwa.
Problem z agile/xp/itd. polega na tym, że niestety nie daje żadnych
kryteriów oceny ani obrony przed taką możliwością a przez to prowadzi
do fałszywego poczucia bezpieczeństwa.

[*] więcej:

http://www.inspirel.com/articles/Mythical_Code_Cover
age.html

--
Maciej Sobczak * http://www.msobczak.com * http://www.inspirel.com

do góry

W dniu 2011-05-21 10:46, yassek pisze:
> W dniu 2011-05-21 09:27, Rafal(sxat) pisze:
>>> sporo); ilu moze byc programistow w polsce - ze sto tysiecy moze?
>>> na swiecie? kilka milionow?
>>
>>
>> na świecie sądze że około 45 463 352
>>
>> w polsce 1/3 społeczeństwa, wszyscy myślą że sa programistami
>
> programista - to brzmi dumnie

Raczej żałośnie (w kontekście tego wątku). ;)

do góry