Planowanie długoterminowe i zwinne?

Mój zespół niedawno przeszedł proces opracowywania prawie rocznego planu naszej pracy. Podzieliliśmy plan na trzy fazy. Każda faza będzie obejmować kilka uruchomień.

Zastanawiam się, czy z twojego punktu widzenia jest to źle? Myślę, że to nie jest zły pomysł, ponieważ nie poświęciliśmy zbyt wiele czasu na projektowanie niczego poza kilkoma pierwszymi krokami. Możemy zmienić kierunek. Jednocześnie to miłe, że nie działamy z najbliższym terminem.

Wizja tego, dokąd ma zmierzać projekt, to Dobra Rzecz ^TM .

Wiara, że ​​właśnie tak się stanie, nie jest.

„Przygotowując się do bitwy, zawsze uważałem, że plany są bezużyteczne, ale planowanie jest niezbędne.”

- Dwight D. Eisenhower

Podejście przyjęte przez metodykę Agile polega na rozbiciu rzeczy na strawne kawałki i ponownym dostosowaniu wizji po strawieniu każdego kawałka.

Oznacza to, że twój punkt końcowy za rok nie będzie dokładnie taki, jak myślisz teraz. Powinieneś jednak zająć się wszystkimi pozycjami o wysokiej wartości na liście i dbać o zaangażowanie i zadowolenie interesariuszy w miarę postępów.

OK, zarządowi przedstawiono mit do zaplanowania. Mam nadzieję, ze względu na was, że nie trzymają was tego. Ponieważ, niewidoczny wzrok, jestem gotów postawić pieniądze, że twój zespół nie osiągnie niczego takiego, jak mówi ten długoterminowy plan. W rzeczywistości, jeśli osiągniesz średnią branżową, stracisz około 2 razy. W większości organizacji, po oszacowaniu, staje się klubem, w którym mogą cię pokonać tyle, ile chcą.

Prawdopodobnie myślisz, że jestem po prostu cyniczny. Przecież właśnie przekazałeś niejasne czasy dla nieokreślonych zestawów funkcji, o których wszyscy wiedzą, że mogą się zdarzyć znacznie wolniej lub szybciej niż przewidywano, prawda? Niestety, większość z nich może być prawdą, ale ludzie nie słyszą tych liczb. Słyszeli daty, a data, którą kiedyś się wypowiedziała, była bardziej solidna niż mówiłeś. Ponadto, jeśli istnieje łańcuch komunikacji, stanie się jeszcze bardziej solidny. A gdy klientom zewnętrznym obiecano coś ze sprzedaży opartej na tym, co powiedziałeś, nagle przekonasz się, że liczba ta jest znacznie mniejsza niż powinna. Gwarantuję, że nie doceniłeś czasu, jaki zajmie.

Po tym oczywistym punkcie zalecam, abyś przeczytał Oszacowanie oprogramowania, aby dowiedzieć się czegoś o tym, jak naprawdę należy dokonać oszacowania oprogramowania . Dowiesz się dużo o tym, co zrobiłeś źle i jak lepiej zrobić to następnym razem. (Podczas tego procesu dowiesz się, dlaczego jestem tak pewien, że przeceniłeś to, co zrobisz.)

To powiedziawszy, zwinność polega w dużej mierze na ograniczeniu procesu do tego, co jest odpowiednie dla małego zespołu. Często dobrym sposobem na ograniczenie procesu jest próba ograniczenia długoterminowego planowania na dużą skalę na rzecz planowania mniejszych rzeczy w krótkim okresie. Jest to również bardziej uczciwe - ponieważ nie wiesz, co się stanie w przyszłości. Jednak często nie jest to zgodne z większymi potrzebami biznesowymi, dlatego bez względu na to, czy deklarujesz się jako zwinny, czasem musisz planować dłuższe plany.

Powiedziawszy to, zdecydowanie doradzam, abyś odkrył kluczowy fakt na temat terminów, które przekazałeś, które niestety prawdopodobnie powrócą jako ostateczne terminy, by cię ugryźć. I faktem jest to. O co dbają ludzie, data lub zestaw funkcji? Mam na myśli to. Często organizacje mają określone daty, które mają znaczenie. Na przykład załatw coś na konferencję lub przed wakacyjną porą. W takim przypadku ważne jest, aby coś uwolnić, a nie tyle, czy to coś jest kompletne. Innym razem istnieje zestaw funkcji, które naprawdę muszą zostać wydane razem, a kompletność ma większe znaczenie niż to, kiedy to się dzieje. Jeśli możesz odkryć, w jakiej jesteś sytuacji, twój zespół będzie w znacznie lepszej pozycji, aby zaplanować, jak poradzić sobie z (prawie) nieuniknionymi chrupnięciami, które nadchodzą.

Dobrze jest mieć plan, o ile uważasz, że jest w toku, a nie coś napisanego w kamieniu.

Kluczem tutaj jest regularne wydawanie wersji (co najmniej raz w miesiącu), zbieranie prawdziwych opinii od użytkowników i aktualizacja planu na podstawie tych informacji.

Oznacza to, że Twój plan zmieni się, gdy zmieni się zakres projektu. To dobra rzecz , ponieważ oznacza, że ​​użytkownicy dowiedzieli się więcej o tym, czego chcą.

Zakładając, że przez project-managementi agilechodziło Scrum, to nie byłaby dokładna droga.

Z Scrumperspektywy czasu, jeśli masz plan roczny, powinieneś mieć co najmniej tyle Sprintu, ile jest miesięcy w roku. Dlatego twój roczny plan staje się bardziej zwinny, ponieważ można go zmieniać między dwoma Sprintami.

A nie Sprintmoże być dłuższy niż miesiąc, w którym Teamzobowiązuje się do przywrócenia Sprint Backlog Itemsstatusu Done.

Donejest tu ważnym słowem, a każda z nich Scrum Teammusi mieć jedną definicję „zrobione”, tzn. tam, gdzie nie ma już pracy do wykonania. Kiedy a Sprint Backlog Itemjest zrobione , oznacza to, że napisano analizę, architekturę i dokumentację techniczną oraz że funkcja została dokładnie przetestowana (testy jednostkowe, testy integracyjne, testy funkcjonalne ...).

Gdy elementy Product Backlogzostaną wprowadzone, a Przedmioty będą traktowane priorytetowo z mniej ważnymi funkcjami na dole i najważniejszymi na górze, Zespół (programistów) określa, jak długo powinien Product Backlog Itemtrwać rozwój każdego z nich na podstawie własnego doświadczenia. W tym miejscu możesz ustalić, że projekt będzie wymagał pełnego roku pracy. Weź pod uwagę, że tylkoProduct Ownerpowinien nadać priorytet Przedmiotom, ponieważ to on jest odpowiedzialny za zwrot z inwestycji, w przeciwnym razie wie, co jest najważniejsze dla użytkownika końcowego. Ponadto zespół oceni czas wymagany do pełnego opracowania funkcji, chociaż tu i tam mogą znajdować się fragmenty kodu, które mogą odpowiadać potrzebom tej funkcji, to znaczy, aby uniknąć dalszej złożoności i upewnić się, że przedmiot nie powinien przyjąć dłużej niż to, co według Zespołu będzie wymagać. Backlog produktu nie musi być idealny! Na tym etapie procesu wystarczy proste wyliczenie historii użytkowników, które możemy myśleć o systemie do opracowania.

W Sprint Planning Meetingtym czasie zespół zobowiązuje się do opracowania tego, co zostanie opracowane na następne Sprint, a tym samym do stworzenia Sprint Backlog. Sprint BacklogSkłada się z podzbioru opartego na Product Backlog Items, że Teamzobowiązuje się do zrobienia na koniec Sprintu. Biorąc na przykład na przykład Backlog 50 produktów, a wszystkie 50 50 artykułów wymaga roku, zespół może chcieć wybrać, powiedzmy, 5 pozycji z Backlogu Produktu i utworzyć Backlog Sprint z tymi 5 Przedmiotami. Te same 5 przedmiotów można w razie potrzeby rozszerzyć / rozbić na wiele innych przedmiotów, przez co zespół może zmienić zdanie po zmianie i zobowiązać się do wykonania tylko 4 przedmiotów z 5 wcześniej wybranych przedmiotów z rejestru produktów.

Po zakończeniu Spotkania Planowania Sprintu, które może trwać nie dłużej niż 8 godzin przez cały miesiąc Sprint, w którym Zespół nie tylko zobowiązuje się wykonać pracę nad wybranymi Przedmiotami, ale planuje, w jaki sposób wykona zadanie aby każdy w zespole wiedział dokładnie, co musi zrobić, Sprintrozpocznie się. Dla zespołu ważne jest, aby zespół był funkcjonalny.

To powiedziawszy, pod koniec każdego Sprintu, który w obecnej sytuacji trwa miesiąc, wszystkie Przedmioty, do których wykonania Teamzobowiązał się, będą dostarczane w pełni funkcjonalnymi funkcjami, ukierunkowanymi na Przedmioty wybrane z Rejestru Produktu. Musi być dostarczalny, ale nie jest obowiązkowy, aby został dostarczony, jeśli nie ma sensu robić tego zgodnie z Product Owner.

To w miejscu, w Sprint Review Meetingktórym Product Ownernależy wezwać, Teamdemonstruje się, co zostało zrobione podczas Sprintu, i gdzie trzeba powiedzieć, dlaczego nie wykonał, jeśli ma to zastosowanie, całej pracy, do której się zobowiązał. Cofnięta praca jest następnie umieszczana z powrotem Product Backlogi dostępna dla następnej Sprint. Upewnij się, że te cofnięte elementy zostaną uwzględnione w następnym Sprincie, chyba że Właściciel Produktu poinformuje inaczej, na wypadek gdyby cel się zmienił. Ale co najważniejsze, chociaż cel systemu zmienił się podczas Sprintu, nie przerywaj go, chyba że jest to absolutnie konieczne. Tylko właściciel produktu ma prawo przerwać sprint.

Po zakończeniu Sprint Review Meeting, który powinien trwać nie dłużej niż 4 godziny miesięcznego sprintu (o ile dobrze pamiętam), nadszedł czas, aby przejść do Sprint Retrospective Meeting. Jest Sprint Retrospectiveto konieczne, Teamaby wystąpiło, aby mógł omówić, w obecności Scrum Master i Właściciela produktu (opcjonalnie), co poszło nie tak, w jaki sposób Zespół Scrumowy może poprawić jego wydajność itp. I odpowiednio wprowadzić poprawki.

Po upływie terminu dla Sprint Retrospectivenowego Sprint Planning Meeting, nastąpi nowy , aby zaplanować następny Sprinti utworzyć nowy Sprint Backlog.

Pamiętaj, że Teamodpowiedzialny jest za utrzymanie Daily Scrumtrwającego 15 minut spotkania stand-up, podczas którego każdy członek zespołu odpowiada na trzy pytania (nie w tej kolejności):

1. Co zrobiłeś od ostatniego Daily Scrum?
2. Co planujesz robić do następnego Daily Scrum?
3. Jakie problemy lub przeszkody napotkałeś od ostatniego Daily Scrum?

Nie Scrum Masterma obowiązku bycia tam, ale ma obowiązek zapewnić, że zespół spotyka się na Daily Scrum i że członkowie prawidłowo odpowiedzą na trzy pytania.

Scrum Master jest odpowiedzialny za przestrzeganie zasad Scrum przez innych członków Zespołu Scrum (Scrum Master, Właściciel produktu i Zespół).

W końcu, zgodnie z tymi prostymi zasadami, Twój zespół programistów stanie się zwinny. Zwinność to zdolność do nadążenia za każdą zmianą tak szybko, jak to tylko możliwe, na końcu każdego sprintu, gdzie może się dowiedzieć o zmianach wprowadzonych przez właściciela produktu do rejestru produktu. W przypadku całkowitej katastrofy i całkowitej zmiany orientacji maksymalna strata, którą firma musi pochłonąć, to miesiąc rozwoju, co jest dość zaniedbywalne, biorąc pod uwagę, że w miesiącu jest tylko 20 dni roboczych.

Jeśli potrzebujesz dodatkowych szczegółowych informacji na temat Scrum i Agile Software Development, odwiedź Scrum.org i ich Przewodnik Scrum .

Cóż, to całkiem odpowiednia odpowiedź! Mam nadzieję, że przynajmniej pomoże ci to w zarządzaniu projektami.

EDYCJA 1

Podczas gdy planujesz zrobić trzy lub cztery fazy, jak to nazywasz, bardziej prawdopodobne jest, że Twój Zespół straci koncentrację z głównego celu. Jeśli po pierwszym kwartale zademonstrujesz, co zrobił Twój zespół, być może przydadzą się pewne ważne zmiany, które będą wymagały istotnego przeprojektowania i przemyślenia architektury oprogramowania, wznawiając go może z powodu ponad 20 dni straconej pracy. Zasada zwinności polega na tym, aby móc nadążyć za zmianami, gdy tylko się pojawią, lub tak szybko, jak to możliwe, w rozsądnym czasie, tj. Dla Scruma - ramą czasową sprintu.

1. Myślę, że powinieneś mieć jak najwięcej uruchomień. Jedyną rzeczywistą informacją zwrotną / wskaźnikiem postępu w rozwoju oprogramowania jest kod wdrożony w środowisku produkcyjnym. Niezależnie od tego, jakiego procesu używasz, im częściej wdrażasz na żywo, tym bardziej zwinny. To znaczy, wcześniej otrzymujesz prawdziwe opinie od prawdziwych użytkowników i możesz je wcześniej dostosować.

2. Chociaż nie powinieneś robić Big Design Up Front , myślę, że dobrze jest myśleć o dużym obrazie za każdym razem, gdy masz zamiar dostosować i uzupełnić zaległości, zarówno dla Scruma (na następny sprint), jak i Kanban / flow (gdy jest miejsce) w limicie WIP). Jeśli weźmiesz pod uwagę całość (produkt, usługę itp.), Łatwiej jest zastanowić się, które elementy pracy przyniosą Ci większą wartość w następnej kolejności.

3. Pamiętaj, że duży obraz się zmienia. Tak często, jak bierzesz pod uwagę zaległości, dostosowując priorytety itp., Rozważ także zmiany w ogólnym obrazie. Rzeczy zmieniają się w czasie, w tym potrzeby konkretnych klientów, a nawet całych rynków. Twój duży obraz powinien to odzwierciedlać, aby Twoje priorytety mogły być dostosowane do rzeczywistości za każdym razem, gdy uzupełniasz zaległości, a nie tylko na początku, kiedy tworzysz plan.

Podsumowując, myślę, że im bardziej zwinnie, tym więcej inspekcji i adaptacji.

Planowanie dużych zdjęć nie trwa tak długo, a duże projekty muszą mieć na uwadze duży obraz podczas definiowania sprintu, w przeciwnym razie skróty wykonane podczas sprintu mogą powodować problemy później.

Powinieneś:

1. Przygotuj plan główny (najlepiej bez załączonych terminów), który będzie ewoluował w miarę upływu czasu.

2. Podczas definiowania sprintu upewnij się, że jest on zgodny z dużym obrazem. Nie zawsze oznacza to, że zmienisz swoje wyobrażenie o tym, co jest potrzebne do sprintu. Czasami podczas definiowania sprintu odkryjesz, że duży obraz powinien zostać dostosowany. Tak czy inaczej duży plan zdjęciowy i sprint powinny być spójne ze sobą podczas sprintu.

3. Plan główny należy dostosowywać w miarę upływu czasu. Nauczysz się różnych rzeczy podczas pracy. Pojawią się nowe możliwości, pojawią się punkty konfliktu w planie. Możesz dostosowywać plan główny w trakcie pracy. Ale prawie zawsze powinieneś przeglądać go między sprintami - aby uwzględnić lekcje z ostatniego sprintu i upewnić się, że następny sprint jest w harmonii z dużym obrazem.

Myślę, że najlepiej, jeśli zaległości i plan dużego projektu to osobne struktury. Właściciel dużego projektu utrzymuje plan główny w hierarchicznym formacie konspektu w celu zachowania kontekstu, a następnie można pobrać z niego funkcje / zadania, aby zasilić zaległości, które z kolei zasilą kolejny sprint.

Zaległości, w przeciwieństwie do planu głównego, mogą być dodawane przez innych członków zespołu. Główny właściciel projektu musi upewnić się, że elementy zaległości i plan dużego obrazu pozostają w harmonii - czasem dostosowując element zaległości, a czasem plan dużego obrazu.

Ta metoda utrzymuje siłę zwinności i siłę wyrównywania wszystkich elementów projektu najlepiej, jak potrafisz w danym momencie, dzięki planowaniu dużego obrazu.

Jim

Dodam tutaj krótką formę mojego anty-zwinnego rantu.

Zwinność może być bardzo destrukcyjna w przypadku dużych projektów, szczególnie przy tworzeniu bibliotek i ram, które będą fundamentem przyszłego rozwoju. Naprawdę ważną kwestią na wczesnych etapach jest „czy mój projekt będzie obsługiwał funkcje, które będziemy musieli dostarczyć w ciągu następnego roku?”. Większość strategii Agile nie pozwala na tego rodzaju myślenie naprzód, dlatego tworzone są punkty niepowodzenia projektu.

Jestem trochę obolały w tej kwestii, ponieważ sam byłem po prostu spalony. Przepisujemy niektóre z naszych podstawowych bibliotek. Pierwsze fazy zostały ukończone i spełniły cele fabularne w ich sprintach. Wszystko jest bardzo zwinne. Następnie zostałem wprowadzony na pokład, aby dodać funkcje dynamicznego ładowania. Jednak utknąłem na około sześć tygodni, ponieważ to, co napisano wcześniej, zakładało, że nigdy nie nastąpi dynamiczne ładowanie, zmarnowałem dużo czasu na przepisywanie i omawianie tego, co już było. Najgorsze jest to, że dynamiczne ładowanie było na początku w specyfikacji; mając na uwadze, że początkowa praca miała na uwadze wszystkie przyszłe wymagania i wykonała „duże prace projektowe z góry”, które zwinne praktyki uważają za złe, mogłem wdrożyć moją funkcję w ciągu kilku dni.

Lekcja polega na tym, że używaj zwinności do drobnych rzeczy, które chcesz wyrzucić. Czasami może być świetnie. Nie jest to jednak jedyny sposób na rozwój oprogramowania. Pisząc podstawowy kod, który wiąże się z wysokim ryzykiem lub będzie miał długi okres użytkowania, zrób duży projekt.