Zamknięcia projektu w Scrum

W typowym środowisku programistycznym zamknięcia projektu oznaczają koniec projektu.

1. Dokumentacja projektu jest kompletna i archiwizowana,
2. uwolnione zasoby,
3. problemy i wnioski są udokumentowane, oraz
4. uroczysta kolacja / przyjęcie organizowane z okazji uroczystości.

Ostatni krok jest opcjonalny, ale jest bardzo motywujący dla uczestników. :-)

Porównaj to z Scrum. Wiem, że scrum działa na historie z zaległości . Tak więc technicznie każda iteracja zamyka pewne historie. Są tutaj dwa pytania.

1. Jak pasuje do grupy, która pracuje nad wieloma jednoczesnymi projektami ?
2. W jaki sposób ta koncepcja ma zastosowanie w przypadku projektu obejmującego wiele grup ?

Czy też termin zakończenia projektu w ogóle nie dotyczy projektów T&M ?

Jak pasuje do grupy, która pracuje nad wieloma jednoczesnymi projektami?

Po pierwsze, „wiele jednoczesnych projektów” jest uważane za naprawdę zły pomysł. Celem scrum jest sprint i gotowe. Zmiana projektów na rozpoczęcie kolejnego sprintu jest uciążliwa. Wykonanie dwóch projektów jednocześnie nie jest sprintem. To bałagan.

Jednak Scrum nie różni się niczym od metody nieagresywnej (wodospad). Kiedy zaległości zostaną zredukowane do około zera, nadal będziesz gotowy. Tak samo, jakbyś miał podejście do wodospadu zamiast podejścia zwinnego.

Czasami zaległości są niezerowe, ale klient jest zachwycony i nie chce już więcej. Więc jesteś tak samo gotowy. Zwykle wykonywane wcześniej i taniej niż wodospad (który musi zbudować wszystko, nawet pomysły, które okazały się bezużyteczne).

W jaki sposób ta koncepcja ma zastosowanie w przypadku projektu obejmującego wiele grup?

To samo, co projekt inny niż scrum z wieloma grupami. Nic się nie zmienia w ludziach. Nadal lubią dobrą imprezę.

Czy też termin zakończenia projektu w ogóle nie dotyczy projektów T&M?

Dlaczego fakturowanie miałoby cokolwiek zmieniać na temat charakteru pracy lub ceremonii na końcu?

Zazwyczaj widzę zwinne metody, takie jak praktyki scrum, w bardziej ustrukturyzowanych ramach zarządzania projektami. To wcale nie jest sprzeczność. Zwinny działa na rzecz dostarczania, jego celem jest szybsze dostarczanie odpowiedniego oprogramowania. Pomaga w interakcjach między programistami a interesariuszami. Może być używany jako część programu na określony czas lub do rozszerzeń otwartych.

Mając to na uwadze, nie ma powodu, dla którego reszta zarządzania projektami nie może być zarządzana w tradycyjny sposób, z PM zarządzającym osią czasu, kosztami i innymi zależnościami. Po zakończeniu masz jak zwykle wydarzenia zamknięcia.

Pracuję w finansach, czasem pojawiają się nowe przepisy lub pojawia się nowa giełda, a my mamy datę rozpoczęcia tego, co jest mocno osadzone. Nadal używamy metody Agile do dostarczania, ale w ramach bardziej tradycyjnych ram zarządzania projektami, dzięki czemu dostarczamy ją na czas.

Szacowanie jednostek pracy i wybór rozwiązania możliwego do osiągnięcia w dostępnych ramach czasowych czyni nas dobrymi programistami (jedną z rzeczy, które powinienem powiedzieć).

W Scrum, podobnie jak we wszystkich technikach zwinnych, projekty to drobne rzeczy, które przychodzą i odchodzą, a zespół pozostaje razem. Dlatego nie ma rytuału „clojure projektu” jako takiego. Raczej przy projekcie zanika, podczas gdy kolejne woskuje. Przepływ elementów zaległości stopniowo przesuwa się z jednego do drugiego. Zespół ledwo zna różnicę.

Rzeczywiście, zespół może jednocześnie pracować nad dwoma lub trzema różnymi projektami. Znowu ledwo znają różnicę. Elementy zaległości przychodzą do zespołu na początku każdego sprintu, a zespół je wdraża. Wszystkie mogą należeć do jednego projektu lub mogą być równo podzielone na kilka. Zespół nie dba o to. Zespół po prostu wdraża otrzymane elementy zaległości.

Jeśli firma musi zmienić priorytet projektów, wystarczy zmienić przepływ elementów zaległości do zespołów.

Niektóre z omawianych tutaj kwestii zostałyby pochłonięte przez większość sprawnych procesów, takie jak dokumentacja i wydania często występujące jako rzecz oczywista, zamiast oczekiwania na jakiś zewnętrzny wyzwalacz. Oczywiście nie zawsze tak będzie, w zależności od tego, jakiego rodzaju klientów posiadasz i jaki rodzaj działalności prowadzisz. Na przykład, jeśli tworzysz pojedynczą część większego systemu będącego własnością podmiotu zewnętrznego, zwykle jest jakaś data napędzająca proces, i ta data byłaby odpowiednim czasem na wykonanie dodatkowych czynności porządkowych i, oczywiście, imprezy. Innym razem, nawet gdy klient jest klientem wewnętrznym, firma może nadal uznać, że osiągnął kamień milowy / główny produkt / inny, który ponownie wymaga zakończenia księgowości / imprezy. Jeśli Twoja firma zaangażuje się w planowanie wersji, zapewni to naturalne punkty zwrotne, ale nawet jeśli tego nie zrobisz, idealnie jest mieć środki sukcesu oparte na biznesie. Oznacza to, że projekty mogą już nie być cechą Twojego procesu inżynieryjnego, ale z pewnością mogą być częścią Twojego biznesu, a celebrowanie / radzenie sobie z nimi może i powinno być częścią kultury Twojej firmy.