blog.testowka.pl

Wizja produktu

opublikowany przez 27, Gru, 2011, w kategoriach Agile, Scrum

Agile jako niezmiernie elastyczne podejście do procesów wytwarzania oprogramowania ma także pewne wymagania, które by Agile działało muszą zostać spełnione. Jednymi z krytycznych wymagań są jasno określona wizja wytwarzanego produktu oraz zdefiniowane cele dla zespołu/zespołów.

Paradoksalnie decyzja o wdrożeniu Zwinnych Metodyk Wytwarzania Oprogramowania jest często spowodowana problemami z jakimi borykają się organizacje. Agile w zamyśle osób decyzyjnych często ma być lekiem na całe zło i srebrną kulą rozwiązującą wszystkie problemy. Zaletą Agile jest między innymi to, że nawet jeśli nie dostarcza rozwiązań problemów to bardzo dobrze te problemy obnaża i pozwala na identyfikację ich źródeł.

Problemem, który często obserwuje jest brak spójnej (o ile jakiejkolwiek) wizji produktu oraz problem związany z decyzyjnością w sprawach tejże wizji. Często widzę łańcuszek „zaufania” wyglądający mniej więcej tak: developerzy ufają managerom, że mają oni wizję rozwoju produktu, line managerowie ufają swoim przełożonym, że to oni wiedzą jak produkt powinien się rozwijać, wyżsi managerowie wierzą w to, że to zarząd czy też dyrektor decyduje o tym jak ma produkt ostatecznie wyglądać i że ma wszystkie konieczne informacje do tego by takie decyzje podejmować, dyrektor jest pewien że jego przełożony/prezes wie co tak na prawdę robimy bo ma „więcej informacji”… I w drugą stronę prezes jest przekonany, że oddelegował wystarczającą ilość władzy dyrektorowi (bo przecież jako prezes ma mniej informacji, które ma dyrektor) by ten dbał o wizję i rozwój produktu, dyrektor jest pewien, że bez względu na to, że być może on do końca nie wie jak produkt ma wyglądać jego pracownicy w postaci managerów jakoś dają sobie radę i przecież mają więcej informacji od niego, managerowie wierzą w to, że developerzy wiedzą co robią w końcu przecież znają ten system najlepiej. Ostatecznie okazuje się, że większość decyzji podejmowanych jest ad-hoc i za plecami przełożonych, a osoby, które teoretycznie powinny być odbiorcami produktu godzą się z tym co dostają myśląc, że takie były idea i zamysł managerów czy innych osób, które według ich mniemania są odpowiedzialne za kształt produktu.

Problem braku decyzyjności jest bardzo często jednym z pierwszych problemów bezlitośnie obnażanych przez zwinne metodyki zarządzania projektami.

Nie jest na szczęście tak, że w Agile z powyższym problemem nie da się nic zrobić – np. Scrum dostarcza takich narzędzi jak Product Backlog i rolę Product Ownera, który jest odpowiedzialny między innymi za kolejność wykonywanych zadań i formowanie wizji produktu. Niemniej jednak odpowiedni dobór Product Ownera nadal pozostaje często problematyczny.

Często słyszę pytania na temat motywacji zespołów i poszczególnych osób. Nie ma żadnych ogólnych zasad, które by mówiły o tym jak motywować poza jedną mówiącą o tym, że ludzi nie da się zmotywować – można tylko utworzyć odpowiednie środowisko, które będzie sprzyjało motywacji i dostarczyć odpowiednich narzędzi, które tą motywację pozwolą wykorzystać. Takim narzędziem jest między innymi zdefiniowanie kierunku w którym zespół będzie mógł podążać, celu, który będzie osiągalny i którego osiągnięcie będzie stanowiło samo w sobie świetną nagrodę. Z moich obserwacji wynika, że zespoły, które wiedzą do czego dążą i znają wizję produktu, który tworzą pracują znacznie efektywniej niż zespoły, które mają ograniczone informacje na ten temat.

Agile opiera się na samo-organizacji zespołów, która w skrócie polega na tym by określić pewien obszar w którym zespół może się poruszać i zdefiniować cel, który zespół ma osiągnąć (bez względu na to czy mówimy tutaj o „zespole” jako programistach, czy np. całym dziale IT, albo całej organizacji). Bez określonego celu zespół będzie się poruszał w kółko, a ewentualne sukcesy będą dziełem przypadku. Oczywiście możemy zdefiniować granice na tyle twardo i zminimalizować obszar do tego stopnia, że poruszanie się po nim będzie prowadziło tylko w jednym kierunku – do osiągnięcia celu – ale to już jest Manage and Control a nie Agile i jak sama nazwa wskazuje wymaga ciągłej, ścisłej kontroli i nadzoru.

Powyższy post jest rozwinięciem kolejnej części prezentacji na temat przyczyn niepowodzeń wdrożeń Agile w organizacjach, którą od czasu do czasu wygłaszam przy różnych okazjach. Wkrótce pojawią się kolejne części opisujące kolejne problemy. Prezentacja oraz notka powstały na podstawie obserwacji moich i moich koleżanek i kolegów zajmujących się na co dzień wdrożeniami Agile, a także wielu godzin rozmów z różnymi ludźmi na tematy mniej lub bardziej związane z wdrożeniami Agile. Cały cykl możecie znaleźć tutaj.


3 Comments for this entry

1 Trackback or Pingback for this entry

Skomentuj