Nie, Scrum nas nie "uratował" od Waterfalla... za to powoli sam się nim staje ;-)

Nieraz już słyszałem w odpowiedzi na moje lub cudze narzekanie na Scruma i jego ciężkość, że "to co chcesz wrócić do Waterfalla"...

Moja odpowiedź jest standardowo mniej więcej taka "Ale wiesz, że tak na poważnie nikt nigdy nie stosował Waterfalla? Sam Waterfall pojawił się jako pomysł w 1 papierze napisanym dla DoD jako antypattern tego jak tworzyć oprogramowanie"...

To mi wyciągają, że o proszę a tak pisano software w latach 70...

Stąd dziś napiszę "dłuższą" wersję tego co mam w głowie gdy mówię o Waterfallu ;-)

Tak, Waterfall był używany, ale to nie jest tak, że to była jakaś uznana metodologia tworzenia oprogramowania i trzeba z nią było walczyć.

W latach 50 czy 60 oprogramowanie się bardziej zdarzało, pisane je dla rządów i wielkich firm. Nikt właściwie nie wiedział jak się za to zabrać więc próbowano metod, które działały w przemyśle gdy budowano sprzęt, albo gdy budowano sieć energetyczną czy telefoniczną. 

Powstawały specyfikacje i podobne dokumenty, bo nikt jeszcze nie wpadł na to jak to robić.
Nie było nawet jeszcze programistów jako takich... w NASA pierwszymi programistami były naprawdę kobiety i to często czarne, które wcześniej pracowały jako "computery" czyli osoby, które przeprowadzały obliczenia. 

Samo oprogramowanie było też dużo prostsze niż dzisiejszy software,

W latach 60 kod, który liczył nawet tak skomplikowane rzeczy jak symulacje bomby atomowej był szczytem komplikacji, ale dziś gra komputerowa robi więcej, bardziej skomplikowanych obliczeń.... nie przez przypadek dzisiejsze ładowarki USB mają większe moce obliczeniowe niż komputer, który pomagał lądować ludziom na Księżycu ;-)

Gdy powstało SABRE czyli Semi Automated Business Research Environment jako joint-venture między IBM, a American Airlines to tak, stosowano podejście ze specyfikacjami i nawet kodem pisanym ręcznie i później przenoszonym na komputery.... bo to był jeden z pierwszych dużych systemów komputerowych.... (dużych jak na tamte czasy, on zastępował to co do tej pory robiło kilka osób siedzących w pokoju w którym pod sufitem były przypięte wszystkie planowane układy siedzeń na jakiś tam czas i agent dzwonił, mówił co chce a oni na papierze to zaznaczali...)

W latach 70 się zaczęło robić ciekawiej bo komputery miały już kilka lat i wtedy właśnie powstał ten słynny papier mówiący o Waterfallu jako antypaternie. Komputery z magicznych potworów które zajmowały kilka pomieszczeń zaczęły maleć i mieściły się w biurku i się komplikowały więc stare metody, gdzie coś tworzono przez 2 lata się nie skalowały... stąd ten papier opisywał metody bazujące na iteracjach.... bo nagle komputery stawały się bardziej dostępne i to już nie było pisanie kodu "na sucho" coraz częściej feedback był dużo szybszy.
No i wtedy przyszedł 1975 i Altair BASIC... Gates z Allenem wcale nie używali Waterfalla... oni w ~8 tygodni to napisali, metodą prób i błędów... 
Tej samej techniki pisania używano później, co było nawet prostsze bo już taki VIC20 od Commodore pozwalał ludziom pisać kod i go od razu uruchamiać...

Cała software'owa część Silicon Valley to był ruch oparty o trial and error, o iteracje. Nikt tam nie używał Waterfalla.

Tak w tym czasie "wielkie" systemy dla banków czy urzędów skarbowych powstawały nadal ze specyfikacjami (choć i tam było coraz więcej trial and error), a z czasem w latach 80 ta kultura hackerów z Silicon Valley zaczęła być dominującym podejściem do tworzenia softu. Nawet duże firmy robiące "poważny" software Enterprise miały coraz więcej ludzi, którzy się tak uczyli programować.

Często było tak, że powstawały wielkie specyfikacje, które pisali poważni ludzie w garniturach, a później i tak implementacja powstawała metodą prób i błędów.

Dzisiejszy Software ma swoje "korzenie" nie w Waterfallu, ale w tym co robili hackerzy z Silicon Valley i podobnych miejsch.
Wszystkie OSy których używamy, wszystkie języki programowania, to są "dzieci" tego ruchu. C i Unix nie powstały jako wielkie systemy z tysiącami stron dokumentacji. One powstały z potrzeby. C powstał by mógł powstać Unix... a Unix powstał bo chcieli mieć w końcu coś gdzie mogliby używać komputera szybciej w wiele osób, by mieć szybki feedback gdy zrobią błąd.... to było całkowicie przeciwne modelowi Waterfalla.

Gdy w 2001 roku powstał Agile Manifesto on nie był "przeciwko Waterfallowi", on był przeciwko tworzonym przez firmy ad hoc procesom i chaosowi. Bo ludzie, którzy tworzyli oprogramowanie już od ~25 lat stosowali trial and error i wiedzieli, że to działa.

Dzisiejszy Scrum z certyfikatami, powtarzalnymi spotkaniami, wydzielonym Scrum Masterem, estymatami, mierzeniem prędkości i naciskiem na przewidywalność jest właśnie odwrotem od tego co chciał Agile Manifesto. Jest próbą narzucania developerom sztywnych ram "biznesowych"... chociaż tym razem służą one nie tyle biznesowi firmy, a biznesom ludzi robiących kasę na certyfikacji Scrumowej ;-)

Scrum jest dobrą metodologią, choć praktyka wskazuje, że każdy dobrze wprowadzony Scrum zmienia się w końcu w Kanbana ;-) [czyli nie, najpewniej nie powinno się zaczynać od Kanbana, Kanban jest dobry gdy między developmentem, a productem jest zaufanie i obie strony wiedzą, że gramy do tej samej bramki]. Ale to Scrum ma służyć ludziom, a nie ludzie Scrumowi. 
Na początku Scrum jest po to by chronić development. Product często chce zmieniać priorytety i cele, wtedy 2 tygodniowy Sprint jest stabilizatorem. To jest narzędzie, którego team może użyć do odrzucenia zmian celów, można powiedzieć w połowie Sprintu "OK, chcecie zmiany wymagań? Spoko, to całą robotę którą mamy z poprzedniego tygodnia wyrzucamy i zaczynamy wszystko od nowa". To jest szansa dla teamu na stabilizację, a dla productu lekcja, że dostają to co "zamówili", a jak zmieniają "zamówienie" to dostaną to odpowiednio później. Ale to uczenie się nawzajem prowadzi do wzrostu zaufania i w końcu team może odrzucić 2 tygodnie Sprinty, bo product nie zmienia zdania co 3 dni... ale jak zmienia to jest to na tyle ważne, że warto zmienić kierunek szybciej. Ludzie się też uczą dzielić robotę na mniejsze kawałki i straty w razie zmiany kierunku są też mniejsze....

Ale to wszystko nie dzieje się dzięki religijnemu oddaniu rytuałom Scruma, czy ideologicznemu nadzorowi Scrum Mastera ;-) a przez to, że dev team wie co ma robić....

Podobne posty^beta
SCRUM i ogólnie Agile to często taka zakamuflowana forma premature optimization
Kariera IT, jak iść w górę i jak iść w bok ;-)
Branche i Scrum to taki security blanket dla programistów
Kupię sobie jednak Copilota
Moja teoria firm IT