Archiwum: December, 2008
Koniec roku sprzyja podsumowaniom, no więc i ja się o jedno malutkie pokuszę. Co się działo w polskim agile w roku 2008?
Rok zaczął się nieźle, bo w lutym odbyło się pierwsze spotkanie Agile Underground, które w Krakowie zorganizowali Bartosz Bańkowski, Adam Byrtek i Jakub Dziwisz. Kraków niewątpliwie jest aktywny jeśli chodzi o agile. Niestety skończyło się na iteracji pierwszej :(
Warto nadmienić, że ci sami panowie maczają też palce w działalności PAUG czyli Polish Agile Users Group, która to zanotowała już trzeci okres działalności. Tutaj muszę przyznać, że po archiwum postów widać, że działo się stosunkowo najwięcej w tym roku, co cieszy mnie bardzo. Aktywują się nowe osoby i nie jest tak źle. Rozwinęło się tam kilka ciekawych i pouczających dyskusji, że wspomnę tylko o jednej :D, która wybuchła nagle na bazie małego spamu jaki przedostał się na listę. Zachęcam do czytania, a co ważniejsze - do pisania na liście.
W tym roku na łamach PAUGa powstała lista firm stosujących, bądź próbujących stosować agile w swoich projektach. Nawet trochę się dopisało. Lunar Logic utrzymuje też taką listę na łamach swojej strony Agile Poland. Również zachęcam do zaglądania tam (i dopisania się).
Niestety albo o nich nie słychać albo podupadły tak aktywne w 2007 spotkania PAUGa w Krakowie, w czwartkowe wieczory. Co prawda nie udało mi się nigdy dotrzeć z Wrocławia na takie spotkanie, ale z samych podcastów i prezentacji można stwierdzić, że tematy oraz zapraszane tam osoby były ciekawe. Tyle, że w tym roku było chyba tylko jedno :(
Polska agile’owa blogosfera… no cóż - początek roku również był całkiem dobry. Ilfrin zaczął swój “Poradnik Młodego Sapera“, niestety około lipca wyleciał na czwartej minie w powietrze :-) i słuch po nim zaginał (a wciąż czekamy na następne odcinki). Na blogu chłopaków z True Solutions też na początku roku jeszcze trochę o XP można było przeczytać, ale szybko się skończyło, bo pochłonął ich własny startup (co z resztą nie dziwi, tylko poczytałbym jeszcze czasem o tym jak się wam nad nim pracuje w kontekście XP - życzę powodzenia w roku 2009). Szymon Włochowicz na blogu “Innowacyjność” często zapuszcza się w rejon metod zwinnych (tu życie jeszcze się tli i miejmy nadzieję, że nie zgaśnie w nadchodzącym roku). Z reszta sam nie jestem lepszy - prawie półroczna dziura w pisaniu, więc czego ja się czepiam…
Jasną gwiazdką jaka rozbłysła za to pod koniec tego roku w polskich blogach było AgileTuning.PL, czyli posty w formie podcastów na tematy związane z różnymi technikami zwinnego tworzenia oprogramowania. Bardzo atrakcyjna forma no i przede wszystkim dobra treść… słucha się z przyjemnością - oby tak dalej.
W każdym razie moje osobiste wrażenie jest takie, że pierwsza połowa roku 2008 była nieco bardziej aktywna w sferze agile niż końcówka… Mam nadzieję, że to (podobnie jak w moim przypadku) jedynie brak czasu na internetową aktywność a nie brak tematów. Tych miejmy nadzieję jeszcze nam w Polsce nie brakuje.
Wreszcie w tym roku można było się przeszkolić w ramach Certified Scrum Master we Wrocławiu, Warszawie i w Krakowie. Scrum Masterów nam w Polsce przybywa, chociaż mam wrażenie, że ostatnio kwestia nowych szkoleń trochę ucichła. Czyżby wszyscy SM już się w Polsce przeszkolili :-)?
Ach no właśnie… muszę też nieskromnie nadmienić, że powstały w Polsce dwa narzędzia wspomagające zarządzanie w duchu agile. Nieskromnie, bo jedno jest nasze, czyli stworzone przez Agilers. Mam na myśli tinyPM, który doczekał się pod koniec roku wersji 1.2. Drugie to produkcja Code Sprinters o nazwie Banana Scrum. A skoro jesteśmy przy narzędziech agile, to muszę też wspomnieć dokonałą bibliotekę Mockito do szpiegowania obiektów autorstwa Szczepana Fabera, która ujrzała swiatło dzienne również w tym roku (gratuluję doskonałej prezentacji na JDD 2008)
No więc czego sobie i Wam życzyć na ten nadchodzący rok 2009?
Może mimo, że procesy i narzędzia są potrzebne, abyśmy przede wszystkim cenili ludzi i współpracę z nimi.
Mimo niewątpliwej wartości dokumentacji, abyśmy główną uwagę zwracali na działające oprogramowanie.
Abyśmy podczas długich i ciężki negocjacji kontraktów nie zapominali, że przede wszystkim liczy się współpraca z klientem.
Wreszcie, abyśmy potrafili reagować na zmiany mimo wcześniej ustalonego planu :-)
A poza tym… POBUDKA! Fani agile wyjdźcie z okopów i pokażcie się innym… piszcie, pytajcie, spotykajcie się, wymieniajcie się wiedzą i doświadczeniem (sam powinienem sobie bardziej do serca wziąć własne życzenia ;-)… wciąż tego za mało w Polsce, a przecież umiemy to robić. W 2009 roku do roboty!
December 30th, 2008
Nie tak dawno powstała grupa, której celem jest wypracowanie pewnego szablonu kontraktu na wykonanie aplikacji wg metodyk agile.
Tak faktycznie w Polsce cały czas ciężko uciec od kontraktów typu fixed price ze względu na pewne przyzwyczajenia i strach przed innym rodzajem umowy, która nie zabezpieczałaby odpowiednio klienta (chociaż to raczej pobożne życzenie z tym zabezpieczeniem). No więc zamiast z tym walczyć może należy się z taką sytuacja “zaprzyjaźnić”. Żeby po raz kolejny nie wdawać się w pustą dyskusję na temat tego jakie to fixed price jest złe, postaram się tym razem zamieścić fragmenty faktycznych zapisów z umów jakie sami stosujemy u siebie. A więc podyskutujmy o konkretach…Na początek sekcja dotycząca trybu wykonania projektu:
TERMIN I SPOSÓB WYKONANIA UMOWY
- Strony zgodnie ustalają termin rozpoczęcia prac na dzień X a termin zakończenia prac na dzień Y.
- Wykonanie umowy odbywać się będzie iteracyjnie, tj. w równych N tygodniowych etapach.
- Po każdym etapie, począwszy od etapu nr 2, Zamawiający odbierze od Wykonawcy wykonane elementy Systemu oraz zgłosi uwagi i poprawki.
- Przed każdym kolejnym etapem Zamawiający określi elementy, które powinny być zrealizowane przez Wykonawcę w kolejnym etapie w pierwszej kolejności uwzględniając swoje uwagi zgłoszone po odebraniu etapu poprzedniego.
- Zamawiający może wprowadzić do zakresu projektu elementy nie przewidziane w załączniku nr 1. Pracochłonność nowych elementów zostanie oszacowana przez Wykonawcę i będą mogły one być zrealizowane w ramach niniejszej umowy bez zmiany wynagrodzenia, jeśli Zamawiający zrezygnuje z innych elementów o tej samej szacowanej pracochłonności. Uznaje się wtedy, że zakres projektu nie uległ zmianie. Nie ulega także zmianie termin ukończenia prac określony w pkt 1.
- W przeciwnym wypadku, tj. kiedy Zamawiający wprowadzi do planu nowe elementy bez usuwania z planu innych elementów Systemu, wynagrodzenie Wykonawcy może wzrosnąć proporcjonalnie do pracochłonności nowo wprowadzonych do planu elementów. W takim przypadku zmianie może ulec także termin ukończenia prac określony w pkt 1.
Jest też sekcja:
PRAWA I OBOWIĄZKI STRON
a w niej taki oto punkt, który określa nic innego jak proporcjonalność zapłaty do wykonanej do danego momentu pracy oraz wprowadza swobodę zakończenia projektu przy osiągnięciu odpowiedniej wartości przez klienta:
- Jeżeli wykonanie Systemu według zdefiniowanego w załączniku 1 zakresu okaże się niecelowe bądź jeżeli Zamawiający z przyczyn sobie wiadomych zrezygnuje z dalszego wykonywania umowy, Zamawiający będzie mógł odstąpić od niniejszej umowy za zapłatą odpowiedniej części wynagrodzenia za opracowanie Systemu na rzecz Wykonawcy, adekwatną do stopnia ukończenia Systemu.
I jeszcze może:
WYNAGRODZENIE
- Wynagrodzenie płatne jest w transzach po każdych … odebranych przez Zamawiającego etapach, proporcjonalnie do stopnia ukończenia prac nad Systemem.
- Wykonawca nie może żądać podwyższenia wynagrodzenia, jeżeli wykonał prace dodatkowe bez uzyskania zgody Zamawiającego na zasadach określonych w “TERMIN I SPOSÓB UMOWY”.
To nie są oczywiście wszystkie elementy umowy, ale pozostałe nie są tutaj interesujące bo zawierają raczej elementy standardowe nie związane z procesem agile w żaden sposób. Dodatkowo wyjaśnię tylko, że pojawiający się w powyższych punktach “załącznik nr 1″ (przecież każda dobra umowa musi taki załącznik zwierać :-) to nic innego jak lista user story z oszacowaniami w punktach (o tym jak taka listę do umowy budujemy w następnym poście).
Tym samym chciałbym zachęcić was do dyskusji na temat tego, co o takich zapisach myślicie? A może stosujecie inne, albo dodatkowe? Piszcie… a może uda się jakoś zebrać też i nasz polski sposób na kontrakt agile.
December 10th, 2008
Hotelowa nuda sprzyja pisaniu, a ja właśnie nudzę się w hotelu po szkoleniu… no dobrze - nie nudzę, ale nie bardzo wiem dzisiaj za co zabrać się najpierw, to może jednak czas na małe wynurzenie się z okopów.
Na początek małe wyjaśnienie do tego dziwacznego tytułu :-) Otóż chciałbym napisać dzisiaj parę słów na temat śledzenia projektu. Zdarzyło mi się jakiś czas temu słyszeć co iterację “We are on the right track!” (o matko minęło już prawie pół roku), co natchnęło mnie później do napisania niniejszego posta. No więc jak się pewnie domyślacie “We are on the right track!” miało ze stanem faktycznym tyle wspólnego co “We are in the right truck!”.
Ale po kolei. Na co wam to wygląda (brazek):
No tak… całkiem zwyczajny burndown. No może nie taki zwyczajny bo nie w punktach ale w procentach (ale to się za raz wyjaśni). No właśnie… na jego postawie można by nawet powiedzieć, że na pierwszy rzut oka faktycznie jesteśmy na dobrej drodze. Załóżmy, że wykres ten powstał na bazie jakiegoś projektu, który rozpoczął się od kontraktu z fixed price. Czyli w jakiś sposób (np. w punktach) zostaliśmy zmuszeni do oszacowania wstępnego zakresu projektu i wyszło nam np. 50 punktów - to jest nasze 100% na starcie. Jak fixed price to i cenę ustaliliśmy, przy czym cena nie jest tutaj taka istotna… najważniejsze, że ona się przekłada w głównej mierze na pewną pulę osobogodzin jaka się za tą ceną kryje (no bo zakontraktowaliśmy przecież X naszych programistów na Y tygodni / iteracji). Załóżmy że było to 500 osobogodzin - to też na starcie nasze 100%, ale budżetu.
Więc co jeśli, nasz wykres zacznie wyglądać tak:
No właśnie - już nie jest kolorowo… a wszyscy myśleli, że idzie tak pięknie. Każdy tymczasem w duchu rysował sobie ten wykres tak:
Do czego zmierzam? Otóż przy śledzeniu wypalania się projektu (albo przy śledzeniu samego velocity) istnieje pokusa do patrzenia się tylko na zakres, a wykres typu burndown chart ma to do siebie, że jedna krzywa nie wygląda groźnie dopóki opada w miarę równo, bo reagujemy zwykle tylko na zachwiania trendu. Nie widać natomiast po nim (zwłaszcza jeśli szacujemy w punktach), jak to sie ma do faktycznie przepracowywanych przez zespół godzin.
Stąd też te procenty… bo jak porównać wypalanie projektu w punktach do wypalania budżetu w pieniądzach lub osobogodzinach. Można to właśnie zrobić przeliczając obie wielkości na procent jaki do danego momentu został w projekcie wykonany / zużyty względem całkowitej wartości danego parametru. Wykonaliśmy 10 puntów, to daje nam 20% zakresu, przepracowaliśmy 125 godzin - to 25% budżetu. I co? już zapala się nam czerwona lampka… a samo 20% jeszcze nie wyglądałoby na nic złego. Tak faktycznie to może nie jest - może właśnie taki był plan. Tylko czemu w takim razie zużyliśmy na to wszystko już 25% naszego budżetu.
To jest ujęcie, które mi się osobiście podoba i chętnie go używam. Jeszcze tylko uwaga na koniec. W takiej metodzie, jeśli zmienia się zakres projektu w trakcie (czyli klient dorzuca coś nie wyjmując z listy nic w zamian), to wykres zaczyna wolniej opadać, ale nigdy nie zaczyna się podnosić. Podobnie z budżetem… jeśli dorzucimy trochę pieniędzy :-) to dźwignie to cały wykres a nie tylko iterację, w której następuje zmiana. Ale to nie przeszkadza w niczym, bo chodzi tu o obserwację rozbieżności między obydwoma liniami.
Ciekaw jestem waszych opinii oraz metod na to jak nie uśpić swojej uwagi i nie zgubić z oczu własnych pieniędzy. Ukończenie projektu w terminie to nie wszystko…
December 8th, 2008
