blog.testowka.pl

Archiwum wiadomości z Grudzień, 2011

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.

4 komentarze więcej...

Zbyt wiele osób a za mało kompetencji.

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

Jakiś czas temu znalazłem ogłoszenie w którym ogłoszeniodawca szukał między innymi testerów do dużego projektu jakim miało być przepisanie systemu wspierającego bankowość elektroniczną pewnego banku.

Poniżej fragment ogłoszenia:

„Projekt ma trwać ok. 4-5 lat i jest organizowany przez 6 krajów: Polskę, Chiny, Brazylię, Stany Zjednoczone, Singapur i Indie. Na całym świecie do tego projektu ma być zatrudnionych 2000 osób”

Jestem w stanie zrozumieć, że systemy bankowe są dosyć skomplikowane (miałem z nimi trochę do czynienia) niemniej jednak 4-5 lat dla jakiegokolwiek projektu IT to perspektywa niesamowicie abstrakcyjna (przynajmniej dla mnie). Jeśli już na wstępie pomysłodawcy zakładają taki okres czasu to w jaki sposób uwzględnią zmiany jakie przez ten okres mogą się pojawić. Przez „zmiany” mam na myśli chociażby zmiany prawne, nie wspominając już o tym, że w takim okresie czasu mogą powstać zupełnie nowe technologie, które zrewolucjonizują tą branżę etc. Kolejny element ogłoszenia – 2000 osób [SIC!] – a po co aż tyle? – co oni chcą cały system operacyjny (albo cztery) do tego napisać, czy co? (a może… kto wie…). Skład narodowy zaangażowany w ten projekt też o czymś mówi – czyżby dewiza „zróbmy to tanio”?

Nie mówię, że się nie uda – w 5 lat można na prawdę wiele zrobić. Nawet jeśli 3/4 albo 9/10, a nawet 95/100 z tych ludzi będzie robiło rzeczy zupełnie bez sensu i zbyteczne to powinno się udać stworzyć ww. system bankowości elektronicznej, który być może będzie nawet działał lepiej od tego, który ów bank posiada obecnie. Pytanie tylko „Po co angażować tyle osób skoro prawdopodobnie można by było to zrealizować przy udziale kilkunastu do kilkudziesięciu osób?”.

Pozostaje mi tylko życzyć powodzenia. A gdyby przypadkiem zajrzał tutaj któryś ze szczęśliwie zatrudnionych do tego projektu to z chęcią usłyszę jakieś relacje z postępów prac.

Powyższe ogłoszenie najprawdopodobniej wynika z podejścia do wytwarzania oprogramowania i zarządzania projektami zawierającego taki termin jak „zasoby ludzkie” – wspomniane podejście zakłada, że jeśli praca postępuje zbyt wolno to należy dostarczyć więcej „zasobów” w postaci programistów/testerów/stażystów/praktykantów/whatever. Takie „zarządzanie zasobami ludzkimi” w wielu organizacjach doprowadziło do niesamowitego wzrostu liczby pracowników tworzących (z punktu widzenia funkcjonalności) względnie proste rzeczy, pracujących w środowisku w którym narzut komunikacji z tak dużą ilością osób na około jest tak duży, że praktycznie nie da się zrobić nic. Z zaszłości historycznych systemów wytwarzanych przez jakiś czas przez tak dużą ilość osób wynika nadzwyczajne skomplikowanie tych systemów – każdy programista pisze po swojemu i rozwija system w swoją stronę, z problemów komunikacyjnych wynika rosnąca ilość duplikacji i kierunków (wizji) w jakich system podąża etc. do większej ilości kodu potrzeba więcej osób, które w jakiś magiczny sposób posiądą tajemną wiedzę przynajmniej o jakimś wycinku funkcjonalności tworzonych produktów i w ten sposób spirala sama się nakręca.

Na jednej z prezentacji na konferencji ALE w Berlinie przedstawiono ciekawą teorię na temat tego, że Agile może wydajnie działać w organizacjach nie przekraczających 200 osób, gdyż średnio właśnie tyle osób każdy człowiek jest w stanie poznać, zapamiętać i z tyloma osobami jest w stanie utrzymywać mniej lub bardziej bliskie kontakty, a przede wszystkim jest w stanie spamiętać czym dana osoba się zajmuje. Podobnie liczba optymalna osób w zespole 5-12 to liczba wynikająca z naszej natury – mniej więcej tyle jest średnio liczba osób w rodzinie (powyższe wynika z uwarunkowań genetycznych, historycznych i ewolucyjnych).

Ponadto żeby skutecznie wdrożyć Agile w organizacji potrzeba przekonać do tego jak największą ilość osób, w tak dużych organizacjach przekonanie do czegokolwiek nawet połowy osób jest z góry skazane na niepowodzenie (lub zajmie nieskończoną ilość czasu).

Agile stawia na małe zespoły, które potrafią w krótkim czasie przy minimalnym narzucie komunikacyjnym dostarczyć działające oprogramowania wytworzone w sposób prosty. Niektórzy mówią nawet o ekstremalnie prostym programowaniu – stąd właśnie termin Extreeme Programming (XP). Przeważnie skomplikowanie rozwiązań wynika z problemów komunikacyjnych w organizacji, traktuje o tym między innymi Prawo Conway’a które obrazuje to jak problemy komunikacyjne między ludźmi wpływają na problemy integracji systemów tworzonych przez tych ludzi.

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 komentarze więcej...

Agile? – tak znam – to taki iteracyjny waterfall.

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

Zwinne podejście często oznacza zmiany sposobu myślenia, co okazuje się być niezmiernie trudne zwłaszcza w organizacjach, które od dłuższego czasu stosowały znacznie „cięższe” metodyki oparte na zarządzaniu i kontroli. Przyzwyczajenie chociażby do tego, że niektóre etapy wytwarzania oprogramowania następują w ściśle określonej kolejności jeden po drugim często jest przekładane na implementację Agile.

Częstym pomysłem na wdrożenie Agile jest rozbicie iteracji na poszczególne etapy: najpierw mamy kilka pierwszych dni na analizę, pisanie dokumentacji, planowanie i projektowanie, następnie kilka do kilkunastu dni na kodowanie i pod koniec jak starczy czasu tak zwany code freeze lub feature freeze oznaczający nie dodawanie w tym czasie nowych funkcjonalności kosztem skupiania się na testowaniu. W praktyce okazuje się, że jest to nierealne i niestety czasu na testy już nie ma albo jest mocno ograniczony.

Niejako rozwinięciem powyższego pomysłu jest tworzenie specjalistycznych iteracji poświęconych konkretnym etapom wytwarzania oprogramowania. Tak mamy po sobie kolejno: iteracje analizy, planowania i projektowania, kilka iteracji kodowania i jak starczy czasu to iteracje w całości poświęcone integracji, testowaniu i wdrażaniu. Oczywiście możemy wtedy stworzyć specjalistyczne zespoły zajmujące się każdy tylko jednym etapem. Niektórzy próbują nawet układać harmonogramy takich iteracji tak, by żaden zespół się nigdy nie nudził i żeby nie było przestojów produkcyjnych (pomocne bywają wykresy Gant’a) .

Powyższe pomysły z Agile nie mają zbyt wiele wspólnego o ile w ogóle coś mają. Na pierwszy rzut oka widać, że wygląda to jak Waterfall lub Mini-Waterfall w postaci inkrementalnej. Kiedyś spotkałem się nawet z określeniem „Wagile” będącym kombinacją słów Waterfall i Agile.

W Agile każda iteracja musi dostarczać działające, przetestowane i zintegrowane oprogramowanie wnoszące jakąś wartość biznesową. Spełnienie tego warunku nie jest proste – wiąże się z tym wdrożenie odpowiedniej organizacji pracy i zbudowanie silnie współpracującego ze sobą zespołu, co w efekcie daje jeszcze większe korzyści.

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.

2 komentarze więcej...

To jest tak proste, że aż się prosi by to uprościć.

opublikowany przez 05, Gru, 2011, w kategoriach Agile, Scrum, XP

Agile jest niezwykle nieskomplikowanym podejściem do wytwarzania oprogramowania narzucającym jedynie niezbędne minimum zasad w zupełności wystarczających do zbudowania mocnych i stabilnych podstaw na bazie których można wprowadzać pewne modyfikacje i ulepszać istniejące procesy.

W zasadzie Agile samo w sobie nie jest metodyką – to sposób myślenia (mindset), sposób codziennej pracy,  oparty na czterech filarach spisanych w postaci Manifestu Agile:

Ludzie i ich wzajemne interakcje ponad procedury i narzędzia.
Działające oprogramowanie ponad wyczerpującą dokumentację.
Współpraca z klientem ponad negocjację umów (tworzenie kontraktów).
Reagowanie na zmiany ponad ścisłe realizowanie planu.

To minimum zasad często samo w sobie staje się pokusą tego by je jeszcze bardziej ograniczyć. Postulaty manifestu Agile chociaż wydawało by się proste bardzo często są błędnie interpretowane co prowadzi do wdrożeń zwinnych metodyk zarządzania projektami kończących się porażką lub nie dających oczekiwanych (lub możliwych do osiągnięcia) efektów. Na Manifeście Agile opiera się wiele „zwinnych” metodyk i praktyk takich jak Scrum czy Programowanie Ekstremalne (XP). Metodyki te są same w sobie bardzo proste – zawierają tylko podstawowe zasady, których przestrzeganie gwarantuje wzrost efektywności zespołów developerskich. Niemniej jednak dla niektórych wydaje się to tak proste, że staje się bez znaczenia i niektóre praktyki są pomijane.

W ten sposób powstaje coś takiego jak ScrumBut: „Używamy Scrum, ale nie mamy codziennych spotkań”, „Używamy Scrum, ale nie mamy czasu na retrospekcje”, „Używamy Scrum ale nasz manager mówi nam co i ile będziemy robić w tej iteracji” etc.  Podejście typu „Weźmiemy trochę tego, trochę tamtego a resztę pozostawimy tak jak w modelu kaskadowym” powoduje, że wprowadzane zmiany nie mają szans działać w pełni o ile w ogóle cokolwiek polepszają.

Transformacja organizacji w stronę Agile to proces długofalowy, który wymaga wielu poświęceń i wyrzeczeń, a przede wszystkim wymaga otwartości na zupełnie nowe podejście do wytwarzania oprogramowania a także często wymaga od wdrażających możliwości wprowadzania zmian nie tylko w samym IT.

Gwoli ścisłości: to nie jest tak, że metodyki nie wdrażane w pełni nie będą działały w ogóle – będą, tylko efekty takiego wdrożenia będą dużo mniej stabilne i dużo mniej widoczne. Kilkukrotnie widziałem sytuacje w których metodyki pomimo tego, że wdrożone niekompletnie lub nieprawidłowo same się regulowały i ostatecznie coraz bardziej przypominały podręcznikowe wdrożenia, niestety widziałem też sytuacje, w których niecierpliwość spowodowana brakiem widocznych, obiecywanych efektów prowadziła do całkowitej rezygnacji z dalszego podążania w kierunku Agile.

Powyższy post jest rozwinięciem pierwszej 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.

2 komentarze więcej...