Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
dyskusyjnych:kseh6s$r8v$...@s...invalid...

>Jeśli uważasz, że odpowiedź brzmi 12 miesięcy i dwa miliony, to w
>większości przypadków byś się mylił. Prawidłowa odpowiedź brzmi "nie
>wiadomo", może to być 18 miesięcy i 2.5 miliona jeśli masz szczęście,

Jeżeli firma zgodziła się na 12 miesięcy i dwa miliony, to przy 18
miesiącach i 2.5 milionach kary umowne mogą być bolesne. Spróbuj np. nie
płacić przez 6 miesięcy rachunków za prąd i/lub "internet". Aby
niedotrzymywanie terminów, brak dyscypliny wydatków itd. były możliwe, to
warunkiem koniecznym jest słabość umysłowa klienta lub korupcja. Oczywiście
można uznać, że jak coś "zrobi się w pół roku" to naprawdę będą to dwa lata
(na poziomie technicznych w firmie)... tyle że w umowach (prawnicy) to muszą
już od początku być dwa lata. Inaczej może zaboleć. Auć!

>ale może to być równie dobrze 5 lat i 10 milionów, albo możesz w ogóle nie
>dostać takiego systemu. Zakładając, jeszcze raz, że dostawca dotrzyma
>umowy.

Zadziwiające: dostawca DOTRZYMUJE umowy a odbiorca NIE DOSTAJE ZAMÓWIONEGO
SYSTEMU. Logika doprawdy porażająca!

>Gdyby nie dotrzymał to, jak piszesz, mógłbyć pozwać go i dostać

Zaczynasz jarzyć.

>odszkodowanie. Ale jeśli dotrzyma, to nikogo nie możesz pozwać i
>ostatecznie koleś może po wzięciu 10 milionów powiedzieć, że dalszych

W czym problem, jeżeli np. kod źródłowy należy do zleceniodawcy (wiem,
będzie nieco drożej)?

>Ale jeśli jednak obydwie strony dotrzymają umowy, to Fred wyląduje z dwoma
>milionami w kieszeni, a Bob z bezużytecznym oprogramowaniem.

No to ja zapytam: a dlaczego bezużytecznym?

>A co ja mam do tego? Ja nie świadczę usług, a gdybym świadczył, to raczej
>na umowach time and materials. Na fixed price fixed scope to bym się
>zgodził dopiero przy bardzo małym ryzyku i bardzo dużym mnożniku i

Geeez. Zgodziłbyś się. Natychmiast. Wystarczy odpowiednia motywacja.

>Ma pracę, bo jest wielu klientów, którzy nie tylko się zgadzają, ale nawet
>wolą umowy time and materials.

Podobno bezrobocie wynosi około 30% wśród absolwentów. Znaczy się jest
trochę krucho z klientami, bo inaczej wszystkich młodych i zdolnych upchnąć
dałoby się w branży IT.

>Antek znajdzie klienta, tylko tym klientem nie będzie Bob. CO jest

Nie rozumiesz. Bob to pasożyt. Żeruje na rozmaitych bosych Antkach. Antki
uwierzyły w Agile i takie tam. Uwierzyły w to, że da się bez prawników, bez
umów, podpisów i krawatów. A Bob to paskuda taka sama jak np. prawnicy
blokujący sprzedaż produktu konkurencji "bo zastosowano w nim wkręty o tej
samej średnicy co w naszym produkcie".

Pasożytów, na przykład tasiemca, nie szukasz. To pasożyt dopada cię
znienacka, bo np. nie lubiłeś myć rąk. Podobnie z Bobem. Nigdy nie wiesz,
kiedy go spotkasz i jak będzie wyglądał. Może np. wyglądać zupełnie jak twój
serdeczny kumpel ze studiów.

Oczywiście, przy zleceniach za "tysiącpincet" to wartość oczekiwana strat da
się przeboleć. Ale już przy kontraktach na 2 miliony euro byłbym nieco
ostrożny.

>umowy z kimś takim jak Bob. Na szczęście oprócz Bobów, którzy zamawiają
>oprogramowanie tylko po to, żeby wyrolować dostawcę, istnieje jeszcze

Bob nikogo nie chce rolować (przynajmniej miejmy nadzieję że nie ma
osobistej urazy do Freda) - Bob chce zmaksymalizować zysk. A to że przy
okazji doprowadzi Freda do bankructwa czy jakoś tak... to chyba nie jest
jakiś wielki problem etyczny (dla Boba).

>Ale w przypadku, o którym pisałem, nie dochodzi do zerwania umowy.

Dochodzi. Soft nie spełnia wymagań zawartych w umowie "drobnym druczkiem".
Jak mawiają Rosjanie: p...no.

>Właśnie pisał o dokładnie takich umowach, w których opisane dojenie
>występuje na maksa. Vide historia o przesunięciu przycisku za ćwierć
>miliona.

Spoko, spoko. Jeżeli przesunięcie przycisku kosztowało 250 000 euro ($?) to
pewnie przyniosło przynajmniej 250 000 + 1 euro zysku. Inaczej nikt nie
przesuwałby tego przycisku.

do góry

On 20/07/2013 20:37, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:kseh6s$r8v$...@s...invalid...
>
>> Jeśli uważasz, że odpowiedź brzmi 12 miesięcy i dwa miliony, to w
>> większości przypadków byś się mylił. Prawidłowa odpowiedź brzmi "nie
>> wiadomo", może to być 18 miesięcy i 2.5 miliona jeśli masz szczęście,
>
> Jeżeli firma zgodziła się na 12 miesięcy i dwa miliony, to przy 18
> miesiącach i 2.5 milionach kary umowne mogą być bolesne.

Nie mogą być, bo kary umowne są wypłacane w przypadku naruszenia
terminu. W tym przypadku naruszenia terminu nie ma - zamawiający sam
zgadza się przesuwać termin, a jeśli nie, to zgodnie z oryginalną umową
po 12 miesiącach dostaje produkt bezużyteczny.

>> ale może to być równie dobrze 5 lat i 10 milionów, albo możesz w ogóle
>> nie dostać takiego systemu. Zakładając, jeszcze raz, że dostawca
>> dotrzyma umowy.
>
> Zadziwiające: dostawca DOTRZYMUJE umowy a odbiorca NIE DOSTAJE
> ZAMÓWIONEGO SYSTEMU. Logika doprawdy porażająca!

Dostaje zamówiony system. Nie dostaje systemu, którego może używać.

>> odszkodowanie. Ale jeśli dotrzyma, to nikogo nie możesz pozwać i
>> ostatecznie koleś może po wzięciu 10 milionów powiedzieć, że dalszych
>
> W czym problem, jeżeli np. kod źródłowy należy do zleceniodawcy (wiem,
> będzie nieco drożej)?

Może nie być nieco drożej, tylko dużo, dużo drożej. Niektórzy dostawcy w
ogóle się na to nie zgodzą, bo do budowania systemów używają
istniejącego wcześniej kodu, który jest objęty tajemnicą handlową.

Oczywiście jeśli w końcu wylądujesz z milionami linijek kodu źródłowego,
to też nie znaczy, że znajdziesz kogokolwiek, kto się zgodzi wprowadzać
nawet niewielkie zmiany tanio. Musiałbyś znaleźć kogoś, kto ma
ekspertyzę we wszystkich zastosowanych technologiach, lub też
zamawiający musiałby być skłonny zapłacić za naukę przyjnajmniej częsci
z nich. Ponadto w ogóle zrozumienie architektury systemu na podstawie
kodu źródłowego jest niebanalnym zadaniem jeśli nie masz do dyspozycji
kogoś, kto wcześniej nad tym kodem pracował i mógłby ci cokolwiek
wytłumaczyć. W szczególności jeśli wykonawcy zupełnie nie zależy, żeby
zdawany przez nich system był łatwy do zrozumienia przez kogokolwiek
innego. Poza tym coiężko się będzie zabepieczyć przezd wszelkimi
ewentualnościami typu: wykonawca oddaje kod źródłowy, ale testów którymi
wewnętrznie ten kod weryfikował - już nie.

>> Ale jeśli jednak obydwie strony dotrzymają umowy, to Fred wyląduje z
>> dwoma milionami w kieszeni, a Bob z bezużytecznym oprogramowaniem.
>
> No to ja zapytam: a dlaczego bezużytecznym?

Z wielu powodów.

Przede wszystkim tak jak w dużym systemie informatycznym popełnienie w
którymś momencie błędu przez programistę nie jest możliwością, tylko
pewnikiem, tak samo popełnienie błędów przy pisaniu bardzo szczegółowej
specyfikacji tego systemu jest co najmniej bardzo prawdopodobne.
Rewidowanie, czytanie, konsultowanie takiej specyfikacji ciężko jest tak
zrobić, żeby wyłapać wszystkie czy nawet większość takich błędów. Dalsze
eliminowanie tych błędów z coraz większym prawdopodobieństwem przed
podpisaniem umowy jest lawinowo coraz droższe, może nawet dorównać lub
przekroczyć cenę samego softu.

Wyłapanie tych błedów na dalszych etapach jest możliwe, wiele z nich
zauważanych jest już w czasie analizy czy pisania kodu, niektóre przy
testowaniu oprogramowania u wykonawcy, niektóre przy próbie wdrożenia, w
fazie UAT, czy jeśli masz pecha, to już w produkcji. Tak czy inaczej w
takiej sytuacji musisz prosić wykonawcę o zmianę, co oznacza
renegocjację kontraktu, nowy termin, nową cenę.

Drugi powód jest taki, że język naturalny nie jest wystarczająco
precyzyjny, żeby jednoznacznie opisać takie wymagania. W tekście pisanym
po polsku czy po angielsku prawdopodobnie będzie wiele zdań, które można
interpretować na różne sposoby - z których niektóre (które miał na myśli
piszący specyfikację) będą zgodne z wymaganiami zamawiającego, inne nie.
Interpretacje w oczywisty sposób niepoprawne nie przejdą, ale istnieją i
takie, w przypadku których ewentualny sąd uzna, że wykonawca miał prawo
zrozumieć to w taki sposób i nie ma w tym jego winy - np. że wybór
właściwej interpretacji jest oczywisty dopiero znając pewne szczegóły
wewnętrznej organizacji u zamawiającego, które były oczywistą
oczywistością dla piszącego specyfikację (który tam pracuje i tymi
szczegółami żyje), ale o których wykonawca nie mógł wiedzieć
przystępując do umowy.

Kolejny powód jest taki, że zmieniają się realia i software, który byłby
użyteczny w momencie zamawiania może być bezużyteczny w momencie jego
odbioru. Powodem mogą być zmiany w samej organizacji zamwaiającego
(restrukturyzacja, zmiany w modelu biznesowym), zmiana warunków
zewnętrznych (wymiana platformy elektronicznej na Giełdzie Papierów
Wartościowych) lub w pewnych branżąch zmieniające się przepisy lub ich
obowiązujące interpretacje (software jest technicznie zdatny do użycia,
ale jego używanie w takiej formie po zmianie przepisów jest niezgodne z
prawem).

>> A co ja mam do tego? Ja nie świadczę usług, a gdybym świadczył, to
>> raczej na umowach time and materials. Na fixed price fixed scope to
>> bym się zgodził dopiero przy bardzo małym ryzyku i bardzo dużym
>> mnożniku i
>
> Geeez. Zgodziłbyś się. Natychmiast. Wystarczy odpowiednia motywacja.

No to właśnie mówię - małe ryzyko i duży mnożnik byłby odpowiednią
motywacją. Jeśli bym wiedział, że zrobię coś w miesiąc, a już
ekstremalnie nieprawdopodobne jest, żeby mi to zajęło więcej niż trzy,
koszty własne będą żadne, to pewnie się zgodzę na dwuletni termin i
odpowiednio wiele milionów.

W praktyce oczywiście zgodzę się na mniej - bo w zależności od mojej
sytuacji będę np. dużą firmą z dużą ilością zleceń i będę miał całą
kalkulację ryzyka wiedząc np. jak często rzeczywisty czas i koszty
wykonania przekraczają pierwotne estymaty o dany procent, będę miał
armię prawników wpisujących do umów klauzule ograniczające
odpowiedzialność, to będę mógł w ramach tej kalkulacji stracić określone
kwoty na jakimś procencie zleceń i nadal być do przodu z zysków na
pozostałych.

Jeśli natomiast jestem jednoosobową spółką z oo, to nie mam tej armii
prawników i nie stać mnie na straty, ale chroni mnie instytucja
ograniczonej odpowiedzialności - mogę przyjąć zlecenie Boba, przez rok
wypłacać sobie pensje i diety, a jak za rok się nie uda dostarczyć softu
według umowy, to sobie spokojnie zbankrutuję, stracę tego laptopa co go
mam na majątku firmy, a z oszczędności zakupię kolejnego laptopa i użyję
go jako kapitału założycielskiego kolejnej spółki z oo.

>> Ma pracę, bo jest wielu klientów, którzy nie tylko się zgadzają, ale
>> nawet wolą umowy time and materials.
>
> Podobno bezrobocie wynosi około 30% wśród absolwentów. Znaczy się jest
> trochę krucho z klientami, bo inaczej wszystkich młodych i zdolnych
> upchnąć dałoby się w branży IT.

Nie znaczy, bo branża IT jest zainteresowana raczej zyskami niż
obniżaniem bezrobocia wśród absolwentów.

>> Antek znajdzie klienta, tylko tym klientem nie będzie Bob. CO jest
>
> Nie rozumiesz. Bob to pasożyt. Żeruje na rozmaitych bosych Antkach.

Rozumiem. Dlatego właśnie mówię - jeśli formy umowy oferowane przez
Antka spowodują, że Bob sobie pójdzie gdzie indziej, to tylko świadczy o
tym, że Antek dobrze kombinuje.

> Antki uwierzyły w Agile i takie tam. Uwierzyły w to, że da się bez
> prawników, bez umów, podpisów i krawatów. A Bob to paskuda taka sama jak
> np. prawnicy blokujący sprzedaż produktu konkurencji "bo zastosowano w
> nim wkręty o tej samej średnicy co w naszym produkcie".

No ale właśnie Antek ma rację - Bob nie będzie pasożytował na nim, tylko
na Fredzie, który nie wierzy w Agile i w związku z tym oferuje kontrakty
fixed time fixed scope. Antek uwierzył w Agile więc proponuje time and
materials, co uodparnia go na atak Boba.

> Pasożytów, na przykład tasiemca, nie szukasz. To pasożyt dopada cię
> znienacka, bo np. nie lubiłeś myć rąk. Podobnie z Bobem. Nigdy nie
> wiesz, kiedy go spotkasz i jak będzie wyglądał. Może np. wyglądać
> zupełnie jak twój serdeczny kumpel ze studiów.

No więc dla Antka Agile jest jak mycie rąk. Nie musi rozpoznać Boba,
wystarczy, że Bob ucieknie z krzykiem jak usłyszy warunki Antka.

>> umowy z kimś takim jak Bob. Na szczęście oprócz Bobów, którzy
>> zamawiają oprogramowanie tylko po to, żeby wyrolować dostawcę,
>> istnieje jeszcze
>
> Bob nikogo nie chce rolować (przynajmniej miejmy nadzieję że nie ma
> osobistej urazy do Freda) - Bob chce zmaksymalizować zysk. A to że przy
> okazji doprowadzi Freda do bankructwa czy jakoś tak... to chyba nie jest
> jakiś wielki problem etyczny (dla Boba).

Bob właśnie chce kogoś rolować, na tym polega jego pomysł na
maksymalizację zysku.

Normalnie jednak produkcja oprogramowania opłaca się, bo istnieje
również taki pomysł na maksymalizację zysku, który nie wymaga
bankrutowania czy doprowadzania do strat wykonawcy. Wręcz przeciwnie -
bankructwo, czy choćby zakończenie współpracy przez wykonawcę jest dla
takich klientów dużym problemem, bo wprowadzanie dlaszych zmian do
oprogramowania staje się znacznie bardziej kosztowne lub wręcz niemożliwe.

>> Ale w przypadku, o którym pisałem, nie dochodzi do zerwania umowy.
>
> Dochodzi. Soft nie spełnia wymagań zawartych w umowie "drobnym
> druczkiem". Jak mawiają Rosjanie: p...no.

No to mamy dwie historie - Nierzetelnego Freda i Freda Naciągacza (przed
przypadek mają takie samo imię). Fred Naciągacz bardzo dba o to, żeby
dotrzymywać terminów, a jeśli już (rzadko) nie da rady, to sumiennie
płaci kary umowne (umawia się tylko tak, żeby go było stać na owe kary)
- nawet jeśli ma do tego dopłacić. Bo cały biznes model Freda Naciągacza
opiera się na tym, że większość klientów chce potem wielu zmian w
specyfikacji i jest skłonna zapłacić za nie sporo więcej, niż te zmiany
kosztują (bo bez nich soft jest z reguły beezwartościowy albo
przynajmniej mocno upośledzony).

I teraz załóżmy, że Bobowi udało się doprowadzić Nierzetelnego Freda do
bankructwa i zainkasować okrągły milion, przy kosztach własnych
powiedzmy 100 tysięcy (stworzenie specyfikacji i napisanie umowy
kosztuje). W międzyczasie dowiaduje się, że niejako Bosy Bolek ma
problemy z dotrzymywaniem terminów, więc proponuje Bolkowi taką samą
umowę na dwa miliony. Dla Bolka dwa miliony to niewyobrażalny majątek,
więc mówi - czemu nie. Podpisuje umowę jako prezes Bolo sp z o o, bierze
pół miliona zaliczki, przez 12 miesięcy wypłaca sobie prezesowską pensję
30 tysięcy miesięcznie, plus pokrywa z zaliczki koszty lanczów
biznesowych, podróży biznesowych, wynajmu biura, pensjęę sekretarki i co
tam jeszcze. Przy tym wszystkim naprawdę uczciwie się stara zrobić
program według specyfikacji Boba. Jest to oczywiście niemożliwe, więc
Bob pozywa Bolka, sąd zadądza milion euro odszkodowania, Bolo zp z o o
ogłasza upadłość, komornik zajmuje majątek firmy w postaci laptopa,
sztuk 1, Bosy Bolek rejestrujee firmę Bolorz sp z o o, wykładając jako
kapitał zakładowy równowartość laptopa, sztuk 1, z pieniędzy, które
zarobił jako preze Bolo sp z o o. Bosy Bolek jest do przodu, Bob stracił
właśnie pół miliona, ale póki co jest jeszcze 400 tys. do przodu.

Tymczasem Fred Naciągacz dowiaduje się o Bobie. Co prawda to nie jego
typowy klient, ale Fred widzi tutaj pewną okazję. Namawia przyjaciela,
żeby zwierzył się Bobowi przy barze jak to się przejechał na tym, że
zlecił jakiś soft u takiego Cholernie Nierzetelnego Freda. Fred
Naciągasz tymczasem odnajduje Nierzetelnego Freda i proponuje intratną
współpracę. Bob oczywiście wkrótce pojawia się u Freda Naciągacza z
propozycją wykonania softu za dwa miliony. Fred patrzy na specyfikację
produktu i jest wniebowzięty - to dokładnie ta sama specyfikacja, którą
dostał Nierzetelny Fred, z tym samym drobnym druczkiem - Bob ogranicza
koszty i czas nie wymyślając za każdym razem nowej specyfikacji za sto
tysięcy. Ponieważ z pendrajwa Nierzetelnego Freda Fred Naciągasz ma
program stworzony według tej specyfikacji, razem z testami, analizą
itd., nie spełniając jedynie drobnego druczku, Fred Naciągacz może
wyliczyć, że uzupełnienie programu o wymagania drobnego druczku to
najwyżej 6 miesięcy roboty. Podpisuje umowę na 12 miesięcy i dwa
miliony, bierze pół miliona zadatku (Bob już jest 100k w plecy) i w 6
miesięcy oddaje program według specyfikacji, łącznie z drobnym drukiem.
Bob może w tym momencie tylko albo zgodnie z umową zapłacić 2 miliony
(jeśli ma), albo zbankrutować. Przy czym jeśli się okaże, że Bob jako
zarządzający spółką Bob Holdings zamówił oprogramowanie za 2 miliony w
momencie kiedy spółka nie miała ani kapitału, ani spodziewanych
dochodów, ani nawet zdolności kredytowej (z braku kapitału i dochodów),
a w dodatku, że to już trzeci raz Bob składa takie zamówienie, to jednak
obstawiam, że są na to paragrafy, którymi można ścignąć Boba osobiście,
cywilnie i prawdopodobnie również karnie. Fred Naciągacz więc zarobi nie
tylko pół miliona zadatku i co tam się ściągnie z egzekucji Bob
Holdings, ale być może również przychód ze zlicytowania domu, samochodu
i sztucznych cycków żony Boba. Bob tymczasem wiesza się w celi na
prześcieradle...

>> Właśnie pisał o dokładnie takich umowach, w których opisane dojenie
>> występuje na maksa. Vide historia o przesunięciu przycisku za ćwierć
>> miliona.
>
> Spoko, spoko. Jeżeli przesunięcie przycisku kosztowało 250 000 euro ($?)
> to pewnie przyniosło przynajmniej 250 000 + 1 euro zysku. Inaczej nikt
> nie przesuwałby tego przycisku.

A jeżeli zamawiający miałby mieć 200 tys (chodziło o dolary nie euro,
ale mniejsza o to) zysku z przesunięcia innego przycisku, to już
zostawił ten drugi przycisk jak był i stracił 200 tysięcy.

To jest oczywiście uproszczona wizja, bo w rzeczywistości w biznesie
masz do czynienia z profilem ryzyka a nie z pewnymi zyskami czy
stratami. Może np. być tak, że złe położenie przycisku powoduje, że co
jakiś czas operator wciska nie ten przycisk i powoduje mniejsze lub
większe straty - nie wiadomo jakie, ale można oszacować
prawdopodobieństwo, że będą np. w przedziale 100-150 tys. I kwestia jest
taka, że w zależności od profilu ryzyka może się okazać, że korzystanie
z programu nie ma sensu, bo ryzyko strat spowodowane złym przyciskaniem
źle położonego przycisku przeważa jakiekolwiek korzyści z korzystania z
programu. I w tym momencie, jeśli zamawiający nie zgodzi się zapłacić
250 tys. za przesunięcie przycisku, to te dwa miliony wydanee już na ten
program są pieniędzmi wyrzuconymi w błoto.

do góry

Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
dyskusyjnych:ksfevv$9th$...@s...invalid...

>Może nie być nieco drożej, tylko dużo, dużo drożej. Niektórzy dostawcy w
>ogóle się na to nie zgodzą, bo do budowania systemów używają istniejącego
>wcześniej kodu, który jest objęty tajemnicą handlową.

No popatrz - cały Linux jest open source - i jak najbardziej nadaje się do
wielu rzeczy, choć przecież jest darmowy.

Więc dywagacje "drożej-taniej" są równie dobre jak wróżenie z fusów. Czy 10x
tyle to drożej? A czy lepiej kupić coś, co posłuży 10 lat, czy system na 1
rok? Możemy gdybać, możemy snuć różnego rodzaju domysły... ale bez konkretów
to do sensownych wniosków nie dojdziemy.

>z nich. Ponadto w ogóle zrozumienie architektury systemu na podstawie kodu
>źródłowego jest niebanalnym zadaniem jeśli nie masz do dyspozycji

Dlaczego jedynie "kodu źródłowego"? Jest dokumentacja, kod źródłowy też nie
śmieciowy, ale spełniający określone standardy itd. Oczywiście, wymaga to
wszystko IQ rzędu 130 i być może znajomości jakiegoś języka programowania,
ale to nie są wyśrubowane wymagania w XXI wieku.

Odwrotnie - zgadzanie się na closed source i nie wnikanie "co jest w środku"
prowadzi do uzależnienia od określonej zewnętrznej firmy. Jeżeli ta firma
opiera się na jakimś geniuszu, który akurat postanowił sobie umrzeć, to wali
się wszystko niczym klocki domina. Takie rzeczy były już przerabiane przez
branżę.

>wytłumaczyć. W szczególności jeśli wykonawcy zupełnie nie zależy, żeby
>zdawany przez nich system był łatwy do zrozumienia przez kogokolwiek

Takich wykonawców eliminuje się już na początku. Wykonawcy musi zależeć i
musi trzymać się standardów, a to co robi musi być "łatwe do zrozumienia"
przynajmniej przez fachowców.

>Rewidowanie, czytanie, konsultowanie takiej specyfikacji ciężko jest tak
>zrobić, żeby wyłapać wszystkie czy nawet większość takich błędów. Dalsze

Ba! Życie to ciężkie jest, a życie programisty szczególnie: nie każdy może
pić drinki z palemką jak AL czy Knuth.

>Drugi powód jest taki, że język naturalny nie jest wystarczająco
>precyzyjny, żeby jednoznacznie opisać takie wymagania. W tekście pisanym

Jeżeli - jako programista - nie potrafisz opisać wymagań - to nie
potrafisz - także jako programista - napisać programu. ;)

>według umowy, to sobie spokojnie zbankrutuję, stracę tego laptopa co go mam
>na majątku firmy, a z oszczędności zakupię kolejnego laptopa i użyję go
>jako kapitału założycielskiego kolejnej spółki z oo.

Zbankrutujesz... zdarza się. Ale twoja wiarygodność jako partnera w biznesie
będzie równa zero, jeżeli nie ujemna. Dlatego na tym laptopie będziesz mógł
ewentualnie pograć w Sapera.

>stratami. Może np. być tak, że złe położenie przycisku powoduje, że co
>jakiś czas operator wciska nie ten przycisk i powoduje mniejsze lub większe
>straty - nie wiadomo jakie, ale można oszacować prawdopodobieństwo, że będą
>np. w przedziale 100-150 tys. I kwestia jest

To po co się przejmować? Koszt wprowadzenia poprawki to 250 000 euro, bez
poprawki straty wynoszą 150 000 euro. Nie wprowadzenie poprawki daje +100
000 euro. Wprowadzenie poprawki daje -100 000 euro oraz brak pewności, że to
przyniesie spodziewane rezultaty i zakończy się wydatkiem jedynie tych 100
000 euro. Właśnie odkryliśmy czym jest konserwatyzm liberalny.

do góry

On 2013-07-20, slawek <h...@s...pl> wrote:
> Bob nie traci zadatku, bo to nie on nie dotrzymał umowy. Zadatek to forma
> zabezpieczenia: ten kto złamie umowę musi płacić. Jeżeli Bob złamałby... ok,
> zadatek przepadł. Ale jeżeli Fred, to nie tylko że Fred oddaje zadatek
> Bobowi, ale jeszcze musi "z automatu" dać drugie tyle. Tak to działa
> (przyznaję, sam się kiedyś nieco zdziwiłem).

Ja też, ale wtedy doczytałem o różnicy między zadatkiem i zaliczką.

--
Secunia non olet.
Stanislaw Klekot

do góry

On 21/07/2013 10:54, slawek wrote:
> Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
> dyskusyjnych:ksfevv$9th$...@s...invalid...
>
>> Może nie być nieco drożej, tylko dużo, dużo drożej. Niektórzy dostawcy
>> w ogóle się na to nie zgodzą, bo do budowania systemów używają
>> istniejącego wcześniej kodu, który jest objęty tajemnicą handlową.
>
> No popatrz - cały Linux jest open source - i jak najbardziej nadaje się
> do wielu rzeczy, choć przecież jest darmowy.

Nie rozumiem jaką w związku z tym masz tezę? Że można używać Linuxa jako
systemu CRM, księgowości czy payroll?

> Więc dywagacje "drożej-taniej" są równie dobre jak wróżenie z fusów. Czy
> 10x tyle to drożej? A czy lepiej kupić coś, co posłuży 10 lat, czy
> system na 1 rok? Możemy gdybać, możemy snuć różnego rodzaju domysły...
> ale bez konkretów to do sensownych wniosków nie dojdziemy.

Powiem w ten sposób - mam wiele lat przepracowanych w dużych firmach (a
więc takich, które ewentualnie można pozwać na te miliony i mieć
nadzieję je dostać) robiące oprogramowanie dla dużych firm (które stać
na zakup oprogramowania za miliony). I te firmy nie oferowały klientom
kodu źródłowego swoich produktów.

>> z nich. Ponadto w ogóle zrozumienie architektury systemu na podstawie
>> kodu źródłowego jest niebanalnym zadaniem jeśli nie masz do dyspozycji
>
> Dlaczego jedynie "kodu źródłowego"? Jest dokumentacja,

O ile jest, znaczy pewnie jest 'end user documentation' do programu, ale
czy jest dokumentacja opisująca architekturę systemu i projekt kodu to
osobna kwestia. A nawet jeśli jest, bo taka dokumentacja jest wymogiem
umowy, to kolejne pytanie ile taka dokumentacja jest warta w momencie
kiedy przygotowuje ją ktoś, komu aktywnie zależy na tym, żeby jak
najtrudniej było z niej skorzystać.

> kod źródłowy też
> nie śmieciowy, ale spełniający określone standardy itd.

Jakie standardy? Nic mi nie wiadomo o jakichkolwiek standardach, które
by można zadekretować umową, a które gwarantowałyby nieśmieciowość kodu.

> Oczywiście,
> wymaga to wszystko IQ rzędu 130 i być może znajomości jakiegoś języka
> programowania, ale to nie są wyśrubowane wymagania w XXI wieku.

Kilka razy spotkałem się z sytuacją konieczności rozczytania kodu i
wprowadzenia zmian do komponentów, na których nikt się nie znał, bo ten,
co je robił odszedł z firmy, a nikt inny ich nie ruszał od dłuższego
czasu. Na podstawiee tych obserwacji uważam, że jest to trudne,
czasochłonne, kosztowne i ryzykowne - efektywne zapoznanie się z cudzym
kodem bez możliwości konsultowania się z autorem to wysiłek porównywalny
z napisaniem tego kodu od początku. Nie mówię nawet, że dla mnie, bo ja
zapewne mam niskie IQ (nie mierzyłem, to nie wiem), ale moim
niewątpliwie inteligentnym kolegom również sprawiało to problemy.

> Odwrotnie - zgadzanie się na closed source i nie wnikanie "co jest w
> środku" prowadzi do uzależnienia od określonej zewnętrznej firmy. Jeżeli
> ta firma opiera się na jakimś geniuszu, który akurat postanowił sobie
> umrzeć, to wali się wszystko niczym klocki domina. Takie rzeczy były już
> przerabiane przez branżę.

Naprawdę? Gdzie/kiedy?

Oczywiście że oferowanie kodu źródłowego redukuje ryzyko klienta, ale
też zwiększa ryzyko dostawcy. Dlatego distawcy się albo nie zgadzają,
albo proponują wyższe ceny.

Weź więc pod uwagę w naszym scenariuszu, że masz nieprzekraczalny budżet
na system w kwocie czterech milionów. I masz jednego dostawcę, który
oferuje umowę na system bez źródeł za dwa miliony, i drugiego, który
daje źródła, ale za cztery miliony. Którego wybierzesz? Przecież jeśli
się okaże, że system wymaga zmian w specyfikacji, żeby go wdrożyć, to co
z tego, że będziesz mógł poszukać innego dostawcy które ci te zmiany
zaimplementuje, skoro już nie będziesz miał czym zapłacić? A nawet jak
ci jeszcze rtrochę zostanie, to nikt ci niezrobi tej modyfikacji za
grosze, bo wejście w cudzy codebase to duża inwestycja upfront.

>> wytłumaczyć. W szczególności jeśli wykonawcy zupełnie nie zależy, żeby
>> zdawany przez nich system był łatwy do zrozumienia przez kogokolwiek
>
> Takich wykonawców eliminuje się już na początku.

Na jakiej podstawie?

> Wykonawcy musi zależeć

A skąd wiesz, komu zależy? Do umowy przecież tego nie wpiszesz.

> i musi trzymać się standardów,

Jakich standardów?

> a to co robi musi być "łatwe do zrozumienia" przynajmniej przez fachowców.

Wpiszesz do umowy, że dostarczony kod ma być "łatwy do zrozumienia"?

>> Rewidowanie, czytanie, konsultowanie takiej specyfikacji ciężko jest
>> tak zrobić, żeby wyłapać wszystkie czy nawet większość takich błędów.
>> Dalsze
>
> Ba! Życie to ciężkie jest, a życie programisty szczególnie: nie każdy
> może pić drinki z palemką jak AL czy Knuth.

Nie rozumiem w jaki sposób taka konstatacja niweluje fakt, że wiele
specyfikacji zawiera błędy.

>> Drugi powód jest taki, że język naturalny nie jest wystarczająco
>> precyzyjny, żeby jednoznacznie opisać takie wymagania. W tekście pisanym
>
> Jeżeli - jako programista - nie potrafisz opisać wymagań - to nie
> potrafisz - także jako programista - napisać programu. ;)

Przecież gdyby zamawiający miał na etacie programistów potrafiących
napisać ten program, to by go w ogóle nie zamawiał, tylko kazał im napisać.

>> według umowy, to sobie spokojnie zbankrutuję, stracę tego laptopa co
>> go mam na majątku firmy, a z oszczędności zakupię kolejnego laptopa i
>> użyję go jako kapitału założycielskiego kolejnej spółki z oo.
>
> Zbankrutujesz... zdarza się. Ale twoja wiarygodność jako partnera w
> biznesie będzie równa zero, jeżeli nie ujemna. Dlatego na tym laptopie
> będziesz mógł ewentualnie pograć w Sapera.

E tam. Ludzie bankrutują, potem zakładają kolejne biznesy i jakoś
działają, często z większym powodzeniem niż poprzednio.

>> stratami. Może np. być tak, że złe położenie przycisku powoduje, że co
>> jakiś czas operator wciska nie ten przycisk i powoduje mniejsze lub
>> większe straty - nie wiadomo jakie, ale można oszacować
>> prawdopodobieństwo, że będą np. w przedziale 100-150 tys. I kwestia jest
>
> To po co się przejmować? Koszt wprowadzenia poprawki to 250 000 euro,
> bez poprawki straty wynoszą 150 000 euro.

Oczekiwane straty wynoszą 150 000 euro, na podstawie bardzo niepewnych
przesłanek. W rzeczywistości mogą być dużo wyższe.

> Nie wprowadzenie poprawki daje
> +100 000 euro. Wprowadzenie poprawki daje -100 000 euro oraz brak
> pewności, że to przyniesie spodziewane rezultaty i zakończy się
> wydatkiem jedynie tych 100 000 euro. Właśnie odkryliśmy czym jest
> konserwatyzm liberalny.

Przejmować się możesz tym, że decyzja o wydaniu dwóch milionów na syetm
oparta była na szacowanych zyskach czy oszczędnościach z użycia tego
systemu, wysokości powiedzmy pół miliona rocznie. To, że źle umieszczony
przycisk generuje rocznie 100 tysięcy strat powoduje, że korzyści z
oprogramowania są niższe niż oczekiwane. Znajdź cztery podobne problemy
i okaże się, że system za dwa miliony przynosi tyle samo strat, co
korzyści - równie dobrze możnabyuło tymi dwoma milionami napalić w piecu.

Co gorsza, ponieważ mówimy nie o pewnych zdarzeniach, tylko o ryzyku, to
może być tak, że wymieniasz pewny i stały koszt na ruletkę. Regularne
tracenie 100 tysięcy rocznie obniża twoją rentowność, ale można
przewidzieć i zarządzać firmą tak, żeby działała mimo tego. Losowy
problem narażający cię na losowe straty o wartości oczekiwanej 100
tysięcy może działać tak, że w pierwszym roku nie będzie żadnych strat,
w drugim żadnych, a w trzecim będzie pięć milionów, przez co firma
zbankrutuje i cała zabawa się zakończy.

W kmońcu problem klienta jest taki, że to, że cena zmiany wynosi 250
tysięcy, i wynikające z tego straty 100 tysięcy rocznie, są konsekwencją
złych wyborów samego zamawiającego, a w szczególności błędnego
przekonania, że kontrakt fixed price fixed scope jest dla niego
korzystniejszy.

do góry

W dniu 2013-07-19 20:37, slawek pisze:
> Użytkownik "Paweł Kierski" napisał w wiadomości grup
> dyskusyjnych:ksbbre$7n7$...@s...invalid...
>
>> Teraz czas na rozbieżności - podaj przykłady projektów, w których
>> wg Ciebie Agile na pewno się nie sprawdzi.
>
> 1. Zamówienia publiczne, które musi (bo takie prawo) rozstrzygnąć przetarg.

Cóż - z prawem i praktyką, które traktują stworzenie, utrzymywanie przez
jakiś czas i szkolenia pracowników (przekazanie systemu) każą traktować
jak produkt, a nie usługę świadczoną przez pewien czas, nie da się
zawalczyć. Co wg mnie świadczy raczej o ułomności praktyki i prawa.

Ale w aktualnej sytuacji - zgadzam się.

> 2. Programy robione ad hoc w jednoosobowym "zespole". Dotyczy także
> zespołu dwuosobowego.

To trochę jak z użyciem systemu kontroli wersji przez jedną lub dwie
osoby. Niby dodatkowy zbędny narzut, ale często się przydaje. Tak samo
elementy planowania i retrospekcji pozwalają wdrożyć się w pewne
pozytywne nawyki.

Pytanie bardziej konkretne - co z Agile będzie przeszkadzało w takim
projekcie?

> 3. Projekty ubezpieczane od ryzyka i szczególnego znaczenia (medycyna).
> W tym także związane z ochroną poufności.

Ubezpieczenie od ryzyka - przyznam, że się nie spotkałem. Ale na ile
mogę się domyślać, to Agile raczej pomoże - w kolejnych iteracjach
widać, jak poziom ryzyka się stabilizuje (dokładniejsze, oparte na
faktach szacowanie terminu, możliwa kontrola jakości w trakcie
wykonania).

Projekty szczególnego znaczenia (medycyna, lotnictwo) - to rzeczy
całkowicie ortogonalne. Duże ryzyko oznacza tyle, że trzeba np.
dowodzić poprawności całego rozwiązania lub chociaż elementów - w takim
razie zapisujemy to w definition of done.

Poufność - to już zupełnie nie w temacie. Jak sposób prowadzenia
projektu ma mieć wpływ na poufność?

> 4. Projekty tworzone społecznościowo na zasadzie totalnego wolontariatu.

Tu Agile może być niepotrzebny, bo cel projektu jest wypracowywany
wspólnie. I nie koniecznie celem tym jest produkt - czasem renoma
zespołu lub poszczególnych deweloperów. To już kompletnie inna bajka.

Ale jeśli jest jakiś cel produktowy i osoba/osoby, które chcą popychać
produkt w kierunku realizacji tego celu, to czemu nie skanalizować
wysiłków korzystając z elementów Agile?

>
> Z Agile trochę jest tak jak z demokracją. Niezła rzecz, byle stosować
> tam gdzie ma sens. Bo głosowaniem nie da się ustalić że każdy kwadrat
> jest trójkątem.

Pewnie tak. Natomiast nadal uważam, że Agile dużo szersze pole
zastosowań, niż to się jeszcze uważa. Nie jest oczywiście żadnym
panaceum.

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

do góry

W dniu 2013-07-19 22:07, Roman W pisze:
> On Fri, 19 Jul 2013 14:35:58 +0200, Paweł Kierski<n...@p...net> wrote:
>> Teraz czas na rozbieżności - podaj przykłady projektów, w których
>> wg Ciebie Agile na pewno się nie sprawdzi.
>
> Software wymagający drobiazgowych certyfikacji, np. medyczny.

Dla przypadku, gdy można certyfikować elementy systemu - jak najbardziej
się da. Certyfikacja jest jednym z elementów definition of done.

Nawet jeśli certyfikacja przewidziana jest tylko dla "kompletnego"
produktu, to nic nie stoi na przeszkodzie, żeby dojście do tego stadium
było prowadzone metodami zwinnymi.

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

do góry

Użytkownik "Andrzej Jarzabek" napisał w wiadomości grup
dyskusyjnych:ksh8j8$6hm$...@s...invalid...

>Nie rozumiem jaką w związku z tym masz tezę? Że można używać Linuxa jako
>systemu CRM, księgowości czy payroll?

A nie można używać do księgowości etc.? Jakiś zakaz jest czy co?

>Powiem w ten sposób - mam wiele lat przepracowanych w dużych firmach (a

Ok, to będzie ważne, zapamiętajmy więc to jako "FAKT A".

>kiedy przygotowuje ją ktoś, komu aktywnie zależy na tym, żeby jak
>najtrudniej było z niej skorzystać.

Ok, ale firma zamawiająca, sprzedająca "szlauchy i kalosze" (nie ma w niej
dość "mocy przerobowej" do zrobienia programu, ale szef przypadkiem ma
ukończone studia z informatyki, z zarządzania i z psychologii) może nie dać
się łatwo wykiwać. I szybko zorientować, że ktoś sabotuje współpracę
(utrudnia korzystanie).

Autentyczna historia: w pewnej firmie trzeba było wymienić klozety, położyć
kafelki/flizy i takie tam. Zdziwienie brygady remontowej nie miało granic,
gdy okazało się że szef firmy zna się na tym lepiej niż oni (nie całe życie
był szefem firmy) i... po prostu nie przepuści, ma być zrobione dobrze. A
umowę robili prawnicy, co prawda nie jacyś nadzwyczajni, ale wystarczająco
dobrzy...

>Jakie standardy? Nic mi nie wiadomo o jakichkolwiek standardach, które by
>można zadekretować umową, a które gwarantowałyby nieśmieciowość kodu.

Nie znasz? To znaczy że nie ma sensu zamawiać u ciebie programów ;)

>Kilka razy spotkałem się z sytuacją konieczności rozczytania kodu i
>wprowadzenia zmian do komponentów, na których nikt się nie znał, bo ten, co
>je robił odszedł z firmy, a nikt inny ich nie ruszał od dłuższego

W tym właśnie miejscu przypomnijmy sobie "FAKT A" (czyli: że masz bogate
doświadczenie i pracowałeś w wielu firmach).

Jeżeli Agile i ogólnie współpraca układają się tak dobrze - to nigdy nie
musiałbyś "rozczytywać kodu" - bo po prostu tym kodem zajmowałby się ten, co
pierwotnie go napisał.

To co robiłeś wynikało właśnie z tego, że - podobnie jak nieuchronna jest
"zmiana" - podobnie nieuchronne jest, że kiedyś "ktoś inny będzie musiał
poprawiać nasz program".

>kodem bez możliwości konsultowania się z autorem to wysiłek porównywalny z
>napisaniem tego kodu od początku. Nie mówię nawet, że dla mnie, bo ja

Ba! Niektórzy autorzy nie żyją, inni są niedostępni. Ale wiesz co?
Wynaleziono pismo, druk i nawet coś takiego jak dokumentacja, rysunek
techniczny, UML i takie tam.

>Oczywiście że oferowanie kodu źródłowego redukuje ryzyko klienta, ale też
>zwiększa ryzyko dostawcy. Dlatego distawcy się albo nie zgadzają, albo
>proponują wyższe ceny.

Dokładnie tak, jak w przypadku np. samochodów: można kupić tanie auto, bez
gwarancji, do którego nie ma części zamiennych ani serwisu - albo nieco
droższe, w którym jest serwis, są części zamienne i gwarancja, a do tego tak
proste w konstrukcji że nie wymaga np. specjalnych narzędzi do naprawiania.

>Wpiszesz do umowy, że dostarczony kod ma być "łatwy do zrozumienia"?

A jest jakiś problem, aby to wpisać? Oczywiście konkretne sformułowanie może
być nieco bardziej wyrafinowane i konsultowane z prawnikami.

Coś takiego w umowie powinno skutecznie odpędzić partaczy przy np.
przetargu.

>Przecież gdyby zamawiający miał na etacie programistów potrafiących napisać
>ten program, to by go w ogóle nie zamawiał, tylko kazał im napisać.

Może ich ma, ale oni mają co innego do roboty? A może ich ma, ale zbyt mało
ich jest?

Wyobraź sobie - firma zamawiająca ma dział IT z 3-4 dobrymi fachowcami.
Program, aby był na czas, musi pisać 15-20 ludzi. Więc firma zewnętrzna. Ale
tych 3-4 fachowców może dość łatwo zorientować się, czy wszystko jest
robione jak trzeba - czy też wykonawca partoli.

>E tam. Ludzie bankrutują, potem zakładają kolejne biznesy i jakoś działają,
>często z większym powodzeniem niż poprzednio.

W tej samej branży? Podaj przykłady. Ja znam jeden, ale facet najpierw, już
po bankructwie, spłacił wszystkich swoich wierzycieli.

>Oczekiwane straty wynoszą 150 000 euro, na podstawie bardzo niepewnych
>przesłanek. W rzeczywistości mogą być dużo wyższe.

Teraz wiem, dlaczego ja nie zamówiłbym u ciebie programu - raz piszesz
konkretne liczby (250 000, 100 000 etc.), potem "w rzeczywistości mogą być
dużo wyższe".

>Przejmować się możesz tym, że decyzja o wydaniu dwóch milionów na syetm
>oparta była na szacowanych zyskach czy oszczędnościach z użycia tego

I dlatego te oszacowania muszą być rzetelne, a nie wyssaną z palca
konfabulacją.

Jak ktoś tego nie rozumie, to niech poszuka najbliższego sandboxa i robi
babki z piasku, a nie poważny biznes.

do góry

> > Software wymagający drobiazgowych certyfikacji, np. medyczny.

> Nawet jeśli certyfikacja przewidziana jest tylko dla "kompletnego"
> produktu, to nic nie stoi na przeszkodzie, żeby dojście do tego stadium
> było prowadzone metodami zwinnymi.

Technicznie może i nie ma przeszkód, ale kulturowo będą. Agile kojarzy się z
nierobieniem niepotrzebnych rzeczy a tymczasem certyfikacja wykonywana przez podmiot
zewnętrzny (przez jakąś Agencję Sprawdzania Projektów i Produktów, odpowiednio dla
branży) robiona jest na podstawie *artefaktów*, które w potocznie rozumianym agile po
prostu nie powstają.
Problem jest tym bardziej widoczny, im bardziej eksponuje się wartość nieformalnych
rozmów i spotkań - jeżeli agile zachęca do tego, żeby Product Owner chodził ze Scrum
Masterem (albo w ogóle z całym zespołem) na przysłowiową pizzę w nadziei na
sprawniejszą wymianę myśli, to naturalne jest, że w takim pół-formalnym procesie
pewne tradycyjne artefakty nie powstaną. Tym bardziej, jeśli przedstawia się to jako
zaletę ("my tu robimy programy, które coś robią a nie dokumentację, która nic nie
robi").

No i na koniec taki zespół zanosi do Agencji Sprawdzania Projektów i Produktów swoje
dzieło a tam pani w recepcji mówi: proszę zostawić produkt *wraz z pełną
dokumentacją* na półce, odezwiemy się.
A tu dupa - produkt udało się jakoś ulepić, ale dokumentacja to była nasza rozmowa w
pizzerni. I tyle z certyfikacji.

Oczywiście to nie musi być zawsze prawdziwy scenariusz. Niektórzy usiłują robić coś
co się nazywa "continuous certification" i chodzi tam o to, żeby w każdej iteracji
kredyt certyfikacyjny się kumulował (tzn. żebyśmy byli coraz bliżej certyfikacji tak
samo jak jesteśmy coraz bliżej kompletnego produktu), ale fakt, że od paru lat się o
tym tylko rozmawia świadczy o tym, że jednak jest jakaś kulturowa ściana, która to
utrudnia, i to po obu stronach: zarówno po stronie wykonawców (za dużo pizzy) jak i
po stronie agencji certyfikacyjnych (ci z kolei nie chcą chodzić na pizzę).

Myślę, że wypracowanie dobrego nowego rozwiązania w tej dziedzinie zajmie jeszcze
jedną albo dwie generacje metod. Tzn. jeszcze nie teraz.

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

do góry

Użytkownik "Paweł Kierski" napisał w wiadomości grup
dyskusyjnych:ksipns$tfd$...@s...invalid...

>> 2. Programy robione ad hoc w jednoosobowym "zespole". Dotyczy także
>> zespołu dwuosobowego.

>Pytanie bardziej konkretne - co z Agile będzie przeszkadzało w takim
>projekcie?

Kluczowe jest "ad hoc" - czyli np. programiki mające wszystkiego 100
linijek... albo nawet jedną. Nic nie będzie przeszkadzało. Ale nic też Agile
nie pomoże.

Doraźnie tworzone jednorazówki. Oczywiście, można użyć Agile i do "99
bottles"...

>Poufność - to już zupełnie nie w temacie. Jak sposób prowadzenia
>projektu ma mieć wpływ na poufność?

Jeżeli dobrze zrozumiałem, to Agile polega na iteracjach. Mogę sobie
wyobrazić jednak zastosowania, które wymagają filozofii "wszystko albo nic".
Nie można mieć programu, który nie jest jeszcze całkiem gotowy, ale już jest
zaszyty w rozruszniku serca. Podobnie nie można mieć programu, który
"trochę" chroni np. wrażliwe dane z dużej bazy itp. Takie rzeczy wolno
uruchamiać (w docelowym środowisku) tylko wtedy, gdy są w 100% a może nawet
200% gotowe. Dlatego metodyka zakładająca "zrobimy i w razie czego będziemy
poprawiać" może być nie akceptowalna - "w razie czego" straty będą poważne,
nieodwracalne i niewybaczalne.

>produkt w kierunku realizacji tego celu, to czemu nie skanalizować
>wysiłków korzystając z elementów Agile?

Jeżeli już robiłbym coś za friko, to nie po to, aby ktoś mógł się bawić w
mojego szefa z tego powodu. Czyli - macie za darmo mój czas i
doświadczenie - ale to ja ustalam ile, gdzie i jak to wam daję. I czy w
ogóle. To, moim zdaniem, nie współbrzmi ze słowem "dyscyplina", a przecież
Agile dyscyplinuje uczestników...

do góry