Oczywiście, że jestem „za.”

Problem z klientem polega na tym, że agile u podstaw ma zmieszczenie się w terminie. Klienta nie interesuje uruchomienie serwisu z 3/4 zamówionych funkcji i dodanie reszty później.

Co do „najsłabszego ogniwa” — wiem z doświadczenia, jak jedna osoba może swoim podejściem zniszczyć morale całego zespołu. Współodpowiedzialność oznacza wtedy konieczność ciągłego naprawiania cudzych błędów, a słabe ogniwo ma to głęboko w poważaniu, bo „i tak po nim poprawią, więc może pisać cokolwiek.”

Po pierwsze piszesz, że agile nie zadziała „[…] Kiedy budujesz coś dla konkretnego klienta i kiedy to klient dostarcza specyfikację funkcjonalności. Dla niego nie jest ważne, żeby mieć jakikolwiek produkt […]”.

No więc nie ważne czy klient dostarcza, czy też nie dostarcza specyfikacji wymagań, bo techniki agile/xp nie zakładają, że zgodnie z nimi trzeba te wymagania zebrać. Osobiście bardzo lubię ideę/technikę tzw. „user stories”, ale równie dobrze można przeprowadzić iteracyjnie projekt mając na wejściu specyfikację od klienta. Zwykle też klient nie potrafi sam przedstawić takiej specyfikacji. Dobrze jeśli potrafi ogólnie przedstawić wizję i swoje oczekiwania. Tutaj techniki z agile pozwalają moim zdaniem szybciej zebrać wymagania bez wgłębiania się w niezrozumiałe dla klienta szczegóły oraz bez zbyt dużej formalności jaką wg mnie nakłada np. stosowanie przypadków użycia (ang. use cases). Oczywiście, że klientowi nie jest wszystko jedno czy dostanie aplikację desktop czy stronę WWW, ale wydaje mi się, że trochę przerysowujesz tutaj przykład. Ja bym to odwórcił — agile pozwala mi dać klientowi stronę WWW o jakiej myślał, a nie taką o jakiej myślał developer i to właśnie w wyniku iteracyjnego procesu (zanim zabrniemy za daleko, klient zdąży już zobaczyć dokąd zmierzamy).

Druga spraw, to to słabe ogniwo w zespole. O ile dobrze zrozumiałem, sugerujesz, że słabe ogniwo w zespole stosującym agile powoduje porażkę tego zespołu. Wydaje mi się, że takie zasady/techniki, jak programowanie parami (choć do niego podchodzę ostrożnie) czy współwłasność kodu (to bardzo ważne moim zdaniem) zapewniają, że jeśli taka osoba nawali, czy nawet odejdzie z zespołu, to każdy członek zespołu jest w stanie zająć jej miejsce. Możemy mieć wtedy tylko spóźnienie, ale na pewno nie paraliż pracy.

I jeszcze jedna rzecz do posta Bazyla. Moim zdaniem każdy proces powinno się wprowadzać małymi krokami a nie od razu w całości, jak sugerujesz. Najpierw zespół powinien zaznajomić się z testowaniem, zbudować sobie środowisko budowania kodu, potem można zacząć z iteracjami, może wprowadzać powoli techniki planowania i estymacji zakresu projektu. Trzeba się z tymi technikami oswajać i dopiero jak się je pozna i pozna się ich wartość, można przechodzić do kolejnych. Inaczej zespół się zniechęci. Będzie odbierał nowy proces jako dodatkowy bezużyteczny wysiłek i proces umrze w zespole śmiercią naturalną. Odwołując się do twojego przykładu ze zderzakiem, to raczej powiedziałbym, że świeżo upieczony kierowca najpierw powinien popróbować z małym miejskim autkiem, zanim przesiądzie się do mercedesa czy samochodu rajdowego.

Pozdrawiam,
Marcin

W mojej obecnej firemce widze proby wprowadzenia tego procesu. Niestety wszyscy zabieraja sie za to jak pies do jeza. Po prawdzie staraja sie wprowadzic caly proces na raty. Na moja sugestie, ze jak kupisz zderzak to za cholere nie mozna go nazwac samochodem i nawet sam z siebie nie spelnia swojej funkcji jakos do nich nie dociera.

Choc szczerze powiem, ze mnie to troszke dziwi. Szczegolnie, ze mam wrazenie, ze wlasnie ze wzgledu na spore doswiadczenie z Agile zostalem zatrudniony w tej firmie.

Na pewno sie podziele tymi spostrzezeniami jeszcze. Jak bedzie jakis bardziej radosny oddzwiek na moje starania zmuszenia firmy do wprowadzenia procesu jakiegokolwiek, bo aktualnie nie ma tu absolutnie nic.

Podobno procesy ograniczaja pomyslowosc programistow, a i tak sa oni tlumieni przez management. Kompletnie tego nie rozumiem :)

Pozdrawiam z wysp.