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

10

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)?

Kaushik
źródło

Odpowiedzi:

19

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.

Philip Kendall
źródło
1
Zawsze czułem, że ta strona zasobów trójkąta jest błędem. Zamień go na jakość i działa lepiej. Ale jesteś na miejscu: przywiąż mnie do daty premiery, jeśli musisz, ale funkcje i jakość spadną w wyniku.
David Arno,
1
@DavidArno Twierdzę, że „jakość” jest częścią definicji Gotowości, która sama w sobie jest częścią każdego wymagania. I „zasobów” na pewno może mieć znaczący wpływ na dostawy, jeśli wziąć zasób dala od projektu.
Philip Kendall,
1
@ChristianHackl: Myślę, że bez względu na metodologię, tworzenie oprogramowania wymaga dużo czasu i pieniędzy, jeśli chcesz także jakości.
Bryan Oakley,
2
@BryanOakley: To prawda. Chciałbym tylko, żeby zwinni ewangeliści w rzeczywistości uznali, że ich metodologie nie są pod tym względem wyjątkowe. Kiedy porzucisz fałszywe założenie, że zwinny pozwala ci mieć ciasto i zjeść je, możesz faktycznie zaprojektować prawidłowy proces rozwoju swojego projektu, wybierając, czy i ile „zwinnego” powinno w nim być.
Christian Hackl
1
@ChristianHackl Żadna metodologia nie jest srebrną kulą. Ale głównym celem „zwinnego” (szerokiego terminu) nie jest to, że powinno to sprawić, że udane dostawy będą tańsze / szybsze, ale że obniży koszty (nieuniknione) awarii.
Guran
3

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.

Daniel
źródło
Czy naprawdę obiecujesz to ludziom? Co jeśli się mylisz i inne podejście dotrzyma terminu przy jeszcze lepszych posiłkach?
Christian Hackl,
1
Podobne argumenty o zwinności i terminach tutaj
Eric King
@Chrześcijanin. Pewnie. Przynajmniej jest to najlepsze, co mogę dostarczyć w ramach tego ograniczenia. Być może ktoś inny mógłby zrobić lepiej, a może gdyby okoliczności były inne, wymyśliłbym lepsze rozwiązanie, ale te spekulacje nie wydają się cenne. Zwłaszcza biorąc pod uwagę, że zawsze mam więcej informacji, im później otrzymam projekt, każdy szacowany termin, który podam teraz, będzie z natury mniej poinformowany niż cokolwiek, co powiem później.
Daniel
oczywiście mówimy o dość złożonym temacie na platformie StackExchange, który nie jest przeznaczony do obsługi szerokich wieloaspektowych tematów. Starałem się, aby moja odpowiedź była zwięzła i koncentrowała się na platformie. W rzeczywistości jest to bardzo wąski wycinek i wiele można powiedzieć o bardziej solidnej naturze tworzenia oprogramowania i organizowaniu cyklu rozwojowego.
Daniel
@Daniel: Cóż, sprzeciwiam się poglądowi, że klient obiecuje idealne wyniki tylko dlatego, że uważasz, że stosujesz najlepsze podejście. To nie jest realistyczne.
Christian Hackl,
2

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.

Dingo
źródło
2

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.

gnasher729
źródło