W jaki sposób zespół Scrumowy uwzględnia zadania związane z infrastrukturą podczas spotkania planistycznego?

W jaki sposób zespół Scrumowy uwzględnia zadania deweloperskie / infrastrukturalne podczas spotkania planistycznego?

Na pierwszy rzut oka nie wyglądają jak historie użytkowników, ponieważ nie zapewniają wartości końcowej.

Jednak dołączanie ich jako zadań do konkretnej historii użytkownika również nie ma sensu. Załóżmy na przykład, że zadaniem jest: „Setup Bamboo”. To zadanie nie jest wymagane do ukończenia historii użytkownika, ponieważ zespół mógł ręcznie zbudować i wdrożyć. Dlatego dołączenie go do historii użytkownika nie ma sensu, ponieważ to zadanie nie jest wymagane do ukończenia historii użytkownika.

To sugeruje, że zadania te stają się historiami użytkowników. Ale wtedy, jeśli historia zespołu ich wskazuje, to zmienia to prędkość, która jest dziwna, ponieważ Właściciel produktu chce poznać prędkość w oparciu o swoje zaległości, a nie o zaległości z dołączoną do nich historią technicznych użytkowników.

To nie są historie użytkowników. To historie interesariuszy. O ile oprogramowanie nie jest opłacane bezpośrednio przez użytkowników, rzadko jest tak, że historia jest tworzona całkowicie na ich korzyść.

Podam kilka przykładów:

• słowa kluczowe artykuły, które pozwalają reklamodawcom na bardziej skuteczne reklamy
• CAPTCHA, które mają powstrzymać moderatorów przed ręcznym radzeniem sobie ze spamem.

Większość historii technicznych faktycznie przynosi korzyści biznesowe, ale rzadko są to dla użytkowników. Sformułowanie ich w inny sposób może pomóc. Zwykle używam szablonu funkcji wstrzykiwania Chrisa Mattsa:

In order to <achieve my goal>
As <the stakeholder who wants the goal>
I want (<some users to do>) <some stuff>.

Wyraźnie uznaje to wszystkie rodzaje interesariuszy, w tym zespół programistów. Teraz możesz także opisywać swoje historie techniczne, wskazując korzyści biznesowe:

In order to minimize the risk of deploying something broken
As the team deploying the code
We want to spend a few days on an automated deployment system.

Napisałem na ten temat kilka postów na blogu: To nie są historie użytkowników , wprowadzanie funkcji i obsługa technicznych historii . Mam nadzieję, że pomogą.

Prędkość jest miarą zdolności zespołu do wykonywania pożytecznej pracy (w przeciwieństwie do Drag). Zadania związane z infrastrukturą nadal przynoszą użytkownikom końcowym wartość, choć pośrednio, zwiększając efektywność zespołu na dłuższą metę. Nie mam problemu ze śledzeniem tych rzeczy jako historii użytkowników (w tym przypadku użytkownik jest zespołem programistów) i nadawaniem im odpowiednich priorytetów. Właściciel produktu w dobrej komunikacji z klientem (klientami) powinien być w stanie dowiedzieć się, gdzie takie zadania mogą się zmieścić bez zakłócania wyników.

Rób je stopniowo.

Jeśli żaden interesariusz tego nie chce, nie rób z tego historii. Zajmij się tym, po trochu. Na przykład przy pierwszym wdrażaniu ręcznym. Za drugim razem trochę zautomatyzujesz. Za trzecim razem zautomatyzujesz trochę więcej. Ostatecznie twoja kompilacja nie jest największym problemem, więc skupiasz się na czymś innym.

Na początku będziesz mieć więcej zadań zorientowanych na programistów, i to w porządku; twoja prędkość (mierzona historiami) będzie po prostu niższa. To poprawna reprezentacja sytuacji. Ale zawsze będziesz miał ich trochę, dlatego ważne jest, aby zespół przyzwyczaił się robić to, co konieczne, aby usprawnić proces.

IMHO idealnym podejściem jest umieszczenie wysiłków związanych z infrastrukturą jako zadań pod historią użytkownika, w której po raz pierwszy ma wartość; jak wspomniałeś.

Biorąc twój przykład; ręczne budowanie i wdrażanie oznacza, że ​​jest to ciągły wysiłek i nie ma formy ukończenia. Istnieje na czas nieokreślony.

To samo można powiedzieć o kodzie, który automatyzuje każdą część wysiłku w typowej aplikacji, która wcześniej była wykonywana ręcznie. Zdefiniowanie tego wysiłku jako zadania w historii użytkownika definiuje zakończenie; który ze swej natury ma wartość dla użytkownika końcowego.

Z pewnością możesz zbudować i wdrożyć aplikację przy każdym sprincie, ale to staje się częścią codziennych zadań, które nie są formalnie śledzone przez zaległości, a potem wszystko staje się dyskusyjne.

Historie użytkowników definiują wartość biznesową z perspektywy użytkownika. Z tego powodu zadania infrastrukturalne są ogólnie uważane za „odpady”. To nie znaczy, że nie są potrzebne. Oznacza to, że wykonywanie większej liczby zadań infrastrukturalnych przyniesie mniejszą wartość biznesową. Z tego powodu zadania związane z infrastrukturą nie powinny być traktowane jako historia użytkownika i nie powinny być dołączane do historii użytkowników.

Na spotkaniu planistycznym zespół musi rozważyć, jakie zadania związane z infrasturcją będą absolutnie niezbędne podczas następnego sprintu. Zobowiązanie zostanie wykonane z myślą o tych zadaniach związanych z infrastrukturą. Wpłynie to na szybkość zespołu, co jest poprawnym wynikiem, ponieważ prędkość mierzy, ile wartości biznesowej może dostarczyć zespół.

Nigdy nie utożsamiałem historii użytkowników z koniecznością dostarczania wartości końcowej. Może to być powszechne, ale nie tak traktujemy historie użytkowników. Czasami tego rodzaju zadania są uważane za szczytowe, ale mieliśmy również regularne historie użytkowników, których punkt szacuje się jak każdą inną historię użytkownika.

Z tego, co widziałem, znaczna część infrastruktury jest uważana za pewnik. Obejmuje to między innymi:

• System kontroli wersji;
• Zautomatyzowany system kompilacji;
• IDE i inne narzędzia programistyczne;
• Serwery programistyczne;
• Proces wdrażania; i
• Proces projektu i standardy.

Większość metodologii, z którymi pracowałem, nie przywiązuje do nich dużej uwagi. Tworzą one to, co nazywam wersją 0. Te rzeczy powinny być na miejscu, zanim zaczniesz programować. Po rozpoczęciu pracy nad historiami wszelkie zmiany tych rzeczy mogą być śledzone jako usprawnienia procesu.

Chociaż zespół programistów może mieć wkład, większość tych elementów powinna być obsługiwana przez zespół wsparcia projektu. Standaryzacja tych pozycji w wielu projektach powinna przynieść organizacji znaczny zwrot.

Rozważ następujące:

• Zespół Scrumowy dodaje główne funkcje do istniejącego pakietu produktów.

• Istnieje potrzeba aktualizacji technologii / narzędzi / narzędzi programistycznych, aby pozostać na bieżąco w oparciu o najlepsze praktyki inżynierskie.

• Sensowne jest załadowanie wersji wstępnej z tą pracą, aby w trakcie wydania można było rozwiązać problemy z Sprintami.

• Ponieważ firma uzyskuje pośrednią wartość z tych pozycji, sugeruję, że w celu zachowania przejrzystości są to pozycje Backlogu Produktu (PBI).

• Zespół dokonuje oceny tych elementów i traktuje je tak, jak w przypadku dowolnego PBI.

Ta kwestia sprowadza się do tego, że nie chcę tracić czasu na próbę ukrycia tej pracy jako zadań pod innymi PBI zorientowanymi bardziej na biznes.

Nie chcę, aby rozmiar PBI był wypaczony przez tego rodzaju prace infrastrukturalne. Chcę zobaczyć, co się dzieje i zrozumieć, za co płacę.

Uważam również, że warto mieć świadomość, że zespół rozumie zaangażowanie, jakie podejmuje firma, inwestując w infrastrukturę wymaganą do dostarczania wysokiej jakości rozwiązań.

XP zaleca sugerowanie posiadania „zerowej iteracji”, w której skonfigurowane są wszystkie narzędzia i infrastruktura. Pisanie opowiadań jest opcjonalne, ale prawdopodobnie jest dobrym pomysłem. Możliwość przetestowania infrastruktury (przyrostowa kompilacja, automatyczne testowanie i wdrażanie, powiadomienia itp.) Jest korzystna

W naszym zespole wykonujemy następujące czynności:

1. Załóż niższy współczynnik ostrości .
2. Spróbuj uwzględnić takie zadania w historiach użytkowników, które faktycznie wymagają ich wdrożenia.
3. Jeśli niektóre zadania są całkowicie konieczne, ale nie zapewniają bezpośredniej wartości biznesowej (np. Migracja testów jednostkowych z jednej platformy do drugiej), na początku sprintu tworzymy listę „zadań ciągłych” . Są to zadania związane z programowaniem, które nie są opowieściami, ale zespół programistów chce je wykonać. Wymieniamy te zadania na naszej tablicy, wciąż oddzielając je od historii. Podczas sprintu na każdym codziennym spotkaniu sprawdzamy, co zostało zrobione, aby je osiągnąć.

Najważniejszy jest krok 2. Podobnie jak w zwinnej praktyce, w Scrumie starasz się robić jak najmniej, aby wykonać swoje zadania. Weź to jako sposób, aby nie marnować życia na niepotrzebną pracę: z mojego doświadczenia wynika, że ​​aż 50% „niedoszłych” rzeczy ostatecznie zostaje porzuconych i nieobsługiwanych na dłuższą metę.