Kategoria 'Relacje z klientem'
Wiadomo nie od dziś, że zamieszany jestem w tworzenie narzędzia agile o nazwie tinyPM. I pewnie jako dostawca tego typu narzędzi nie powinienem pisać tego posta (tak mi coś dzwoni z tyłu głowy)…
Kontekst, albo szczypta histrorii
Kiedy podjęliśmy decyzję o napisaniu tinyPM’a kilka lat temu, częściowo świadomie, częściowo podświadomie, w każdym z projektów próbowaliśmy wdrażać jakieś zwinne praktyki. Zwykle jakaś część zespołu była rozproszona więc używaliśmy różnych narzędzi do wspomagania naszej komunikacji i udostępniania jak najlepszej informacji o stanie projektów.
Wtedy właśnie zaczęły nam doskwierać ograniczenia, jakie narzucały nam w taki bądź inny sposób narzędzia których używaliśmy (Excel, Wiki, SharePoint, itp.). Dlatego podjęliśmy decyzję o napisaniu własnego oprogramowania.
tinyPM był projektem prowadzonym po godzinach, wieczorami lub w weekend. Pamiętam, że zaczęliśmy od zarządzania informacją na wiki (nasz backlog i to co wokół niego). Po 3-4 iteracjach byliśmy gotowi do przeniesienia się do tinyPM’a. Wszystko co zawarte było z tinyPM’ie wynikało z naszych własnych doświadczeń. Pracując z nim od samego początku naprawialiśmy natychmiast wszystko co nam samym zaczęło przeszkadzać.
Kiedy tinyPM zbliżał się do jakieś wersji powiedzmy 0.69 (czyli taki niby już działający produkt, którego nikt jeszcze nie miał okazji zobaczyć) trafił się projekt, w którym miało być wdrożonych najwięcej praktyk agile. Nawet klient mocno parł na to aby tak zrobić.
Początkowo używaliśmy tam Trac’a, ale szybko przestał nam wystarczać. Zarówno nasz ówczesny pracodawca jak i klient zgodzili się na to aby użyć jako wsparcia naszego tinyPMa. To było świetne, bo na bieżąco do tinyPMa trafiały usprawnienia i funkcje, które bezpośrednio wynikały z codziennej praktyki naszego zespołu. Ich ślady można znaleźć w produkcie do dzisiaj.
Po kilku miesiącach zdecydowaliśmy się wydać wersję 1.0 i od tej pory zaczęliśmy zbierać informacje także przez UserVoice i e-mail. Nadal był to projekt, który prowadziliśmy równolegle z pracą na etacie programistów, ale założyliśmy już w tym czasie spółkę, aby móc formalnie sprzedawać licencje.
Projekty nad którymi pracowaliśmy na etacie stanowiły dla nas stałe źródło obserwacji i doświadczeń będących pożywką dla ulepszania tinyPM’a. Jednak praca na etacie i rozwój żyjącego już produktu były bardzo wyczerpujące. Nasze wysiłki skupiły się więc na uniezależnieniu się i zajęciu się na 100% naszym produktem.
Udało się. Praca nad tinyPM stała się naszym jedynym zajęciem, naszą pracą na etacie tyle, że na własny rachunek.
Tutaj docieramy do dylematu…
No właśnie. Jako dostawca narzędzia wspierającego zespoły stosujące praktyki agile, zajmowaliśmy się naszym narzędziem. Można by rzec, że od tego momentu mogliśmy się skupić na produkcie i na potrzebach naszych użytkowników. Jednak to co straciliśmy, to nasz udział w innych projektach. Zamieniliśmy go na intensywniejszą pracę nad tinyPM.
Najwięksi z producentów takich narzędzi prowadzą również (a może przede wszystkim) działalność konsultingową i szkoleniową. Ich armia coach’ów spędza miesiące w innych firmach wdrażających kulturę i praktyki agile. Inne firmy, takie jak nasza, opierają swoją działalność głównie o sprzedaż licencji.
Tylko czy to nie oznacza, że tracimy powoli kontakt z rzeczywistością?
Oczywiście używamy naszego własnego produktu do śledzenia pracy nad rozwojem tegoż. Pytanie czy to jest wystarczające? Czy producent tego typu narzędzia może opierać jego rozwój wyłącznie na komentarzach i potrzebach użytkowników zgłaszanych na forach takich jak nasze, czy też wiadomościach e-mail od użytkowników? Czy zwykła rozmowa, bez wniknięcia w kontekst projektów z jakimi borykają się użytkownicy to nie za mało? Pewne rzeczy trzeba poczuć na własnej skórze, żeby je zrozumieć.
To taki mini paradoks (przynajmniej tak go odczuwam), że tworząc narzędzie do zarządzania projektami, nie można dać się mu pochłonąć w 100%. Wbrew pozorom na jakość tego typu produktu duży wpływ ma właśnie fakt, czy tworzący go ludzie mogą część swojego czasu poświęcić zupełnie innym projektom. Projektom, które stanowią pożywkę dla rozwoju produktu oraz pole do doskonalenia samych procesów czy praktyk znajdując potem odzwierciedlenie w narzędziu.
Czas pokaże, czy projekt jaki my sobie znaleźliśmy (Conference Radar) wystarczy aby na nowo złapać dystans i zmienić nieco kontekst. A może właśnie dla “zdrowia” produktu należy rozszerzyć działalność i zacząć pracować z innymi zespołami?
Czy to ma sens? Jakiemu dostawcy zaufalibyście bardziej?
August 27th, 2011
Chciałbym was zaprosić do napisania posta. Celem jest powstanie cyklu “Agile Made in Poland“, w którym zaprezentowane byłby polskie firmy stosujące szeroko rozumiane agile/lean, to jak to robią i jakie praktyki oraz elementy stosują. Fajnie byłoby gdyby powstał z tego taki przegląd na jak wiele sposobów można wdrożyć te idee (bo spodziewam się różnorodności :-))
Dla usystematyzowania postów proponuję następującą listę pytań / strukturę (oczywiście format możemy jeszcze przedyskutować w komentarzach):
- Czym zajmuje się wasza firma? Kim są wasi klienci (chodzi o branżę)?
- Jak w kilku zdaniach wygląda wasz proces lub cykl życia produktu/projektu?
- Jaka jest struktura i sposób działania waszych zespołów?
- Jakie praktyki uważacie za najlepiej sprawdzające się, w waszym przypadku, w pracy z klientem i z ludźmi wewnątrz firmy?
- Jakie praktyki stosujecie dla zapewnienia jakości oprogramowania?
- Czy były jakieś praktyki, które nie zadziałały mimo prób ich wdrożenia? Dlaczego?
- Co chcielibyście zmienić w działaniu firmy jeśli chodzi o proces jaki stosuje?
- Czy chcielibyście coś dodać? Jakieś luźne przemyślenia na temat agile u was lub w Polsce?
Jeśli ktoś pokusi się o napisanie posta w tym formacie, to chętnie opublikuję go tutaj, ale będzie świetnie jeśli napiszecie na swoich blogach. Będę tylko wdzięczny za zachowanie formatu i danie mi znać (np. wpisując linka w komentarzach).
Uchylcie rąbka tajemnicy jak wygląda Agile Made in Poland…
May 25th, 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
Co prawda, to co za raz napiszę nie ma takiego bezpośredniego związku z agile, ale od jakiegoś czasu mnie to nurtuje. Zainspirowany lekturą książki “Implementing Lean Software Development” i korzystając z faktu, że mam akurat okazję obserwować tworzenie się zespołu typu nearshore, mam do was pytanie.
Jak zbudować relację firma matka - firma nearshore, tak aby obie opierały swoją pracę na modelu obopólnej korzyści? W języku angielskim jest takie zgrabne słowo incentive (zachęta? korzyść?). Gdzie szukać tej korzyści dla obu stron?W swojej książce Marry i Tom Poppendieck użyli przykładu outsourcingu usług typu help desk, gdzie wykonawcy wcale nie musi zależeć na rozwiązywaniu problemów klientów swojego zleceniodawcy jeśli jego model współpracy oparty jest na ilości obsłużonych błędów. W takim wypadku rozwiązywanie problemów odbiera pracę (i dochody) wykonawcy a to na pewno nie leży w jego interesie.
Mój przypadek jest bardzo pobony, tzn. firma typu nearshore buduje zespół głównie utrzymaniowy (być może w przyszłości także i rozwojowy). Spojrzmy na obie strony tego układu.
Klient:
- liczy na niższe koszty,
- potrzebuje nowych ludzi, a lokalny rynek się wyczerpał i bardzo trudno jest rekrutować specjalistów,
- zależy mu na tym, aby nowy zespół stał się równie wydajny jak jego własni ludzie
Wykonawca (firma typu nearshore):
- jest tańsza i łatwiej się jej pozbyć niż zwalniać własnych ludzi w razie kryzysu (modne słowo ;-),
- ma dostęp do ludzi i jest ich w stanie zrekrutować,
- zależy jej na trwaniu kontraktu i pozyskiwaniu coraz większej liczby zadań dla większej liczby ludzi bo zarabia na marży od ich pracy
No właśnie… pierwsze dwa punkty po obu stronach teoretycznie pasują do siebie i zwykle z połączenia właśnie takich celów rodzi się pomysł na nearshoring lub offshoring. Gorzej z punktem trzecim o którym jakoś cicho.
Zespół utrzymaniowy działa prawie jak help desk. Jeśli szybko rozwiąże problemy, to pozbawi się dochodu (jeśli rozliczany jest na godziny, czyli na zasadzie time and material). Z drugiej strony mamy jednak do czynienia z naprawianiem błędów oprogramowania. Gdyby przyjąć wynagrodzenie takiego zespołu oparte o ilość rozwiązanych problemów to byłoby to dość niebezpieczne dla wykonawcy, bo tego typu problemy bywają bardzo różne i jedne wymagają dużo więcej pracy niż inne.
Co powinny być w takim razie tą wspólną zachętą do współpracy dla obu stron, tak aby klient miał pewność, że jego partner wykona swoje zadania jak najlepiej i jak najszybciej, a wykonawca miał taki sam interes w takim właśnie podejściu do realizacji kontraktu? Czy to możliwe aby taki model współpracy nie wymagał skrupulatnej kontroli ze strony klienta, i ciągłego sprawdzania czy zespół nearshore pracuje a nie leży z założonymi rękami? Jak mierzyć wydajność takiego zespołu? Szacować pracochłonność zleceń tak jak szacujemy naszą pracę przy nowych projektach?
February 10th, 2009
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
Dlaczego decydujemy się na próbę wprowadzenia procesów agile? Najczęściej skuszeni jesteśmy obietnicą:
- szybszego dostarczania działającego oprogramowania (a co za tym idzie, lepszej wydajności naszych zespołów),
- lepszej jakości wytwarzania oprogramowania,
- szybszego reagowania na zmiany wymagań (i lepszego ukierunkowania się na klienta)
Pewnie w głowie każdy obiecuje sobie jeszcze kilka rzeczy, ale skupię się na tych trzech. A raczej na tym, co się stanie jeśli zaczniemy się skupiać na jednej z nich…
Dzisiaj usłyszałem od kogoś kogo mogę nazwać hmm… koordynatorem projektu? Niech będzie koordynator… No więc usłyszałem “jest dobrze, najważniejsze że mieścimy się w harmonogramie, harmonogram jest najważniejszy”. Jak to mierzymy? Chyba ilością zrealizowanych user story w stosunku do wyznaczonego w kontrakcie zestawu. Czyli mamy powiedzmy zakontraktowane 100 pkt, do dzisiaj powinniśmy mieć 30 pkt żeby projekt “wypalał” się nam w tempie gwarantującym dotrzymanie terminu. Może nawet jesteśmy do przodu w stosunku do planu.
Czyżby obietnica numer jeden była właśnie realizowana? Nic bardziej mylnego… niestety. Problem polega na tym, że nie w terminie jest klucz do sukcesu, ale w odpowiednich priorytetach. Co z tego, że dotrzymujemy terminów realizacji projektu jeśli na liście realizowanych funkcjonalności brakuje tych kluczowych. Ktoś może powiedzieć, że to oczywisty błąd, bo backlog projektu powinien być tak zbudowany, że na samym początku realizujemy najważniejsze user story. Więc jeśli tego nie robimy to sami kręcimy sobie pętlę na szyję.
Racja, chociaż sytuacja jak zwykle jest bardziej skomplikowana niż to się zakłada w tutorialach :-) Jeśli projekt cierpi na opóźnienie w dostarczaniu przez klienta niezbędnych informacji, to oprócz rozwiązywania tego problemu, na innym froncie trzeba robić co się da, nawet jeśli nie do końca jest to realizacja backlogu po linii priorytetów.
W takiej sytuacji może się okazać, że prosta statystyka zrealizowanych user story może nastrajać optymistycznie i uśpić czujność zarówno zespołu jak i klienta. A potem okaże się, że tak faktycznie to na tak powstałym produkcie nie da się realizować żadnego biznesu, bo składa się on głównie z terminowo zrealizowanych ozdobników.
Tak więc drodzy klienci… nie wierzcie samym statystykom… Zawsze patrzcie na wartość jaką niesie dla was każde nowe user story! Drogie zespoły (całe zespoły!) zawsze zadawajcie sobie podstawowe pytanie - do kogo skierowany jest produkt i czy to co właśnie macie zamiar zaimplementować pomaga użytkownikowi zrealizować jego podstawowe cele?
Z resztą ta druga rada jest bardzo podobna do porady na temat pisania dobrych user story. Zawsze kiedy piszemy lub implementujemy nowe story należy sobie zadać pytanie “jak mam zamiar zademonstrować wynik?”. To na pozór proste pytanie bardzo często ujawnia nasze braki w zrozumieniu zadania, podpowiada jak najlepiej zaimplementować dane user story, aby dobrze spełniało wymagania, wreszcie pozwala wskazać dużo testów akceptacyjnych.
Jeszcze raz… podstawą naszych działań jest wartość produktu a dopiero potem terminowość. Klient, kiedy terminy zaczną gonić, na pewno łatwiej poświęci mało istotne z punktu widzenia biznesu user story zamykające listę w backlogu jeśli zadania będą realizowane zgodnie z ich wartością, niż zdecyduje się na odpuszczenie istotnych user story, które zostały odłożone na koniec. I nie pomoże tutaj fakt, że do ostatniej chwili nasz harmonogram wyglądał idealnie.
June 10th, 2008
