Programowanie zwinne

Programowanie zwinne (ang. agile software development) – początkowo nieznacząca sekta, obecnie najpopularniejsza religia wśród programistów. Jej podstawowym założeniem jest bycie fajniejszym (zwinniejszym) od nie-edżajlowych deweloperów.

Przykazania

Jeden z proroków prezentuje Agile Manifesto

Podstawą religii Agile jest stworzony w 2001 roku przez siedemnastu proroków Agile Manifesto, stanowiący odpowiednik dekalogu. Oto treść Manifestu:

Zwinnie wytwarzając oprogramowanie i pomagając ziomkom w tym zakresie, odkrywa się lepsze sposoby bycia fajnym. W wyniku tych doświadczeń przedkłada się:

• fajni ludzie i melanże ponad procesy i narzędzia
• pisanie ogromnych ilości niezwiązanego wzajemnie ze sobą kodu ponad obszerną dokumentację
• targowanie się z klientem ponad formalne ustalenia
• zmienianie wszystkiego jak popadnie ponad podążanie za planem

Według Manifestu Edżajl, to co wymieniono po prawej stronie jest reliktem przeszłości i każdy kto te rzeczy stosuje jest dinozaurem. Jesteśmy od was zwinniejsi.

Stand-up meeting

Współczesny stand-up meeting

Wśród elementów metodyk zwinnych można wymienić stan dupy stand-upy, czyli zebrania członków zespołu na stojąco. Z założenia niewygoda wynikająca z ciągłego stania ma skutkować krótszymi spotkaniami, niestety wraz ze wzrostem popularności biurek do stania znacząco zwiększyła się wytrzymałość programistów na stanie. Obecnie wykształciły się różne szkoły rozwiązywania tego problemu, od spotkań stanych na rękach, przez stanie bosymi stopami na rozgrzanych węglach aż po spotkania w egzotycznych pozycjach inspirowanych jogą ekstremalną.

Metodyki edżajlowe

Na żyznym gruncie mniej lub bardziej spójnego pierdolenia o programowaniu zwinnym wyrosło całkiem sporo dziwnych i dziwniejszych metodyk. Warto tutaj zaznaczyć, że wszystkie poniższe metodyki faktycznie istnieją i nie zostały zmyślone przez autora. O Scrumie nie będziemy pisać, bo jest już passé i nikt poważny go nie stosuje.

Guilt Driven Development

Jedna z bardziej skutecznych metodyk. Na początku iteracji każdy członek zespołu składa obietnice, które elementy zrealizuje. Wszystkie obietnice zapisywane są w odpowiedniej bazie, a komputer nigdy nie zapomina. Jeśli nie dotrzyma się jakiejś obietnicy, odpowiedni program napomina dewelopera i robi mu wyrzuty komentując jego niesłowność i nieodpowiedzialność. Przykładowe wyjście takiego programu:

Obiecałeś do końca iteracji zaimplementować funkcjonalność #4069, a kodu dalej coś nie ma… Zastanów się, co to mówi o Tobie? Czy kiedykolwiek dojrzejesz do bycia odpowiedzialnym dorosłym? Czy Twoja matka byłaby z ciebie dumna? Przysięgałeś na zdrowie matki, że to zrobisz, czy rzeczywiście tak nisko cenisz sobie jej zdrowie?

Słowem wyjaśnienia – bardziej zaawansowane programy nękające wymagają wprowadzenia wielu informacji o każdym członku zespołu, jego rodzinie, zdrowiu psychicznym, osiągnięciach w nauce i życiu erotycznym. Następnie programista musi przysiąc na coś, co jest wysoko w jego hierarchii wartości (np. na Boga, matkę, rachunek różniczkowy…) dla maksymalnej skuteczności. Warto zaznaczyć, że programy nękające działają także w święta, ba, w dni ustawowo wolne od pracy nękają aż trzy razy częściej.

Wśród skutków ubocznych metodyki GDD można wymienić między innymi większą podatność członków zespołu na załamanie nerwowe, depresję i ogólną zwiększoną śmiertelność. Należy ją stosować wraz z agresywnymi technikami poszukiwania pracowników w celu zapewnienia stałej ilości programistów w projekcie.

Lider zespołu SDD musi zadbać o odzież ochronną dla siebie

Shame Driven Development

Metodyka nieco podobna do Guilt Driven Development, ją również można implementować przy pomocy narzędzi automatycznych, ale daje dużo lepsze efekty, gdy robią to ludzie. Podstawowym założeniem jest rezygnacja z jakichkolwiek wymagań przy commitowaniu i merge'owaniu kodu. Tak, żadnych durnych code review, żadnych unit testów, kod nie musi się nawet kompilować, cała odpowiedzialność spoczywa na programiście. Jeśli w kodzie będą jakieś bugi (a będą), należy delikwenta publicznie wyśmiać i zagonić do roboty. Prekursorem tej metodyki jest twórca Linuksa, Linus Torvalds, oto kilka wypowiedzi mistrza:

Ten gówniany commit został oznaczony jako „stabilny”, ale coś mi się wydaje, że nawet tego nie skompilowałeś!

Oczywiście, sugerowałbym też żeby geniusz który myślał, że czytanie danych BAJT PO JYM BAJCIE to dobry pomysł powinien zostać poddany wstecznej aborcji. Kto ka robi tak idiotyczne rzeczy? Jakim cudem nie umarł jako dziecko, skoro prawdopodobnie był zbyt głupi, by znaleźć cycka do ssania?

I crème de la crème:

Mauro, ZAMKNIJ RYJ!

Skutki uboczne SDD są w gruncie rzeczy podobne do skutków GDD, więc nie będziemy się powtórnie nad nimi rozwodzić.

Bug Driven Development

Bardzo naturalna metodyka, która głęboko rezonuje z każdym pełnokrwistym programistą. Dobremu deweloperowi nie trzeba jej nawet tłumaczyć, bo jest dlań oczywista i intuicyjna. Podstawowym założeniem jest napisanie jak największej ilości kodu w jak najkrótszym czasie, byle się kompilowało, nic więcej, nie musi nawet za bardzo działać. Następnie w kolejnych iteracjach należy łatać bugi do skutku.

Technika Bug Driven Development gwarantuje zakończenie projektu w skończonym czasie i budżecie. Niestety, górnym oszacowaniem czasu potrzebnego na wdrożenie całości jest Apokalipsa, dlatego kluczowym jest zachowanie optymizmu i wytrwałe targowanie się z klientem.

Programowanie ekstremalne

Praojciec wszystkich najciekawszych metodyk zwinnych, otoczony tak wielkim szacunkiem, że zasłużył sobie na własny artykuł.

Główny artykuł: Programowanie ekstremalne