Edytujesz „Programowanie zwinne”

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

== Przykazania ==
[[Plik:Rembrandt Harmensz. van Rijn 079.jpg|thumb|180px|Jeden z proroków prezentuje ''Agile Manifesto'']]
Podstawą religii Agile jest stworzony w [[2001]] roku przez siedemnastu proroków ''Agile Manifesto'', stanowiący odpowiednik [[dekalog]]u. 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'' ==
[[Plik:Conjunto español 2003 02.png|thumb|180px|Współczesny ''stand-up meeting'']]
Wśród elementów metodyk zwinnych można wymienić ''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<ref>Kolejny hipsterski wymysł</ref> znacząco zwiększyła się wytrzymoł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]] nie przebacza. 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:
{{Cytat2|''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 jej właśnie zdrowie, 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 [[Bóg|Boga]], [[Matka|matkę]], [[rachunek różniczkowy]]…) dla maksymalnej skuteczności.

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, [[Depresja|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.

=== ''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 [[Scalanie|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:
{{Cytat2|''Ten gówniany commit został oznaczony jako „stabilny”, ale coś mi się wydaje, że nawet tego nie skompilowałeś!''<ref>[https://lkml.org/lkml/2013/7/13/132 Źródło]</ref>}}
{{Cytat2|''Oczywiście, sugerowałbym też żeby geniusz który myślał, że czytanie danych BAJT PO J{{cenzura3}}YM BAJCIE to dobry pomysł powinien zostać poddany wstecznej aborcji. Kto k{{cenzura3}}a robi tak idiotyczne rzeczy? Jakim cudem nie umarł jako dziecko, skoro prawdopodobnie był zbyt głupi, by znaleźć cycka do ssania?''<ref>[https://lkml.org/lkml/2012/7/6/495 Źródło]</ref>}}
I ''crème de la crème'':
{{Cytat2|''Mauro, ZAMKNIJ {{cenzura3}} RYJ!''<ref>[https://lkml.org/lkml/2012/12/23/75 Źródło]</ref>}}

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 należy łatać bugi w kolejnych iteracjach do skutku.

=== 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]]}}

{{Przypisy}}

[[Kategoria:Programowanie]]