Archiwum

Dlaczego warto pracować iteracyjnie i przyrostowo?

Wielokrotnie na szkoleniach w trakcie dyskusji, gdy dochodzimy do wątku limitowania pracy w toku i jak najczęstszego wdrażania wartości biznesowej małymi partiami, kolejni uczestnicy odgrzewają dyskusję, że „nie opłaca się” robić małych wdrożeń i że bardziej ekonomiczne jest wdrażać produkt wielkimi wersjami w dużych odstępach czasu. Każdy kto dłużej popracował zwinnie w porządny sposób i każdy kto zna podstawowe teorie, które udowadniają sensowność częstych wdrożeń małymi partiami, wie, że rzekoma opłacalność rzadkich wdrożeń to złudzenie. Widzę jednak, że o wiele trudniej w takiej sytuacji wyjść z perspektywy własnych doświadczeń praktycznych i sformułować logiczny, spójny i przekonujący wywód, który może przekonać wspomnianego wcześniej nieprzekonanego dyskutanta. W tym artykule, bazując na książce Donalda G. Reinertsena „The Principles of Product Development Flow: Second Generation Lean Product Development”, wymienię 10 powodów, dla których warto dostarczać produkt małymi partiami.

(więcej…)
 

Co daje szacowanie relatywne zespołowi?

Jednym z celów estymacji (szacowania) zadań w Scrum jest pozyskanie przez Zespół Deweloperski informacji, jak wiele zadań mogą “włożyć” do Sprintu (iteracji), który trwa od 1 tygodnia do 1 miesiąca. Scrum różni się w związku z tym od tradycyjnych metodyk gdzie estymacja często jest robiona na początku trwania projektu i dotyczy całego jego przebiegu.

W tym wpisie, który jest kontynuacją moich poprzednich dotyczących estymowania (metody wyceny wymagań, jak wytłumaczyć szacowanie relatywne) chcę wam przybliżyć korzyści jak i wady estymowania relatywnego.

(więcej…)
 

„Iterate” – recenzja gry planszowej o rozwoju produktu

Od jakiegoś czasu przy okazji wydarzeń społecznościowych w Polsce (np. ostatniego Agile By Example) można było zauważyć, że rośnie rozgłos na temat “Iterate”, gry planszowej rozwijanej od kilku lat przez Tomka Włodarka (wraz z Kamilem Surmaczem i Kasią Gunią). Choć współpracowałem z Tomkiem, nie miałem bezpośredniej okazji do wzięcia udziału w kolejnych iteracjach wersji gry, choć widziałem zawartość pudełka, gdy nie miało ono żadnej profesjonalnej oprawy. Dostałem zaproszenie do dołączenia do otwartego warsztatu opartego o aktualną “produkcyjną” wersję Iterate i dzięki temu mogłem poznać zasady gry a tym artykułem podzielę się wrażeniami z wszystkimi czytelnikami.

(więcej…)
 

„Strategize” Romana Pichlera – strategia i roadmapa produktowa w pigułce

Roman Pichler przez wielu kojarzony jest z udaną książką „Agile Product Management with Scrum”, która idealnie pokrywa temat roli Product Ownera i w zwięzły sposób podpowiada jak realizować działania związane z Backlogiem Produktu, współpracą z zespołem i interesariuszami. Przynajmniej dla mnie ta książka jest lekturą obowiązkową, jedną z kilku, które automatycznie polecam, gdy ktoś mnie pyta jakie książki związane z agile należy przeczytać na początku swojej przygody z tym podejściem. W moje ręce wpadła ostatnio książka „Strategize. Product Strategy and Product Roadmap Practices for the Digital Age” tego samego autora i w podobnie kompletny, a jednocześnie zwięzły sposób Roman wyczerpuje temat strategii produktu, budowania jego roadmapy i całego aspektu pracy koncepcyjnej Właściciela Produktu. Czyli opisuje wszystko to, co się dzieje, zanim PO przyniesie swój pomysł na kolejny Refinement Backloga czy  Planowanie Sprintu.

(więcej…)

 

Jak wytłumaczyć zespołowi szacowanie relatywne? 3 propozycje ćwiczeń

Jednym z największych wyzwań w pracy Zespołu Deweloperskiego, ale też Product Ownera z interesariuszami jest określenie, kiedy dana funkcjonalność zostanie dostarczona. Jest wiele aspektów tego zagadnienia. Relacje, emocje, asertywność, szacowanie. I właśnie tą ostatnią kwestią chce się dzisiaj zająć. Jakie są metody relatywnego szacowania zadań, jak to wytłumaczyć zespołowi i dlaczego jest to lepsze podejście od klasycznego?

(więcej…)

 

Proxy Product Owner po stronie dostawcy? Plusy i minusy rozwiązania.

Zespoły Deweloperskie pracujące w software house’ach często doświadczają niełatwej współpracy ze zdalnym Product Ownerem, pracującym po stronie zagranicznego klienta. Problemy to najczęściej kiepska dostępność Product Ownera dla zespołu, brak kompetencji produktowych, fizyczna odległość od zespołu oraz bariery językowe. Rozwiązaniem może być wprowadzenie roli proxy Product Ownera po stronie dostawcy. Koncepcja ta — jak łatwo się domyślić — ma swoje plusy i minusy.

 

(więcej…)

 
Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X