Jak przedstawić zwinny projekt osobom skupionym na wodospadzie [zamknięte]

Nasz zespół został poproszony o przedstawienie naszych wysiłków rozwojowych w planie projektu. Nikt nie jest niezadowolony z naszej pracy ani kwestionowania naszych możliwości dostarczania, po prostu bierzemy udział w zaproszeniu do składania projektów dotyczących bydła IT. Problem w tym, że jesteśmy zwinnym zespołem i nie myśleliśmy o naszej pracy w kategoriach formalnego planu projektu.

Chociaż mamy ogólne pojęcie o tym, nad czym pracujemy, nie jesteśmy w 100% pewni, dopóki nie zaplanujemy iteracji. Do tej pory nasz zespół działał w dużej mierze w próżni i nie było wymagane przedstawianie naszej metodologii ani wskaźników podmiotom zewnętrznym. Przestrzegamy większości praktyk zalecanych w programowaniu ekstremalnym .

Odbywamy kwartalne spotkania poświęcone planowaniu, aby poznać ogólne historie, nad którymi będziemy pracować przez kwartał. To powiedziawszy, nasze historie są udokumentowane na kartach 3 x 5 i są szacowane tylko na początku iteracji, w której będą opracowywane. Po oszacowaniu dokumentujemy historię w Team Foundation Sever . Podczas iteracji dołączamy kod do historii i oznaczamy historie jako ukończone po zakończeniu. Na podstawie tych danych jesteśmy w stanie wygenerować wykresy spalania i prędkości. Co najważniejsze, znamy naszą średnią prędkość dla iteracji, która powstrzymuje nas przed odgryzaniem więcej, niż możemy przeżuć.

Nie zamierzam modyfikować sposobu, w jaki pracujemy nad rozwojem, ale chcę przedstawić nasze działania rozwojowe w raporcie, który zrozumie tylko ktoś zaznajomiony z wodospadem. W tym , jak wygląda plan projektu zwinnego , Kent McDonald wykonuje dobrą robotę, przedstawiając różnice między planami projektów zwinnych i wodospadowych. Określa różnice w pociskach eksploatacyjnych:

• Zwinny plan projektu oparty jest na funkcjach
• Zwinny plan projektu jest podzielony na iteracje
• Zwinny plan projektu ma różne poziomy szczegółowości w zależności od ram czasowych
• Agile Project Plan jest własnością zespołu

Możliwość wyjaśnienia różnic jest świetna, ale jak najlepiej przedstawić dane?

Pokaż im w połowie zwinny manifest zwinny .

To zdecydowanie mówi ci, na czym polega system Agile , porównując go z metodami kaskadowymi :

Osoby i interakcje między procesami i narzędziami,
a my mamy obowiązkowe procesy i narzędzia do kontrolowania interakcji tych osób (preferujemy termin „zasoby”)

Oprogramowanie działające na obszernej dokumentacji,
o ile oprogramowanie to jest kompleksowo udokumentowane

Współpraca z klientami w zakresie negocjacji umów
w ramach ścisłych umów, oczywiście, i podlega rygorystycznej kontroli zmian

Reagowanie na zmianę w następstwie planu,
pod warunkiem, że istnieje szczegółowy plan reagowania na zmianę i jest on ściśle przestrzegany

Raz musiałem to zrobić. Zespół chciał zrobić Agile, klient chciał (i zrozumiał Agile), zewnętrzną stronę trzecią (nazywają ich „audytorami”), chciał zobaczyć raporty Waterfall.

Ważnym powodem, dla którego mogliśmy kłamać, było to, że trzecia strona tak naprawdę nie dbała, chcieli tylko zaznaczyć pola. Gdyby Klient był zadowolony, a Zespół był zadowolony, „Audytorzy” nie cofnęliby się i nie sprawdzili raportów, które im przekazaliśmy, zanim sprawdzili ostatnie pola.

Nie rób tego, jeśli trzecia strona ma znaczenie, a faktycznie obchodzi Cię, że używasz wodospadu . Jeśli audytorzy wiedzą, że jesteś zwinny, i po prostu nie zaktualizowali swoich dokumentów, aby cię wspierać - możesz kłamać.

Co robisz? Kłamstwo , ale białe kłamstwo.

• Przeformułuj funkcje, jako wymaganie „Must have Feature”.
• Twoja praca jest w iteracjach, iteracje trwają zwykle ponad X tygodni, plan wodospadu lubi widzieć rzeczy ogólnie w tygodniach, więc nie ma wielkiego problemu. Możesz oznaczyć koniec każdej iteracji jako kamień milowy. Kamienie milowe to wodospad. Iteracje mają zwykle motyw (lub powiązany epos), dzięki czemu możesz nakleić motyw / epicki tytuł na kamieniu milowym (np. 21/11 mieć ukończone GUI).
• Oblicz swoją prędkość (na podstawie wykresów spalania / w górę) i oblicz, ile czasu średnio przedstawia Punkt Story (przynajmniej przy obecnej prędkości), to da ci czas trwania zadania. Często lubią te niedokładne, ale do pewnego stopnia będą miały znaczenie.
• Twój plan ma inny poziom szczegółowości w zależności od ram czasowych - w zasadzie taki sam dla wodospadu. Możliwa różnica w planie wodospadu ma różne szczegóły w zależności od odbiorców.

• Zespół Agile jest właścicielem planu zwinnego. Plan wodospadu jest własnością kierownika projektu. Prawdopodobnie masz już Project Managera i prawdopodobnie wykonują to tłumaczenie . Powinni przejąć na własność ten przetłumaczony dokument i ochronić drużynę przed atakiem, który z tego powodu może na nich spaść. Zadaniem kierownika projektu Agile lub Waterfall jest ochrona zespołu przed zakłóceniami, które uniemożliwiają mu pracę.

• Pewnie, że tak naprawdę nie wiesz, co robisz podczas następnej iteracji, ale z grubsza wiesz, co robisz. Masz na to wyczucie, a po Iteracji jeszcze trudniejsze. (Słyszałem, że to się nazywa Radar Iteracyjny). Kłam i powiedz, że tak. a kiedy kłamiesz w zębach o karcie opowieści, której nie ma na twoim radar iteracji, i po prostu ją gdzieś umieścisz. Mam nadzieję, że nie musisz przesyłać zbyt wielu aktualizacji planu projektu, albo zauważą, że nie zrobiłeś tego, co powiedziałeś.

Zasadniczo jest to ból. Tłumaczenie zajmie wiele godzin pracy. Jeśli musisz to zrobić dużo, zautomatyzuj to.

Pierwszym pytaniem, jakie należy zadać, jest to, czego tak naprawdę chce firma? Niektóre firmy są całkowicie zadowolone, widząc zwinne sprinty przedstawione / podzielone na wykres Gantta. Może to nie mieć sensu dla nikogo, kto faktycznie rozumie sprinty i może zmieniać się regularnie, ale jest znany osobom, które o to proszą. Następnie wraz z wykresem Gantta zaprezentuj wypalenie itp.

Przeszliśmy przez coś podobnego i ostatecznie (jeśli Agile działa) to się sprzedaje (jeśli nie, to dlaczego to robisz?). Ludzie zaczynają rozumieć „wysiłek” i to, że pewna drużyna jest w stanie „spalić” 40 punktów wysiłku w 2-tygodniowym sprincie i są w rzeczywistości całkiem niezłe w oszacowaniu tych punktów wysiłku. Gdy zobaczą korzyści, sprzedają ten proces reszcie firmy. Ale najważniejsze jest to, że nigdy, nigdy nie możesz narzucić go komuś, bo po prostu się odeprze.