On May 18, 10:06 pm, Wojciech Jaczewski <w...@o...pl> wrote:
> Andrzej Jarzabek wrote:
> > Te pomysły to przede wszystkim położenie nacisku na bezpośrednią
> > komunikację, np. że raczej warto włozyć wysiłek w to, żeby z zespołem
> > siedział ktoś dobrze rozumiejący dziedzinę, niż żeby ktoś taki
> > przygotował szczegółową dokumentację.
>
> Tylko że jeśli człowiek znający dziedzinę pójdzie na urlop, bądź jest chory,
> to z jego pomocy się nie skorzysta. Natomiast ze stworzonej dokumentacji -
> tak.

Istnieje genialne w swojej prostocie rozwiązanie tego problemu: mieć
przynajmniej dwóch takich ludzi w zespole i pilnować, żeby obydwaj nie
wyjeżdżali na urlop w tym samym czasie.

do góry

epsilon$ while read LINE; do echo \>"$LINE"; done < "Andrzej Jarzabek"
>> > Te pomysły to przede wszystkim położenie nacisku na bezpośrednią
>> > komunikację, np. że raczej warto włozyć wysiłek w to, żeby z zespołem
>> > siedział ktoś dobrze rozumiejący dziedzinę, niż żeby ktoś taki
>> > przygotował szczegółową dokumentację.
>> Tylko że jeśli człowiek znający dziedzinę pójdzie na urlop, bądź jest chory,
>> to z jego pomocy się nie skorzysta. Natomiast ze stworzonej dokumentacji -
>> tak.
>Istnieje genialne w swojej prostocie rozwiązanie tego problemu: mieć
>przynajmniej dwóch takich ludzi w zespole i pilnować, żeby obydwaj nie
>wyjeżdżali na urlop w tym samym czasie.

Trzech. Jeden na urlopie, jeden chory, a pracować ktoś musi...

--
\------------------------/
| K...@e...eu.org | http://www.nieruchomosci.pl/mieszkanie,10161961
| http://epsilon.eu.org/ |
/------------------------\

do góry

Mariusz Kruk wrote:

> epsilon$ while read LINE; do echo \>"$LINE"; done < "Andrzej Jarzabek"
>>> > Te pomysły to przede wszystkim położenie nacisku na bezpośrednią
>>> > komunikację, np. że raczej warto włozyć wysiłek w to, żeby z zespołem
>>> > siedział ktoś dobrze rozumiejący dziedzinę, niż żeby ktoś taki
>>> > przygotował szczegółową dokumentację.
>>> Tylko że jeśli człowiek znający dziedzinę pójdzie na urlop, bądź jest
>>> chory, to z jego pomocy się nie skorzysta. Natomiast ze stworzonej
>>> dokumentacji - tak.
>>Istnieje genialne w swojej prostocie rozwiązanie tego problemu: mieć
>>przynajmniej dwóch takich ludzi w zespole i pilnować, żeby obydwaj nie
>>wyjeżdżali na urlop w tym samym czasie.
>
> Trzech. Jeden na urlopie, jeden chory, a pracować ktoś musi...
>

Ale pod warunkiem, ze jak sa wszyscy trzej to i tak biora jedna pensje :)

--
Michal

do góry

On May 18, 8:37 pm, "Przemek O." <p...@o...eu> wrote:
> W dniu 2011-05-17 23:20, Andrzej Jarzabek pisze:
>
> >> Dokumentacja jest potrzebna zawsze przy dużych projektach.
>
> > Z mojego doświadczenia wynika, że bieżąca dokumentacja w dużych
> > projektach jest bardzo często mocno niekompletna,
>
> Kierownik projektu - dupa.
[...]
> j.w.

Może i tak, ale ostatecznie produkt idzie do produkcji i zarabia dla
firmy pieniądze, so he must be doing something right.

> > a koszt jej utrzymania przewyższa korzyści jakie przynosi.
>
> To nie jest prawdą.

Przynajmniej w niektórych przypadkach jest to prawdą.

> Koszt utrzymania przy wykorzystaniu automatów
> dokumentujących jest niewielki (zarówno czasowy jak i kwotowy). Tylko
> trzeba mieć dobry i sumienny zespół który wie co robi.

Z mojego doświadczenia: wartość automatycznie generowanej dokumentacji
też nie jest szczególnie wielka (w porównaniu z przeglądaniem kodu).
Czy ta wartość równoważy overhead, nie mam na ten temat zdania, ale
zdecydowanie uważam, że nie robi to większej różnicy.

Z drugiej strony nie jestem tez przekonany, czy automatyczne
generowanie dokumentacji jest jakoś sprzeczne z agile.

> > W skrócie - niepotrzebna.
>
> To już bujda na resorach. Jeśli nigdy nie była Ci potrzebna, to masz
> szczęście.

Byłaby potrzebna, gdyby była kompletna i aktualna. W takiej postaci
jak była, to pożytki korzystania z niej były równoważone przez szkody
- sumaryczna wartość zerowa, a koszt tworzenia i utrzymywania jednak
niezerowy.

> > Ktoś siedzi rok w projekcie i go nie zna? Chyba żartujesz.
>
> Ktoś kto siedzi rok w projekcie razem z kilkoma innymi programistami ma
> prawo nie pamiętać implementacji wszystkiego co zrobił na początku, lub
> tym bardziej co ktoś inny zrobił.

Ale jednak większość implementacji będzie pamiętał, bo regularnie
wchodzi w nią debuggerem, refaktoryzuje itd. Pytanie, czy overhead
związany z utrzymywaniem aktualnej i szczegółowej dokumentacji przez
cały czas równoważy to, że raz na rok komuś ta dokumentacja się przyda
żeby trochę szybciej zrozumieć jakiś rzadko używany kawałek kodu. I
jak na tę odpowiedź wpływa stosowanie np. rygorystycznych coding
standards, które zabraniają pisania kodu tak, żeby trudno go było
czytać.

Moje zdanie jest takie, że dla większości kodu da się go napisać tak,
żeby intencja była jasna i w tkaich przypadkach dokumentacja ma
niewielką wartość, a jej tworzenie jest stratą czasu. Są też
przypadki, gdzie problem jest nieredukowalny i kod będzie z
konieczności trudny do zrozumienia dla kogoś, kto nie siedzi w
problemie i nie zna koncepcji danego rozwiązania. I w takich
przypadkach dokumentację jak najbardziej należy tworzyć. Wydaje mi
się, że takie podejście nie jest sprzeczne z agile tak jak ja tę
koncepcję rozumiem.

> > Po pierwsze, po to masz coding standards, żeby nie było.
> > Po drugie, w praktyce zespół, który pracuje nad kodem od roku ma o nim
> > lepszą wiedzę, niż jest zawarta w dokumentacji. Jeśli praktykujesz
> > shared ownership, to masz sporą szansę na to, że dany programista będzie
> > sam znał odpowiedź. A jeśli nie, to praktykując kolokalizację zespołu,
> > łatwo jest mu po prostu zapytać i dostać odpowiedź. A jeśli utknie, to
> > po to masz daily standup, żeby ci, co wiedzą, mogli się zgłosić do pomocy.
>
> Teoria... piękna. W praktyce to tak nie działa.

Dobrze, w takim razie, i pytam o to bez żadnej szydery, proszę
opowiedz o swoich doświadczeniach, jak to działa w praktyce w
kolokalizowanych zespołach praktykujących coding standards, shared
ownership, daily standup i najlepiej jeszcze pair programming (albo
przynajmniej code review).

> > Ja mówię o tym, co w waterfallu jest tworzone w design phase. Wymagań i
> > analizy do tego nie wliczam.
>
> Tylko że to powstaje na ich podstawie. Z ogólnych bajek zleceniodawcy
> oprogramowanie się nie zmaterializuje. A i umowę wypadałoby podpisać na
> coś konkretnego, a nie na wyimaginowaną możliwość otrzymania być może
> czegoś co potrzebuje w bliżej nieokreślonym terminie.

Ja mówię, że design phase to jest osobny problem. Nawet jeśli masz
zformalizowane, udokumentowane i zakontraktowane wymagania, to możesz
pominąć design phase i od razu zabrać się za kodowanie.

> >> Yea! Right! Jak już pisałem to się sprawdzi przy pisaniu notatnika.
> > A jednak całkiem spore programy się w ten sposób robi.
>
> A bo ja wiem, nie spotkałem się jeszcze z dużym projektem tworzonym w
> całości z uwzględnieniem Agile. Częściowo tak, w całości nie. Ale może
> pracuje w dziedzinach gdzie z założenia nie można sobie na to pozwolić.

A ja się spotkałem (nie z bardzo bliska co prawda). Tzn. oczywiście w
aspekatch, które były objęte 'scope' danej metodologii.

> > Tu trochę przyznam, że wychodzę poza swoje kompetencje, ale o ile
> > rozumiem, to przede wszystkim XP pomyślanie jest nie pod kątem
> > projektów, które się w pewnym momencie zdaje i zamyka, tylko raczej do
> > takich, które w pewnym (wczesnym) momencie mają pierwszy release, a
> > potem regularni i dość często kolejne release'y, np. co miesiąc albo co
> > dwa miesiące.
>
> To co opisujesz, to bardziej mi pasuje do starej definicji
> prototypowania z ominięciem najważniejszej części, że prototypu nie
> wdraża się produkcyjnie.

Hm? Prawie każdy produkt software'owy po wypuszczeniu do produkcji ma
kolejne wersje.

> > Jeśli się nie da, a decyduje się na XP, to się zakłada, że kontrakt
> > będzie renegocjowany po zawarciu, że zlecenidawca będzie skłonny do
> > zmiany kontraktu jak zobaczy, że dostaje w pierwszej kolejności to,
> > czego najbardziej potrzebuje i że będzie miał szybko funkcjonalny
> > produkt. Wtedy odpowiednie role w zespole osłaniają przed tym programistów.
>
> Nie rozumiem. Patrzę teraz z perspektywy przedsiębiorcy. Mnie interesuje
> na kiedy mogę mieć produkt i ile za niego mam zapłacić. Średnio mnie
> interesuje czy dostanę jakiś kawałek wcześniej czy później. Ważna jest
> data wdrożenia całości.

Nieprawda. Jako przedsiębiorcę, interesuje cię, czy zarobisz na tym
oprogramowaniu i ile.

Jeśli dochodzisz do wniosku, że potrzebujesz jakiegoś programu do
zarabiania, i określasz zespół ficzerów jaki ten program (jak ci się
wydaje) powinien mieć, to zawsze musisz brać pod uwagę taki
scenariusz, że jeden kontrahent powie, że zajmie to trzy lata, drugi
zażyczy sobie 150 milionów dolarów, a trzeci powie że zrobi w 12
miesięcy, ale nie zgodzi się na takie kary za opóźnienie, jakbyś
chciał (w praktyce pozostawiając sobie furtkę do nawet znacznych
opóźnień).

W końcu bierzesz tego trzeciego, umawiasz się na 18 miesięcy i
czekasz. Po 9 miesiącach twój konkurent zaczyna eksploatację swojego
programu, który ma 1/3 ficzerów zamówionych przez ciebie, ale już
pozwala mu zarabiać. Zarobione pieniądze idą między innymi na
finansowanie dalszego dewelopmentu, i brakujące ficzery stopniowo
pojawiają się w programie konkurencji w wersjach 1.1, 1.2, 1.3. Po 18
miesiącach twój wykonawca ci mówi, że niestety nie ma jeszcze dla
ciebie zamówionego programu, bo wystąpiły obiektywne problemy z
implementacją niektórych ficzerów, ale że za dwa miesiące już będzie.
Na otarcie łez dostajesz symboliczną karę. Po kolejnych dwóch
miesiącach kontrahent mówi, że beta testing wyłapał poważny problem i
potrzebuje jeszcze miesiąc. W międzyczasie świat się zmienia, bo
regulator wprowadził nowe przepisy, albo tąpnął rynek metali
nieżelaznych, albo ktoś wymyślił nowy rodzaj kauczuku i okazuje się,
że połowa ficzerów, które wpisałeś w kontrakt jest ci niepotrzebnych,
a za to przydałoby się kilka nowych ficzerów. Idziesz z tym do swojego
wykonawcy a on na to, że tak, owszem, da się zrobić, możemy
renegocjować kontrakt.

> Przykład z życia. Właśnie będą mi kłaść kostkę na posesji. Rozmawiałem z

O kurcze, w tym momencie przebiłes o kilka długości wszystkie
idiotyczne metafory i analogie jakie pojawiły się w tej dyskusji.

> A wystarczyło zrobić na początku analizę, spytać co po tym będzie
> jeździć, zaproponować wzór, kolor itd itp. Jeden projekt, jedno
> wykonanie i płaca za faktyczny metraż i brak straconego czasu.
> I tylko pozornie nie ma to związku z tworzeniem oprogramowania.

I tylko pozornie nie ma związku z dowodzeniem Wielkiego Twierdzenia
Fermata.

> > No i oczywiście niektóre projekty są wewnętrzne, więc nie ma całego tego
> > krapu.
>
> To całkiem inna bajka. Jeśli ktoś choć raz pisał projekt wewnętrzny to
> dobrze o tym wie.

Jeszcze uściślę, nie chodzi mi o projekt wewnętrzny w sensie "jest
używany przez firmę a nie klientów", tylko "jest zamawiany przez
kierownictwo firmy, a nie przez klienta". W odróżnieniu od sytuacji,
kiedy przychodzi klient do firmy i mówi "chcę to a to", sytuacja kiedy
ktoś w firmie wychodzi z inicjatywą "gdybyśmy zrobili program, który
robi to-a-to, to może udałoby się to komuś sprzedać". I ja w takim
sensie pracuję głównie przy projektach wewnętrznych, i wtedy myślenie
jest takie, że jeśli można zacząć sprzedawać program z okrojoną
funkcjonalnością za 6 miesięcy, a potem dodawać ficzery w kolejnych
wersjach, albo można zażądać pełnego zestawu ficzerów i czekać 18
miesięcy na wersję 1.0, to to pierwsze rozwiązanie ma duży sens
biznesowy.

> > Powiem ci tak: mylisz się.
>
> No to moment, macie tych analityków i projektantów w zespole czy nie?

Mamy.

> > Nie wiem, może pracujesz w jakiejś specyficznej branży, albo
> > specyficznej kulturze, w której waterfall się sprawdza, ale consensus
> > jest jednak taki, że nie sprawdza się prawie nigdy.
>
> Żartujesz chyba, przez tyle lat się sprawdzał i nagle przestał?

Nigdy się nie sprawdzał.

> Fakt mam specyficzną branżę, wymagającą dużego nadzoru i certyfikowania
> oprogramowania. I jedno powiem, jeśli chcesz mieć oprogramowanie
> certyfikowane, to nie przejdzie brak projektu, analizy czy dokumentacji
> kodu.

Wiesz, to jest oczywiste, że jak potrzebujesz certyfikacji, to
spełniasz wymogi certyfikacji niezależne od tego, czy one mają poza
tym sens, czy nie.

Tak z ciekawości, ta certyfikacja polega też na tym, że certyfikują
wam cały proces, tzn. muszą być jakieś konkretne fazy zbierania
wymagań, analizy, designu itd. z datami rozpoczęcia i zakończenia, czy
tylko wymagają artefaktów? Bo przecież to, o czym ja piszę, nie
wyklucza wcale istnienia projektu, analizy i dokumentacji kodu w
momencie zakończenia projektu.

> > Ja też pracowałem z analitykami, wydaje mi się, że dość dobrymi, ale
> > zawsze było tak, że dokumenty, które wyprodukowali trzeba było mocno
> > modyfikować w trakcie developmentu. I komunikacja, a nie dokumentacja,
> > była kluczowa dla skuteczności realizacji _rzeczywistych_ wymagań.
>
> Ale komunikacja zawsze jest istotna. Tyle że analityk musi znać zarówno
> specyfikę branży dla której pisze się oprogramowanie, jak i możliwości
> zespołu. Z mojej strony mogę jedynie zauważyć, że o ile modyfikacja
> wymagań (z zasady ich doprecyzowanie) ma miejsce, jednak wyłapywane to
> jest na etapie tworzenia projektu aplikacji a nie w fazie kodowania.
> Zmiany w fazie projektowania są dużo mniej kosztowne niż w fazie kodowania.

To ja powiem tak: może w waszej specyficznej branży się sprawdza, ale
poza nią to jest piękna teoria, bo w fazie projektowania klient czy
domain expert przeczyta dokument, popatrzy na schemat i powie "tak,
tak to właśnie ma działać", a jak mu pokażesz wersję alfa, to powie
"nie, zuepłnie nie o to chodziło", "jeśli nie ma tej informacji, to ta
funkcja jest bezużyteczna", "owszem, w dokumencie tego nie ma, ale to
oczywiste". I okazuje się, że musisz wyrzucić połowę kodu i 3/4
projektu.

do góry

On May 19, 9:47 am, Mariusz Kruk <M...@e...eu.org> wrote:
> epsilon$ while read LINE; do echo \>"$LINE"; done < "Andrzej Jarzabek"
>
> >> Tylko że jeśli człowiek znający dziedzinę pójdzie na urlop, bądź jest chory,
> >> to z jego pomocy się nie skorzysta. Natomiast ze stworzonej dokumentacji -
> >> tak.
> >Istnieje genialne w swojej prostocie rozwiązanie tego problemu: mieć
> >przynajmniej dwóch takich ludzi w zespole i pilnować, żeby obydwaj nie
> >wyjeżdżali na urlop w tym samym czasie.
>
> Trzech. Jeden na urlopie, jeden chory, a pracować ktoś musi...

Ale przeciez masz w biurze iluś-tam programistów, którzy od iluś
miesięcy pracowai nad tym tematem i rozmawiali z tymi ludźmi.
Prawdodpobnie będą mieli jednak jakieś pojęcie o tym, co należy dalej
robić, żeby przez ten tydzień czy dwa robota kompletnie nie stanęła.
Poza tym masz przy projekcie ileś tam innych czynności, które nie
wymagają udziału customera/analityka/domain experta: testowanie,
refaktoryzacja, optymalizacja, research, ćwiczenia integracyjne ;-)

do góry

On May 19, 9:49 am, Michal Kleczek <k...@g...com> wrote:
> Mariusz Kruk wrote:
>
> > Trzech. Jeden na urlopie, jeden chory, a pracować ktoś musi...
>
> Ale pod warunkiem, ze jak sa wszyscy trzej to i tak biora jedna pensje :)

Albo jeden, tylko że bez prawa do urlopu i chorobowego.

do góry

On May 18, 8:31 pm, A.L. <l...@a...com> wrote:
>
> Drogi Kolego, s pisania Kolegi wnosze ze Kolaga jest na trzecim
> semestrze informatyki, a software pzremyslowego nie mowiac o jego
> prdukcji, nei widzial nawet pzrez szybe.

Drogi Kolego, nie napiszę, co wnoszę z pisania Kolegi, bo nie
interesuje mnie wymiana obelżywych adpersonów.

do góry

On 2011-05-19, Andrzej Jarzabek <a...@g...com> wrote:
>> Koszt utrzymania przy wykorzystaniu automatów
>> dokumentujących jest niewielki (zarówno czasowy jak i kwotowy). Tylko
>> trzeba mieć dobry i sumienny zespół który wie co robi.
>
> Z mojego doświadczenia: wartość automatycznie generowanej dokumentacji
> też nie jest szczególnie wielka (w porównaniu z przeglądaniem kodu).

Bo ja wiem? Nawet w niewielkich projektach, gdy mam kod podzielony na
moduły, wolę oglądać API modułu pisanego parę tygodni temu
w przeglądarce HTML niż w kodzie źródłowym, w którym zresztą i tak muszą
być takie same komentarze określające konwencje, jak te idące do
perldoca czy innego doxygena.

Inaczej: jeśli te komentarze i tak już tam muszą być, to czemu by
przyzerowym kosztem ich nie wyróżnić (dla człowieka i dla generatora
dokumentacji) i nie wygenerować z nich dokumentacji dla API?

> Czy ta wartość równoważy overhead, nie mam na ten temat zdania, ale
> zdecydowanie uważam, że nie robi to większej różnicy.

Wielkiej różnicy nie robi, ale moim zdaniem i tak jest wystarczająca
żeby zrównoważyć koszt wprowadzenia formatowania.

>> > Tu trochę przyznam, że wychodzę poza swoje kompetencje, ale o ile
>> > rozumiem, to przede wszystkim XP pomyślanie jest nie pod kątem
>> > projektów, które się w pewnym momencie zdaje i zamyka, tylko raczej do
>> > takich, które w pewnym (wczesnym) momencie mają pierwszy release, a
>> > potem regularni i dość często kolejne release'y, np. co miesiąc albo co
>> > dwa miesiące.
>>
>> To co opisujesz, to bardziej mi pasuje do starej definicji
>> prototypowania z ominięciem najważniejszej części, że prototypu nie
>> wdraża się produkcyjnie.
>
> Hm? Prawie każdy produkt software'owy po wypuszczeniu do produkcji ma
> kolejne wersje.

Ale co miesiąc? O_o
Toż samo testowanie czy wszystko działa w środowisku zbliżonym do
produkcji trwa tyle czasu (patrzę z perspektywy admina, więc osoby,
która to wdraża u klienta na produkcji).

--
Secunia non olet.
Stanislaw Klekot

do góry

On 2011-05-19, Andrzej Jarzabek <a...@g...com> wrote:
> On May 19, 9:49 am, Michal Kleczek <k...@g...com> wrote:
>> Mariusz Kruk wrote:
>>
>> > Trzech. Jeden na urlopie, jeden chory, a pracować ktoś musi...
>>
>> Ale pod warunkiem, ze jak sa wszyscy trzej to i tak biora jedna pensje :)
>
> Albo jeden, tylko że bez prawa do urlopu i chorobowego.

I bez prawa do śmierci. I bez prawa do złożenia wymówienia.

--
Secunia non olet.
Stanislaw Klekot

do góry

On May 18, 7:51 pm, "Przemek O." <p...@o...eu> wrote:
> W dniu 2011-05-18 14:44, Andrzej Jarzabek pisze:
>
> > A co zrobi, jeśli nie znajdzie dostawcy, który się na takie kary
> > zgodzi (i o którym z dużym prawdopodobieństwem da się powiedzieć, że
>
> Każda umowa ma określone konsekwencje w przypadku jej niewypełnienia. To
> czy będą one w niej zapisany, czy wynikną z kodeksu to inna sprawa.
> Zawsze istnieje odpowiedzialność sprzedawcy / producenta za wytworzony
> produkt.

Oczywiście, nigdy nie pisałem, że jest inaczej.

> > będzie wypłacalny)? Powszechnie wiadomo, ż projekty informatyczne
> > często mają opóźnienia i że warunki są często renegocjowane. Wykonawcy
>
> Źle zarządzanie projekty.

Możemy sobie to tak nazwać, ale w takim razie trzeba stwierdzić, że
zleceniodawca nie ma żadnej możliwości zapewnienia w momencie
składania zlecenia, że projekt nie będzie źle zarządzany, a w dodatku
- zwłaszcza w przypadku większych projektów - szansa, że projekt
będzie źle zarządzany jest znaczna.

> > oprogramowania, zwłaszcza jeśli mowa o dużych firmach, raczej nie będą
> > chętne do brania na siebie ryzyka gigantycznych strat w przypadku
> > kiedy okaże się, że czegośtam w praktyce nie da się zaimplementować.
>
> Nigdy, nawet w czasach gdy pisałem samodzielnie oprogramowanie na
> zlecenie nie podjąłbym się go bez uprzedniej analizy wymagań oraz
> określenia wykonalności. Kurcze - przecież to są podstawy, na ich
> podstawie można oszacować czas trwania projektu oraz jego wartość.
> Przecież nikt w umowie nie wpisze wartości roboczogodziny tym bardziej
> jeśli nie ustali się czasu potrzebnego na realizację projektów. Aż tak
> naiwnych klientów nie ma.

Poszukaj pod "time and materials contract". POza tym są jeszcze inne
możliwości układów, np. proponowany w XP "negotiated scope contract".

> > Analogią raczej byłoby zamówienie stworzenia nowego modelu traktora.
> > Firma potrzebuje nowy model traktora, który będzie maił jakiś
> > specjalny ficzer, i dostaje taki model, tylko że po dostarczeniu
> > okazuje się, że ten model grzęźnie w błocie i jako taki jest
> > bezużyteczny. Wykonawca twierdzi, że dostarczony prototyp spełnia
> > wszystkie warunki zapisane w umowie, a jak zleceniodawca chce taki,
> > który nie grzęźnie, to on chętnie podpisze kolejną umowę na wersję
> > 2.0, tylko że będzie to kosztowało 50 milionów i zajmie kolejne dwa
> > lata.
>
> Po pierwsze jeśli chodzi o traktory to z zasady grzęzną w błocie. Od

Przepraszam, nie znam się na traktorach i nie chcę się znać. Posdstaw
sobie za grzęźnięcie w błocie coś innego, co dyskwalifikuje traktor.

Proponuję w związku z tym porzucić metaforę traktorową i rozmawiać o
tworzeniu oprogramowania.

> Co więcej, analityk w trakcie pracy z klientem bez problemu by to
> wyłapał, przy wizycie na tym błotnistym polu. A mając takie wymaganie,
> wytwórca mógłby przed przystąpieniem do realizacji zlecenia określić czy
> w ogóle jest w stanie coś takiego wykonać.

Przecież analityk pracuje dla wykonawcy, jaki miałby interes w tym,
żeby doradzać klientowi, żeby nie zapomniał o wpisaniu błota do umowy?

do góry