W dniu 2011-05-15 20:49, A.L. pisze:

> Zbyt wielu - NIEKOMPETENTNYCH
>
> Kompetentnych - zbyt malo.

Nic odkrywczego. We wszystkim tak jest, że 80% wszystkiego to badziew.

> Dlatego mimo pol tuzina owtartch pozycji i chyba z 50 interviews
> pozycje sa ciagle nieobsadzone
>
> A.L.

Z twojego punku widzenia tak to może wyglądać.
Być może na "kretynów", którzy wymagają 100.000$ rocznie nie stać was?
Lub szukacie nie w tej "kategorii"...? :)

Czy mógłbyś podać przykład oferty?


Z.

do góry

On 21/05/2011 07:51, Michal Kleczek wrote:
> Andrzej Jarzabek wrote:
>>
>> 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.

Każda funkcjonalność jest testowana w każdej iteracji od momentu jej
zaimplementowania, bo najpierw się pisze test, a potem implementację.

> To sie da tak robic jak twoj zestaw testow da sie wykonac w ciagu 15 minut.

To oczywiście zależy od produktu.

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

To zależy od produktu. Generalnie im więcej funkcjonalności, tym dłużej
trwają testy, ale wiele produktów w stanie release można automatycznie
przetestować przez noc, więc jeśli codziennie robisz build/integrację,
to możesz go testować przez noc.

Jeśli nie dasz rady zrobić wszystkich testów przez noc, to możesz
wyizolować, które testy mają kiepski stosunek czasu do
prawdopodobieństwa faila, i te testy robisz tylko raz na iterację. Jeśli
dwa-trzy dni wystarczą, to w niektórych krajach jest takie coś, jak weekend.

Ostatecznie też nie jest tak, że jak się robią automatyczne testy, to
programiści muszą siedzieć na rękach. Możesz spokojnie ustalić proces
tak, że testy się wykonują, a programiści już kodują nowe testy i nowe
ficzery.

Zakładając jednak, że masz mały zespół w którym jest najwyżej 9
programistów, to zanim dojdziesz do etapu, gdzie automatyczne testy
trwają tydzień, to upłynie sporo wody (to oczywiście zależy od specyfiki
produktu, ale typowo tak jest). Ponieważ cały czas rewidujesz proces, to
zanim do tego dojdzie zespół będzie mógł zdecydować, co z tym zrobić.
OPcji jest kilka:
* Zrównoleglić testy
* Wydłużyć iterację (owszem, generalnie metodologie z krótką iteracją
uznają, że w dojrzałych produktach w części przypadków wydłużenie
iteracji ma sens)
* Podzielić produkt
* Zmienić proces tak, że między zakończeniem iteracji a "ready to
release" trwa tydzień.

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

Od razu: "ready to release" nie oznacza "robisz release".

Jeśli któryś test failuje, to dana iteracja nie jest "ready to release".

> 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

Przede wszystkim tak: jeśli masz buga w danej iteracji, to naprawienie
tego buga staje się absolutnym priorytetem. Jeśli ma to sens, to
wsztrzymujesz pracę nad nowymi stories do czasu naprawienia buga,
ewentualnie możesz wstrzmać część nowych prac i zabronić dodawania
czegokolwiek, co ma potencjał do konfliktu z bugfixem. Jeśli nie chcesz
tracić czasu i chcesz, żeby programiści nie zajmujący się naprawianiem
buga pracowali nad swoimi stories, to mogą robić to na robiczym branchu.

Po drugie: jak naprawiasz buga, to naprawiasz go tak, żeby był
naprawiony we wszystkich kolejnych iteracjach, a nie tylko w tej jednej,
w której został znaleziony.

Po trzecie: istotnym priorytetem jest to, żeby bugi były wyjątkiem, a
nie regułą. Jeśli bugi są na tyle częste, że regularnie musisz opóźniać
release, odwoływać demo lub ogłaszać, że dana iteracja nie jest "ready
to release", to masz problem gdziee indziej. Robisz wtedy root cause
analysis i zajmujesz się naprawą przyczyny tego stanu rzeczy.

Biorąc pod uwagę powyższe, zazwyczaj możesz zrobić tak, że wyrzucasz
builda z poprzedniej iteracji i pracujesz nad naprawieniem buga w
bieżącej iteracji, zachowując wszystkie stories, które są już zakończone
i decydując case-by-case o tym, czy stories które są zaplanowane lub w
trakcie będziesz nadal próbował zrealizować w aktualnej iteracji, czy
odłożysz do następnej. Jeśli nie masz kompletnie spierdzielonego
procesu, to naprawienie buga znalezionego w n-tej iteracji powoduje, że
n+1 iteracja nie ma buga, więc jesteś ready to release.

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

Co to znaczy "nie wiesz, co testować"? Jeśli zrobisz dokładną analizę,
to masz w tej analizie absolutnie kompletny zestaw testów, który
gwarantuje jakość produkcyjną? Włącznie z testowaniem na problemy
wynikające ze współbieżności, performance test itd.?

W metodologiach agile każda iteracja jest planowana, więc na początku
każdej iteracji wiesz, co w tej iteracji jest do zrobienia, i na każdą z
tych rzeczy piszesz testy. Problem masz taki, że przecież w ten sposób
nie wyłapiesz przecież wszystkich potencjalnych problemów wynikających
np. ze współbieżności, performance, niespodziewanych zachowań interfejsu
użytkownika itd. Część takich rzeczy programiści wyłapią jako
potencjalne ryzyko, ale jednak na ogół bugi biorą się z tego, czego
programiści nie przewidzą. Dlatego w danym momencie masz zestaw testów A
B C D E F G H I J K L M N O P Q R S T U V W X Y Z, które zgodnie z twoją
wiedzą testują całość funkcjonalności programu, ale jednocześnie masz
exploratory testing, który wykrywa ci buga, spowodowanego np. przez race
condition, na którego piszesz test Ń, który zostaje dopisany doo skryptu
testującego i jest testowany w każdej kolejnej iteracji.

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

Dlaczego? W wielu produktach da się je przetestować automatem w 15
godzin lub mniej. Biorąc pod uwagę, że testy mogą być równolegle
wykonywane na np. ośmiu maszynach, a testy mogą de facto lecieć przez
22-23 godziny na dobę, to zbiór produktów dających się testować w ten
sposób jest naprawdę szeroki. A jeśli już naprawdę się nie da, to zawsze
można zrobić fall back do warianty "za każdą iteracją".

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

Tu znowu raczej niż się zastanawiać co jest a co nie jest "agile",
odniosę się do konkretnej metodologi Shore&Warden. Otóż w niej zakłada
się, że zespół nie pracuje z oddzielnym działem QA, tylko sam robi
testowanie swojego produktu. Ma w związku z tym swoich testerów i swoje
zasoby do testowania.

Jeśli chodzi o to, jak jest "normalnie" to też bywa różnie: ja
pracowałem w dużej firmie (spółka akcyjna z indeksu FTSE100), wcale nie
w procesie agile, ale właśnie na takiej zasadzie, że mieliśmy testowanie
tylko wewnętrzne, nie było żadnego działu QA. Działało to bardzo dobrze.

>> 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"?

Czemu nie? W Shore&Warden jest opisana rola analityka w zespole. Poza
tym to jest "lub analityk", czy faktycznie analityk jest potrzebny
zależy od projektu.

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

No więc ja się nie dziwię, że masz takie dziwne wyobrażenie, skoro nie
wyłapałeś i nie doczytałeś kluczowej sprawy: klient siedzi on site z
programistami i ewentualnymi analitykami. Konkretnie masz rolę tzw.
"customer representative" lub "on-site customer" (w żargonie XP skrótowo
nazywanego customerem), która z definicji jest osobą rozumiejącą i
mogącą podejmować decyzje co do tego, jak program ma być używany. W
przypadku programu robionego na zewnętrzne zlecenie powinien to
zazwyczaj być faktycznie przedstawiciel zleceniodawcy (ewentualnie ktoś,
komu zleceniodawca w tej kwestii ufa).

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

Żeby potem nie tracić pieniędzy na przepisywanie jeszcze raz programu,
który działa i robi to, co trzeba.

Jeśli spodziewasz się, że szansa na to, że jakakolwiek znacząca część
funkcjonalności prototypu trafi do produkcji, to można pisać go jako
throwaway code, który nie musi być programowany parami.

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

Czemu nie? Jeśli z powodu błędów korzyści z analizy nie równoważą
kosztów, to nie robisz analizy.

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

Co to znaczy "bez końca"? Jeśli to, że po otrzymaniu wersji 1.0
zleceniodawca płaci i zamawia 1.1, 1.2 etc. ad infinitum, to super.

Jeśli masz sytuację, że customer uniemożliwia dostarczenie nawet MMF
przez ciągłe zmiany wymagań na kompletnie odmienne, to jest pewien
problem. Ale też nie jest to problem nie do przejścia: tutaj działa to,
że masz customera on-site i feedback loop: w pierwszej kolejności pytasz
"no dobra, tydzień temu mówiłeś tak, zrobiliśmy z tego story, dałeś to
jako priorytet, a teraz mówisz, że jest śmak, o co chodzi?"

No i może być faktycznie tak, że nie jest to jakiś celowy sabotaż, tylko
np. albo się pomylił, albo nastąpiła jakaś obiektywna zmiana
okoliczności (powiedzmy dostawca zewnętrznych danych zmienił definicję
jednego z pól). Ale w takim przypadku idziesz do zleceniodawcy i
tłumaczysz, że są obiektywne trudności i trzeba wydłużyć termin i
zapłacić ekstra.

Zleceniodawca ma zaufanie, że faktycznie tak jest, bo:
* customer mu to potwierdza,
* customer jest jego pracownikiem,
* customer został zatrudniony na podstawie tego, że rozumie wymagania i
* że zleceniodawca mu ufa, ponadto
* customer rozmawia z innymi specjalistami w swojej firmie i oni
potwierdzają, że faktycznie tak jest.

Oczywiście jeśli wychodzi, że customer jest niekompetentny, to też to
zgłaszasz stakeholderom i wtedy jest to oczywista wina zleceniodawcy, że
wyasygnował niekompetentną osobę jako swojego przedstawiciela.

Jeśli customer jest niekompetentny a zleceniodawca nie chce tego przyjąć
do wiadomości, lub np. zleceniodawca każe customerowi celowo sabotować
projekt (bo np. w międzyczasie uznał, że nie jest mu potrzebny, a nie
chce ponosić konsekwencji rozwiązania kontraktu), to masz sytuację
utraty zaufania. Nie jest to koniec świata, ale jest to zasadniczo
koniec agile, bo agile (a przynajmniej Shore&Warden) zakłada zaufanie.
Prawdopodobnie i tak w tym momencie twoim priorytetem przestaje być
maksymalizacja dostarczonej wartości dla zleceniodawcy i długotrwała
współpraca, a raczej powinieneś przyjąć strategię jak najszybszego
możliwie bezstratnego zakończenia współpracy - poczynając od propozycji
rozwiązania umowy za porozumieniem stron, a kończąc na wypełnieniu
warunków umowy przez dostarczenie bezużytecznego produktu i/lub
rozprawie sądowej. Tak czy inaczej, w tym przypadku pomaga ci to, że
kontrakt jest sformułowany tak, że możesz go wypełnić w najgorszym
przypadku dostarczając wersję 1.0 z MMF, po czym oczywiście się nie
zgadzasz na żadne kolejne wersje, a w lepszym przypadku (time&materials)
możesz z niego wyjść na zasadzie ("my przestajemy robić, wy nam
przestajecie płacić, wypowiedzenie z dwumiesięcznym wyprzedzeniem".

Przy czym tak w ogóle to jest czarny scenariusz, bo jednak zazwyczaj jak
ktoś zamawia program, to dlatego, że go potrzebuje, a jeśli celowo bądź
przez niekompetencję opóźnia pierwszy release w nieskończoność, to nigdy
go przecież nie dostanie.

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

C3. I C3 wyprodukował jednak działającą wersję. Nie będę wnikał, czy to,
co można przeczytać o przyczynach politycznych jest prawdą czy wymówką,
natomiast zwrócę uwagę, że C3 to był "prototyp" XP. Bracia Wright też w
swoim czasie rozbili trochę samolotów.

Jeśli chodzi o udane wdrożenia XP, to znane jest studium przypadku JP
Morgan Chase.

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

Zgadza się. Ale niekoniecznie dlatego, że wytworzenie danego kawałka
funkcjonalności jest nieporównywalnie tańsze, przede wszystkim dlatego,
że prototyp nie ma pełnej funkcjonalności i dlatego, że nie jest tak
skrupulatnie testowany. Pisanie czytelnego, przejrzystego kodu zgodnie z
coding standards nie jest samo w sobie znacząco droższe od pisanie
spaghetti code.

>> Tu jest trochę fałszywe założenie, że taniej jest pisać kod niższej
>> jakości od kodu wysokiej jakości.
>
> Drozej jest?

Mniej więcej tak samo drogo.

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

Może tak być, ale dobry programista nawet pisząc na kolanie tworzy
porządny kod bez bugów.

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

Żeby nie tracić czasu i pieniędzy na pisanie od nowa. I jeszcze raz:
oczywiście, czasem lepiej nie stosować i potem ewentualnie pisać od
nowa. XP obejmuje też takie przypadki.

>>> 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???
[...]
> 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.

Nie takich problemów (że refactoring jest praktycznie niemożliwy) jest
bardzo mało. Spróbuj wymyśleć jakiś inny przykład, niż zmiana języka.

(Niech zgadnę: zleceniodawca powiedział, że chce program do księgowości
a potem się okazuje, że zapomniał dodać, że właściwie to on ma sterować
promem kosmicznym)

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

Przecież nie półgodzinnej rozmowy, tylko ciągłej pracy z. I w sumie nie
tak łatwo o przykład takiej decyzji, której odwrócenie np. po tygodniu
jest "bardzo kosztowne". Jedno, co mi przychodzi na myśl, to konieczność
zakupu już na początku jakichś bardzo drogich narzędzi czy systemów,
mówimy o wydatku rzędu setek tysięcy dolarów (dla - przypominam -
najwyżej kilkunastoosobowego zespołu). Bo wyrzucenie nawet całego kodu,
który w pierwszym tygodniu napiszą programiści nie jest "kosztowne", a
informacje w tym czasie uzyskane będą cenniejsze niż wiedza z analizy i
zbierania wymagań robionych przez miesiąc.

do góry

W dniu 2011-05-21 08:51, Michal Kleczek pisze:
[...]
>> 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.

Dokładnie tak 8-) Przerywamy, jeśli w tym momencie spodziewany wzrost
przychodów po dodaniu pewnej funkcjonalności jest mniejszy niż koszt
kolejnej iteracji. Zarabialiśmy na kolejnych wersjach, na następnej
nie zarobimy, więc zamykamy lub zawieszamy robotę. Bo może pojawić się
nowa potrzeba, dla której będzie warto dołożyć funkcjonalność.

>>> - 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ć. Gdy w ramach prototypu klient chce zobaczyć jeszcze jedną
funkcjonalność, a w środku jest tyle sznurka i taśmy klejącej, że
w typ prototypie nie da się jej dodać bez gruntownej refaktoryzacji
albo i przepisania prototypu.

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

Nie wszystkie. Te, które są aktualnie potrzebne. Chyba wiem, gdzie jest
pies pogrzebany. Agile w naturalny sposób stosuje się w projektach,
w których nikt nie ma pojęcia, co będzie za pół roku. A klient chce
(bo wg niego warto - robi to świadomie) podjąć ryzyko tworzenia
oprogramowania tak, żeby jak najszybciej dotarło na rynek. Wszystkie te
ryzyka związane z tym, że gdzieś się potkniemy i będzie to kosztowało
w którymś momencie przepisywanie wszystkiego są znane i akceptowane.
Bo wartością tego projektu jest wypuszczenie na rynek produktu jak
najszybciej. Nawet, jeśli nie ma wszystkiego, a tylko krytyczne
funkcjonalności. Chodzi zazwyczaj o to, żeby przy założonym czasie tak
dopasować scope i jakość, żeby wyprzedzić konkurencję. Szczegółowa
analiza na początku spowalnia wydanie pierwszych wersji. Po za tym
trzeba elastycznie odpowiadać na to, co akurat konkurencja wypuszcza.
Być może będą to funkcjonalności, których nie wzięliśmy pod uwagę na
początku, ale użytkownikom się spodobały.

W projektach o bardzo dobrze zdefiniowanym i "sztywnym" scope, przy
założeniu pewnej jakości negocjujemy czas i koszt. Do tego dobra,
robiona od A do Z analiza nie tylko ma sens, ale jest konieczna.

--
Paweł Kierski
n...@p...net

do góry

On 21/05/2011 09:39, Zenek1234 wrote:
> W dniu 2011-05-18 11:04, Andrzej Jarzabek pisze:
>>
>>> 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.

Jak są większe zwolnienia, to firmy się "chwalą". Poza tym pracownicy
"się chwalą".

> Dlatego nasunęło mi się takie pytanie.

Po pierwsze sprecyzuj, co to znaczy "dalej". Bo jeśli np. pytasz, co się
dzieje z tymi młodymi zdolnymi co ich Google zatrudniło przed 30-ką, po
tym, jak skończyli 50 lat, to może sobie popatrz na kalendarz, zastanów
się, spróbuj sobie policzyć na palcach, to może załapiesz.

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

A skąd w ogóle pomysł, że Google to taka firma? Ze średniego wieku
pracowników to nijak nie wynika.

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

Nie wiem. Ale zauważ, że z tej średniej nie wynika, że tarszy
programista ma gorzej. Po prostu ilość komputerów i ilość tworzonego
oprogramowania przez ostatnie kilkadziesiąt lat wzrastała lawinowo, np.
50 czy nawet 30 lat temu nie było zbyt dużo pracy dla programistów, a w
Polsce to już w ogóle, więc trudno oczekiwać, żeby ludzie masowo
wybierali taką ścieżkę kariery (nie mówiąc już o tym, że możliwości
nauki też były ograniczone).

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

Jeden z nielicznych od danej egzotycznej technologii. Takich technologii
jest więcej niż jedna, poza tym jeśli weźmiesz pod uwagę to, co powyżej,
że kiedyś dużo mniej ludzi zostawało programistami, to masz rozwiązanie:
ludzie, którzy zostawali programistami 30 lat temu są nieliczni wśród
ogółu programistów, bo 5 lat temu 1000 razy więcej ludzi zostało
programistami niż 30 lat temu. Ci ludzie znają się za to na kilku
egzotycznych technologiach, których już się dzisiaj nikt nie uczy, a
które nadal są wykorzystywane. Są nieliczni, więc są cenni, więc
najczęściej (znaczy w większości przypadków) zgarniają kokosy.

>> ewentualnie kieruje zespołem, ewentualnie odłożył kasę i założył swoją
>> firmę.
>
> Nieliczni.

Nieliczni w stosuku do ogólnej ilości programistów. W stosunku do ilości
ludzi, którzy kiedykolwiek w życiu byli programistami, a teraz są po
50-tce, to jednak stosunkowo liczni.

Że w Polsce takich ludzi nie ma? A słyszałeś o żelaznej kurtynie? O
CoCom? Ech, ta dzisiejsza młodzież.

>>> Czy zastanawialiście się, co będziecie robić w tym wieku?
>>
>> W jakim celu?
>
> Choćby po to, żeby zastanowić się nad sensem życia

Dobre! :)

> i tego, czy spełniamy
> się zawodowo, wykonując taki oto zawód.

Się spełniamy albo się nie spełniamy. Jaki na to ma wpływ, co się stanie
w przyszłości? Jutro może mnie przejechać samochód, jakie to ma
znaczenie dla tego, czy się dzisiaj spełniam zawodowo, czy nie?

do góry

On 21/05/2011 10:19, Maciej Sobczak wrote:
> 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.

Znaczy, nie robisz żadnych testów, bo testy niczemu nie zapobiegają, a
tylko dają fałszywe poczucie bezpieczeństwa.

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

Ej, ale jak rozumiesz "się nie da"? Że testy spowodują, że w ogóle
błędów nie będzie, no to rzecz jasna. Ale skoro i tak będą, to klienta
może interesować, czy będzie ich mniej czy więcej, czy będą występować
częściej, czy rzadziej. I jeśli mówisz klientowi, że testowanie nie ma
na to żadnego wpływu, to moim skromnym zdaniem jednak go trochę oszukujesz.

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

Nie tylko unit testy można odpalać z automata. Można automatycznie
testować całe systemy, nawet GUI.

> 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[*].

Bo źle interpretujesz tę miarę. Ona mówi ci tyle, że jak masz kod
niepokryty testami to jest potencjalnie źle, a nie, że jak masz pokryty
to jest dobrze.

> Wybij sobie z głowy taki pomysł, że jakakolwiek (pseudo)metodologia
> pozwoli niedoświadczonym ludziom robić dobre projekty.

Oczywiście! Stąd moje zastrzeżenie do waterfall, że te wszystkie
metodologie analizowania i projektowania to i tak machanie rękami wokół
tego, że szacunki opierają się na doświadczeniu osoby z odpowiednim
doświadczeniem.

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

Zgoda! I to nie jest tak, że w agile nie ma planowania. Jest planowanie,
i podstawą planowania jest to, że się zbiera osoby z odpowiednim
doświadczeniem w jednym pomieszczeniu.

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

Ach, widzisz, tylko tak się składa, że istnieje taka szkoła
projektowania jak "simple design"/"incremental design", która mówi, że
na każdym etapie projekt jest tak prosty, że da się go wymyśleć w 15
minut, narysować na papierze w 20 sekund, wytłumaczyć w 5 minut i
zapisać w kodzie w sposób tak oczywisty, że papierowa dokumentacja nie
jest potrzebna. Przykładowo: "rozdzielę program na część pobierającą
komunikaty z feeda i część analizującą i przetwarzającą te komunikaty,
takie moduły mogą być od siebie w dużej mierze niezależne. Mam więc
projekt taki, że FeedInterface przekazuje Message do MessageProcessor.
Robienie w tym momencie większego projektu uważam za błąd.

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

O, super to ująłeś, mogę pożyczyć? "Analiza, projekt - bywa, że są do
dupy i dają fałszywe poczucie bezpieczeństwa. Problem z
waterfall/iterative polega na tym, że nie dają żadneej obrony przed taką
możliwością, a przez to prowadzą do fałszywego poczucia bezpieczeństwa."

do góry

On 21/05/2011 13:19, Paweł Kierski wrote:
> W dniu 2011-05-21 08:51, Michal Kleczek pisze:
> [...]
>>
>> I projekt trwa bez konca... Ew. konczy jak c2 (tak, tak - pierwszy
>> projekt
>> XP) - czyli przychodzi ktos z gory i go brutalnie przerywa.
>
> Dokładnie tak 8-) Przerywamy, jeśli w tym momencie spodziewany wzrost
> przychodów po dodaniu pewnej funkcjonalności jest mniejszy niż koszt
> kolejnej iteracji. Zarabialiśmy na kolejnych wersjach, na następnej
> nie zarobimy, więc zamykamy lub zawieszamy robotę. Bo może pojawić się
> nowa potrzeba, dla której będzie warto dołożyć funkcjonalność.

Noo, Beck opisywał późniejsze problemy z C3 w ten sposób, że ludzie,
którzy mieli być on-site customerami (projekt był wewnętrzny) podawali
zupełnie inne wymagania, niż rzeczywiście wymagali ludzie odbierający
projekt. Problem był znany od jakiegoś czasu, ale nie dało się nic
zrobić, bo fumfle fumfli itp. Pomijając czy tak faktycznie było, czy
tylko się tak tłumaczył z własnej indolencji, to można chyba przyjąć, że
nie ma takiej metodologii, która by dała radę korporacyjnej polityce :)

> Nie wszystkie. Te, które są aktualnie potrzebne. Chyba wiem, gdzie jest
> pies pogrzebany. Agile w naturalny sposób stosuje się w projektach,
> w których nikt nie ma pojęcia, co będzie za pół roku. A klient chce

Przecież niekoniecznie aż "nie ma pojęcia". Pojęcie można mieć, ale też
się można liczyć z tym, że to, co się dzisiaj myśli, że będzie, to jutro
się jednak będzie wiedziało, że jednak nie będzie.

do góry

W dniu 2011-05-21 11:19, Maciej Sobczak pisze:
[...]
> 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.

To co napisałeś o przewadze dobrego projektu nad dobrymi testami, to
prawda. Agile nie twierdzi, że testy są "ostatecznym rozwiązaniem".
Pisanie po kawałku nie oznacza, że jest pisaniem bez planu. Każde
dodanie funkcjonalności to zaprojektowanie tego uzupełnienia (czasem
przeprojektowanie większego kawałka).

Coś w czym brałem udział:
http://www.slideshare.net/mateuszsrebrny/agilewarsaw
-spikes

--
Paweł Kierski
n...@p...net

do góry

On 20/05/2011 09:12, Przemek O. wrote:
>
> Nie, bo analiza jest własnością zleceniodawcy. Tak więc robi się ja
> tylko raz.

Jeszcze się spytam: często się zdarza, że wykonawca korzysta z analizy
dostarczonej przez zleceniodawcę i wykonanej przez kogoś innego (z kim
zleceniodawca się nie dogadał) - bez robienia własnej analizy?

do góry

On 21 Maj, 15:03, Andrzej Jarzabek <a...@g...com> wrote:

> > Nie zapobiegam im ani testami z automata ani ręcznymi.
>
> Znaczy, nie robisz żadnych testów,

Czytaj cały post zanim odpiszesz.

> Ej, ale jak rozumiesz "się nie da"? Że testy spowodują, że w ogóle
> błędów nie będzie, no to rzecz jasna. Ale skoro i tak będą, to klienta
> może interesować, czy będzie ich mniej czy więcej, czy będą występować
> częściej, czy rzadziej.

Tak. Dlatego staram się mieć dobry projekt - po to, żeby błędów było
mniej.

Testy oczywiście są. Ale robię z nich fetyszu i nie stawiam ich w
centrum procesu.

> Nie tylko unit testy można odpalać z automata. Można automatycznie
> testować całe systemy, nawet GUI.

Nie, nie można.
Tzn. nie twierdzę, że nie ma na świecie rozwiązań, które to obiecują
(więc nie pokazuj mi linków do tych rozwiązań :-p ).
Twierdzę tylko, że nie można.

> > Wybij sobie z głowy taki pomysł, że jakakolwiek (pseudo)metodologia
> > pozwoli niedoświadczonym ludziom robić dobre projekty.
>
> Oczywiście! Stąd moje zastrzeżenie do waterfall, że te wszystkie
> metodologie analizowania i projektowania to i tak machanie rękami wokół
> tego, że szacunki opierają się na doświadczeniu osoby z odpowiednim
> doświadczeniem.

Ostatecznie tak to wygląda.

> > 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ć.
>
> Zgoda! I to nie jest tak, że w agile nie ma planowania. Jest planowanie,
> i podstawą planowania jest to, że się zbiera osoby z odpowiednim
> doświadczeniem w jednym pomieszczeniu.

Właśnie nie jestem o tym przekonany. Mam wrażenie, że agile stał się
wyjątkowo atrakcyjny właśnie dla młodego pokolenia, przez swoją mniej
lub bardziej jawnie wyrażoną obietnicę, że programowanie może być
znowu "cool". Każdy chce, żeby było cool, więc im bardziej coś wygląda
cool, tym lepiej. I tak powstają niezliczone odmiany "procesów" agile
- szybciej, niż można je uwiarygodnić przez faktyczne doświadczenie.

Problem w tym, że jeżeli już masz cały pokój ludzi z dużym
doświadczeniem, to właściwie nie ma znaczenia, jaki to będzie proces.
I tak to zrobią dobrze i to jest właśnie ten nieuchwytny czynnik
ludzki.

> Ach, widzisz, tylko tak się składa, że istnieje taka szkoła
> projektowania jak "simple design"/"incremental design", która mówi, że
[...]
> Robienie w tym momencie większego projektu uważam za błąd.

A kto mówi, że on ma być większy? On ma być wystarczający. W
szczególności brak projektu nie jest wystarczający.

Dla przykładu, mój ostatni projekt na papierze nie zawierał formalnych
diagramów. Były ze dwa (!) obrazki w stylu prezentacji power pointa,
ale ani kawałka UMLa ani niczego podobnego. Był za to *dokładniejszy*
opis protokołu oraz interakcji w skali makro, była też bardziej
dokładna analiza konsekwencji różnych fakapów, bo projekt
dotyczył systemu krytycznego. Całość była napisana tak, żeby inny
senior, niezwiązany z projektem ale poproszony o ocenę, powiedział, że
się przekonał.
Ja wcale nie sugeruję tutaj żadnego RUPa czy czegoś w tym stylu.
Twierdzę natomiast, że wystartowanie od razu z wersją demo jest słabe
i zwiększa ryzyko, że na wersji demo się skończy. Twierdzę też, że TDD
jest słabe, bo rzeczy naprawdę ważnych nie potrafi uchwycić.

> > 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.
>
> O, super to ująłeś, mogę pożyczyć? "Analiza, projekt - bywa, że są do
> dupy i dają fałszywe poczucie bezpieczeństwa. Problem z
> waterfall/iterative polega na tym, że nie dają żadneej obrony przed taką
> możliwością, a przez to prowadzą do fałszywego poczucia bezpieczeństwa."

Spoko. Możesz pożyczyć, bo to jest prawda i istnieje również w wersji
"there is no silver bullet". Mogę jedynie powiedzieć, że naciąłem się
z testami, bo już nie raz zaprowadziły mnie (albo kogoś z mojego
otoczenia) w buraki natomiast nigdy nie naciąłem się z projektowaniem
- bo zawsze projekt był wartością dodaną, która wyznaczyła kierunek
prac i którą można było uwiarygodnić (albo wyprostować!) jeszcze przed
napisaniem pierwszej linijki kodu.

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

do góry

On 19/05/2011 17:58, Przemek O. wrote:
> W dniu 2011-05-19 18:35, Andrzej Jarzabek pisze:
>
> Nie będę się tłukł z pokrętną logiką. Jeśli coś jest wymagane i obie
> strony o tym wiedzą to musi być to wpisane w umowę lub dokument
> określający zakres zlecenia.

I co, np. jeśli masz specyfikacje programu z GUI, to masz wpisane w
wymagania że program nie może reagować na polecenia uużytkownika z
opóźniniem większym niż ileśtam sekund? Że napisy nie mogą być białe na
białym? Że serwer nie może startować przez trzy dni?

>> zakłada, że zrobi traktor, który nie grzęźnie, ale gdyby były jednak z
>> tym trrudności, to nie musi renegocjować umowy i nie musi płacić kar
>> za opóźnienia - wiedząc, że jest takie wymaganie _może_ jednak
>> próbowac renegocjować umowę na swoją korzyść (np. wydłużając termin
>> albo zwiększając cenę za enchancement).
>
> Po pierwsze pisz po polsku. Po drugie z czego miały by wynikać te
> trudności? Chyba z niekompetencji zleceniobiorcy. Ale to już jego problem.

Proszę bardzo: umawiasz się na program biorący dane z jakiegoś
zewnętrznego źródła (nie związanego z twoim zleceniodawcą) i
przetwarzające je w jakiś sposób. Trudność może polegać na tym, że
specyfikacja źródła danych może zawierać informacje które są
niedokładne, niekompletne lub wręcz nieprawdziwe. W związku z tym
wypełnienie wymagań na przetwarzanie może wymagać wielokrotnie większej
pracy niż by wynikało z pierwotnej analizy opartej na specyfikacji. W
dodatku uzyskanie brakującej informacji może zająć czas, który trudno z
góry przewidzieć - bo np. zależy od tego, jak sprawnie te informacje
będzie w stanie uzyskać support dostawcy danych. A wszystkiego tego
dowiadujesz się dopiero jak napiszesz program i zaczniesz go testować na
rzeczywistych danych.

>> zleceniodawca może dostać pierwszy release na trzy miesiące przed
>> terminem i zacząć już na nim zarabiać, a my obiecujemy w dalszej
>
> Zakładając że da się wykroić interesującą zleceniodawcę część.

W przypadku większego programu często się da.

>> kolejności zająć się tym, co wypadło. I customer representative i
>> tygodniowe iteracje z wersją demo są również po to, żeby zleceniodawca
>> wiedział, że nie jest robiony w bambuko.
>
> Jeśli coś wypadło i okazuje się że zleceniodawca na pierwszym wydaniu
> może zarabiać, to zleceniobiorca zrobił go już w bambuko i wcisnął
> dodatkowe funkcje których nie potrzebuje do zarabiania. Racja?

Nie racja. Dodatkowe funkcje są do zarabiania jeszcze więcej.

>> Bo każdy porządny developer ma Oracle Machnine wpiętą w slota PCI.
>
> Wiesz, jeśli się robi z nastawieniem "agile" w wydaniu do którego
> próbujesz mnie przekonać to faktycznie powinien.
> Ale mając doświadczenie, porządną analizę wymagań oraz projekt. Nie
> potrzebuje jej, bo może oszacować zarówno koszt jak i termin wykonania.
> Że nie wspominając już o tym, czy w ogóle jest w stanie wykonać to zadanie.

Oczywiście, że można oszacować. Tylko że jest różnica między
oszacowaniem a rzeczywistością.

>> W interesie zleceniobiorcy jest również znać notowania giełdy na
>> przyszły tydzień, i żeby mu diamenty z nieba do ogródka spadały.
>
> ??? Sugerujesz że nie da się oszacować kosztów i terminu wykonania

Sugeruję, że "oszacować" to nie to samo, co "znać". W interesie byłoby
oczywiście znać koszta i terminy, ale oszacowanie nie daje ci tego, że
je _znasz_.

> projektu. No patrz, genialny jestem bo od wielu lat mi się to udaje. I
> najczęściej stosuje projekty kaskadowe lub kaskadowe z iteracjami. Żyje
> chyba we własnym świecie, tylko dlaczego mi za to płacą???

No popatrz, a mnie się wiele razy udało trafnie oszacować bez
udokumentowanej analizy i projektu. I widziałem jak innym się to też
udaje, więc chyba to nie dlatego, że jestem taki genialny. A skoro można
trafnie oszacować bez analizy i projektu, i można trafnie oszacować z
analizą i projektem, to znaczy, że pod względem przydatności do
szacowania czasu i kosztów analiza i projekt są bezużyteczne.

Tak, oczywiście możesz twierdzić, że analiza i projekt dają
dokładniejsze, bardziej zgodne z rzeczywistością oszacowanie. Ale po
pierwsze należałoby to uzasadnić, a tutaj dowód anegdotyczny nie jest
żadnym argumentem. W ogóle trudno tutaj o jednoznaczne przesłanki w
jedną i w drugą stronę, bo jest bardzo dużo zmiennych.

Natomiast nawet gdyby przewidywania były rzeczywiście dokładniejsze, to
pytanie czy na tyle dokładniejsze, żeby korzyści z tego równoważyły
koszta wykonania analizy i projektu. Moim zdaniem (ale też nie twierdzę,
że mam na to jakieś dowody) jest tak, że osoba lub zebranie osób z
odpowiednim doświadczeniem jest w stanie najwyżej w pół godziny trafnie
oszacować koszt i czas na podstawie prezentacji wizji i zadania kilku
kluczowych pytań (zakładając, że jest pod ręką ktoś, kto będzie potrafił
na nie kompetentnie odpowiedzieć). Jeśli szacowanie na podstawie analizy
będzie nawet dokładniejsze, to różnica będzie minimalna, bo analiza nie
bierze pod uwagę czynników takich jak powyżej.

>> Ja przecież nie zakładam, że zleceniobiorca wie z góry. Ja zakładam,
>> że nikt nie wie z góry.
>
> Czego nie wie? Banialuki opowiadasz. Zleceniodawca nie wie co potrafi?

Nie wie ile czasu zajmie i ile będzie kosztować.

> Bierze projekty w ciemno?

Co to znaczy "w ciemno"? Jeśli chodzi o to, czy podejmuje ryzyko, że
zajmie nie tyle, ile mu się wydaje, że zajmie, albo będzie kosztować nie
tyle, ile mu się wydaje, że będzie kosztować, albo że w ogóle się nie
będzie dało zrobić, to owszem, podejmuje takie ryzyko. Zawsze w biznesie
podejmuje się jakieś ryzyko.

do góry