Jako, że jest początek roku, to powinienem pisać podsumowanie działań agile w Polsce w 2010 roku… i pewnie w ciągu paru dni to zrobię. Tymczasem pomyślałem, że napiszę o czymś niedocenianym, czyli o technice 5 Why znaną z Lean i o analizie źródłowego problemu. No i pozwolę sobie tym razem zrobić to w nieco lżejszej formie :-)
Na wstępie wyjaśnię tylko, że chodzi o to, iż często po wykryciu problemu w projekcie, zespole, życiu, itd., staramy się mu zaradzić nie zastanawiając się nad tym co jest faktyczną przyczyną… Tym samym leczymy objaw a nie przyczynę. Kończy się to zwykle powtórką problemu w niedalekiej przyszłości. Technika “5x Dlaczego?” (5 Why?) to jedna z wielu technik dochodzenia do sedna problemu i jednocześnie bardzo w prosta w zastosowaniu. Wystarczy zadać sobie kilka pytań dlaczego?
To tyle tytułem wstępu, a teraz przenieśmy się do… przedszkola :-) Usłyszałem jakiś czas temu od syna:
Problem: “Byłem dzisiaj niegrzeczny… :(”
Tutaj można by się zatrzymać i reakcja mogłaby być taka, że wpadamy w gniew i wymierzamy karę, np. “No jak mogłeś… nie będzie dzisiaj oglądania bajek w TV”. Ale poczekajmy z tym i zadajmy pierwsze pytanie “dlaczego?”.
Pytanie: “Dlaczego? Co się stało?”
Odpowiedź: “Popchnąłem koleżankę z innej grupy…”
Dzieci maja wyjątkową zdolność do przekazywania minimalnej informacji wymaganej do zaspokojenia pytania rodzica. Czy nie przypomina to nam naszych własnych wyjaśnień dotyczących problemu? No to drążymy dalej…
Pytanie: “Ale dlaczego? Czy coś Ci zrobiła?”
Odpowiedź: “Zabrała mi kolegę…”
No dobra… teraz wiemy jeszcze mniej niż na początku.
Pytanie: “Jak to zabrała? Dlaczego ją za to popchnąłeś?”
Odpowiedź: “Bo ona mieszka na tym samym podwórku… i chciała, żeby się bawił z nią. Ale ja się z nim bawiłem pierwszy!”
Ok. Teraz już mamy obraz całej sytuacji. No i właśnie… Czy właściwym problemem jest złe zachowanie. Nie, to raczej był zły efekt wynikający z innego problemu. Mój syn spotkał się w przedszkolu po raz pierwszy z sytuacją, gdzie jego kolega może znać kogoś innego, kogo on sam nie zna. Gdyby nie drążyć moglibyśmy nie dowiedzieć się co tak faktycznie wymaga wyjaśnienia.
Mogło się skończyć na reprymendzie “Nie popychaj nikogo więcej”. Efekt byłby taki, że następnym razem zamiast popychania byłoby szczypanie (dzieci nie tylko dostarczają bardzo precyzyjnych w ich mniemaniu odpowiedzi - bardzo precyzyjnie traktują też to co do nich mówimy ;-))
Po bardziej naukowy opis metody odsyłam np. do Wikipedii. Są też inne techniki (np. fishbone diagram). A wy jakie techniki stosujecie do root cause analysis?
January 3rd, 2011
Marcin Niebudek
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
Marcin Niebudek
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
Marcin Niebudek
Tak… pierwsze Code Retreat we Wrocławiu jest już historią. 23 października o nadludzkiej porze jaką jest 8:00 rano w sobotę przyszło razem pokodować 61 osób! Myślę, że już sam ten fakt świadczy o sukcesie przedsięwzięcia jakie Grzegorz Dziemidowicz zainicjował we Wrocławiu przy wsparciu JUG’a i grupy Kunszt.
Celowo piszę “zainicjował”, bo sami organizatorzy myślą o powtórzeniu warsztatów za ok pół roku, a ja mam nadzieję, że przy naszym (uczestników) pozytywnym odzewie uda się ich zachęcić do zrobienia tego nawet szybciej :-)
Jak wyglądało Code Retreat?
Cały dzień podzielony został na 2 bloki składające się z 3 sesji kodowania w parach, które trwały 45 min każda + 10 min na retrospekcję. Po 3-ciej sesji w hotelowej restauracji podano wyśmienity obiad, który zawdzięczamy sponsorowi wydarzenia, czyli firmie Tieto.
Z resztą z obiadem wiąże się taka mała anegdotka, bo na oficjalnej stronie Code Retreat Corey’a Haines’a, wśród reguł opisujących organizację takich warsztatów, można znaleźć zdanie:
“Obiad powinien być czymś dobry, serwowanym. Moją regułą jest, że jeśli masz chęć przyjść o 8:00 rano aby spędzić z innymi cały dzień na kodowaniu, to zasługujesz na coś więcej niż pizza na obiad.”
Ale nie o jedzenie w tym wszystkim chodzi. Podczas każdej sesji mieliśmy zmieniać pary, co też uczyniłem, bo pierwotnie moim zamiarem było właśnie spróbować pracy z różnymi ludźmi, których nie znam. Takie podejście gwarantuje maksymalny poziom wymiany wiedzy. Problem do rozwiązania był cały czas ten sam - gra w życie, ale po pierwszych dwóch sesjach pojawiły się pomysły na podejście do problemu z zupełnie różnych kierunków.
Pary mogły np.:
- spróbować używać maksymalnie 2-4 linijkowych metod i maksymalnie 4 metod w klasie
- używać tylko obiektów immutable
- nie używać if’ów
- nie używać liczb i tablic do reprezentacji planszy i reguł gry
- itp.
Niektóre pomysły podrzucał na Twitterze Corey, który był w tym czasie zdaje się w Amsterdamie na podobnym Code Retreat :-)
Co ćwiczyliśmy?
Każda para miała wybrać sobie co głownie będzie ćwiczyła podczas sesji. W parach, w których ja kodowałem wybraliśmy:
- Pracę w parze ze zmianami co 5 min + TDD
- Ping-ponga (praca w parze gdzie jedna osoba pisze test, druga go implementuje) + podstawy pisania testów w JUnit
- TDD as if you meant it (Darek Mielniczek zasiał zainteresowanie tym tematem, które trwało do ostatniej sesji :-))
- Implementacja zagadnienia od góry, czyli od testów akceptacyjnych na całej grze.
- Immutability - tutaj moim zdaniem za mało było testów.
- TDD as if you meant it - drugie ćwiczenie poszło lepiej. Siła w powtórkach (Kata).
Czego się nauczyłem?
- Pierwszy raz próbowałem “TDD as if you meant it”
- Poznałem trochę tricków na refaktoryzację w Eclipse (+ trochę nowych skrótów klawiszowych)
- Spojrzałem na problem z kilku perspektyw
- Popracowałem w parze, co rzadko mi się zdarza
Co być może dałem od siebie?
- Propagowałem szablon should* (given, when, then) jakiego nauczyłem się jakiś czas temu od Szczepana Fabera i Bartka Bańkowskiego
- Pokazałem użycie biblioteki FestAssert + pluginy do Eclips’a jak MoreUnit
- Być może przekazałem w jednej z par trochę podstaw na temat testów w ogóle i dzielenia ich na mniejsze kawałki
Myślę, że spokojnie mogę stwierdzić iż nauczyłem się dużo w tak krótkim czasie. Gdyby osoby, z którymi programowałem mogły powiedzieć, że zyskały ode mnie tyle co ja od nich, to byłby to dla mnie duży komplement.
Generalnie bardzo podoba mi się formuła Code Retreat, bo kompletnie usuwa bariery pomiędzy doświadczonymi i niedoświadczonymi uczestnikami. Wynika to chociażby z faktu, że nawet jeśli jesteś doświadczony w jakiejś sferze, to okazać się może, że ta druga osoba uzupełni tą wiedzę czym innym jeśli zmienimy nieco charakter ćwiczenia. I o to w tym wszystkim chodzi.
Na podsumowanie
Powiem tak. Jeszcze raz gratuluję organizatorom. Było świetnie. A dodatkowym dowodem niech będzie to, że nie zrobiłem ani jednego zdjęcia. Code Retreat wciągnęło mnie do tego stopnia, że od 8:00 do 17:00 nie przypominam sobie ani chwili, w której pomyślałbym, że nie ma co robić ani z kim porozmawiać, więc może pstryknę parę zdjęć.
W podsumowaniu warsztatów padały głosy, że być może można nieco usystematyzować ramy takich następnych sesji w parach i narzucić więcej tematów do ćwiczeń. Ja raczej pozostałbym przy dowolności tego co para chce ćwiczyć i przy swobodzie wymiany doświadczeń. Oby następne spotkanie odbyło się nie później niż po nowym roku!
October 24th, 2010
Marcin Niebudek
Już w najbliższą sobotę we Wrocławiu odbędzie się pierwsze otwarte Code Retreat. To niezwykła gratka dla tych, których interesuje ruch Software Craftsmanship i chcą dodatkowo poćwiczyć sobie pisanie czystego kodu, TDD i pracę w parach.
Cieszy też fakt, że zainteresowanie było tak duże, że wejściówki rozeszły się praktycznie natychmiast. Ale cały czas można się wpisywać na listę oczekujących. No i mam nadzieję, że jest to pierwsze z wielu tego typu spotkań, które na stałe zagoszczą we Wrocławiu. Zobaczymy 23 października. Postaram się napisać więcej po spotkaniu.
Chciałbym przy tej okazji wspomnieć o możliwości uzyskania zielonej obrączki “Clean Code” promowanej przez Uncle Bob’a (Robert C. Martin). Taką obrączkę może dostać każdy, to przekaże min 10 USD na jeden z celów charytatywnych wymienionych na stronie akcji. Osobiście zaświadczam, że obrączki do Polski docierają :-) Więcej szczegółów tutaj:
http://butunclebob.com/ArticleS.UncleBob.GreenWristBand
October 19th, 2010
Marcin Niebudek
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
Marcin Niebudek
Od dawna chciałem to zrobić i w końcu się udało. Zrobiliśmy z moim starym zespołem Agile LEGO Game. W związku z tym, że moja kariera szkoleniowa jest wyjątkowo krótka, więc to był doskonały temat do ćwiczeń. Dodatkowo poznawanie zasad agile poprzez grę przemawia do mnie najlepiej.
No więc do rzeczy. To co chcę tutaj napisać, to krótkie podsumowanie jak te mini warsztaty poszły moim zdaniem oraz kilka uwag co powinienem poprawić.
Zdecydowałem się do gry wybrać user stories używane już wcześniej podczas innych tego typu warsztatów, czyli budowanie nowego gatunku zwierzęcia ;-). Efekty możecie podziwiać poniżej na zdjęciach. Tutaj zamieszczam też krótką prezentację, której użyłem jako wstępu do gry.
Celem było:
- zapoznanie zespołu z wartościami skrytymi za terminem agile
- przedstawienie idei iteracyjnego wytwarzania oprogramowania
- wyjaśnienie jak działa velocity i jak zespół agile poznaje swoje możliwości
- dobra zabawa
Wydaje mi się, że udało się te cele zrealizować. Natomiast co do samej mechaniki gry, to:
1. Nie wyjaśniłem, przy okazji opisywania co to są stories tego, co oznacza business value i tego, że to ona stanowi priorytyzację ze strony klienta. Następnym razem lepiej wyjaśnić to przed startem pierwszej iteracji.
2. Ja grałem rolę klienta dla dwóch zespołów. Przy trzech i więcej lepiej byłoby mieć klienta na każdy zespół.
3. Zacierała się granica pomiędzy fazą estymacji i planowania w trakcie każdej z iteracji. Przy czym pozwoliłem zespołom estymować jak chciały. Być może warto wprowadzić namiastkę planning pokera (np. w formie gry w marynarza). Z resztą to się wiąże z następnym problemem.
4. Jeden zespół zrobił wszystkie, a drugi wszystkie bez jednej user story. Przy czym zestaw był raczej pomyślany tak, żeby jednak trochę stories zostało. Wynika to z kilku przyczyn. Zespoły były 4-5 osobowe i to chyba za dużo. Nie zwróciłem uwagi, że nie trzeba wykonać całego zestawu stories z pierwszej iteracji, co dało efekt małego wyścigu i oba zespoły w pierwszej iteracji zbudowały prawie wszystko.
5. Użyłem http://e.ggtimer.com do mierzenia czasu. Lepiej do odmierzania czasu zabrać osobny zegarek, żeby nie przełączać prezentacji.
Co poprawię następnym razem:
- zwrócę większą uwagę na business value
- postaram się zmniejszyć tempo na rzecz lepszego wytłuszczenia etapów iteracji
October 12th, 2010
Marcin Niebudek
Właśnie narodziła się grupa Agile Warsaw, która ma na celu stworzenie w Warszawie społeczności ludzi związanych ze zwinnym wytwarzaniem oprogramowania.
Inicjatorzy (Marcin Gozdalik, Mateusz Srebrny, Paweł Lipiński, Marek Kirejczyk) chcieliby utworzyć przestrzeń z klimatem wzajemnego uczenia się, wymiany doświadczeń, wspólnego szukania nowych dróg do lepszego tworzenia oprogramowania, prowadzenia zespołów i zaspokajania potrzeb klientów.
Także zachęcam warszawiaków z zacięciem agile’owym do dania szansy tej grupie, bo kto jeśli nie wy właśnie zapewnicie jej miesiące (jeśli nie lata) prosperity!
Spotkania planowane są w wybrane poniedziałki, o godzinie 19stej w siedzibie firmy Aenima, ul Łucka 15 pok. 227. Planowana formuły spotkań to mini-wykład (15-30min) po którym następuje dyskusja i wymiana doświadczeń, oraz Open Space Technology. Spotkania kończą się retrospektywą / socjalizacją / networkingiem w okolicznym pubie.
Najbliższe spotkanie odbędzie się 24tego maja, tematem przewodnim będzie przejście ze Scruma do Kanabana, a poprowadzi go Marek Kirejczyk.
May 12th, 2010
Marcin Niebudek
No i powoli AgileCE 2010 przechodzi do historii (chociaż na twitterze jeszcze przez jakiś czas pobrzmiewać będą echa tej bardzo dobrej konferencji). Poniższe zdjęcie zaprowadzi was do większego zbioru, gdzie możecie zobaczyć jak to wyglądało. Już niedługo organizatorzy powinni zamieścić wszystkie prezentacje, bo każda była nagrywana.
W związku z tym, że konferencja była w całości prowadzona w języku angielskim a dodatkowo tinyPM był jednym ze sponsorów tego wydarzenia, zamieściłem podsumowanie i kilka przemyśleń na temat konferencji na naszym blogu produtkowym:
Jeśli macie ochotę poczytać o konferencji po Polsku to odsyłam także do pojawiających się artykułów na innych blogach:
Podsumowując konferencję jednym zdaniem myślę, że była ona świetnie zorganizowana a i merytorycznie stała na wysokim poziomie. Na pewno jak na pierwszą konferencję w Polsce w całości poświęconą Agile była sukcesem i czekamy na kolejną edycję w 2011. Miejmy nadzieję, że obie konferencje AgileCE oraz AgileEE (która już za pół roku w Kijowie) na stałe wejdą do naszego kalendarza imprez.
Wielkie podziękowania i gratulacje dla Paula Klippa za uczynienie tego wydarzenia możliwym!
April 12th, 2010
Marcin Niebudek
Jeśli jakimś cudem zapomnieliście, nie wiedzieliście albo zignorowaliście fakt, że już za 2 dni w Krakowie odbędzie się pierwsza 2-dniowa konferencja poświęcona w całości Agile, to jest to wasza ostatnia szansa aby się tam jeszcze pojawić.
AgileCE będzie miało dwie ścieżki wykładów oraz open space. Mimo, że konferencja odbywa się w Krakowie, będzie w całości po angielsku i z tego co przekazywali dotąd organizatorzy, spodziewamy się międzynarodowego towarzystwa.
Ja się wybieram, jeszcze niezdecydowanych namawiam, a zdecydowanej już części mówię do zobaczenia… Poznacie mnie oczywiście po koszulce tinyPM :-)
April 6th, 2010
Marcin Niebudek
Next Posts
Previous Posts
