Kategoria 'Agile dla managerów'
Koniec wakacji i jesień stała się strasznie naładowana ciekawymi wydarzeniami w świecie Agile. Co więcej dużo z nich jest w zasięgu osób mieszkających w Polsce. Nie trzeba jechać do Salt Lake City, w którym właśnie trwa konferencja Agile2011 organizowana przez Agile Alliance.
Ja na jesień wybrałem AgileByExample w Warszawie i Agile Eastern Europe w Kijowie.
Pisałem już o AgileByExample. Teraz konferencja wygląda jeszcze bardziej zachęcająco, bo znany jest program konferencji, który jest pełen ciekawych wystąpień. Co najważniejsze dla mnie, nie będzie żadnych powtórek z konferencji ACE z kwietnia, tak więc mamy w tym roku w Polsce dwie uzupełniające się konferencje o tematyce Agile. Czego chcieć więcej?
Jeśli nie zdecydowałeś jeszcze czy pojawisz się na AgileByExample 15-16 września, to podejmij decyzję teraz, bo wśród rejestrujących się do 25 sierpnia rozlosowany zostanie kupon upominkowy o wartości 50 USD do wykorzystania w Amazon.com (spokojnie starczy na 2 fajne agilowe książki na długie jesienne wieczory).
Zachęcam do rejestracji. Dla mnie pozycja obowiązkowa jeśli chodzi o Agile w Polsce!
August 10th, 2011
In the world of Agile adoption… tak pewnie zacząłby tę zapowiedź Hal Douglas :-) Ale poważnie… Tej jesieni będziemy świadkami narodzin nowej konferencji o tematyce Agile w Polsce. Mam tutaj na myśl:
Agile By Example 2011
Przyjemność to dla mnie podwójna, gdyż zostałem zaproszony do współpracy przy jej organizacji.
Agile By Example w założeniach ma być konferencją zawierającą praktyczne rady dla tych, którzy myślą o rozpoczęciu małej rewolucji w swojej firmie, lub już wkroczyli na tę drogę (i zauważyli już, że to raczej wyboista ścieżka).
Przybywa nam w Polsce firm, które mają już ciekawe doświadczenia z Agile i będziemy bardzo zadowoleni jeśli uda nam się zebrać te doświadczenia podczas 2-dniowego spotkania.
Konferencja odbędzie się w Warszawie 8-9 września 2011 roku, więc zarezerwujcie czas. Już niedługo rusza C4P i zachęcam do udziału wszystkich, którzy chcieliby podzielić się swoimi dotychczasowymi doświadczeniami. To nie muszą być elaboraty jak to zmieniłem 1000 osobową organizację. Wystarczy zespół, mały dział, coś co zadziałało i z czym chcecie pójść dalej.
A może właśnie jakieś praktyki “książkowe” nie zadziałały? Wiem, że trudniej jest wystąpić z failure story, ale o to też chodzi! Uczmy się na błędach i wyciągajmy wnioski. Po to właśnie powstaje Agile By Example.
Śledźcie stronę konferencji http://www.agilebyexample.com oraz Twittera @AgileByExample. Ja również o co ciekawszych etapach nie omieszkam poinformować na blogu. Do zobaczenia jesienią w Warszawie!
May 19th, 2011
Ostatnio pisałem o efekcie uczenia się / doświadczenia w kontekście iteracyjnego podejścia. Dzisiaj czas na nieco inne spojrzenie na iteracyjność. Przyjmijmy prosty model projektu (tabelka na obrazku poniżej):
- projekt potrwa 6 iteracji (dla uproszczenia niech 1 iteracja = 1 miesiąc),
- koszt każdej iteracji to 20 000 zł, czyli koszt projektu 120 000 zł,
- po wypuszczeniu produkt zacznie zarabiać 10 000 zł / miesiąc,
- co 4 miesiące przychody z produktu ulegną podwojeniu.
Podejście I - wszystko naraz
Wypuszczamy projekt po 6 miesiącach, kiedy skończymy wszystko (niech będzie nawet, że 100% zgadza się ze specyfikacją, a klient nie narzeka). Produkt zaczyna pracować na siebie. I będzie to wyglądało mniej więcej tak jak przedstawia to linia czerwona na wykresie.
Podejście II - iteracyjnie (to bardziej interesujące)
Pierwszą wersję produktu wypuszczamy po 3 miesiącach. Nie ma ona co prawda wszystkich funkcjonalności, ale:
- takie podejście zakłada, że po każdej iteracji mamy wdrażalny produkt, a nie jakieś projekty, wstępne szkielety itp.,
- najpierw dostarczamy to co z punktu widzenia klienta najważniejsze, a mniej istotne elementy zostają na koniec,
- klient odbiera pracę po każdej iteracji - widzi działający produkt i ma szansę zareagować na różne sposoby.
Co się stanie? Skoro na pierwszy ogień idą elementy systemu kluczowe z biznesowego punktu widzenia (podkreślam “z biznesowego”), to można zaryzykować stwierdzenie, że w połowie projektu mamy już trzon aplikacji, która jest w stanie zacząć zarabiać. Przyjmując, że zasada Pareto działa, to zaledwie 20% funkcji systemu potrzeba do tego, żeby aplikacja robiła 80% tego co ma robić.
Tak więc odbijamy krzywą zysku i od 4 iteracji zaczynamy “tracić” mniej (pierwsza strzałka). Po 11 miesiącach wychodzimy na prostą, podczas gdy w pierwszym podejściu mamy w tym samym momencie wciąż dziurę w budżecie na 60 000 zł (druga strzałka).
Ale nie tylko o zmniejszenie kosztów tutaj chodzi. Mogłoby tu się jeszcze wydarzyć kilka innych rzeczy:
- od 3-4 miesiąca testujemy w prawdziwych warunkach nasze założenia biznesowe i mamy jeszcze 3 szanse na ich modyfikację
- mogłoby się okazać, że po 5 iteracji produkt już ma co trzeba i użytkownicy wcale nie domagają się reszty funkcji, która stanowi tak faktycznie tylko fajne, ale nikomu nie potrzebne dodatki (pamiętamy - to co najbardziej istotne poszło na pierwszy ogień) - wydatki spadłyby do 100 000 zł
- itp.
Oczywiście pełno tu uproszczeń. Nie każdy projekt nadaje się do wcześniejszego wdrożenia (na myśl przychodzi mi np. oprogramowanie medyczne, itp.). Chodzi jednak o samo spojrzenie na szanse i możliwości wynikające z iteracyjności i rygoru dostarczania działającego produktu co iterację. Krzywe łamać się będą różnie w różnych kontekstach, niemniej mało prawdopodobne, aby czerwona linia znalazła się nad niebieską.
November 10th, 2010
Przyznam się szczerze, że dzielę ten wpis na dwie części z lenistwa ;-) bo nie nie mam jeszcze gotowego drugiego modelu, o którym też chcę napisać. Ale do rzeczy…
Do tego posta zainspirowała mnie jedna z prezentacji na AgileEE 2010, gdzie zobaczyłem slajd na temat efektu uczenia się, albo szerzej efektu doświadczenia. Myślę, że warto mu poświęcić chwilę.
W tej teorii chodzi o to, że jeśli powtarzamy coś cyklicznie, np. wykonując jakaś usługę lub produkując coś, to jeśli podwoimy ilość tych czynności (lub ilość produkowanych elementów), to koszt lub nakład pracy na ich wytworzenie spadnie o pewną stałą wartość, którą można przewidzieć lub zbadać.
Dla wielu dziedzin życia zaobserwowano różne współczynniki dla krzywej doświadczenia. Zwykle wahają się one między 10% a 30%. Sprowadzając to do wytwarzania oprogramowania możemy powiedzieć, że podczas projektu, zdobywamy wiedzę na jego temat, na temat technologii, w której go wykonujmy, itd. Przy czym istotnym punktem dla całego procesu uczenia się, jest moment weryfikacji tego co zrobiliśmy z oczekiwaniami klienta.
Załóżmy w takim razie, że współczynnik zdobywania doświadczenia będzie dla nas wynosił 10%. Co to oznacza jeśli projekt będzie weryfikowany na koniec? No niewiele, bo tak faktycznie wtedy (na końcu) dowiemy się czegoś od klienta (np., że coś się mu nie podoba). Będziemy mogli jedynie powiedzieć, że jeśli będziemy mieli wykonać podobny projekt jeszcze raz, to jego koszt spadnie o 10%. Po 4 projektach spadnie o kolejne 10% w stosunku do wcześniejszego kosztu, po 8 o kolejne 10% i tak dalej.
A co jeśli podzielimy projekt na iteracje. W naszym przykładzie przyjmiemy, że projekt potrwa 16 iteracji. Tym samy stworzymy sobie 16 okazji do tego, aby czegoś nauczyć się podczas współpracy z naszym klientem. Da nam to tyle, że po 2, 4, i 8 iteracjach nasza efektywność wzrośnie o 10% (czyli koszt spadnie o 10%) w stosunku do dotychczasowego.
Jeśli nadal umiem policzyć całkę oznaczoną ;-), to wychodzi, że podczas 16-to iteracyjnego projektu można zredukować jego koszt o ponad 22% czyli bagatela jedną piątą. To teraz niech podniesie rękę szef, któremu się to nie podoba :-)
Oczywiście pełno tutaj uproszczeń i tak faktycznie nie znam żadnych badań nad naszą branżą w kontekście tych efektów. Ale coś w tym jednak jest i warto się nad takim podejściem do tematu zastanowić.
October 25th, 2010
Jakiś czas temu napisał do mnie Paweł Polewicz i “wypomniał” :-) mi, że obiecałem napisać coś o eksperymentach z Kanban w zespole utrzymaniowym. No dobra, to było w sierpniu… czas reakcji mam słaby, ale obiecałem, że do tematu wrócę, więc czas na zwierzenia… W tym przypadku będzie to raczej historia bez happy end’u, ale po kolei.
Kontekst projektu
Zespół składał się z 9 osób - 5 testerów i 4 programistów. Klient był zdalny (Niemcy), my pracowaliśmy we Wrocławiu. Na początku projektu spędziliśmy kilka tygodni u klienta na szkoleniu, aby zapoznać się z systemem i ludźmi. To był ogromy system tworzony od 25 lat. Nasza rola została ograniczona do naprawy błędów i testowania.
Po powrocie ze szkoleń nadal mieliśmy raczej mętne pojęcie na temat tego systemu, dlatego postanowiliśmy wprowadzić jakiś proces, który poukłada naszą pracę i zastymuluje wymianę wiedzy. Ze Scrum’a wyjęliśmy codzienne spotkania i dołożyliśmy do tego Kanban z wizualizacją na tablicy tego co się dzieje, oraz limitami. O limitach za chwilę.
Wybór padł na Kanban ze względu na to, że charakterystyką całego procesu było to, że błędy napływają w nieprzewidywalnej ilości i nie da się oszacować ich czasochłonności. One po prostu płyną.
Spotkania i tablica
Tablica dała nam możliwość wizualizacji stanu projektu. Tym samym każdy w dowolnym momencie mógł się dowiedzieć/przypomnieć sobie kto co robi i z czym ma do czynienia. Normalny kanbanboard miałby jedną ścieżkę, gdzie programiści byliby pierwszą częścią, a po nich praca przepływałaby do testerów. Ale ze względu na charakter naszego zespołu i podział odpowiedzialności (testerzy nie testowali błędów naprawionych we Wrocławiu przez programistów) zdecydowaliśmy podzielić ją na dwie części osobno dla testerów i dla programistów.
Sam system podzielony był na moduły i każdy programista został przydzielony do innego modułu (pierwszy problem). Testerzy byli w nieco lepszej sytuacji, bo dostali początkowo 3 moduły ale bez jakiegoś szczególnego podziału, więc zajmowali się nimi wszyscy. Niestety tylko jeden czy dwa moduły pokrywały się z tymi, nad którymi przyszło pracować programistom (drugi problem).
Na początku spotkania przy tablicy miały sens, bo informowaliśmy się nawzajem o rozwiązaniach podstawowych problemów (np. “naprawiałem dzisiaj błąd w module X i on funkcjonuje tak… zwróćcie uwagę na konfigurację tutaj i tutaj jeśli przyjdzie wam tam zaglądać”). Ale w miarę postępu czasu te informacje, ze względu na specjalizację poszczególnych członków zespołu, zaczęły interesować maksymalnie 2-3 osoby na 9 uczestniczących w spotkaniu.
Szybko też nasz klient podzielił pracę w sposób jeszcze bardziej rozłączny (testerzy też dostali osobne moduły) mimo, że sugerowaliśmy dokładnie coś odwrotnego po to, aby jakoś skorelować to co robią programiści i testerzy. Chcieliśmy wprowadzić pracę w parach (programista + tester) 2-3 godziny dziennie. Wydawało się, że to mogłoby przyspieszyć poznawanie systemu, ponieważ tester i programista patrzyli na system z innej strony, więc jeden drugiemu mógł doskonale uzupełniać pojęcie o całości. Niestety podział wprowadzony przez klienta skutecznie utrudniał taką wymianę wiedzy.
Tzn. sam podział tematyczny nie przeszkadzał jeszcze pracy w parach, bo ona pomogłaby każdemu osiągnąć większe pojęcie o całym systemie. Problem stanowiła raczej celowość takiego działania. Początkowym założeniem było, że przecieramy szlak i zespół będzie się powiększał, ale ten proces trwał tak powolnie po stronie klienta, że praktycznie każdy członek zespołu w wyniku działań klienta skupiał się bardziej na swojej specjalizacji, niż wiedzy ogólnej.
Limity WIP nie zadziałały
Limity WIP (ang. work in progress) w naszym przypadku miały służyć spowolnieniu zapełniania się kolumny PENDING przez tickety, które szybko odkładamy na bok jeśli nie radzimy sobie z nimi. Limit działa na cały zespół, więc chcieliśmy zastymulować konieczność pomagania sobie przy problematycznych ticketach (jeśli np. kolega ma problem, to nie zaczynam kolejnej rzeczy tylko pomagam mu rozwiązać jego). Celem było też szybsze zmuszenie nas do zatroszczenie się po naszej stronie, aby tickety nie leżały i czekały na lepsze czasy.
Limity nie zadziałały moim zdaniem z trzech powodów:
- Limit ma szansę być przekroczony tylko jeśli wyjście ticketu z danego stanu blokuje limit w kolejnym etapie. Czyli jeśli limit wypchniętych przez programistów ticketów byłby ograniczony limitem ticketów jakie testerzy mogą przyjąć do wykonania, a tutaj nie byliśmy ustawienie jedni po drugich, tylko równolegle obok siebie (innymi słowy testerzy nie testowali tego co programiści naprawili we Wrocławiu). Wyście z procesem na stronę klienta, w ogóle nie wchodziło w grę.
- Limity można złamać tylko przy zmianach stanu, czyli kończeniu pracy nad ticketem i braniem następnego, a to czasem trwało np. tydzień więc i tak pomagaliśmy sobie w trakcie a nie w przerwach. Natomiast nie istniał problem tego, że jedna osoba bierze się za zbyt wiele rzeczy.
- Zwykle gdy pojawiał się problem i praca zaczynałaby się piętrzyć, to ze względu na to, że wymagała ona pomocy z Niemiec, a to potrafiło trwać 2-3 dni, więc siłą rzeczy odkładaliśmy takie rzeczy do kolumny PENDING.
Ostatni z grzechów głównych
Retrospekcje… Początkowo przyjęły one formę spotkań ad-hoc przy kawie i luźnych dyskusji nad całym procesem. Zastanawialiśmy się co można zmienić lub ulepszyć. Nie udało się nam jednak nadać im jakiegoś regularnego charakteru z konkretnymi wnioskami (np. aby naprawić chociaż jedną przeszkodę w jakimś okresie). Proces wyglądał raczej odwrotnie. Problemy głównie wynikały z przeszkód komunikacyjnych i bardzo powolnego procesu decyzyjnego po stronie klienta.
Ścieżki komunikacyjne wewnątrz zespołu były skutecznie degenerowane na rzecz komunikacji Wrocław - Niemcy, co wiązało się z totalnym ograniczaniem naszej odpowiedzialności i sprowadzanie roli zespołu tylko do roli zdalnych robotników. Nie tak wyobrażam sobie nearshoring.
Ostatecznie chęć poprawiania czegokolwiek zaczęła się wypalać w zespole.
Napisy końcowe
Na pierwszy rzut oka wygląda, że w tym projekcie wszystko było porażką. Na pewne zabrakło nam zapału i być może umiejętności do tego aby pewne elementy zadziałały. Ale to co chciałbym podkreślić najbardziej i co powinno stanowić puentę tego posta to, że żaden proces nie jest w stanie Cię uratować jeśli podłoże do jego wprowadzenia nie jest odpowiednie. W naszym przypadku sam kontekst projektu (stary monolityczny projekt + nearshoring) oraz brak motywacji do poprawy czegokolwiek, był moim zdaniem kluczową przyczyną porażki przy wprowadzania Scrumowo-Kanbanowej hybrydy.
Jeśli któreś z powyższych problemów wydają się wam znajome i udało się je wam przezwyciężyć to piszcie. Co prawda nie jestem już częścią tego zespołu, ale projekt trwa. Kto wie, może ktoś podejmie jeszcze jakieś próby na placu boju.
October 16th, 2010
Jakiś czas temu pisałem na blogu tinyPM o tym czy szacowanie zadań w obrębie user stories w ogóle jest zasadne (Are you brave enough not to estimate your tasks?). Dzisiaj chciałbym podsumować w formie artykułu moją niedawną rozmowę z Marysią na temat estymacji i jej różnych wcieleń.
Zacznijmy trochę od końca (przynajmniej z mojego punktu widzenia) czyli od Scrum’a i burndown’u robionego na bazie pozostałej na dany moment pracochłonności zdań. W Scrum zalecane jest oszacowanie zadań na początek (w godzinach) i prowadzenie dziennika, w którym Scrum Master zapisuje informacje od członków zespołu, ile dane zadanie im zajęło w danym dniu i ile myślą, że jeszcze zostało. Tak każdego dnia, aż zadanie zostanie wykonane.
Co daje taka metoda? Początkowe szacowanie pozwala zorientować się czy zespół nie przeholował z deklaracją ile może faktycznie zrobić. Potem w ciągu trwania sprintu tworzony jest wykres na bazie sumy czasów pozostałych dla wszystkich zadań. To daje obraz tego co sądzi w danym momencie zespół na temat pracy jaka została jeszcze do wykonania. Ta suma może w danym dniu przewyższać estymację z dnia poprzedniego lub nawet początkową estymację co oznacza, że napotkaliśmy problemy, lub nie przewidzieliśmy jakiś zadań, których wykonanie jest konieczne do ukończenia user story.
Na koniec sprintu kończymy z zadaniami, które są powiązane z dwiema liczbami. Pierwotną estymacją oraz faktyczną sumą czasu spędzonego nad zadaniem. Daje nam to porównanie jak trafne są nasze oceny z początku sprintu. Dążymy oczywiście do tego, aby z czasem te dwie liczby okazywały się zbieżne :-)
A teraz do sedna. Po co nam takie śledzenie zadań? Czy nie da się prościej?
Szacowanie zadań wynika tak faktycznie z dwóch potrzeb:
Potrzeba nr 1
Mamy długą iterację. Np. 30 dni wg klasycznych zaleceń Scrum, a chcemy jak najdokładniej wiedzieć czy mamy jakiś problem z wykonaniem tego co w iteracji zadeklarowaliśmy. Chcemy to wiedzieć na bieżąco i chcemy wiedzieć czy idziemy dobrym kursem czy nie.
Potrzeba nr 2
Chcemy być w stanie ocenić to jak nam idzie szacowanie. Czy się mocno mylimy i w jakich sytuacjach najmocniej a w jakich najrzadziej.
I teraz każdą z tych potrzeb można zaspokoić na co najmniej kilka znanych mi sposobów, ale zależy to od przyjętej praktyki.
Małe user stories dające się ukończyć w ciągu jednego dnia. Bez podziału na zadania.
Jeśli stosujemy małe user stories, których realizacja nie ciągnie się przez całą iterację, to nie potrzebujemy w ogóle zadań ani ich estymacji bo burndown po ukończonych user stories zmienia się często i jest całkiem dokładnym odzwierciedleniem postępów zespołu. Jeśli dodatkowo user stories oszacowane są w punktach, to stwierdzenie, że ukończyliśmy w danym momencie 3 z 8 punktów daje nam całkiem dokładną informację o tym, w którym punkcie się znajdujemy.
Jeśli chodzi o dokładność szacowania, to wystarczy rejestrować czas pracy spędzony nad poszczególnymi user stories. Ocenę trafności szacowań da analiza informacji ile czasu średnio zajmują nam historyjki 1-punktowe, ile 2-punktowe itd. Okazać się może wtedy, gdzie mamy największe odchyłki. Należy się zastanowić z czego wynikają, aby uwzględnić to w kolejnym szacowaniu.
Większe user stories przy krótkich iteracjach.
Jeśli nasze user stories są zwykle większe i ich ukończenie zajmuje blisko całą iterację, to burndown po stories praktycznie nic nie mówi, bo przez całą iterację nic się nie dzieje a na koniec mamy skok i zaskoczenie.
W takiej sytuacji naturalną reakcją jest rozbicie user stories na zadania. Przy czym zadania tracą między sobą cechę porównywalności.
Można user stories rozbić na zadania nie większe niż jednodniowe, wtedy na poziomie zadań osiągniemy stan taki jak w poprzednim punkcie na poziomie stories. Można takich zdań nie estymować (skoro są wykonalne w ciągu jednego dnia), bo dokładność ruchów na wykresie będzie zadowalająca. Można powiedzieć ze skoro wykonaliśmy 12 z 25 maksymalnie jednodniowych zadań to jesteśmy mniej więcej w połowie pracy i porównać to z momentem iteracji.
W tym przypadku również bardziej interesujące wydaje się badanie jak nam idzie szacowanie user stories a nie zadań (których jeszcze nie zaczęliśmy estymować).
Długa iteracja i kilka naprawdę dużych user stories.
Przy np. 30 dniowej iteracji i user stories, które i tak zajmują prawie cały ten okres (iteracja zawiera np. 2-3 takie historyjki) dochodzimy do stanu w którym user stories tracą znaczenie z punktu widzenia śledzenia iteracji. Koniec jest zbyt odległy aby można sobie pozwolić na brak bieżącego i rzeczywistego obrazu tego jak nam idzie. Reakcja po 30 dniach może być zbyt późna.
Tutaj pojawia sie potrzeba estymacji zadań i potrzebujemy do tego jednostki, którą nadal można porównywać (np. godziny lub tez punkty). Z punktami jest ten problem, że ciężko rozbić story oszacowanego na 3 punkty, na 5 zadań i je także oszacować w takich samych punktach które w sumie dadzą 3.
No to może w godzinach… bliskie to wszystkim programistom. Ale jak wiemy, mocno się różnimy w szacowaniach godzinowych. Więc co z tego ze coś szacowaliśmy na 8 godzin, skoro w takcie miesiąca okazuje się: “oj pomylilem sie, to zajmie wiecej bo jeszcze musimy…”, itp.
Stąd pomysł ze Scrum na prowadzenie dziennika z czasem pozostałym do wykonania. Ta technika niweluje niedokładność szacowań godzinowych przy długich sprintach i ciągnących się przez wiele dni zadaniach. Codziennie mamy najbardziej rzeczywisty obraz stanu projektu.
Informacja o czasie pozostałym do wykonania nie daje nic jeśli chodzi o weryfikację estymacji po ukończeniu iteracji. Wtedy również istotny jest czas faktycznie spędzony nad zadaniami.
Można też spróbować weryfikować średnie czasu w grupach user stories szacowanych na tyle samo punktów. Ale przy długich iteracjach i dużych stories dokładność szacowania user stories bardziej zaczyna interesować samego właściciela produktu na poziomie planowania wydań. Zespół programistów bardziej obchodzą dokładności na zadaniach, bo w porównaniu do pierwszego punktu, to zadania zaczynają spełniać tę samą rolę co tam małe user stories.
Po co ten cały wywód?
Otóż wciąż często spotkam się z twierdzeniem, że do dobrego planowania potrzebujemy dokładnie takiego sposobu śledzenia zdań jak to proponuje Scrum, czyli szacowania zadań w godzinach, codziennego śledzenie czasu spędzonego i pozostałego na każdym zadaniu.
Tymczasem twierdzę, że tak faktycznie nie ma się co przywiązywać do tej metody, bo została ona opracowana z właśnie po to, by dać odpowiednią dokładność przy sprintach 30 dniowych i kilku dużych user stories wykonywanych w trakcie sprintu.
Natomiast coraz częściej obserwujemy zmianę w preferowanej długości iteracji i skracanie jej do 7 lub 14 dni. Także user stories są często dużo mniejsze niż początkowo zakładał Scrum czy XP. Dlatego zawsze należy dobrać narzędzia i środki do aktualnych warunków, bo być może to samo da się osiągnąć w dużo prostszy sposób.
Ja preferuje podejście na granicy pierwszego i drugiego i czyli iteracją 14 dniowa, małe stories z zdaniami dającymi się wykonać w ciągu jednego dnia. Tym samym interesuje mnie szacowanie user stories w punktach. Nie szacuję zadań. Natomiast śledzenie rzeczywistego czasu wykonania zdań, a w efekcie całego story, może dawać interesujący materiał do przemyśleń.
I jeszcze na koniec odsyłam do dobrego artykułu Mike’a Cohna na temat relacji user stories i ich faktycznego czasu wykonania: How Do Story Points Relate to Hours?
A wy którą metodę preferujecie / stosujecie?
February 22nd, 2010
Bitwa trwa, czas więc oddać swój strzał w dyskusji jaka rozgorzała na łamach Warszawskiego JUGa. Polecam poczytanie jej (urosła już do pokaźnych rozmiarów) a tymczasem ja postaram się ją tutaj (subiektywnie) streścić i odnieść się do paru rzeczy jakie mi wydały się tam najistotniejsze.
Tak więc dyskusja rozpoczyna się od słusznego spostrzeżenia Grzegorza Lipke (to on tą burzę wywołał :-), że Agile zdobywając popularność wśród polskich firm jest postrzegany jako proste rozwiązanie na trudne problemy, i że dużo ludzi liczy na pewnego rodzaju cudowne uleczenie po ich wdrożeniu.
Tymczasem rzeczywistość nie wygląda tak różowo. Podstawowy zarzut jaki pada w dyskusji to, że ta pozorna wolność jaką ludzie widzą w lekkich metodykach częściej prowadzi do chaosu i pogarsza sytuację pod przykrywką “samoorganizacji zespołu”.
Dyskusja zeszła też na tematy problemów:
- z wyceną i szacowaniem (o tym już parę razy pisałem, więc moje zdanie znacie),
- brakiem dokumentacji (która może być krytyczna)
- brakiem doświadczenia potrzebnego do prawidłowego zastosowania metodyk lekkich
Pojęcia
Po pierwsze czuję, że należy wyprostować trochę pojęć, bo w trakcie tej dyskusji przeplatają się wady Agile, czy Scrum czy może zamiast tego XP, albo prawie Agile = Scrum. To, dość typowe, utożsamienie Scruma z Agile wydaje mi się krzywdzące dla obu stron. Agile to pewna idea, zbiór czterech podstawowych wartości i zarys zasad jakie im towarzyszą. Scrum natomiast to jedna z implementacji tych wartości w dziedzinie lekkich metodyk (choć do końca metodyką nie jest). XP natomiast to zespół praktyk bardzo bliskich pracy programiście. Mało się w XP kładzie nacisku na zarządzanie ludźmi, projektami, produktami.
Jeśli więc mówimy o wadach Agile, to mówimy o wadach jakie dostrzegamy bądź w wartościach z Agile Manifesto, bądź w 12 praktykach, które tym wartościom towarzyszą. Pytanie czy któraś z nich wam się nie podoba? Co innego jeśli mówimy o ich wdrożeniu w życie. Tutaj jest już wiele pomysłów jak to zrobić. Jednym z nich jest Scrum, choć nie odpowiada on na wszystkie elementy z Agile Manifesto.
Może więc chodzi nam o wady Scrum? Na pierwszy rzut oka można zauważyć kilka:
- Scrum nie jest pełnym zbiorem, dlatego często uzupełnia się go w kontekście wytwarzania oprogramowania o praktyki z XP (uzupełnia a nie stosuje jedno zamiast drugiego)
- Scrum (z resztą jak cały ruch Agile) pierwszorzędny nacisk i całą odpowiedzialność kładzie na ludzi (tak na mnie i na Ciebie też :-) - czy to faktycznie wada?
- Scrum zakłada, że twoje otoczenie będzie równie zaangażowane jak ty, czyli zarówno sponsorzy jak i właściciele produktu, management, wszyscy mają swoje role. Problem w tym, ze nasze konteksty w życiu codziennym nie są takie różowe i w Scrum ciężko znaleźć na to odpowiedź.
Lekkość i prostota
Jacek Laskowski napisał w swoim komentarzu do dyskusji, że lekkie metody nie są, mimo swojej nazwy, wcale lekkie we wdrożeniu. A kto mówi, że są? Lekkość i prostota tych metod nie polega dla mnie na ich wdrożeniu. I nie mylmy prostoty z prostactwem (simple not simplistic). Ich lekkość leży w prostocie narzędzi jakich używają do osiągnięcia celu. Bezpośrednia rozmowa, krótkie spotkanie, mała kartka z user story, backlog (prosty w budowie). To są narzędzia, które są proste w zrozumieniu i nie wprowadzają zbędnego narzutu na zespół, który ma się skupić na swoim głównym celu, jakim jest dostarczenie wartości klientowi poprzez wytworzenie niezawodnego oprogramowania.
Zgadzam się z Pawłem Lipińskim w kwestii jakości. Każdy zarzut pod kątem pogorszenia się jakości w wyniku zastosowania lekkich metod jest nieuzasadniony, bo jednym z kluczowych problemów jakich Agile próbuje dotknąć jest właśnie jakość. Jeśli się pogarsza, to coś jest nie tak z zespołem a nie z założeniami metodyki (moja opinia).
Ludzie
Ludzie… W sumie to chodzi o dwie kwestie. Pierwsza to ta, że bardzo ciężko wprowadzać metodyki lekkie w niedoświadczonych zespołach. Moje pytanie brzmi - a którą metodykę wprowadza się łatwo w takich zespołach? Ja nie znam żadnej metodyki wytwarzania oprogramowania, którą wprowadzałoby się lekko i przyjemnie. Bo nie mówimy tutaj o produkcji masowej pana Forda, która była pomyślana właśnie pod kątem słabo wykwalifikowanej kadry. Więc jeśli mówimy o zespole, to jeśli ktoś poważnie myśli o podnoszeniu jakości jego pracy i w ogóle o zarządzaniu ludźmi, to nie zostawia słabo doświadczonych ludzi samych sobie.
Jeśli mówimy o dopiero formującym się zespole, np. w nowej firmie, gdzie brak nam doświadczenia z metodami lekkimi, to dlaczego oczekujemy, ze wszystko się nam uda? Wiadomo, będziemy eksperymentować. Nie zrzucajmy na karby metodyki naszych problemów z jej implementacją. Poza tym żadna z metodyk lekkich niczego nie narzuca pod rygorem kary śmierci. Te same problemy wystąpią w takim zespole podczas próby wprowadzenia PRINCE2 czy RUP (osobiście myślę, że większe). tutaj liczy się kontekst w jakim stosujemy dane praktyki. Coś co działa u mnie może nie działać u ciebie, więc się tego kurczowo nie trzymaj. To jest jedna z cech odróżniających metodyki lekkie od tych bardziej sformalizowanych.
Dla mnie małe doświadczenie nie jest problemem, bycie natomiast słabym programistą, managerem, testerem itd., mimo doświadczenia już problemem jest. Ja takich ludzi nie chcę. Rzadko wypowiadam się kategorycznie, ale w tym przypadku moje zdanie na ten temat jest jednoznaczne. Ja chcę mieć w zespole ludzi dobrych, ba… najlepszych. Idealnie lepszych ode mnie. Dla słabych, dla których to co robią to nic szczególnego, bo znaleźli się w IT przez przypadek, bo ta praca jest dobra jak każda inna, a przy tym można trochę zarobić, nie ma u mnie miejsca. Co mają ze sobą począć? Najlepiej znaleźć sobie inne zajęcie.
Dla mało doświadczonych, zapalonych do pracy, kreatywnych ludzi, wszystkie metodyki lekkie przygotowały narzędzia, aby uczynić z nich coraz lepszych specjalistów i to w wielu aspektach ich pracy. Trzeba tylko chcieć po to sięgnąć.
Po co Agile, czyli kontekst wdrożenia
Ach i jeszcze na koniec, bo zaczynam nudzić… Dla mnie podstawowym wyznacznikiem do podjęcia się wdrożenia metod lekkich jest odpowiedź na pytanie co tak faktycznie chcemy zmienić w obecnym procesie. Powszechna jest opinia, że z Agile będzie szybciej, lepiej, więcej, taniej, fajniej, lżej. WTF?
Może będzie szybciej, bo wcześniej klient dostanie to na czym mu zależało, a może szybciej się to wszystko wywróci i to też dobrze, bo można minimalizować straty. Czy będzie taniej? No pytanie dla kogo? Czasem faktycznie może się udać zmniejszyć koszty, ale częstsze będzie wykonanie produktu o wyższej jakości przy tym samym koszcie i czasie. Czy lżej? Na początku na pewno nie! Żadna z metodyk nie mówi nic o słodkim nieróbstwie (chyba, że coś przeoczyłem :-).
Tak więc Agile nie pomaga robić szybciej, taniej, więcej. Pomaga natomiast sprawnie ujawnić i rozwiązać problemy, które przed sobą postawimy - w naszym kontekście i z naszymi ludźmi.
November 4th, 2009
Dzisiaj chciałbym krótko zareklamować artykuł Pawła Lipińskiego z Pragmatists na temat “Zwinnego Rozwijania Oprogramowania”. Artykuł jest wprowadzeniem do filozofii kryjącej się za Agile Manifesto i zawiera interpretację zarówno czterech punktów manifestu, jak i dwunastu praktyk, które towarzyszą manifestowi (a o których często zapominamy).
Nie będę zbyt długo recenzował tego artykułu, bo nie mam się za bardzo do czego przyczepić :-) Zgadzam się zarówno z duchem całego artykułu jak i z interpretacją samego manifestu agile. Artykuł wypełnia lukę wśród materiałów na temat podstaw agile jakie można przeczytać po polsku, a jednocześnie zawiera wiele sugestii wynikających z praktyki.
Po lekturę odsyłam do Pragmatists oraz na bloga Pawła:
http://blog.pawellipinski.com/2009/10/wprowadzenie-do-zwinnego-rozwijania.html
Natomiast tekst polecam także jako czytankę, jaką można pokazać klientowi, którego chcemy uświadomić na temat tego, co do niego mówimy, kiedy próbujemy go przekonać, że te nasze czarne sztuczki to dla jego dobra :-)
Tymczasem czas samemu zabrać się za napisanie czegoś po polsku…
October 26th, 2009
Właśnie wróciłem z krótkich wakacji, z których przywiozłem sobie osobliwą pamiątkę - ulotkę pizzerii oferującej pizzę na telefon z dostawą do domu. Czemu jest w niej coś dziwnego? O tym za chwilę :-) Najpierw zabawmy się w mini projekt tworzenia takiej ulotki. Jesteśmy pracownikami restauracji i zastanawiamy się jak też ma nasza ulotka wyglądać:
- Oferujemy pizzę z dostawą do domu… napiszmy to dużymi literami, żeby każdy się zorientował.
- Mamy promocję “Zamów 3 pizze, 4-tą dostaniesz gratis” - musi być na ulotce!
- Oczywiście musi tam być też lista naszych pizz i ceny (duży wybór, więc poświęcimy temu całą stronę)
- Mamy ograniczony budżet ulotka będzie więc czarno-biała
- Jeszcze trzeba wybrać jakieś ładne zdjęcia z pizzą na jedną i drugą stronę.
Macie już w głowie jakiś ogólny obraz ulotki? Taka zwyczajna… A nie brakuje na tej liście czegoś? To może inaczej… Spójrzmy na planowanie funkcjonalności ulotki oczami jej użytkownika i spiszmy user story:
- Jako klient chcę się dowiedzieć jakie pizze są dostępne (z jakimi dodatkami) i ile kosztują abym mógł wybrać odpowiednią pizzę dla siebie.
- Jako klient chciałbym się dowiedzieć czy są dostępne jakieś promocje, abym mógł ew. dokonać jakiegoś korzystniejszego zakupu.
- Jako klient chcę się dowiedzieć z ulotki jaki jest numer telefonu abym mógł zamówić pizze, które wybrałem.
- Jako klient chciałbym wiedzieć gdzie mieści się pizzeria, na wypadek gdybym chciał się jednak przejść i zjeść pizzę na miejscu zamiast zamawiać ją telefonicznie.
Teraz już chyba domyślacie się dlaczego ta ulotka z “pizzą na telefon” tak mnie rozbawiła… Autorzy zapomnieli o numerze telefonu i adresie. Jedyną wskazówką była nazwa restauracji, więc ostatecznie udało się znaleźć numer w internecie :-)
A cały ten wakacyjny epizod skojarzył mi się z user story dlatego, że patrzenie na wymagania z punktu widzenia użytkownika a nie z punktu widzenia technicznych aspektów projektu jest moim zdaniem szalenie istotne i może czasem uratować “projekt” :-). User stories doskonale się do tego nadają, zwłaszcza, że początkowo celowo ukrywają te techniczne, nieistotne na etapie formowania wizji, szczegóły (jak kolory, zdjęcia, rozkład na stronach).
Innym aspektem, który tylko teraz zasygnalizuję jest to, ze często same user story są pisane bardziej od technicznej strony z pominięciem tej części “aby…”, która niesie ze sobą wartość dla użytkownika. A więc dostarczajmy przede wszystkim wartość użytkownikom, a nie projekt odbiorcy.
August 3rd, 2009
Agile powoli staje się głównym nurtem w sferze zarządzania wytwarzaniem oprogramowania (przynajmniej na zachodzie). SCRUM wdarł się na dobre do zespołów i całych organizacji. Co raz częściej słyszy się o zmianie kierunku i adaptacji elementów systemu produkcyjnego Toyoty takich jak Kanban (przynajmniej dla mnie ten rok w zachodniej blogosferze minie pod znakiem szczególnego zainteresowania Lean Software Development i Kanban).
Jeśli więc hasła Agile, SCRUM, Lean, Kanban są dla Ciebie nowością, ale ktoś wokół zaczyna o tym rozmawiać i ciekawi Cię o co w tym wszystkim chodzi, to poniżej znajdziesz moją subiektywną selekcję miejsc od których możesz zacząć podróż w ten ciekawy świat…
Na początek lektura obowiązkowa!!!
http://www.agilemanifesto.org
http://www.agilemanifesto.org/principles.html
To drugie szczególnie, bo często zapominamy o tej części Agile Manifesto. Jak dla mnie ruch, którego promotorem jest “Uncle Bob”, czyli Rober C. Martin, jest nierozerwalną częścią kultury agile… A tak, czy mówiłem już kiedyś, że agile to kulutra, sposób myślenia i podejścia do wytwarzania oprogramowania, a nie tylko zbiór praktyk… jeśli nie to na pewno powiem, ale może innym razem :-). Także do lektury obowiązkowej dołączam też:
http://manifesto.softwarecraftsmanship.org
SCRUM:
Żeby nie startować od razu od Kanban, to na początek Scrum w pigułce od Mike’a Cohna (taki mini słowniczek):
http://www.mountaingoatsoftware.com/scrum
Książek na temat SCRUM i Agile jest na prawdę dużo i ciężko wybrać jakąś konkretną. Dla mnie najlepszym wyborem na start będzie książka Henrika Kniberga “Scrum and XP from the Trenches” (PDF za darmo dostępny na InfoQ):
http://www.infoq.com/minibooks/scrum-xp-from-the-trenches
Po pierwsze doskonałym uzupełnieniem do książki Henrika Kniberga o Scrum, jest jego artykuł “Kanban vs Scrum”:
http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf
A po drugie artykuł z InfoQ (polecam też śledzenie samego InfoQ!). Ten artykuł może jest ciut skomplikowany, ale są w nim zasygnalizowane wszystkie podstawowe rzeczy, więc to dobry start do ew. dalszych poszukiwań co te wszystkie dzwine rzeczy oznaczają:
http://www.infoq.com/articles/hiranabe-lean-agile-kanban
AGILE
Jeśli nie zmęczy Cię lektura i wciąż zafascynowany tematem dotrzesz do tego momentu, to polecam śledzenie blogów. Ja czytam między innymi (takie moje prywatne TOP 5):
http://agile-commentary.blogspot.com
http://blog.mountaingoatsoftware.com
http://www.agileforall.com/blog
http://blog.crisp.se/henrikkniberg
http://agileinaflash.blogspot.com
Zapytasz - A CZEMU TO WSZYSTKO PO ANGIELSKU!? A no bo w Polsce wciąż kiepsko z materiałami o Agile.
Tym bardziej warto się czegoś na ten temat nauczyć i poeksperymentować bo reszta świata ucieka…
Po polsku polecam posłuchanie sobie podcastów z AgileTuning:
http://agiletuning.pl
To tyle na start ode mnie… Ciekaw jestem co polecą inny czytelnicy (zwłaszcza w swerze Lean / Kanban). Właśnie zaczynamy eksperymenty z Kanban w 9-osobowym zespole utrzymaniowo testowym, więc już niedługo trochę wieści z tych eksperymentów na pewno ujawnię :-) Tymczasem miłej lektury.
July 11th, 2009
Previous Posts
