blog.testowka.pl

Agile a polityka

opublikowany przez 17, Sty, 2012, w kategoriach Agile, Scrum, Zarządzanie

Wdrożenie Agile w organizacji oznacza między innymi zapewnienie maksymalne transparentności. Czasem przejrzystość bywa nie na rękę niektórym osobom. O ile zrozumiałe są względy prawne czy ograniczenie dostępu do poufnych i czułych informacji to bezpodstawne wydają się być próby ograniczania dostępu do podstawowych narzędzi i zasobów. Bardzo często spotykam się z sytuacją, gdzie testerzy nie mają dostępu do kodu aplikacji – jak w takim razie mają na prawdę zrozumieć jej działanie, jak badać zależności, szacować ryzyko etc. Jak testerzy mają poszerzać swoją wiedzę na temat programowania i inżynierii nie wspominając już o wiedzy na temat aplikacji, gdy widzą tylko okrojoną warstwę interfejsu użytkownika.

Drugie pytanie dlaczego nie mają dostępu? Trudno mi nawet próbować zgadywać co jest przyczyną bo odpowiedzi które przychodzą mi do głowy są bliskie wielkiej torii konspiracji i zmowy wszechświata na temat tego, że Ziemia tak na prawdę jest sześcianem… Zyski z dostarczenia testerom kolejnych źródeł wiedzy są oczywiste i nie będę ich tutaj opisywał.

Wspomniany wcześniej problem zarządzania w organizacji często jest inicjatorem problemów czysto politycznych – bo jak to tak bez zarządcy niewolników? Przecież organizacja musi mieć swoją strukturę. Fakt – musi, ale to nie przeszkadza w tym by ta struktura istniała poza samo-organizującymi się zespołami i służyła wyłącznie do ogarnięcia kwestii formalnych i kadrowych. Agile i Scrum dostarczają pewnych struktur – mamy Product Ownera, który de facto jest managerem produktu, mamy Scrum Mastera który aby wykonywać swoje obowiązki i skutecznie usuwać przeszkody stojące na drodze zespołowi powinien mieć wystarczającą moc sprawczą i decyzyjną (nie zatracając się w iluzję władzy nad zespołem). Ciekawy, empiryczny opis roli managera w Agile przedstawił Andy Brandt na swoim blogu.

By Agile mogło działać sprawnie potrzebna jest współpraca na wszystkich szczeblach organizacji – wszyscy łącznie z kierownictwem powinni mieć wspólny jasno zdefiniowany cel i wizję tego co tworzą – tylko dzięki temu i przejrzystości działań, która ogólnie poprawia komunikację możliwe jest rozwinięcie najwyższej prędkości bez start jakości.

Tylko zapewnienie przejrzystej wizji produktu pozwala na uniknięcie wykonywania zbędnej pracy. Alberto Savoia w wykładzie otwierającym GTAC 2011 zatytułowanym „Test is dead” podsumował obecne zmagania zapewniania jakości oprogramowania w jednym zdaniu: „It’s no more about doing now it is about doing the right It” – programowanie jest kosztowne, a jedynym miejscem gdzie należy szukać oszczędności jest ilość tego co się programuje i eliminowanie ficzerów o małej wartości lub zupełnie zbędnych.

Użyłem słowa Polityka bo to właśnie z tym kojarzy mi się to co widzę często w organizacjach – problemy związane z komunikacją, dostępem do informacji, konfliktami interesów etc. Widziałem wiele prób zamykania zespołów w swoistych szklanych kulach, które chroniły ich od polityki – takie rozwiązania przeważnie działają, ale prędzej czy później coś się przez kulę przebija i wtedy zaczynają się problemy.

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.


Skomentuj