Wprowadzenie metody z rodziny Agile nie jest w ogóle łatwe. Problemem zazwyczaj jest to, że menedżment powierzchownie dowiadując się o co chodzi, odbiera nową metodę jako obietnicę - od teraz w magiczny sposób wszystko zacznie lepiej działać. Nieważne, że mamy kiepskich ludzi i hołdujemy zasadzie "każdego specjalistę można zastąpić przez skończoną liczbę studentów". Nieważne, że kompletnie nie dba się o zarządzanie wiedzą i umiejętności w zespole, bo nigdy nie ma na to czasu. Nieważne, że osoby realizujące projekty są przerzucane między projektami - bo przecież chodzi o interdyscyplinarność i każdy się powinien we wszystkim orientować. Nieważne, że terminy ustala się apriori, z do końca niejasnych przyczyn lub zakłada się, że to jedyny sposób, żeby przekonać klienta, że jesteśmy profesjonalni, a w terminie się "jakoś zmieścimy". Nieważne, że nie znajdujemy czasu na to, aby utrzymywać architekturę i kod, bo przecież nie ma czasu na tego typu zbędne czynności.
Nieważne, bo przecież Agile obiecuje, że teraz będzie już tylko pięknie. Dokleimy etykietkę to tego co robimy teraz - niech się to nazywa np. "Scrum", zrobimy trochę więcej chaosu, bo przecież chodzi o zarządzanie chaosem - zatem każdy robi co chce i jak chce, przestajemy cokolwiek dokumentować. Przecież stosujemy Agile, wszystko się samozorganizuje.
I dlatego najczęściej Agile nie działa, bo ludzie, którzy po omacku go stosują lub menedżment, który wstępnie akceptuje korzyści z danego podejścia, stosują bardzo uproszczone myślenie - "Ok. Robimy Scrum. Ale tak naprawdę 8 z 10 elementów nam nie pasuje, więc wybierzemy sobie, to co pasuje (dwa elementy), a resztę będziemy robić tak jak do tej pory (czytaj wyżej).
I tak wszystko będzie tak jak było, albo gorzej.
ZATEM UWAGA: W takim przypadku nie należny, nawet nie WOLNO zacząć stosować Agile. Agile to zmiana, ogromna zmiana, to nie etykietka, która rozwiąże wszystkie problemy (w tym przypadku prawdopodobnie lepiej się sprawdzi butelka alkoholu).
piątek, 9 grudnia 2011
Subskrybuj:
Posty (Atom)
