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.