Zwinne - skoki i ogólna oś czasu

Zespół rozpoczyna swój pierwszy kapitałowy projekt Agile, a projekt wydaje się, że będzie dobrze pasował do metodologii (tj. Prawdopodobnie możemy po prostu złapać zwinną książkę i postępować zgodnie z nią jak przepis), z jednym zamieszaniem:

Projekt obejmuje trzy rzeczy, z którymi nikt w zespole nie ma żadnego doświadczenia: integracja z systemem Foo Payroll, możliwość obsługi typu pliku XYZ89 (gdzie „XYZ89” = jakiś typ pliku, o którym nigdy nie słyszałeś), i konwersja niektórych inne pliki, aby mogły być obsługiwane przez Frobnobdicator.

Jak rozumiem, standardową praktyką zwinną byłoby zaplanowanie szczytów dla każdego z nich, po czym możemy ustalić, ile czasu to zajmie (nie jestem pewien, że istnieje duża szansa, że ​​klient zdecyduje się tego nie robić im, ponieważ są to dość solidne wymagania projektu)

Więc moje pytania to:

1. Czy wykonujemy wszystkie kolce z góry w pierwszej iteracji, aby uzyskać lepszy szacunek czasu potrzebnego na ich wykonanie i / lub uruchomienie „chodzącego szkieletu”?

2. Jeśli nie, to czy całkowity harmonogram projektu nie byłby na łasce jednego z tych szczytów powracających z danymi, że ta konkretna historia potrwa znacznie dłużej, niż nam się to udało?

Jaki jest najlepszy sposób postępowania z wieloma skokami, gdy są to w zasadzie niezbywalne wymagania projektu?

Sposób, w jaki radziłem sobie z tymi podejrzanymi niewiadomymi w moim planie projektu, to próba ustawienia czasu dla zespołu programistów na wykonanie prototypów nieznanej funkcjonalności. Daje to korzyść z jasnego informowania o tym, co będzie wymagane do wykonania specjalistycznych zadań, dowodzi, że są one technicznie wykonalne, i kształci resztę zespołu w zakresie możliwych pułapek, których należy unikać, gdy rozpocznie się aktywny rozwój.

Właśnie dlatego wiele projektów Agile zaczyna się od, jak to nazywam, Sprint 0 .

Pomyśl o tym, jak sznurowanie butów do biegania, rozciąganie i nakładanie bandaży na sutki tuż przed rozpoczęciem maratonu. Ten czas można wykorzystać na wstępne planowanie projektu i tworzenie historii użytkownika, wdrażanie projektu i architektury, tworzenie ram oprogramowania, a programiści mogą pracować nad wszelkimi prototypami i dowodami koncepcji dla każdej nowej technologii lub nieznanych wyzwań technicznych, które sprawią, że historia użytkownika stanie się punktem wyjścia oszacowanie znacznie łatwiejsze.

Powinieneś robić rzeczy w kolejności ustalonej przez właściciela produktu (lub klienta). Nie ma sensu zabijać się z powodu czegoś, co było naprawdę miłe. Chodzi o to, że jeśli zabraknie Ci czasu i coś nie zostanie zrobione, powinny to być przedmioty o najniższym priorytecie.

Jeśli nie będą traktować priorytetowo tego, czego chcą, będziecie walczyć.

Jeśli sprawy są względnie równe, nie zaczynaj od najtrudniejszego przedmiotu - zacznij od łatwej wygranej, która da zespołowi szansę na przyzwyczajenie się do współpracy przy użyciu nowej metodologii, a klientowi pewność, że mogą dostarczyć rzeczy w ten sposób. Po ustaleniu zmierzyć się z czymś trudnym. Zmierz złożoność trudnego przedmiotu na tle złożoności łatwiejszych rzeczy, które właśnie zrobiłeś, a zaczniesz rozumieć, ile czasu zajmie mu przejście.

Złożone przedmioty nie są tak naprawdę „kolcami”. Są to po prostu rzeczy, które wymagają większego wysiłku, aby zrozumieć. Podziel je na prostsze zadania, na ile to możliwe.

Możliwym rozwiązaniem jest stworzenie zabawki do wykonania testu koncepcyjnego, aby dowiedzieć się, jak rozwiązać problem i określić czas, a następnie dodać tę historię do sprintu z innymi historiami.

Na koniec sprintu dostarczasz wartość i produkt, nawet jeśli jest to aplikacja na konsolę hack. Chodzi o to, aby nie obniżyć produktywności całego zespołu, jeśli zabraknie czasu, do kolejnego sprintu dodajesz kolejne podobne zadanie.