17moments

Właściciel Produktu to także członek zespołu

Wed, 01 Feb 2012 03:38:00 -0800

Od zawsze traktowaliśmy klienta jako tę drugą stronę. Zawsze byliśmy „my” i zawsze byli „oni”. Nawet pracując w Scrumie z wewnętrznym klientem, kiedy rolę Właściciela Produktu (Product Owner) pełni osoba z naszej organizacji, nader często jesteśmy świadkami postawy „my kontra oni”. Postawę tę można zaobserwować najczęściej podczas Planowania czy Przeglądu Sprintu, ale także w pracy codziennej w trakcie Sprintu czy przy innych okazjach. Deweloperzy najczęściej winą za coś obarczają Właściciela Produktu i vice versa.

Postawa jest wynikiem przyzwyczajeń, które Scrum próbuje naprostować w postaci Zespołu Scrumowego, w którego skład wchodzą: Właściciel Produktu, Zespół Deweloperski i Scrum Master. Kiedy jednak mówimy o zespole w kontekście Scruma, najczęściej mamy na myśli jedynie Zespół Deweloperski. Zapominamy, że Zespół Scrumowy to także zespół, a Właściciel Produktu jest jego członkiem.

Jako członkowie Zespołów Scrumowych powinnyśmy współpracować na zasadach pracy zespołowej i znosić bariery komunikacyjne między poszczególnymi członkami zespołu.

Jeśli więc jesteś deweloperem, a szczególnie jeśli jesteś Scrum Masterem, następnym razem, kiedy zobaczysz, że Właściciel Produktu ma problem np. ze sformułowaniem historyjki użytkownika, zamiast narzekać na brak kompetencji u niego, spróbuj mu pomóc, tak jakbyś pomógł koledze z zespołu. Jeśli jesteś Właścicielem Produktu i np. zbyt często nie akceptujesz wykonanej przez deweloperów pracy, bądź dla nich dostępny w trakcie Sprintu i staraj się im pomóc, a nie tylko wymagaj. Niezależnie od roli pamiętaj, że razem tworzycie zespół i także od Ciebie zależy, czy będzie to prawdziwy zgrany zespół, czy będzie nim tylko z nazwy.

Permalink | Leave a comment »

Czy User Experience można zaprojektować?

Wed, 11 Jan 2012 05:22:00 -0800

Hasło user experience (UX) od jakiegoś już czasu jest silnie obecne w branży interaktywnej i ogólnie w wytwarzaniu oprogramowania. Mówimy o projektowaniu UX, powstały stanowiska User Experience Designer czy User Experience Director.

Cieszy rosnąca świadomość wagi user experience w kontekście sukcesu produktu, jakim jest serwis internetowy czy w ogóle oprogramowanie użytkowe, ale niesłusznie jest to często sprowadzane do badania użyteczności i projektowania interfejsu użytkownika (UI).

Wikipedia:

User experience (UX) is the way a person feels about using a product, system or service. [...] ISO 9241-210 defines user experience as "a person's perceptions and responses that result from the use or anticipated use of a product, system or service". So, user experience is subjective and focuses on the use.

User experience to wszystko to, czego osoba doświadcza podczas korzystania z produktu, systemu lub usługi. Całość odczuć, wrażeń, które są wynikiem wpływu kilku czynników: samego użytkownika, właściwości produktu oraz kontekstu, w jakim produkt jest używany.

Odczuć i wrażeń zaprojektować się nie da. Zaprojektować można produkt z myślą o użytkowniku i czynnikach wpływających na jego odczucia.

Sama lista właściwości produktu, jakim jest oprogramowanie, które wpływają na odczucia użytkownika jest bardzo długa. Nie chodzi tylko i wyłącznie o użyteczność i ergonomię interfejsu, ale też o stabilność działania, poczucie bezpieczeństwa, wydajność, szybkość odpowiedzi na interakcję ze strony użytkownika, dostępność (accessibility), dostępność (availability), cenę i wiele innych kwestii.

Mnogość czynników oraz szeroki zakres wiedzy i niezbędnych umiejętności powodują, że zapewnianie dobrego user experience to działalność złożona i wymaga współpracy specjalistów z wielu dziedzin: projektantów, programistów, administratorów, grafików, analityków, konsultantów biura obsługi klienta, marketerów itd.

Tak więc zapewnianie dobrego user experience, to rzeczywiście coś dużo więcej niż projektowanie interfejsu i testowanie użyteczności. Czy to jednak oznacza, że potrzebujemy stanowisk typu UX Specialist, UX Designer, UX Director?

Jesteśmy chyba jedyną branżą, w której mamy stanowiska dedykowane UX. Inne branże, w których nie chodzi o nic innego, jak o user experience, nie potrzebują dedykowanych temu stanowisk. W branży filmowej mamy reżyserów, scenarzystów, aktorów, kompozytorów, scenografów, inżynierów dźwięku, kamerzystów, specjalistów wielu innych dziedzin. Każdy z nich robi swoje i współpracuje z resztą zespołu ze świadomością, że ostatecznie liczy się „user experience” widza. Bez pomocy User Experience Directora.

Dlaczego nam już nie wystarcza specjalista ds. użyteczności (Usability Specialist) czy projektant interfejsu (UI Designer)?

Permalink | Leave a comment »

Prędkość a pojemność

Thu, 17 Nov 2011 03:59:00 -0800

Załóżmy, że dwa zespoły rozpoczynają pracę nad jednym i tym samym Rejestrem Produktu i niezależnie od siebie pracują nad tymi samymi historyjkami użytkownika (user stories). Dla uproszczenia przyjmijmy, że wszystkie historyjki zostały oszacowane na 5 punktów (story points) każda.

Elementy Rejestru Produktu	Estymata
Historyjka A	5 pkt.
Historyjka B	5 pkt.
Historyjka C	5 pkt.
Historyjka D	5 pkt.
Historyjka E	5 pkt.
Historyjka F	5 pkt.
Historyjka G	5 pkt.
Historyjka H	5 pkt.
Historyjka I	5 pkt.
Historyjka J	5 pkt.

Sprint pierwszy

Na pierwszy Sprint każdy zespół wybrał po 3 historyjki: A, B i C. Oba zespoły ukończyły wszystkie zaplanowane historyjki, a więc prędkość (velocity) obu zespołów jest taka sama i wynosi 15.

Sprint drugi

Na drugi Sprint oba zespoły wybierają znowu po 3 historyjki: D, E, F i znowu wszystkie udaje im się ukończyć. Prędkość znowu 15.

Sprint trzeci

Na trzeci Sprint zespół nr 1 wybiera historyjki G, H i I. Zespół nr 2 natomiast wykrył błąd w aplikacji, który powstał podczas realizacji Historyjki B. Zespół dodaje więc do Rejestru Produktu element „Błąd B#1”, usunięcie którego zespół szacuje też na 5 pkt. Do trzeciego Sprintu wybiera więc usunięcie błędu B#1 oraz historyjki G i H, bo więcej nie zdąży zrobić.

Obu zespołom udaje się ukończyć wszystko, co sobie zaplanowały na Sprint. Prędkość obu zespołów znowu jest taka sama i wynosi 15. Czyżby?

Nie bilansuje się

Spójrzmy na Rejestr Produktu i stan samego produktu. Produkt jest bogatszy w przypadku zespołu nr 1 o historyjkę I. Zespół 2 dopuścił się gdzieś wcześniej (przy historyjce B) zaniedbania i za ukończone zostało uznane coś, co zawierało defekt. Więc tak naprawdę należałoby cofnąć się do pierwszego Sprintu, cofnąć akceptację historyjki B i obliczyć prędkość zespołu na 10. Oczywiście nikt tego nie robi.

W takich przypadkach należy przyznać zespołowi nr 2 na start trzeciego Sprintu −5 do prędkości i wtedy wszystko się bilansuje. Prościej: nie wliczać do prędkości zespołu prac mających na celu usunięcie usterki. Dla pełnej przejrzystości rozgraniczyć prędkość (velocity) i pojemność (capacity) zespołu. W tym przypadku za trzeci Sprint prędkość zespołu nr 2 wynosiła 10, a pojemność — 15.

Uogólniając:

Prędkość zespołu to wszystkie ukończone w trakcie Sprintu elementy Rejestru Produktu, które tworzą wartość dodaną do produktu.
Pojemność zespołu to wykonana w trakcie Sprintu praca. Pojemność wyznacza możliwą do osiągnięcia prędkość, gdyby były przetwarzane tylko te elementy, które tworzą wartość dodaną, a praca była ukończona.

Co tworzy wartość dodaną?

Czy tylko usuwanie usterek i nieukończona praca nie powinny być wliczane do prędkości? Co tworzy wartość dodaną, a co nie? Posłużmy się autem, jako analogią.

Załóżmy, że jesteśmy właścicielem auta o nominalnej wartości 20 tys. złotych. Jak wiadomo, auto się czasem psuje i usterki trzeba usuwać, należy też dokonywać okresowych przeglądów i ponosić koszty na profilaktyczne naprawy. Wszystkie te prace, choć potrzebne, i związane z nimi koszty nie zwiększają nominalnej wartości naszego auta. Co innego, jeśli zainwestujemy na przykład w sprzęt audio, zamontujemy czujnik cofania (którego domyślnie nie było), wymienimy felgi na alu itp.

Tak samo należy patrzeć produkt, jakim jest oprogramowanie. Usuwanie usterek, refaktoryzacja, uzupełnianie kodu testami jednostkowymi, analizy, raporty, dopisywanie dokumentacji „po fakcie” — to wszystko, choć wartościowe, nie dodaje wartości produktowi, a jest jedynie kosztem ponoszonym na jego utrzymanie, a czasem wręcz spłacaniem długu technologicznego, czyli wyrównywaniem poziomu jakości do pewnego stanu zero, a nie na plus.

Warto rozgraniczać te dwie metryki; zwiększa to przejrzystość, a Zespół Scrumowy i interesariusze mają jaśniejszy obraz całej sytuacji, a ich analiza (np. w trakcie Retrospektywy) może pomóc w poszukiwaniu metody na zwiększenie prędkości.

Permalink | Leave a comment »

Przegląd Sprintu to nie (tylko) demo

Mon, 12 Sep 2011 03:34:00 -0700

Na koniec każdego Sprintu odbywa się Przegląd Sprintu (Sprint Review). Często spotkanie to określa się potocznie jako Demo, bo Zespół Deweloperski demonstruje wtedy to, co udało się stworzyć w trakcie Sprintu. W praktyce więc spotkanie to często sprowadza się do demonstracji wprowadzonych nowych lub zmienionych funkcjonalności dla Właściciela Produktu.

Prezentacja produktu, choć kluczowa, nie jest jednak jedynym elementem tego spotkania, ani tym bardziej jego celem samym w sobie. Prezentacja Przyrostu produktu jest niezbędna, aby można było dokonać jego inspekcji, co ma prowadzić do adaptacji pod postacią zmian w Rejestrze Produktu.

Jest to także spotkanie, w którym oprócz Zespołu Scrumowego uczestniczą pozostali interesariusze. Aby mogli oni udzielić wartościowej informacji zwrotnej, potrzebują kontekstu, jaki stanowi aktualny Rejestr Produktu prezentowany i omawiany przez Właściciela Produktu.

Zamiast więc myśleć o Przeglądzie Sprintu jako demonstracji zmian w produkcie przez Zespół Deweloperski dla Właściciela Produktu, należy spojrzeć na to jak na:

prezentację wyników Sprintu w kontekście planów rozwoju produktu
przez cały Zespół Scrumowy dla interesariuszy obecnych na spotkaniu
w celu uzyskania informacji zwrotnej i ustalenia najbliższych kroków.

Aby to osiągnąć należy dobrze zaplanować i przeprowadzić samo spotkanie, które może przyjąć następujący przebieg:

Właściciel Produktu przypomina Cel Sprintu i określa, czy udało się go osiągnąć.
Właściciel Produktu wymienia elementy Rejestru Produktu (np. historyjki użytkownika) wybrane przez Zespół Deweloperski do Sprintu i określa, które z nich zostały ukończone.
Zespół Deweloperski demonstruje to, co udało się ukończyć, odpowiada na pytania dotyczące produktu oraz omawia problemy, jakie napotkał w trakcie pracy i jak je rozwiązał.
Właściciel Produktu prezentuje aktualny Rejestr Produktu omawiając zmiany, jakie zaszły w nim od ostatniego Przeglądu.
Biorąc pod uwagę postępy i tempo prac Właściciel Produktu przewiduje termin zakończenia prac i najbliższego wydania oraz przedstawia alternatywne drogi do osiągnięcia celu. Pomocne może być wyliczenie aktualnej prędkości (velocity) oraz symulacja terminu zakończenia różnego zakresu prac przy różnych założeniach co do prędkości.
Zespół Scrumowy wraz z obecnymi na spotkaniu interesariuszami omawia najbliższe kroki, czyli to, co najprawdopodobniej będzie robione w nadchodzącym Sprincie.

Na wejściu mamy więc Przyrost produktu, na wyjściu zaś powinniśmy otrzymać uaktualniony Rejestr Produktu, który posłuży Zespołowi Scrumowemu w jak najlepszym zaplanowaniu kolejnego Sprintu.

Podsumowując: Przegląd Sprintu to nie (tylko) demo, ani tym bardziej spotkanie statusowe, na którym Zespół Deweloperski raportuje Właścicielowi Produktu i zbiera oklaski bądź wysłuchuje słów krytyki. Przegląd Sprintu to spotkanie robocze całego Zespołu Scrumowego oraz interesariuszy nad produktem i planami jego rozwoju.

Permalink | Leave a comment »

Optymalna długość Sprintu

Fri, 02 Sep 2011 04:01:00 -0700

Długość iteracji w Scrumie (Sprint) jest ograniczona do jednego miesiąca kalendarzowego. Chociaż w najnowszej wersji Scrum Guide’a nie ma określonego minimalnego czasu trwania Sprintu, to przyjmuje się, że krótsze niż jeden tydzień mogą być nieefektywne. Jak określić optymalną długość Sprintu?

Długość Sprintu powinna być określana na podstawie akceptowalnego poziomu ryzyka z jednej strony i czasu potrzebnego zespołowi na wytworzenie czegoś ukończonego z drugiej. Poziom ryzyka zależy od złożoności środowiska, w jakim pracujemy i horyzontu planowania.

Czynniki składające się na złożoność środowiska to: wymagania (ich znajomość i zmienność, co ma odzwierciedlenie w Rejestrze Produktu i jego dynamice); technologia (nowa czy dobrze znana itd.); i ludzie (wielkość zespołu, zgranie, doświadczenie i poziom umiejętności, różnorodność specjalizacji itd.).

Jeśli więc mamy np. początek projektu, kiedy w wymaganiach jest dużo niewiadomych, często się zmieniają, Zespół Deweloperski jest liczny (np. 6-9 osób), świeżo skompletowany i do tego pracuje w nowej technologii, której nie zna, to mamy do czynienia z bardzo złożonym środowiskiem. Obranie więc 30-dniowego horyzontu planowania w takiej sytuacji spowoduje prawdopodobnie to, że poziom ryzyka będzie nie do przyjęcia. Chcąc go ograniczyć można redukować złożoność albo skracać horyzont planowania.

Oczywiście redukując i skracając do minimum możemy dojść do sytuacji, kiedy taki „zespół” nie będzie w stanie niczego wytworzyć. To ta druga strona, determinująca minimalną długość iteracji.

Tak więc to wszystko zależy od bardzo wielu czynników i nie ma prostej odpowiedzi na pytanie o optymalną długość Sprintu, chociaż ogólne wzorce można spróbować określić:

Dla krótkiego projektu (np. 2-miesięcznego) lepsze będą krótkie iteracje (np. 1-2 tygodniowe), bo długich (miesięcznych) będzie po prostu za mało i będziemy mieli zbyt mało okazji do inspekcji i adaptacji. W długich projektach można zaryzykować dłuższe iteracje, bo krótkie mogą okazać się zbędnym narzutem organizacyjnym.
Jeżeli mamy do czynienia z mało zaangażowanym klientem, lepsze mogą być znowu krótsze iteracje, bo zmusi go to do częstszych kontaktów z zespołem. Z zaangażowanym, ulokowanym w pobliżu zespołu Właścicielem Produktu umiejącym wykorzystywać Scrum w swojej pracy, można spróbować dłuższych.
Dla świeżych i niedoświadczonych zespołów znowu lepsze mogą być krótsze iteracje, żeby zespół nauczył się wytwarzać coś małego ale ukończonego. Długie iteracje to zbyt duże ryzyko, że więcej czasu i pracy się zmarnuje. O miesięczne Sprinty może się pokusić zgrany zespół wyjadaczy.
Jeżeli wymagania są słabo znane albo uczymy się nowej technologii, może być potrzeba wprowadzania częstszych zmian i szybszego uzyskiwania informacji zwrotnej, a więc krótsze iteracje. Stabilny, dobrze przygotowany Rejestr Produktu, oraz technologia, z którą czujemy się komfortowo — można dłuższe.

Ważne jest, żeby zdawać sobie sprawę z tych wszystkich czynników i przy określaniu długości Sprintu brać je wszystkie pod uwagę, a najlepiej długość określać empirycznie, tj. wypróbowując różne „ustawienia”, pamiętając jednocześnie, że zbyt częste zmiany „ustawień” to znowu zwiększanie złożoności.

Permalink | Leave a comment »

Nowa wersja Scrum Guide’a

Thu, 21 Jul 2011 04:34:00 -0700

20 lipca 2011r. na Scrum.org została opublikowana nowa wersja Scrum Guide’a. Na razie tylko w języku angielskim, ale społeczność Scrum zapewne już pracuje nad tłumaczeniami na inne języki, w tym polski.

O ile nic się nie zmieniło, jeśli chodzi o podstawy Scruma, to doprecyzowano kilka kwestii i udoskonalono sam dokument, o czym można przeczytać w komunikacie Kena Schwabera i Jeffa Sutherlanda.

Główne zmiany:

Scrum Guide zawiera teraz jedynie reguły gry, a więc usunięto wszelkie wskazówki.
Zespół, który wcześniej nazywano The Team, od teraz nazywa się The Development Team (Zespół Deweloperski), zaś członków zespołu nazywa się deweloperami. Zapewne dla jaśniejszego rozróżnienia pojęć Zespołu Scrumowego i Zespołu „właściwego”.
Zespół Deweloperski nie zobowiązuje się do ukończenia całej pracy zaplanowanej podczas spotkania planistycznego Sprintu. Zespół tworzy prognozę pracy, którą wierzy, że wykona podczas Sprintu, ale prognoza ta zmienia się w trakcie Sprintu w miarę, jak zespół dowiaduje się więcej.
Nie jest już wymagany wykres spalania (burndown chart) do śledzenia postępów pracy. Natomiast pozostała do wykonania praca jest sumowana codziennie i znana oraz postępy nadal powinny być śledzone.
Planowanie wydania, choć wartościowe, nie jest wymagane. Nigdy nie było, ale we wcześniejszej wersji Scrum Guide’a było opisane.
Rejestr Sprintu (Sprint Backlog) składa się z elementów Rejestru Produktu (Product Backlog) wybranych do Sprintu i planu ich dostarczenia. Twór znany jako „element Rejestru Sprintu” (Sprint Backlog item) nie jest więc konieczny.
Rejestr Produktu (Product Backlog) nie jest już „spriorytetyzowany”, tylko „uporządkowany”.

Autorzy zapowiadają na przyszłość szersze wyjaśnienie wprowadzonych zmian.

Permalink | Leave a comment »

Zespół w Scrum to kapela rockowa

Wed, 02 Feb 2011 03:40:00 -0800

Zespół w Scrum powinien być interdyscyplinarny, tzn. powinien posiadać wszelkie niezbędne kompetencje (wiedzę, umiejętności, uprawnienia itd.) do wykonania całej pracy potrzebnej do osiągnięcia celu, tj. przekształcenia elementów Rejestru Produktu (Product Backlog) w kolejne przyrosty produktu.

Zasada ta często jest błędnie rozumiana jako jedna z dwu skrajności:

zespół musi mieć dedykowanego specjalistę z każdej dziedziny (programista back-end, front-end, projektant UI, grafik, DBA, tester itd.), a najlepiej po kilku na wypadek nieobecności;
każdy członek zespołu to na tyle wszechstronnie rozwinięta osoba, że potrafi wykonywać pracę z każdej dziedziny i w razie czego zastąpić każdego innego kolegę.

Tymczasem prawdziwa interdyscyplinarność zwinnych (agile) zespołów leży gdzieś pomiędzy tymi skrajnościami.

Kapela rockowa czy muzycy sesyjni?

W kapeli rockowej także mamy specjalizacje (gitarzysta, często nawet z podziałem na węższe specjalizacje: rhythm i lead guitar; basista; perkusista; wokalista itd.). Chociaż nie widzimy często na koncertach muzyków zamieniających się rolami, to większość z nich zna przynajmniej podstawy gry na innych niż swój instrumentach, a wszyscy mają pojęcie o tym, co robią jako zespół — o rock 'n' rollu.

(Zdjęcie na licencji CC-BY-SA 3.0 pochodzi z Wikipedii)

Wszystkim muzykom w kapeli przyświeca jeden cel: zagrać koncert dla publiczności; nie: odegrać partię swojego instrumentu. Na scenie słuchają siebie nawzajem, wspierają się, dopasowują jeden do drugiego. Kiedy jeden się pomyli, reszta ratuje sytuację. Jako zespół ponoszą wspólnie odpowiedzialność za udany bądź nieudany koncert.

Jeden cel — wygrać — przyświeca także drużynom sportowym. Podział na specjalizacje nie stoi na przeszkodzie, żeby bramkarz nie strzelił czasem gola.

Zwinny zespół IT ma wspólny cel (rozwój produktu) i dąży do jego osiągnięcia współdzieląc odpowiedzialność, pomagając sobie kiedy trzeba, dzieląc się obowiązkami i wiedzą. W zespole chodzi o robienie czegoś razem, a nie za kogoś.

Czy Twój zespół to kapela rockowa czy zbiór sesyjnych muzyków grających, jak menedżer każe?

Permalink | Leave a comment »

Agile UX — komunikacja w procesie projektowania (prezentacja)

Tue, 14 Dec 2010 04:13:00 -0800

23 listopada 2010 odbył się w Gdańsku tematyczny 3camp poświęcony użyteczności z okazji World Usability Day, który przypada w listopadzie.

Oto nagranie i slajdy z moją prezentacją, w której w skrócie przybliżyłem, jak w Gratka Technologie wykorzystując Scrum próbujemy dbać o użyteczność produktów, nad którymi pracujemy, a w szczególności, jak wygląda projektowanie interfejsu użytkownika w zespole.

Agile UX — Komunikacja w procesie projektowania from 3camp.pl on Vimeo.

Agile UX komunikacja w projektowaniu

View more presentations from 3camp.

Przydatne materiały w tym temacie:

Permalink | Leave a comment »

Cytaty ze Scrum in Depth z Kenem Schwaberem

Tue, 18 May 2010 08:03:00 -0700

W dniach 13-14 maja 2010 r. miałem okazję uczestniczyć w szkoleniu Scrum in Depth prowadzonym przez Kena Schwabera. Poniżej kilka wybranych cytatów z notatek.

— Jak przekonać klienta do używania Scruma?
— Nie eksponuj tego klientowi. Po prostu zacznij używać Scruma, dostarczaj coś w równych odstępach czasu i pytaj, czy to jest to, czego potrzebuje.

Myśl o Scrumie jak o teściowej, która uważa, że jej córka mogła wyjść za mąż lepiej i która zamierza pomóc ci stać się wystarczająco dobrym mężem. Właśnie zaprosiłeś ją, by zamieszkała z wami.

Nie wiń narzędzia (Scruma) za to, że ujawniło pewne problemy.

Praca menedżera to zrobić coś z tym, co właśnie usłyszałeś, a nie mówić, że ci się to nie podoba.

Najcięższa część to zmiana swoich przyzwyczajeń. Nie klienta.

Artefakty per projekt vs. per produkt. Myśl raczej o cyklu życia produktu niż projektu.

Używanie Scruma w wytwarzaniu oprogramowania jest trudne, ponieważ wytwarzanie oprogramowania jest trudne. Nie Scrum.

Scrum jest dla dorosłych ludzi.

Scrum nie da odpowiedzi na pytanie „jak?”

Permalink | Leave a comment »

Tankuj do pełna, czyli dlaczego Sprintów się nie skraca

Tue, 27 Apr 2010 12:00:00 -0700

Nawiązanie do tematu z poprzedniego wpisu.

Sytuacja w firmie

Klient rozwija 8 produktów (serwisów WWW) mając do dyspozycji 4 zespoły deweloeprskie. Przez większość czasu każdy z zespołów pracuje nad jednym wybranym przez klienta produktem. Zespoły w większości starają się używać Scruma i pracować w Sprintach o stałej długości starając się oddać co 2 tygodnie kolejną wersję produktu.

W ten sposób można rozwijać jednocześnie 4 produkty co jakiś czas „przełączając” jeden z zespołów na inny produkt. Pozostałe czekają w tym czasie na swoją kolej. Często jednak pojawiają się tzw. „wrzuty” na kilka dni w jednym z czekających produktów. Mimo, że nie są to duże prace, to są to nowe funkcjonalności, dlatego nie mogą być wykonane w dziale zajmującym się utrzymaniem usług i bieżącym usuwaniem usterek.

Od jakiegoś więc czasu jeden z zespołów deweloperskich nie pracuje w stałych Sprintach, a na bieżąco szacuje zgłaszane przez różnych Właścicieli Produków (Product Owner) „małe projekty” i wykonuje je w ustalanej przez klienta kolejności. Czasem są to „sprinty” na 3 dni, czasem na 7 itp., a zespół działa w modelu push zamiast pull, tj. dostosowuje czas do zakresu prac, a nie odwrotnie.

Klient nie chce się zgodzić na zaproponowany system pracy, zgodnie z którym zespół, jeśli już się przełącza na inny produkt, to powinien się przełączyć przynajmniej na cały jeden Sprint (np. 2 tygodnie), a Właściciel Produktu powinien mieć na tyle aktualny Rejestr Produktu (Product Backlog), żeby zespół miał co robić podczas tego Sprintu.

W rezultacie więc zespół jest non-stop odrywany od pracy, bo ciągle musi wyceniać nowe „projekty” w różnych produktach, koszt wynikający z częstego przełączania się między produktami rośnie (od 1 do 1,5 dnia z 3 zaplanowanych na pracę zajmują ustalenia z Właścicielami Produktów, szacowanie, merge kodu, przegrania na produkcję itp.), osoba od klienta pełniąca rolę Chief Product Ownera (czyt. pilnująca harmonogramu tego zespołu) marnuje godziny na negocjacje z Właścicielami Produktów oraz ustalanie, co i w jakiej kolejności będzie robione.

Klient postrzega całą sytuację jako jeszcze większą elastyczność niż daje Scrum. Nie widzi potrzeby delegowania całego zespołu na całe 2 tygodnie tylko dla jednego z produktów, kiedy przecież w kolejce czekają inne drobne zmiany w pozostałych produktach. Stałe długości Sprintów postrzega jako ograniczenie elastyczności zespołów.

Dlaczego to jest złe i niewydajne? Posłużmy się analogią z życia.

Tankowanie paliwa

Zawsze tankuję do pełna, bo dzięki temu marnuję swój czas na stacji paliw tylko dwa-trzy razy w miesiącu. Owszem, zatankowanie 55 litrów trwa dłużej niż 5 litrów, ale to nie w oczekiwaniu, aż się zaleje paliwo, traci się najwięcej czasu. Więcej czasu się traci na zjechanie do stacji, czekanie w kolejce, płacenie i inne czynności, przez które postój na stacji rzadko trwa krócej niż 10 minut.

Dziwią mnie osoby, które tankują 5 litrów albo „za 20 złotych”. Nie wyobrażam sobie tankowania co 2-3 dni. To całkowicie nieracjonalne.

Nie potrzebuję też większego baku ani nie wożę kanistrów z zapasem paliwa, bo zabrakłoby mi miejsca w bagażniku, a auto byłoby za ciężkie. Nie jeżdżę TIR-em.

Bieżące potrzeby biznesu

No dobra, ale co, jeśli ktoś akurat nie ma przy sobie wystarczającej ilości gotówki, ale musi akurat pojechać nieduży kawałek? Raz może zrobić wyjątek i zatankować tyle, ile można. Jeśli jednak tak dzieje się niemal codziennie, to… być może ciągły brak gotówki jest wynikiem marnotrawstwa czasu przez zbyt częste wizyty na stacjach.

Permalink | Leave a comment »

Dlaczego Sprinty powinny być stałe?

Mon, 26 Apr 2010 12:00:00 -0700

Wydłużenie Sprintu o 1-2 dni, kiedy zespół widzi, że się nie wyrobi ze wszystkimi pracami na koniec, to częsta pokusa dla zespołów rozpoczynających przygodę ze Scrumem.

Niektóre zespoły posuwają się o krok dalej: podczas Planowania Sprintu za każdym razem dopasowują czas jego trwania do zakresu prac, jaki zaplanował(!) już Właściciel Produktu (Product Owner).

Łamie to jedną z podstawowych reguł Scruma: to zespół określa, ile może wytworzyć podczas Sprintu i bierze na siebie tyle pracy, ile jest w stanie wykonać. Zakres prac powinien być dopasowany do „pojemności” (model pull), nie odwrotnie (push).

Mobilizuje to zespół do dostarczenia tego, do czego się zobowiązał, a Właściciela Produktu do bardziej przemyślanych decyzji podczas ustalania priorytetów dla elementów w Rejestrze Produktu (Product Backlog).

Dla zespołu powinno być punktem honoru dostarczenie na koniec Sprintu tego, do czego się zobowiązał podczas Planowania. Nie na dzień później. Bo tego dnia zwyczajnie może nie być.

Dla Właściciela Produktu takie ograniczenie to motywator do wybierania najbardziej wartościowych funkcjonalności. Bo kolejnego Sprintu może już nie być.

Przekłada się to na dokładniejsze planowanie i dostarczanie bardziej wartościowego produktu ze Sprintu na Sprint.

Inne pozytywne aspekty stałych Sprintów

Tak, jak Codzienne Scrumy (Daily Scrum) odbywają się codziennie o tej samej porze dnia, tak Planowanie Sprintu, Przegląd, Retrospektywa powinny odbywać się w równych odstępach czasu. Nadaje to zespołowi pewien rytm pracy, a wypracowana w ten sposób rutyna pozwala skupić się na pracy zamiast myśleć o terminach i innych kwestiach organizacyjnych.

Przekłada się to na wydajność zespołu. Dużo łatwiej jest też wtedy mierzyć prędkość zespołu (velocity), planować Sprinty, wydania i całe projekty.

Permalink | Leave a comment »