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.