Czy ustalenie daty wydania przed zebraniem wszystkich wymagań jest niestabilne?

Właśnie zacząłem czytać książkę „Stosowanie UML i wzorów” autorstwa Craiga Larmana. Uważam to za bardzo interesujące, ponieważ kwestionuje wiele z tego, co powiedziano mi w pracy. Czytałem, że wymagania nie są w pełni zbierane za jednym razem w trybie zwinnym i potrzeba wielu iteracji, aby zakończyć gromadzenie wymagań. Jeśli tak jest, to czy ustalanie sztywnego terminu, który muszę robić w pracy, jest bardzo niestabilne, biorąc pod uwagę, że jutro mogą pojawić się nowe przełomowe wymagania (lub prośba o zmianę podszywająca się pod wymaganie)?

Nie ma absolutnie żadnego problemu z „zwinnym” z ustaloną datą wydania, jeśli jesteś przygotowany do przesunięcia jednej z dwóch pozostałych krawędzi „żelaznego trójkąta”: wymagania dotyczące tego, co musi być w tej wersji lub dostępnych zasobów . Nie można naprawić wszystkich trzech - aw praktyce strona „zasobów” trójkąta jest bardzo często albo mało elastyczna, albo nieefektywna w modyfikacji.

Jeśli jutro pojawią się nowe, ważne wymagania, to w porządku, o ile firma jest gotowa zaakceptować to wymaganie, ponieważ data wydania może się nie powieść - tzn. Przejdzie do następnego wydania.

Myślę, że problemem w wielu obozach Agile jest termin ostateczny. Ryzyko związane z terminem polega na tym, że zakładasz, że wiesz, co należy zrobić. Jak zauważyłeś, nie możesz mieć terminu na nieznane.

To, co opisano w odpowiedzi Filipa, jest o wiele mniej terminem niż ograniczeniem. Moglibyśmy powiedzieć, że mamy środki do marca, dlatego musimy zapewnić jak najlepszy produkt w tym czasie.

Aby dać analogię, załóżmy, że poproszę cię, abyś poszedł do historii sklepu spożywczego i kupił wszystkie artykuły spożywcze na tydzień, a zanim pójdziesz lub spojrzysz na jakąkolwiek cenę, chcę, abyś powiedział mi dokładnie, co wydasz. Ponadto zostaniesz ukarany, jeśli się mylisz. Zrobisz dokładnie to, co ludzie robią z terminami projektu - wybierzesz liczbę z górnej granicy tego, co według ciebie może być zasięgiem, ponieważ ma najmniejszą szansę na karanie. Teraz powiedzmy, że mówię ci, że jest to niedopuszczalne i musisz kupić te same rzeczy, które zaplanowałeś, ale musisz to zrobić za 50 USD taniej, bo inaczej. Co możesz teraz zrobić? Możesz odmówić, możesz po prostu odłożyć argument na później, aż zrobisz zakupy, lub możesz znaleźć sposób, aby oszukać sytuację. Tak dzieje się w wielu organizacjach z terminami ustalonymi na nieznane.

Teraz, widząc, jak niezdrowa jest ta cała sytuacja, Agile mówi tylko: „Jeśli masz budżet, mogę obiecać, że poddam się temu i dam ci najlepsze możliwe posiłki na ten tydzień w tym ograniczeniu”. Jest to zdecydowanie zdrowsza rozmowa.

Zwinność to technika, a nie wynik. W porównaniu do koszenia trawnika, jedna iteracja jest jak jedna linia trawy, którą skoszono. Jeśli ktoś powie „koś cały trawnik w 15 minut”, a używasz zwinnego, być może do końca ukończysz 30%. Potem powtórzysz trochę później i skończysz.

Możesz mieć zaplanowaną datę wydania bez problemu. Tylko upewnij się, że w tym konkretnym dniu nie masz żadnych straconych końcówek. Państwo powinno mieć produkt, który może być dostarczony na końcu każdego sprintu, ale zwykle nie ma nic złego zrobić, jeśli nie; jest to bardziej cel, który koncentruje się na pracy niż na wymaganiu. Jeśli masz zaplanowaną datę premiery, musisz mieć na ten dzień produkt, który można wydać .

Zwykle będziesz dążył do posiadania produktu niesprawdzonego, ale miejmy nadzieję, że będzie można go wypuścić na jakiś czas przed planowaną datą wydania, następnie produkt zostanie przetestowany i naprawiony, dopóki nie zostaną spełnione standardy jakości, a następnie zostanie wydany bez potrzeby paniki. Wydanie będzie zawierało wszystko, co było gotowe w tym czasie.

Teraz może nie być oczywiste dla twojego szefa, że ​​powinieneś również zaplanować drugą datę premiery, z większą liczbą faktycznie zaimplementowanych funkcji.