Co to są plany dostarczania?
W miarę rozwoju organizacji deweloperskich muszą one zreorganizować mniejsze zespoły, które mogą efektywnie zarządzać częściowymi jednostkami pracy. Te zespoły zwykle mają swoje harmonogramy pracy, tablice i inne procesy, które spełniają swoje unikatowe potrzeby w kontekście większych celów organizacji. Z biegiem czasu organizacje mogą stwierdzić, że korzystają z zalet sieci, konsolidując swoje procesy w spójnej strukturze.
Plan dostarczania to wizualizacja jednego lub większej liczby harmonogramów pracy. Ma to na celu zapewnienie zespołom i kierownictwu ogólnego wglądu w to, co każdy zespół planuje tworzyć i kiedy. Umożliwia podejmowanie decyzji, które optymalizują inwestycje w całej organizacji.
Zespoły muszą regularnie przeglądać plany dostarczania, aby upewnić się, że harmonogram pracy jest zgodny z harmonogramami innych zespołów. Te przeglądy powinny radzić sobie z pytaniami, takimi jak:
- Czy na pewno możemy dostarczyć to, co zobowiązaliśmy się do naszego bieżącego harmonogramu?
- Czy jesteśmy pewni, że zespoły, od których zależymy, zapewnią to, czego potrzebujemy zgodnie z ich bieżącym harmonogramem?
- Czy są uśpienie w naszym harmonogramie, że możemy wypełnić pracę?
- Czy występują problemy z zależnościami w zespole lub w różnych zespołach?
Plany dostarczania dodają wartość w dowolnym momencie cyklu życia projektu. Ponieważ są one generowane dynamicznie na podstawie list prac zespołu, są one zawsze aktualne i oferują najnowsze informacje.
Dołączmy do zespołu internetowego Tailspin w dyskusji.
Andy: Po prostu miałem świetne spotkanie z zarządzaniem inżynieryjnym. Pokazowałem pracę, którą robimy z usługą Azure Boards, i cieszy się perspektywą uzyskania innych zespołów na pokładzie.
Mara: Niesamowite! Kiedy się zaczną?
Andy: To najlepsza część. Oni już mają! Wczoraj wieczorem lider projektu aparatu gry stworzył zespół z pewnymi przebiegami i zaczął dodawać elementy robocze. Wziąłem szybki wygląd dziś rano, i to kształtuje się ładnie. Pozwólcie, że pokażemy Ci, do czego są.
Andy przechodzi do bieżącej tablicy sprintu aparatu gry. On i Mara przeglądają przedmioty robocze z dużym zainteresowaniem.
Andy: Hmm... Po prostu zauważyłem, że nie planuje wdrożyć ich beta do końca tego przebiegu. Czy nie spodziewamy się zintegrować naszą ranking z bazą danych beta podczas następnego przebiegu? Nie możemy tego zrobić, jeśli nie wysyłają wersji beta jako pierwszej.
Mara: To dobry punkt. Mamy zależność od tego zespołu, aby stworzyć ten element dostarczany, abyśmy mogli produkować jedną z naszych własnych.
Andy: To mogło naprawdę zaszkodzić naszej produktywności w następnym przebiegu. Dam im telefon, aby dowiedzieć się, co się dzieje.
Niestety, bardziej zaawansowane struktury zespołów mogą powodować przerwy lub opóźnienia w komunikacji. Gdy jeden zespół zostanie zablokowany, może nie być w stanie utworzyć czegoś innego zespołu. Może to nie być głównym problemem dla małej grupy zespołów, które mają codzienne spotkania dla wszystkich zainteresowanych. Jednak w miarę zwiększania rozmiaru i lokalizacji zespoły mogą stać się nie do utrzymania, aby wszyscy wiedzieli, co dzieje się wszędzie. W tym momencie organizacje muszą przejść z czystego modelu "wypychania" (na przykład anonsów osób lub wiadomości e-mail) do modelu "ściągania" (gdzie zespoły mogą przeglądać i śledzić harmonogramy nawzajem).
Andy: Dobrze, po prostu rozmawiałem z dev lead. Powiedziała mi, że ich zespół jest zablokowany do wysłania beta, dopóki zespół sztuki nie wróci z Cliffchella.
Mara: Festiwal muzyczny na szczycie górskim?
Andy: Tak, najwyraźniej, to ogromna sprawa w społeczności projektowej, a ich cały zespół po prostu spada z siatki przez cały tydzień, aby wziąć udział. Zespół silnika gry jest dość zdenerwowany, ponieważ spadł ich harmonogram o trzy tygodnie. Gdyby wiedzieli, że nadchodzi, upewniliby się, że uzyskaliby artefakty potrzebne przed upływem czasu. Przeprosili również za to, że nie poinformowali nas wcześniej. Nie zdawali sobie sprawy, że będziemy czekać na ich beta, aby wysłać naszą część.
Mara: Cóż, przynajmniej możemy się cieszyć, że zespół silnika gry publikuje swoje plany sprintu. Pomogło nam to znaleźć ten problem zależności wystarczająco wcześnie, aby dostosować nasz harmonogram.
Andy: Chciałbym tylko, aby był sposób, aby zobaczyć te potencjalne zagrożenia zbliża się łatwiej. Nasze zespoły mają tak wiele zależności w całej firmie, że nie ma możliwości udziału w każdym spotkaniu i zasubskrybowania każdej grupy dystrybucyjnej.
Mara: Powinniśmy utworzyć plan dostawy, abyśmy mogli zobaczyć nasze sprinty zespołu obok siebie. Pomoże to obu zespołom łatwiej zidentyfikować, jak nasze harmonogramy wpływają na siebie nawzajem.
Rekomendacje do zarządzania wieloma zespołami Agile
Podejście Agile wraz z usługą Azure DevOps może znacznie poprawić przejrzystość i przewidywalność projektu. Jednak projekty mogą nadal napotykać tradycyjne wyzwania, często związane z personelem lub błędną komunikacją. Poniżej przedstawiono kilka kwestii, które należy wziąć pod uwagę podczas skalowania wysiłków agile.
Budowanie zaufania do osób i procesów
Wczesne przeciwniki implementacji Agile są często sceptyczni co do ich zdolności do poprawy wydajności zespołu. Ważne jest, aby liderzy myśli w organizacji budować zaufanie, ilustrując, jak narzędzia i procesy generują wyniki. Czasami te wyniki są ulepszeniami wydajności, które można łatwo oszacować. Nie zapomnij jednak podkreślić zwycięstw zespołu, które występują przez obejście potencjalnych problemów, takich jak możliwe do uniknięcia poślizgi harmonogramu lub problemy z jakością. Gdy ludzie zaczynają kojarzyć korzyści z tego procesu, który je osiągnął, uzyskasz większy entuzjazm.
Podnoszenie poziomu organizacji powyżej zespołu (i osoby)
Niektóre zespoły i osoby otrzymują terytorialne, gdy proponowane są nowe procesy lub zasady. Zamiast określać nowe zasady jako negatywnie ujawniające wyniki określonych zespołów lub osób, należy podkreślić, w jaki sposób nowa przejrzystość w całej organizacji informuje wszystkich o oczekiwaniach. Posiadanie jednego miejsca, w którym każdy może śledzić, w jaki sposób ich praca odnosi się do organizacji, aby osiągnąć swoje cele, doprowadzi do znaczenia ich zaangażowania w proces.
Wspieranie kultury przejrzystości
Niestety, termin "przejrzystość" dostaje zły rap. Nikt nie prosi o większą przejrzystość, gdy wszystko idzie świetnie. Zamiast tego przejrzystość (lub ich brak) jest często obwiniana, gdy zespoły walczą. Nawet ze wszystkimi możliwościami przejrzystości zapewnianymi dla zespołów Agile, nadal podlega uczciwości osób i zespołów. Należy podkreślić, że jednym z powodów przejrzystości jest możliwość identyfikowania i rozwiązywania potencjalnych problemów, zanim będzie za późno. Każdy rozumie, że ludzie czasami wpadają w okoliczności, które uniemożliwiają im spełnianie terminów harmonogramu. Ale jeśli nie czują się bezpiecznie w zgłaszaniu rozczarowujących wiadomości do ostatniej możliwej chwili, może to mieć znacznie bardziej destrukcyjny wpływ. Budowanie poziomu komfortu z przejrzystością może zaczynać się od podziękowania osobom za raportowanie oczekiwanych opóźnień tak szybko, jak to możliwe.