On Monday, 22 July 2013 09:15:50 UTC+1, Paweł Kierski wrote:
> W dniu 2013-07-19 20:37, slawek pisze:
>
> > 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.

Przepraszam, nie znam się za bardzo na zamówieniach publicznych, ale jeśli
powiedzmy gmina chce zatrudnić firmę do sprzątania pomieszczeń rady, to nie
może rozpisać przetargu gdzie firma sprzątająca będzie dostawać określoną
kwotę za okres rozliczeniowy na czas utrzymywania pomieszczeń w czystości,
tylko musi być przetarg na każde sprzątnięcie oddzielnie, ze szczegółowym
spisem wszystkich papierków do podniesienia i plam na podłodze do zmycia w
załączniku?

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

Także - dorzucę - kontrola ryzyka kontraktowego. Jeśli np. tempo prac czy
problemy metytoryczne z implementacją wymagań są większe niż zamawiający
przewidział, to może na wczesnym etapie (np. po wóch-trzech iteracjach)
odstąpić od projektu i zapłacić tylko za te dwie-trzy iteracje lub - w
zależności od umowy - w ogóle nic.


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

A ja bym akurat się zgodził że do tego metody Agile nadają się słabo. W Agile
jest założenie, że pracuje się dla klienta, który może być prawdziwy lub
wirtualny, ale jest zewnętrzny wobez zespołu developerskiego. Celem zespołu
developerskiego jest wyłacznie zaspokojenie potrzeb i maksymalizacja wartości
klienta, a o tym co dokładnie maksymalizuje dowiadują się z konkretnego
źródła - mogą sugerować, ale nie mogą decydować. Jeśli developerzy mają inne
cele, np. chcą robić cool rzeczy, które przyniosą im "renomę", albo sami są
użytkownikami produkowanego softu lub reprezentują użytkowników i osobiście
zależy im, żeby produkt miał określone ficzery albo działał w określony
sposób, to cały proces Agile się sypie.

I dotyczy to nie tylko wyidelizowanego obrazu open source/free software gdzie
hobbyści czy pracownicy naukowi dłubią sobie w rzeczach, które ich interesują,
ale też rozwoju takiego oprogramowania w środowisku korporacyjnym, gdzie np.
do linuksowego kernela kontrybuują inżynierowie z Google, którym zależy na
implementowaniu tego, co jest potrrzebne Google, inżynierowie IBM, którzy chcą
implementować to, co jest potrzebne IBM itd.