Archiwum

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…)
 

Working Agreement Canvas

Według badań, które cytuje Scrum Inc, ponad 60% sukcesu zespołu jest tworzone, zanim zespół zacznie pracować. Jest to jasny sygnał, że dobre zespoły się nie zdarzają, ale są tworzone. Dlaczego o tym piszę? Ponieważ Team Working Agreement Canvas, który chcę Wam w tym wpisie przybliżyć, jest elementem uzgodnienia pewnych rzeczy jeszcze zanim zespół zacznie pracować.

Scrum Inc. stworzył template, którego poszczególne elementy w tym wpisie opiszę. Wpis ten jest on rozwinięciem wpisu Kuby dotyczącego wystartowania zespołu scrumowego.

(więcej…)
 

„Commitment” na „forecast” – co stoi za tą zmianą?

W 2011 roku Scrum Guide przeszedł cykliczną aktualizację. Jedną ze zmian było zastąpienie słowa commitment (pol. zobowiązanie) na słowo forecast (pol. prognoza). Od tego momentu zespół deweloperski prognozuje, które z zadań z Rejestru Produktu zostaną przez niego dostarczone na koniec iteracji. Była to jedna z najbardziej kontrowersyjnych zmian w Scrum Guide, dlatego też napisałem kilka zdań mojego rozumienia tych słów i co się z nimi wiąże.

(więcej…)

 

Błędy z zeszłych sprintów. Jak z nimi postępować?

Zespół scrumowy (zespół deweloperski) skończył pracę na przyrostem. Właściciel produktu odebrał go i przekazał do Klienta (interesariuszy). Klient wdrożył gotowe oprogramowanie (produkt). Po kilku sprintach, kiedy zespół robi już zupełnie inne rzeczy, Klient znajduje błędy w przekazanym oprogramowaniu. I zgłasza je do zespołu scrumowego. Sytuacja z życia wzięta, codzienna. Jak sobie z nią poradzić? Przygotowałem dla Was grafikę obrazującą jedną z możliwych ścieżek postępowania.

(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…)

 

3 metody pozwalające podzielić wymagania funkcjonalne na mniejsze

Zespoły miewają kłopoty w tym, by podzielić elementy Backlogu na kawałki mieszczące się w jednej iteracji. Jak to zrobić? W poniższym artykule opisałem trzy metody uszczegóławiania, doprecyzowywania i zmniejszania wymagań (w artykule będę używał słowa “cięcie”). Są one jednymi z popularniejszych na rynku.

(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