On 2013-07-17, A.L <a...@a...com> wrote:
> On Wed, 17 Jul 2013 20:17:45 +0000 (UTC), "Stachu 'Dozzie' K."
><d...@g...eat.some.screws.spammer.invalid> wrote:
>
>>I to pisze wielki A.L., który widział wszystko w przemyśle w tej swojej
>>hameryce.
>
> Kompleksy masz?..

Nie. Tak bezinteresownie powkurzać cię chciałem tym przytykiem. Chociaż
masz tu trochę racji, ostatnio nie zasłużyłeś sobie na docinki
skierowane w ego.

>>Bywa i tak, że klient
>>(duży) chce, żeby firma programistyczna (duża) wytwarzała mu produkt
>>zgodnie z którąś metodyką agile, co jak najbardziej jest zapisane
>>w umowie.
>
>
> Klienat gowno obchodzi na pgol jaka metodyka bedzie wykonywany
> projekt. Projekt ma byc dobrze, wedle umowy i na czas.

ORLY? To ciekawe czemu w tym przypadku zastrzegł sobie w umowie edżajla.
Jakiś niekumaty ten klient alboco.

>>Nawet ja, smarkacz i gówniarz przy tobie, widziałem takie
>>rzeczy. Bo wiesz, negocjowanie załącznika do kontraktu jest bardzo
>>kosztownym procesem biznesowym i zwyczajnie się nie opłaca przy
>>przeniesieniu przycisku z miejsca na miejsce.
>
> Ja nie jestem w biznesie robienia przyciskow. Chyba jednak mowimy o
> roznych rzeczach.

Mówimy o biznesie i metodykach wytwarzania oprogramowania. Nie
ograniczaliśmy się do biznesu DużychProgramówPrologowych[tm]. A ten
konkretny produkt akurat chodził (chodzi) jako backend usługi
zbierającej dane z urządzeń mobilnych i nie chodziło o zmiany wyglądu
przycisków, gdybyś chciał dyskredytować przykład.

>> Twierdzenie, że wszystko da się
>>a priori uregulować i zawrzeć w umowie -- to dopiero jest utopijne
>>myślenie.
>>
>
> Ale myslenie Agilowcow zw umowa W OGOLE niepotrzebna to tez promach.

Postulaty, które im zarzucasz, oczywiście są równie niedorzeczne.
Ale zdajesz sobie sprawę, że trochę co innego postulują, niż ty im
zarzucasz?

>>> i jezeli wina lezy po stronie firmy
>>> programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
>>> w sadzie. O czym prasa fachowa od czasu do czasu donosi
>>
>>Prasa fachowa donosi też od czasu do czasu o nieudanych wdrożeniach
>>w metodykach nie-agile. Co z tego wynika?
>
> Ze klient - nasz pan

A nie że metodyki nie-agile są do dupy, skoro są nieudane wdrożenia?
To, rzecz jasna, wniosek po użyciu (zastosowanej przez ciebie na
potrzeby argumentu przeciw agile) reguły wnioskowania
"są niepowodzenia => zła metoda".

--
Secunia non olet.
Stanislaw Klekot

do góry

On Wed, 17 Jul 2013 23:08:08 +0000 (UTC), "Stachu 'Dozzie' K."
<d...@g...eat.some.screws.spammer.invalid> wrote:

>On 2013-07-17, A.L <a...@a...com> wrote:
>> On Wed, 17 Jul 2013 20:17:45 +0000 (UTC), "Stachu 'Dozzie' K."
>><d...@g...eat.some.screws.spammer.invalid> wrote:
>>
>>>I to pisze wielki A.L., który widział wszystko w przemyśle w tej swojej
>>>hameryce.
>>
>> Kompleksy masz?..
>
>Nie. Tak bezinteresownie powkurzać cię chciałem tym przytykiem.

Pudlo. Nie jestes w stanie mnie wkurzyc. Mozesz tylko rozssmieszyc.

>Chociaż
>masz tu trochę racji, ostatnio nie zasłużyłeś sobie na docinki
>skierowane w ego.
>

naparwde? Staaaryyy... Co to ma wspolnego z moin ego? Ja tutaj pisuje
w znaczniej mierze dla rozrywki.

>>>Bywa i tak, że klient
>>>(duży) chce, żeby firma programistyczna (duża) wytwarzała mu produkt
>>>zgodnie z którąś metodyką agile, co jak najbardziej jest zapisane
>>>w umowie.
>>
>>
>> Klienat gowno obchodzi na pgol jaka metodyka bedzie wykonywany
>> projekt. Projekt ma byc dobrze, wedle umowy i na czas.
>
>ORLY? To ciekawe czemu w tym przypadku zastrzegł sobie w umowie edżajla.
>Jakiś niekumaty ten klient alboco.
>

Jaki kilent? A tak w ogole, nie widziales klientow-debili?

>>>Nawet ja, smarkacz i gówniarz przy tobie, widziałem takie
>>>rzeczy. Bo wiesz, negocjowanie załącznika do kontraktu jest bardzo
>>>kosztownym procesem biznesowym i zwyczajnie się nie opłaca przy
>>>przeniesieniu przycisku z miejsca na miejsce.
>>
>> Ja nie jestem w biznesie robienia przyciskow. Chyba jednak mowimy o
>> roznych rzeczach.
>
>Mówimy o biznesie i metodykach wytwarzania oprogramowania. Nie
>ograniczaliśmy się do biznesu DużychProgramówPrologowych[tm]. A ten
>konkretny produkt akurat chodził (chodzi) jako backend usługi
>zbierającej dane z urządzeń mobilnych i nie chodziło o zmiany wyglądu
>przycisków, gdybyś chciał dyskredytować przykład.
>
Nie wiem o czym piszesz. Masz jakies kompleksy z tym Prologiem? Naucz
sie, to nei takie trudne

>>> Twierdzenie, że wszystko da się
>>>a priori uregulować i zawrzeć w umowie -- to dopiero jest utopijne
>>>myślenie.
>>>
>>
>> Ale myslenie Agilowcow zw umowa W OGOLE niepotrzebna to tez promach.
>
>Postulaty, które im zarzucasz, oczywiście są równie niedorzeczne.
>Ale zdajesz sobie sprawę, że trochę co innego postulują, niż ty im
>zarzucasz?

Nie chce mi sie dalej komentowac bo mi sie znudzilo

A.L.

do góry

On 17/07/2013 16:56, A.L. wrote:
> On Tue, 16 Jul 2013 23:19:04 -0700 (PDT), Adam Klobukowski
> <a...@g...com> wrote:
>
>> zasadą Agile jest to że wymagania się zmieniają. W momencie zmiany,
>> reprezentant klienta dowiaduje się czy trzeba coś zmienić w już
>> wykonanych elementach i albo to zaakceptuje (i przez to dodatkowy
>> budżet) albo nie. Nie mam w tym mowy aby firma tworząca system
>> robiła coś za darmo.
>
> To jest mniej wiecej takie pisanie jak to ze komunizm jest
> najlepszym ustrojem na swiecie. Utopia, znaczy. Juz ja widze klienta
> ktory placi dodatkowo za to ze programisci cos na odwrot zrozumieli.

Jeśli z umowy wynika, że ma zapłacić, to może zapłacić.

Poza tym w Agile są praktyki zapobiegające takim sytuacjom, typu ATDD/BDD.

> Ci co wymyslaja takie rzeczy, nigdy nei widzieli z bliska ani
> pzremyslu, ani klienta. Nie wiedza ze soft robi sie na podstawie
> umowy, a kazde odstepstwo od umowy musi byc negocjowane i zawarte w
> rozszerzeniu do umowy, i jezeli wina lezy po stronie firmy
> programistycznej, klient nei zaplaci. Mozna sie w razie czego
> spotkac w sadzie. O czym prasa fachowa od czasu do czasu donosi

Soft się robi na podstawie umowy, ale umowy mogą być różnie sformułowane
- nie zawsze jest to "wykonawca wykona software według specyfikacji z
załącznika C w terminie nie później niż ..., za co zamawiający zapłaci
kwotę $BIGNUM".

do góry

On 17/07/2013 22:05, A.L. wrote:
> On Wed, 17 Jul 2013 20:17:45 +0000 (UTC), "Stachu 'Dozzie' K."
>
>> Bywa i tak, że klient
>> (duży) chce, żeby firma programistyczna (duża) wytwarzała mu produkt
>> zgodnie z którąś metodyką agile, co jak najbardziej jest zapisane
>> w umowie.
>
> Klienat gowno obchodzi na pgol jaka metodyka bedzie wykonywany
> projekt. Projekt ma byc dobrze, wedle umowy i na czas.

Może obchodzić, bo metodyka może obejmować uwzględnianie zmian w
wymaganiach, priorytetyzację, klaryfikację wymagań, dostarczanie wersji
demonstracyjnych/RC, przejście od zaakceptowania wersji demonstracyjnej
do release, kontynuację rozwoju oprogramowania po release itd.

W szczególności dla popularnych metodologii Agile wygląda to tak, że
operują one na iteracjach, których długość jest uzgadniana z klientem
(typowo od tygodnia do miesiąca), gdzie na początku iteracji klient
priorytetyzuje zmiany na podstawie szacunków podanych przez wykonawcę,
planuje się transzę zmian do wykonania w kolejnej iteracji, po czym na
koniec iteracji klient dostaje wersję demo, przy której będzie mógł się
zdecydować, czy woli zrobić release, czy zlecić kolejną iterację (czy
jedno i drugie). Metodologia z umowy może mówić, że takie demo jest
"release-ready", znaczy jeśli klientowi odpowiada funkcjonalność, to
może zrobić go-live czy przejść do UAT z taką wersją jak dostał, bez
konieczności np. dodatkowej fazy QA.

>> Nawet ja, smarkacz i gówniarz przy tobie, widziałem takie
>> rzeczy. Bo wiesz, negocjowanie załącznika do kontraktu jest bardzo
>> kosztownym procesem biznesowym i zwyczajnie się nie opłaca przy
>> przeniesieniu przycisku z miejsca na miejsce.
>
> Ja nie jestem w biznesie robienia przyciskow. Chyba jednak mowimy o
> roznych rzeczach.

W niektórych programach są przyciski, a problem przeniesienia przycisku
może wystąpić w programie niezależnie od tego, co ten program konkretnie
robi - może służyć powiedzmy do obracania egzotycznymi papierami
wartościowymi, a zmiana położenia przycisku może wynikać z tego, że
trejderzy w UAT zgłoszą, że interfejs użytkownika jest niekonekwentny i
łatwo omyłkowo klinkąć w zły przycisk, co może mieć bardzo kosztowne
konsekwencje dla firmy. Komuś, nie mówię, że tobie, ale powiedzmy
jakiemuś Iksińskiemu pracującemu przy wykonaniu takiego softu może się
wyadawć, że jest w biznesie skomplikowanych algorytmów wyceniania
egzotycznych instrumentów czy optymalizowania kosztów transakcji, ale
jednak jest również w biznesie robienia przycisków - nawet jeśli akurat
sam tych przycisków nie robi.

Nawet jeśli faktycznie akurat to, nad czym pracujesz nie ma żadnych
przycisków, to zazwyczaj oprogramowanie ma jakąś formę komunikowania się
z użytkownikiem czy operatorem, czy to będą logi, parametry linii
poleceń, pliki konfiguracyjne i tak dalej. I analogiczny problem do
przeniesienia przycisku też się da znaleźć. Powiedzmy: komunikat w logu
na temat jakiegoś problemu nie zawiera istotnej informacji
potrzebnej/pomocnej do namierzenia źródła problemu. Załóżmy, że umowa
jest na tyle szczegółowa, że wynika z niej, że przy tym rodzaju problemu
powinien pojawić się w logu komunikat o wystąpieniu owego problemu, ale
nie na tyle szczegółowa, żeby specyfikować jakie konkretnie dane się w
tym komunikacie znajdą. Masz więc konwersację:
"Wasz program wypisał komunikat 'Błąd importu: nielegalny numer NIP',
ale nie napisał o który NIP chodzi. Czy możnaby dołączyć ten numer do
komunikatu?"
"W umowie nic nie ma, że ma logować błędne NIP-y. Możemy to zrobić jako
change request, za dwa tygodnie przygotujemy aneks do umowy"
Aneks za dwa tygodnie może opiewać na kwotę 100 tysięcy dolarów, plus
trzeba zaangażować dział prawny, procurement i co tam jeszcze.

do góry

On 18/07/2013 02:58, A.L. wrote:
> On Wed, 17 Jul 2013 23:08:08 +0000 (UTC), "Stachu 'Dozzie' K."
> <d...@g...eat.some.screws.spammer.invalid> wrote:
>
>> ORLY? To ciekawe czemu w tym przypadku zastrzegł sobie w umowie edżajla.
>> Jakiś niekumaty ten klient alboco.
>
> Jaki kilent? A tak w ogole, nie widziales klientow-debili?

To jest obusieczny argument, bo również na twoje obserwacje, że klienci
chcą umowy gdziee będzie specyfikacja softu, termin i kwota (tzw. fixed
scope, fixed price contract) - są debilami.

do góry

On 2013-07-18, A.L <a...@a...com> wrote:
>>>>Bywa i tak, że klient
>>>>(duży) chce, żeby firma programistyczna (duża) wytwarzała mu produkt
>>>>zgodnie z którąś metodyką agile, co jak najbardziej jest zapisane
>>>>w umowie.
>>>
>>>
>>> Klienat gowno obchodzi na pgol jaka metodyka bedzie wykonywany
>>> projekt. Projekt ma byc dobrze, wedle umowy i na czas.
>>
>>ORLY? To ciekawe czemu w tym przypadku zastrzegł sobie w umowie edżajla.
>>Jakiś niekumaty ten klient alboco.
>>
>
> Jaki kilent? A tak w ogole, nie widziales klientow-debili?

Jasne, jasne. Jak nagle niezgodność z twoim obrazem świata, to klient
jest debil. Spróbuj czegoś innego.

>>>>Nawet ja, smarkacz i gówniarz przy tobie, widziałem takie
>>>>rzeczy. Bo wiesz, negocjowanie załącznika do kontraktu jest bardzo
>>>>kosztownym procesem biznesowym i zwyczajnie się nie opłaca przy
>>>>przeniesieniu przycisku z miejsca na miejsce.
>>>
>>> Ja nie jestem w biznesie robienia przyciskow. Chyba jednak mowimy o
>>> roznych rzeczach.
>>
>>Mówimy o biznesie i metodykach wytwarzania oprogramowania. Nie
>>ograniczaliśmy się do biznesu DużychProgramówPrologowych[tm]. A ten
>>konkretny produkt akurat chodził (chodzi) jako backend usługi
>>zbierającej dane z urządzeń mobilnych i nie chodziło o zmiany wyglądu
>>przycisków, gdybyś chciał dyskredytować przykład.
>>
> Nie wiem o czym piszesz. Masz jakies kompleksy z tym Prologiem? Naucz
> sie, to nei takie trudne

Tylko wiesz, sysadminowi na wiele się nie przydaje, przynajmniej na
razie, a tymczasem mam inne materiały do nauki, takie, które mi się
rzeczywiście przydadzą (np. Attiya, Welch, "Distributed computing").

A swoją drogą, może tak dla odmiany odnieś się do argumentu? Nie
ograniczaliśmy się do żadnego konkretnego biznesu, w szczególności
biznesu, który ty widzisz, a którego nie opisujesz, bo zasłaniasz się
podpisanymi NDAs.

>>>> Twierdzenie, że wszystko da się
>>>>a priori uregulować i zawrzeć w umowie -- to dopiero jest utopijne
>>>>myślenie.
>>>>
>>>
>>> Ale myslenie Agilowcow zw umowa W OGOLE niepotrzebna to tez promach.
>>
>>Postulaty, które im zarzucasz, oczywiście są równie niedorzeczne.
>>Ale zdajesz sobie sprawę, że trochę co innego postulują, niż ty im
>>zarzucasz?
>
> Nie chce mi sie dalej komentowac bo mi sie znudzilo

Z jakiegoś powodu mnie to nie dziwi. Ciekawe.

--
Secunia non olet.
Stanislaw Klekot

do góry

On Wednesday, 17 July 2013 17:56:21 UTC+2, A. L. wrote:
> On Tue, 16 Jul 2013 23:19:04 -0700 (PDT), Adam Klobukowski
>
> <a...@g...com> wrote:
>
> >> Jest też ciekawe kto, przy zmianie specyfikacji zamówienia generowanej przez
> >> kupującego program, płaci za ekstra wysiłek? Z podręczników Agilizmu wynika,
> >> że to jest free (tj. płaci swoim czasem/zasobami firma softwareowa), ze
> >> zdrowego rozsądku wynikałoby że ???
> >
> >Metodologie Agile (bo jest ich wiele) zakładają że w projekcie, aktywnie bierze
udział reprezentant klienta. Jednocześnie krótkie okresy iteracji projektu powodują
dobrą widoczność zaawansowania. Zmianę wymagań można rozegrać na wiele sposobów, ale
podstawową zasadą Agile jest to że wymagania się zmieniają. W momencie zmiany,
reprezentant klienta dowiaduje się czy trzeba coś zmienić w już wykonanych elementach
i albo to zaakceptuje (i przez to dodatkowy budżet) albo nie. Nie mam w tym mowy aby
firma tworząca system robiła coś za darmo.
>
> To jest mniej wiecej takie pisanie jak to ze komunizm jest najlepszym
> ustrojem na swiecie. Utopia, znaczy. Juz ja widze klienta ktory placi
> dodatkowo za to ze programisci cos na odwrot zrozumieli.

Nigdy nie napisałem że metodologia Agile jest najlepsza.

Tu nie chodzi o to że programiści źle zrozumieli. Zasadą metodyk Agile jest to że
wymagania są płynne i mogą się zmienić. Taka zmiana nie jest czymś negatywnym.

> Ci co wymyslaja takie rzeczy, nigdy nei widzieli z bliska ani
> pzremyslu, ani klienta. Nie wiedza ze soft robi sie na podstawie
> umowy, a kazde odstepstwo od umowy musi byc negocjowane i zawarte w
> rozszerzeniu do umowy, i jezeli wina lezy po stronie firmy
> programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
> w sadzie. O czym prasa fachowa od czasu do czasu donosi

Nie chodzi też o odstępstwa od umowy. Wystarczy podpisać umowę która zakłada że
finalny produkt może się zmienić.

Przy budowie każdego dużego systemu informatycznego wymagania zmieniają się
praktycznie zawsze. Czas powstawania dużego projektu to zazwyczaj co najmniej rok,
zazwyczaj więcej. W tym czasie wiele może się zmienić. W przypadku klasycznych
metodologii, klient zazwyczaj widzi system dwa razy - jak mu go sprzedają i jak mu go
dostarczają. Odstęp czasowy pomiędzy tymi momentami jest dużym problemem. To że
klient coś zamówił, to nie znaczy że jak to dostanie to właśnie tego chce.

W przypadku Agile, klient jest włączony w cały proces powstawania systemu, często
może zacząć go używać już w trakcie jego powstawania. W ten sposób klient ma lepszą
widoczność tego jak system będzie wyglądał a kiedy (co nieuniknione) zmienią się jego
wymagania co do systemu, to wykonawca nie wypnie się mówiąc 'mieliśmy taką a taką
umowę' ale odpowiednio dostosuje się to tych wymagań. W ten sposób klient dostanie
produkt z jego punktu widzenia lepszy i lepiej dostosowany do tego do czego jest mu
potrzebny.

AdamK

do góry

On Thu, 18 Jul 2013 04:47:22 -0700 (PDT), Adam Klobukowski
<a...@g...com> wrote:

>
>Nigdy nie napisałem że metodologia Agile jest najlepsza.
>
>Tu nie chodzi o to że programiści źle zrozumieli. Zasadą metodyk Agile jest to że
wymagania są płynne i mogą się zmienić. Taka zmiana nie jest czymś negatywnym.

No, ale to przeciez od zawsze bylo. Pisal sie ansksy do omowy i tak
dalej. Ale wszystko zalatwialo sie porzadnie a nei an "urrraaa"
>
>> Ci co wymyslaja takie rzeczy, nigdy nei widzieli z bliska ani
>> pzremyslu, ani klienta. Nie wiedza ze soft robi sie na podstawie
>> umowy, a kazde odstepstwo od umowy musi byc negocjowane i zawarte w
>> rozszerzeniu do umowy, i jezeli wina lezy po stronie firmy
>> programistycznej, klient nei zaplaci. Mozna sie w razie czego spotkac
>> w sadzie. O czym prasa fachowa od czasu do czasu donosi
>
>Nie chodzi też o odstępstwa od umowy. Wystarczy podpisać umowę która zakłada że
finalny produkt może się zmienić.
>

Buduje dom, Ustalamy ze ma byc dom i w zasadzie moze nadawac sie do
mieszkania. Przychodza chlopcy i leja beton. I mowia: jak sie cos nei
spodoba to potem odkujemy. I drapia sie w glowe: tu pierdykniemy
sreczyk a tu kuchnie. Kuchnia bedzie na pieterku a sraczyk w piwnicy.
ten facio co bedzie tu mieszkal i tak nei ma pojecia. A mysmy tu tylle
domow wybudowali... No a w koncu w umowie jest napisane ze mzoemy
sobie wybudowac co chcemy

Tak sie domow nie buduje. I softu tez. Byc moze gdzies sie buduje. Ale
nei slyszalem.


>Przy budowie każdego dużego systemu informatycznego wymagania zmieniają się
praktycznie zawsze. Czas powstawania dużego projektu to zazwyczaj co najmniej rok,
zazwyczaj więcej. W tym czasie wiele może się zmienić. W przypadku klasycznych
metodologii, klient zazwyczaj widzi system dwa razy - jak mu go sprzedają i jak mu go
dostarczają. Odstęp czasowy pomiędzy tymi momentami jest dużym problemem. To że
klient coś zamówił, to nie znaczy że jak to dostanie to właśnie tego chce.
>

Przy budowie duzego systemu informatycznego projekt dzieli sie na
etapy - ?\"milestones'. Po kazdym etapie nastepuje pzreglad zgodnosci
z umowa. Jezeli cos sie nie zgadza algo klientowi sie cos odwidzialo,
pisze sie "protokol niezgodnosci", potem ustala sie dalsza akcje.
Czestosc takich spotkan zalezy od umowy. W piecioletnim projekcie z
klientem w Euuropie a firma robiaca soft w USA takie spotkania byly co
6 miesiecy.

>W przypadku Agile, klient jest włączony w cały proces powstawania systemu, często
może zacząć go używać już w trakcie jego powstawania. W ten sposób klient ma lepszą
widoczność tego jak system będzie wyglądał a kiedy (co nieuniknione) zmienią się jego
wymagania co do systemu, to wykonawca nie wypnie się mówiąc 'mieliśmy taką a taką
umowę' ale odpowiednio dostosuje się to tych wymagań. W ten sposób klient dostanie
produkt z jego punktu widzenia lepszy i lepiej dostosowany do tego do czego jest mu
potrzebny.

Bez systemu Agile tez sie tak robi. Nazywa sie to "partial
deployment". Gdy projekt trwa 5 lat, raczej nie czeka sie az caly
projekt sie skonczy tylko oddaje po kawalku.

Wszsystkie "niowoczesne methodologie" typu Agile, Extreme Programming
itede maja jeden glowny cel: dupochron dla firmy robiacej soft.
"Wicie, rozumicie, zastsowalismy najnowsza merodologie - Agile - i nie
wyszlo. The act of God. Sila wyzsza"

do góry

On Thu, 18 Jul 2013 04:16:46 +0100, Andrzej Jarzabek
<a...@g...com> wrote:

>W niektórych programach są przyciski, a problem przeniesienia przycisku
>może wystąpić w programie niezależnie od tego, co ten program konkretnie
>robi - może służyć powiedzmy do obracania egzotycznymi papierami
>wartościowymi, a zmiana położenia przycisku może wynikać z tego, że
>trejderzy w UAT zgłoszą, że interfejs użytkownika jest niekonekwentny i
>łatwo omyłkowo klinkąć w zły przycisk, co może mieć bardzo kosztowne
>konsekwencje dla firmy. Komuś, nie mówię, że tobie, ale powiedzmy
>jakiemuś Iksińskiemu pracującemu przy wykonaniu takiego softu może się
>wyadawć, że jest w biznesie skomplikowanych algorytmów wyceniania
>egzotycznych instrumentów czy optymalizowania kosztów transakcji, ale
>jednak jest również w biznesie robienia przycisków - nawet jeśli akurat
>sam tych przycisków nie robi.
>

Drogi Kolego, ja raz pracowalem w takiej firmie gdzie pzreniesienie
przycisku o 5 milimetrow w lewo wymagalo 20 stron dokumentacji i zgody
facetow z tzrech poziomow hierarchii nade mna. To byla firma
telekomunikacyjna.

>Nawet jeśli faktycznie akurat to, nad czym pracujesz nie ma żadnych
>przycisków, to zazwyczaj oprogramowanie ma jakąś formę komunikowania się
>z użytkownikiem czy operatorem, czy to będą logi, parametry linii
>poleceń, pliki konfiguracyjne i tak dalej. I analogiczny problem do
>przeniesienia przycisku też się da znaleźć. Powiedzmy: komunikat w logu
>na temat jakiegoś problemu nie zawiera istotnej informacji
>potrzebnej/pomocnej do namierzenia źródła problemu. Załóżmy, że umowa
>jest na tyle szczegółowa, że wynika z niej, że przy tym rodzaju problemu
>powinien pojawić się w logu komunikat o wystąpieniu owego problemu, ale
>nie na tyle szczegółowa, żeby specyfikować jakie konkretnie dane się w
>tym komunikacie znajdą. Masz więc konwersację:
>"Wasz program wypisał komunikat 'Błąd importu: nielegalny numer NIP',
>ale nie napisał o który NIP chodzi. Czy możnaby dołączyć ten numer do
>komunikatu?"
>"W umowie nic nie ma, że ma logować błędne NIP-y. Możemy to zrobić jako
>change request, za dwa tygodnie przygotujemy aneks do umowy"
>Aneks za dwa tygodnie może opiewać na kwotę 100 tysięcy dolarów, plus
>trzeba zaangażować dział prawny, procurement i co tam jeszcze.

Drogi Kolego, kolega chce mnie pzrekonac do czego?...

Dla ustalenia uwagi, ja wiem jak przemysl dziala. Ostatnie 19 lat
spedzilem w przemysle amerykanskim. W telekomunikacji, przemysle
naftowym i logistyce. Pzrez ostatnie 5 lat przy moim tytule jest
dodatek "principal". Wiec mniej wiecej wiem na czym polegaja umowy i
interakcja z klientem A soft?... Jak pisze dowcipnie nasz marketing
"can be yours starting from only 2 millions dollars"

Nie neguje ze sa dziedziny gdzie Aglie sie sparwdza doskonale, gdzie
siedzi sie z klientem przy jednym ekranie, nie robi sie zadnych
planow, umow i aneksow i gdzie zadna ze stron nie wie o co chodzi.
Ale to dla mnie jak bajki o elftch i trollach

A.L.

do góry

> Zasadą metodyk Agile jest to że wymagania są płynne i mogą się zmienić.

Tak. Ale jednocześnie niejawnie sugeruje, że te zmiany są tanie. Tymczasem nie są.

Widziałem ostatnio (ale nie mam linka) takie rozważania, że w "tradycyjnej"
metodologii zmiany były kosztowne, ale wszyscy o tym wiedzieli - klienci też, dlatego
klienci *starali się*, żeby tych zmian było jak najmniej. Starali się przez
poważniejsze potraktowanie początkowych etapów, czyli analizy i zbierania wymagań.
Agile niejawnie sugeruje, że zmiany były są i będą, w związku z tym są normalne -
czyli tanie. I przy takim założeniu klienci w ogóle się nie starają, przez co zmiany
są dużo częstsze, niż mogłby by być, gdyby się starali.

Pytanie teraz: który wariant jest korzystniejszy.

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

do góry