jpc poprosił, żebym się ustosunkował do notki Dobry zwinny, zły zwinny.
Czytałem ją gdzieś w okolicach października i nie bardzo chcę się teraz przegryzać ponownie przez cały tekst, dlatego zamiast cytować, napiszę, co sam myślę o tak zwanych zwinnych
metodach prowadzenia projektów.
Część z was pewnie miała już okazję przeczytać Kiedy pomysły umierają…
na blogu nbw. Reszta powinna teraz zabrać się za lekturę. Pracujemy z Tomkiem w tej samej firmie, więc poniżej znajdziecie właściwie tylko uzupełnienie jego tekstu.
Projekt
Zanim zaczniesz stosować jakiekolwiek ekstremalne
metodyki, musisz przede wszystkim zrozumieć, że nie nadają się do każdego projektu. To, co działa dla Google czy 37signals, nie musi działać dla twojego produktu.
Kiedy 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 (czy będzie to program, strona WWW, czy jakikolwiek inny projekt programistyczny). Kiedy jedziesz z samochodem do mechanika, też nie oczekujesz przecież, że dziś przykręci jedną śrubkę, a po tygodniu jazdy spyta, czy mocno stuka, bo nie jest pewien, czy najpierw przykręcić drugi koniec zderzaka, czy może wymienić płyn hamulcowy.
Firma
Metodyki agile
mają to do siebie, że wywołują śmiech u dyrektorów dużych firm. Powód jest prosty — korporacje przez dekady dopieszczały błyszczące schematy hierarchii, wiszące w wielkich szklanych gablotach tuż obok recepcji. Proces decyzyjny wymaga przesłania tony makulatury w górę drzewka tylko po to, żeby propozycja trafiła do pracownika siedzącego w biurze koło ciebie, ale pracującego w innym pionie.
Agile
z drugiej strony promuje czysto asekuracyjną rolę managerów. Nie ma miejsca na wielowarstwową strukturę zwierzchnictwa, managerowie to bardziej przywódcy niż szefowie. Mają ostatnie słowo przy podejmowaniu decyzji, ale z tego przywileju korzystają tylko w ostateczności. W związku z tym, najłatwiej metodyki takie wprowadzić w firmach małych, zatrudniających kilka-kilkanaście osób. Zwinność
stawia na siłę zespołu, a nie precyzowanie każdego elementu w specyfikacji technicznej.
Zespół
Tu znów kontrast z borgiem.
Jeśli projekt ma się powieść, zespół musi być mały, co zapewnia łatwość komunikacji. To pociąga za sobą dużo większe wymagania odnośnie predyspozycji każdego z członków zespołu.
Pracując przy aplikacjach klasy enterprise
(na przykład systemy wspomagania prowadzenia przedsiębiorstw), miałem kilka razy okazję poznać sposób powstawania oprogramowania. Z boku wyglądało to tak, jakby Albert Einstein stał na cokole pośrodku sali i rzucał banany małpom klepiącym w klawiatury. Podejrzewam, że w niejednym zespole jedyną kompetentną osobą był właśnie manager, który doglądał całej bandy klepaczy.
Zwinność
kładzie silny nacisk na zaangażowanie zespołu w życie projektu. Każdy z biorących udział w powstawaniu produktu musi kochać swoją pracę i potrafić podejmować decyzje działające na korzyść projektu, a nie oszczędzające pracę. Nie ma tu miejsca dla maszynistek,
które potrafią szybko klepać kod, ale co chwilę trzeba im mówić, co mają robić dalej.
Podsumowując
Aby wdrożenie nowej polityki prowadzenia projektów się powiodło i miało sens, potrzeba pasji. Nie tylko ze strony zarządu, nie tylko ze strony programisty. Potrzeba chęci przejścia na nowy tryb ze strony wszystkich pracowników, którzy mają jakikolwiek udział w rozwoju projektów.
Żeby przerwać łańcuch, wystarczy jedno słabe ogniwo. Dlatego jedna osoba, która nie będzie myśleć tak, jak reszta, znacznie osłabi zespół (który i tak jest przecież mały), a w rezultacie może doprowadzić do zgonu całego projektu. Nie musi nic specjalnego robić, wystarczy, że swoją niechęcią do wszystkiego będzie wpływać na morale reszty grupy i zniknie pasja.
by matti
04 sty 2007 at 10:18
Pozostaje tylko zyczyc powodzenia i sukcesow w nowym roku! :-) Wszystkiego dobrego w 2007!
by bazyl
09 sty 2007 at 11:31
Szczerze powiem, ze jesli chodzi o Agile to mam pozytywne wrazenie. Pracowalem w tym procesie jakis czas. Ale fakt faktem — firma — czy raczej jej management musi miec jaja, zeby cos takiego wprowadzic.
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.
by Dinaddan
21 sty 2007 at 21:25
Po lekturze Twojego posta Patryku nie bardzo wiem czy jesteś bardziej za, czy przeciw „agile”. Nie zgadzam się z dwoma Twoimi stwierdzeniami.
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
by Patrys
21 sty 2007 at 21:38
Dinaddan:
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.”