Czy Scrum tworzy dodatkowe koszty dla projektów, w których wymagania się nie zmieniają?

Czytam Scrum - kieszonkowy przewodnik Gunthera Verheyena i mówi:

Raport Chaosu z 2011 r. Sporządzony przez Standish Group stanowi punkt zwrotny. Przeprowadzono szeroko zakrojone badania porównując tradycyjne projekty z projektami wykorzystującymi metody Agile. Raport pokazuje, że zwinne podejście do tworzenia oprogramowania zapewnia znacznie wyższą wydajność, nawet wbrew starym oczekiwaniom, że oprogramowanie musi być dostarczone na czas, zgodnie z budżetem i całym obiecanym zakresem. Raport pokazuje, że projekty Agile były trzy razy bardziej udane, a projektów Agile trzy razy mniej nieudanych w porównaniu z projektami tradycyjnymi.

Mam więc sprzeczkę z jednym z moich kolegów, który twierdzi, że w przypadku niektórych projektów (takich jak medycyna / wojsko, w których wymagania się nie zmieniają), Agile (a zwłaszcza Scrum) jest narzutem na wszystkie spotkania itp. I jest bardziej logiczne na przykład użyć wodospadu.

Moim zdaniem Scrum powinien być stosowany w takich projektach, ponieważ zwiększy przejrzystość procesu i zwiększy wydajność zespołu. Myślę też, że wydarzenia Scrumowe nie zajmą dużo czasu, jeśli nie będą potrzebne, ponieważ nie musimy spędzać całych 8 godzin w Planowaniu Sprintu przez 1 miesiąc sprintu. Możemy poświęcić 5 minut, aby mieć pewność, że wszyscy jesteśmy na tej samej stronie i zaczniemy działać.

Czy Scrum stworzy dodatkowe koszty dla projektu, w którym wymagania się nie zmienią?

Uważam, że błędnym założeniem jest twierdzenie, że istnieją projekty, w których wymagania się nie zmieniają. Pracując zarówno w przemyśle obronnym, jak i w branży oprogramowania dla przemysłu farmaceutycznego, mogę powiedzieć, że gdy oprogramowanie znajdzie się w rękach ekspertów merytorycznych (wewnętrznych lub zewnętrznych), otrzymamy informację zwrotną. Czasami ta informacja zwrotna jest w trakcie spełniania wymagań, aw innych przypadkach w rzeczywistości są one błędne lub niekompletne.

Zwinność polega na skracaniu tego cyklu sprzężenia zwrotnego i szybszym dostarczaniu działającego oprogramowania w ręce, uzyskiwaniu tego sprzężenia zwrotnego i decydowaniu, jaki powinien być następny krok, aby upewnić się, że dostarczone oprogramowanie stanowi wartość dodaną, gdy klient zdecyduje się zaakceptować oprogramowanie. Nawet w domenach takich jak systemy wbudowane z niestandardowym sprzętem (np. W domenach takich jak lotnictwo, motoryzacja lub urządzenia medyczne), szybkie udostępnianie cienkich części funkcjonalności i prototypowanie może pomóc upewnić się, że system oprogramowania i sprzętu będzie działają zgodnie z przeznaczeniem i w sposób, który pomoże użytkownikowi końcowemu.

Skrócenie długości cyklu sprzężenia zwrotnego jest ogromnym czynnikiem zmniejszającym ryzyko. Z punktu widzenia zarządzania projektem, jeśli finansujesz projekt na 2-4 tygodnie i masz regularny wgląd w postęp, to zapewnia, że ​​jesteś na dobrej drodze. Dzięki możliwości dostarczania cienkich segmentów funkcjonalności stopniowo zwiększasz stan docelowy i możesz zacząć przewidywać, kiedy go osiągniesz. Jeśli czas staje się ograniczeniem, można opisać funkcje o niższej wartości, ponieważ najpierw wykonana praca powinna być albo funkcją o wysokiej wartości, albo aktywatorem funkcji o wysokiej wartości. W dowolnym momencie możesz zdecydować, czy warto dalej finansować wysiłek, czy iść w innym kierunku i zatrzymać projekt, zanim będzie za późno.

Bardzo krótka odpowiedź brzmi: tak, Scrum jest z założenia droższym podejściem, ale jeśli nazywasz to projektem, prawie na pewno nie ma to znaczenia, a ostatecznie prawie na pewno zawsze spowoduje lepszy zwrot z inwestycji.

Pełniejsza odpowiedź brzmi:

Ogólnie mówiąc, istnieją trzy formy kontroli procesu: Zdefiniowana kontrola procesu, Statystyczna kontrola procesu i Empericzna kontrola procesu. Zdefiniowana kontrola procesu jest zdecydowanie najtańsza. Jest to możliwe dzięki często powtarzanym pracom, które z czasem udoskonalono, aby znaleźć „najlepszy” sposób wykonania pracy. CI / CD w rozwoju oprogramowania należy do tej kategorii. Nie chcesz różnic w procesie kompilacji, więc ujednolicaj proces, dostosowuj go, aż będziesz zadowolony, a następnie zautomatyzuj go. Ten zautomatyzowany proces jest oczywiście o wiele tańszy do przeprowadzenia niż ręczna walka o wdrożenie.

Statystyczna kontrola procesu jest kolejnym najtańszym, ale uwzględnia zmiany w znanym procesie. Procedury medyczne przebiegające zgodnie z planem należą do tej kategorii. Nie chcę za każdym razem wymyślać operacji pomostowania. Postępuję zgodnie z podstawowym procesem i dostosowuję się do zmian. Ma to stosunkowo niskie obciążenie poznawcze i dość wysoki wskaźnik sukcesu.

Następny jest Empirical Process Control, który jest zdecydowanie najdroższy, ponieważ musisz odkrywać proces w trakcie pracy. Uczenie się jest niezwykle wysokie, ale kosztem wydajności i wydajności. Jednak prawie cała praca nad projektem wymaga tego, ponieważ wcześniej wykonano niewiele projektów. Istnieją oczywiście wyjątki. Konfigurowanie dużego środowiska Active Directory jest bardziej statystyczne, ponieważ pracujesz na podstawie kilku wypróbowanych i prawdziwych instrukcji, które nieco odbiegają od wymagań, zależnie od okoliczności. Ale chyba, że ​​twoim projektem jest wykonanie dokładnej pracy, którą wykonano wcześniej, prawie na pewno wymaga Emperical Process Control.

Aby przywrócić go do Scrum, Scrum został zaprojektowany w celu rozwiązywania problemów z kontrolą Emperical Process. Dlatego tak, ma więcej kosztów ogólnych niż inne podejścia. Ponieważ jednak większość projektów wymaga takiego podejścia, jest to dyskusyjny argument.

Kontrapunkt dotyczący medycyny i projektów wojskowych brzmi jak błędna logika. Jeśli realizujesz zamówienie na 500 samolotów, to tak, odtwarzasz coś dokładnie i Scrum prawdopodobnie nie jest korzystny. Jeśli budujesz nowy samolot, a twoje wymagania nigdy się nie zmienią, nie poleciałbym tym samolotem.

Oczywiście, jeśli masz projekt, w którym masz krystalicznie czyste wymagania z góry, możesz wodospadowo rzucić je przed programistami i wrócić dwa lata później, aby spełnić oprogramowanie swoich marzeń.

Ale ogromna większość projektów oprogramowania nie jest taka.

Zwykle klient nie wie, czego potrzebuje. Nie są w stanie zapewnić kompletnych i szczegółowych wymagań. Pomagają tu podejścia iteracyjne: zbuduj małą rzecz, a następnie poproś klienta o opinię. Tak, to „marnuje” czas na pokazy i planowanie następnej iteracji. Ale zbudowanie niewłaściwej rzeczy dla jednego sprintu, a następnie szybkie poprawienie wymagań jest o wiele lepsze niż budowanie niewłaściwej rzeczy dla całego projektu. Oznacza to, że chociaż wymagania z góry mogą umożliwić bardziej efektywny rozwój, podejścia iteracyjne będą bardziej skuteczne .

Programiści muszą poprawnie zrozumieć wymagania, jeśli chcą zbudować użyteczne oprogramowanie. Jaki jest dobry sposób na wykrycie nieporozumień, zanim będzie za późno? Ponownie mogą pomóc podejścia iteracyjne. Ważne jest również, aby sami programiści współpracowali z klientem, zamiast uzyskiwać przefiltrowane informacje tylko przez autora dokumentu wymagań.

Wreszcie świat nie stoi w miejscu podczas projektu. Zmieniają się systemy zewnętrzne, zmieniają się priorytety, zmieniają się ludzie. Udawanie, że wymagania projektu oprogramowania się nie zmienią, jest złym pomysłem, z wyjątkiem krótkich projektów.

Wszystkie te korzyści na poziomie procesu tracą dużą zaletę zwinnego podejścia: zwinność, jeśli jest wykonana poprawnie, sprawia, że wszyscy są szczęśliwsi. Największą z nich jest to, że zwinne techniki koncentrują się na zapewnianiu rzeczywistej wartości w krótkim okresie czasu. Zapewnia to widoczność procesu rozwoju, zapewnia interesariuszom rozsądny poziom kontroli nad projektem i jest znacznie bardziej motywujące niż dążenie do odległego celu. Wiąże się z tym pomysł, że zwinne zespoły będą się w dużej mierze samoorganizowały. Poczucie kontroli nad codzienną pracą sprawia, że ​​ludzie czują się doceniani, a przez to bardziej skłonni do dawania z siebie wszystkiego.

Twój kolega nie myli się, że projekty w stylu wodospadu mogą mieć swoje miejsce. Nie mylisz się, że niektóre zwinne praktyki mogą być czasochłonnymi rytuałami. Ale głupotą jest ignorowanie zalet zwinnego i iteracyjnego podejścia, zwłaszcza lepszego zarządzania ryzykiem i szacunku dla osób. To są rzeczy, które chcesz w każdym projekcie. W razie potrzeby zespół może spróbować zaimplementować niektóre z nich wewnętrznie, ale procesy działają lepiej, gdy wszyscy są na pokładzie.

Myślę, że to może sparafrazować to, co mówi @Cort Ammon, ale oto moje zdanie:

Wymagania zewnętrzne (opisujące „rezultaty”) nie są jedynymi wymaganiami w projekcie. Nawet jeśli wymagania zewnętrzne nie ulegną zmianie, wymagania „wewnętrzne” zmienią się lub będą musiały ulec zmianie w miarę pracy. Deweloperzy odkryją przeszkody lub problemy z podejściem, co wpłynie na pracę innych osób w zespole. Codzienny stand-up sprawi, że wszyscy będą na bieżąco z tymi wewnętrznymi zmianami.

Weź pod uwagę, że:

• Nawet przy stałych wymaganiach funkcjonalnych musisz je przełożyć na wymagania techniczne. I może to być lepiej zrobione przez iteracje. Możesz znaleźć lepsze sposoby rozwiązania problemu w środku projektu.

• Niektóre wymagania mogą być zbyt ogólne lub dwuznaczne: „bądź łatwy w użyciu”, „bądź bezpieczny”. Trudno jest przeanalizować bezpieczeństwo lub użyteczność systemu, czy nie jest on ukończony. Niektóre mogą mieć ukryte implikacje lub mogą nie być dobrze zrozumiane.

• Niektóre wymagania mogą zostać ulepszone. Odpowiadanie w ciągu 200 ms może być dobre, ale 100 może być lepsze. Możesz wybrać najlepszy możliwy wynik, ale poświęć go, jeśli zajdzie taka potrzeba podczas projektu.

• Możesz odkryć jakieś ukryte wymaganie, które nie zostanie zapisane w umowie, ale może zmienić projekt z niepowodzenia na sukces. Nawet jeśli dostarczysz projekt, klient może nie być zadowolony. Być może będą musieli nawet zmienić umowę, aby dodać (i naładować) nowe funkcje, które możesz zaprojektować w projekcie taniej na wczesnych etapach.

• Możesz odkryć, że nie możesz spełnić swoich wymagań w danym czasie. Nie jest tak, że projekty oprogramowania nigdy się nie spóźniają. Zapewnienie najlepszej wartości pozwoli Ci ponownie powiązać funkcje, które chcesz usunąć.

• Wcześniejsze dostarczenie czegoś pomoże w integracji i pokaże, że ten projekt może przynieść rezultaty.

Można wysunąć argument, że jeśli wszystkie wymagania zostaną idealnie określone, istnieje podejście odgórne, które spełnia te wymagania tak szybko, jak to możliwe. Jednak jeśli są to dobre wymagania, mówią ci, co zrobić, a nie jak to zrobić. Jeśli powiedzą ci, jak to zrobić, wolę nazwać to „instrukcjami pracy” zamiast „wymaganiami”, a dyskutowalibyśmy o innym rodzaju problemu.

W związku z tym zawsze istnieje proces opracowywania „sposobu” wewnętrznego dla firmy lub zespołu wdrażającego wymagania. Empirycznie rzecz biorąc, opieramy się na hierarchicznym podejściu, w którym zespół projektantów projektuje system wysokiego poziomu, aby spełnić te wymagania, a następnie wykorzystuje specyfikę tego systemu wysokiego poziomu, aby dostarczyć „wymagania” mniejszym zespołom, które dopracowują nasze szczegóły.

W procesie wodospadu widać to na jednokierunkowej strzałce między projektem a wdrożeniem. Jednak te wymagania nie są ustalone, tak jak te dostarczone przez klienta. Są one wewnętrznie zdefiniowane i mają miejsce na proces iteracyjny. W praktyce projektanci albo kładą duży margines w procesie, aby uwzględnić ten brak iteracji, albo szukają procesu iteracyjnego.

SCRUM i wiele innych powiązanych zwinnych metod, po prostu zapewniają rygorystyczne ramy, w których można wykonać ten iteracyjny proces. Cechą charakterystyczną zwinnych podejść jest to, że rozważają optymalizację tego iteracyjnego wzorca jako rdzeń procesu, zamiast koncentrować się na zewnętrznej warstwie trudnych wymagań. Jak wspomnieli inni, rzeczywiste ustalone wymagania są rzadkie, ale nawet w ich obecności SCRUM stosuje iteracyjne podejście jako metodę kontroli podejścia umownego, w którym się mieści.

To, czy uda się to zrobić, jest kwestią otwartej debaty. Inni podali w tym celu wiele wskaźników. Zwrócę tylko uwagę, że do siły przywódczej należy upewnienie się, że iteracje, które występują pod nimi, dobrze pasują do powyższego systemu umownego. Jest to prawdą w przypadku każdego podejścia do rozwoju, ale jest to bardziej widoczne w podejściu zwinnym, ponieważ zostaliśmy wychowani, aby założyć, że bardziej odgórne podejście jest „normalne” i wyszkoleni przywódcy jako tacy.