Pragmatyczne Programowanie Funkcyjne

uncle bob label image
Przechodzenie do programowania funkcyjnego rozpoczęło się na dobre jakąś dekadę temu. Widzieliśmy jak języki Scala, Clojure i F# zaczęły przyciągać uwagę. To przechodzenie było czymś więcej niż tylko zwykłym entuzjazmem w stylu: "O fajnie, nowy język!". Było w tym coś prawdziwego. Coś, co to napędzało - przynajmniej tak myśleliśmy.

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.

Prawo Moora mówiło, że prędkość komputerów będzie podwajać się każdorazowo co 18 miesięcy. To prawo sprawdzało się od lat 60-tych aż do roku 2000. I wtedy się zatrzymało. Na amen. Częstotliwości zegara osiągnęły 3ghz i krzywa wzrostu spłaszczyła się. Prędkość światła została osiągnięta. Sygnały nie mogły rozchodzić się po układzie elektronicznym z wystarczającą prędkością, aby zapewnić szybsze działanie.
Więc projektanci sprzętu zmienili swój plan działania. Aby zapewnić większą wydajność, dodali więcej procesorów (rdzeni). Żeby zrobić miejsce dla tych rdzeni usunęli wiele elementów pamięci podręcznej i potokowości z tych układów. Zatem procesory stały się odrobinę wolniejsze niż przedtem, ale za to było ich więcej. Wydajność zwiększyła się.
Miałem swoją pierwszą dwurdzeniową maszynę 8 lat temu. Dwa lata później miałem czterordzeniową maszynę. I tak zaczęło się rozmnażanie rdzeni. I wszyscy zrozumieliśmy, że to wpłynie na tworzenie oprogramowania w sposób, którego nie mogliśmy przewidzieć.
Jedną z naszych reakcji na to wszystko było uczenie się Programowania Funkcyjnego (PF). PF mocno zniechęca do zmiany stanu zmiennej raz zainicjalizowanej. Ma to zasadniczy wpływ na współbieżność. Jeżeli nie możesz zmienić stanu zmiennej, nie masz problemu sytuacji wyścigu. Jeżeli nie możesz zaktualizować wartości zmiennej, nie masz problemu jej jednoczesnego nadpisania.
Uważano to za rozwiązanie problemu wielu rdzeni. W momencie, gdy rdzenie rozmnażały się, współbieżność, BA! jednoczesność stała się znaczącym problemem. PF miało więc zapewnić styl programowania, który łagodziłby problemy związane z obsługą 1024 rdzeni w procesorze.
Więc wszyscy zaczęli uczyć się Clojure, lub Scali, lub F# lub Haskella; ponieważ widzieli, że pociąg towarowy już pędził po torach i zmierzał w ich kierunku, a oni chcieli być przygotowani, kiedy nadjedzie.
Ale pociąg towarowy nigdy nie nadjechał. Sześć lat temu miałem laptopa z czterema rdzeniami. On tego czasu miałem ich jeszcze dwa. Wygląda na to, że mój następny laptop też będzie miał cztery rdzenie. Czy jesteśmy świadkami kolejnego spłaszczenia krzywej wzrostu?
Tak na marginesie, wczoraj wieczorem oglądałem film z 2007 roku. Bohaterka używała laptopa, przeglądała strony używając wymyślnej przeglądarki, używała Google'a i odbierała SMSy na telefonie z klapką. To wszystko wyglądało bardzo znajomo. Ooo, jasne, że minęło już trochę czasu - widziałem starszy model laptopa, starszą wersję przeglądarki i telefon z klapką nie przypominał dzisiejszych smartfonów. Nadal - zmiana ta nie była aż tak dramatyczna jak od roku 2000 do roku 2011. I nawet nie zbliżyła się do tej zmiany, jaka miała miejsce pomiędzy latami 1990 - 2000. Czy jesteśmy świadkami kolejnego spłaszczenia krzywej wzrostu w dziedzinie komputerów i technologii oprogramowania?
Więc, być może PF nie było tak kluczową umiejętnością, jak wtedy myśleliśmy. Może nie utoniemy pod zalewem rdzeni. Może nie musimy się martwić układami zawierającymi 32768 rdzeni. Może powinniśmy się odprężyć i wrócić do aktualizowania wartości zmiennych.
Myślę, że to byłby błąd. Duży błąd. Myślę, że to byłby błąd tak duży, jak niepowstrzymane użycie goto. Myślę, że byłoby to tak niebezpieczne, jak porzucenie dynamicznych, polimorficznych wywołań funkcji.
Dlaczego? Możemy zacząć argumentować od tego, co nas najbardziej interesuje. PF sprawia, że współbieżność jest bezpieczniejsza. Jeżeli budujesz system z wieloma wątkami, lub procesami, wtedy użycie PF znacząco zmniejszy problemy, które mógłbyś mieć z sytuacjami wyścigu i jednoczesną aktualizacją zmiennych.
Co jeszcze? Cóż, PF jest łatwiejsze do pisania, łatwiejsze do czytania, łatwiejsze do testowania i łatwiejsze do zrozumienia. Wyobrażam sobie, jak teraz część z was macha rękami i krzyczy do monitora. Spróbowałeś PF i stwierdziłeś, że nie znajdujesz w tym niczego łatwego. Wszystkie te operacje map i reduce, i cała ta rekurencja - szczególnie rekurencja ogonowa to nic prostego. Jasne. Rozumiem. Ale to tylko problem z zaznajomieniem się. Jak tylko obeznasz się z tymi pomysłami - aby rozwinąć taki stopień zaznajomienia nie trzeba dużo czasu - programowanie stanie się o wiele prostsze.
Dlaczego staje się prostsze? Ponieważ nie musisz śledzić stanu systemu. Stan zmiennych nie może się zmieniać; więc stan systemu pozostaje niezmieniony. I to nie tylko systemu nie musisz śledzić. Nie musisz śledzić żadnego stanu listy, czy stanu zbioru, czy stanu stosu, czy kolejki; bo te struktury danych nie moga być zmienione. Jeżeli wkładasz element na stos w języku PF, dostajesz nowy stos, nie zmieniając starego. To oznacza, że programista może żonglować większą ilością piłeczek w tym samym czasie. Jest mniej do zapamiętania. Mniej do śledzenia. I w ten sposób kod jest prostszy do napisania, czytania, rozumienia i testowania.
Więc jakiego języka powinieneś używać? Moim ulubionym jest Clojure. Powód jest taki, że Clojure jest absolutnie prosty. To jest dialekt Lisp, który jest wspaniale prostym językiem. Proszę bardzo, pozwól, że Ci zademonstruję.
To jest funkcja w Javie: f(x);
Teraz, aby zmienić ja w funkcję w Lispie, musisz po prostu przesunąć pierwszy nawias w lewo: (f x).
Teraz znasz już 95% Lispa, i umiesz około 90% Clojure. Ta śmieszna, mała składnia dotyczy większości tego rodzaju języków. To jest absurdalnie proste.


OK, może już widziałeś kiedyś programy w Lispie i nie spodobały Ci się te wszystkie nawiasy. I może nie lubisz tych operacji CAR i CDR i CADR i innych. Nie martw się. Clojure ma trochę lepszą interpunkcję niż Lisp, więc będzie trochę mniej nawiasów. Clojure zamieniło CAR i CDR i CADR na first i rest i second. Co więcej, Clojure jest zbudowany na JVM, co z kolei umożliwia kompletny dostęp do pełnej biblioteki Javy. Interoperacyjność jest szybka i łatwa. I, jeszcze lepiej, Clojure pozwala na pełny dostęp do możliwości OO JVM-a.
"Ale zaraz, zaraz!". Słyszę, jak mówisz. "PF i OO się wzajemnie wykluczają!". Kto Ci to powiedział? To bzdury! Ooo, to prawda, że w PF nie możesz zmienić stanu obiektu; ale co z tego? Tak jak wrzucenie liczby całkowitej na stos daje w wyniku nowy stos - wtedy, kiedy wywołujesz metodę, która aktualizuje jakąś wartość z obiektu, dostajesz nowy obiekt, zamiast zmieniać stary. Łatwo to ogarnąć, szczególnie jak przywykniesz.
Ale wracając do OO. Jedną z własności OO, którą uważam za najbardziej przydatną, w kontekście architektury oprogramowania, jest dynamiczny polimorfizm. I Clojure dostarcza całkowity dostęp do dynamicznego polimorfizmu Javy. Być może przykład wyjaśni to najlepiej.
(defprotocol Gateway
  (get-internal-episodes [this])
  (get-public-episodes [this]))
Powyższy kod definiuje polimorficzny interfejs dla JVM. W Javie ten interfejs wyglądałby tak:
public interface Gateway {
  List<Episode> getInternalEpisodes();
  List<Episode> getPublicEpisodes();
}
Na poziomie JVM wyprodukowany bajtkod jest identyczny. Dzięki tej samej cesze program w Clojure może implementować interfejs Javowy. W Clojure wygląda to tak:
(deftype Gateway-imp [db]
  Gateway
  (get-internal-episodes [this]
    (internal-episodes db))
  (get-public-episodes [this]
    (public-episodes db)))
Zauważ ten argument konstruktora db, i jak wszystkie metody mają dostęp do niego. W tym przypadku implementacje interfejsu po prostu przekazują go do funkcji lokalnych.
Najlepszy z tego wszystkiego, być może, jest fakt, że Lisp, a co za tym idzie Clojure, jest (uwaga) Homoikoniczny, co oznacza, że kod jest danymi, na których program operuje. To łatwo zobaczyć. Ten kod: (1 2 3) reprezentuje listę trzech liczb całkowitych. Jeżeli pierwszy element listy będzie funkcją, tak jak w: (f 2 3) stanie się to wywołaniem funkcji. Z tego, wszystkie wywołania funkcji w Clojure są listami; a listy mogą być bezpośrednio manipulowane przez kod. Z tego wynika, że program potrafi stworzyć i uruchomić inne programy.
Podsumowanie jest takie. Programowanie funkcyjne jest ważne. Powinieneś uczyć się go. I jeśli zastanawiasz się jakiego języka mógłbyś się uczyć, ja sugeruję Clojure.

Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.

Droga Hackera!

uncle bob label image
Zawsze wydawało mi się, że Erik Meijer (@headinthebox) jest całkiem inteligentnym gościem. Prawda? Mam na myśli to, że koleś, który dał nam LINQ, nie może być idiotą, mam rację?
Ale ostatnio ... No cóż, ostatnio zdałem sobie sprawę, że dr Meijer jest po prostu niesamowicie genialny. To znaczy kreatywnie, kosmicznie, bohatersko genialny! A powód? POWÓD? POWÓD jest taki, że właśnie zrobił kawał stulecia!
Proszę, obejrzyj to. Po obejrzeniu tego Ron Jeffries zatweetował:
"no cóż, to było 45 minut, do których już nigdy nie wrócę"

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.

Popatrz na dr Meijera grzmiącego, pieklącego się, dyszącego, pocącego się, szturmującego scenę, emitującego więcej szaleństwa niż normalny móżg jest w stanie znieść. Grzmi wśród płomieni piekielnych i oparów siarki. Jest jak słusznie oburzony kandydat do sejmu. Jest jak moralnie dotknięty aktywista na rzecz praw obywatelskich.
Poczuj entuzjazm i pasję tego człowieka kiedy nawołuje swoich słuchaczy (w czasie 30:00), aby unikali testowania ich kodu. Mówi:
"Jedyna słuszna droga tworzenia Twojego oprogramowania to wrzucenie tego na produkcję! Ponieważ to się zawali. I wtedy, jak tylko się zawali, cofasz to do poprzedniej wersji! ... Nie ma żadnego innego sposobu, w który mógłbyś wcześniej testować swoje oprogramowanie. Więc całe to TDD to gówno? Zapomnij o nim. Jeżeli Twoja firma robi TDD - co robisz? Zwalniasz się! Odchodzisz! Wypisujesz wypowiedzenie już dziś! ... Pisanie testów to marnotrawstwo. TDD jest dla ciot."
Ale nie wyłączaj tego video! Słuchaj dalej! Oglądaj dalej! Zobacz, jak dr Meijer pokazuje nam "jedyną architekturę jaką zna", siedmiowarstwowe struktury OSI dla telekomunikacji. Nudziarstwo, mówisz? Ooo, nie! Na podstawie prostego przykładu architektury opartej na hierarchicznych warstwach, której w zasadzie nikt jeszcze nie zaimplementował, błyskotliwie argumentuje, że zespoły programistyczne powinny być zarządzane poprzez struktury ścisłego nadzoru i kontroli, jak w przypadku Kościoła Katolickiego, czy armii.
"Kościół istnieje od około 2000 lat. Żadne przedsiębiorstwo nie istnieje od 2000 lat. Dlaczego kościół potrafił przetrwać tak długo? Bo to architektura warstwowa!"
Oczywiście! Dlaczego nie wiedzieliśmy tego od samego początku! Kościół przetrwał, bo to wczesna implementacja stosu OSI!


W czasie 34:16 przedstawia obraz typowego programisty i twierdzi, że programiści to w zasadzie żołnierze, którym najlepiej służy wojskowa struktura, taka, jak armia. Mówi:
"Wszystkie nasze firmy powinny mieć kształt ściśle zhierarchizowanych struktur wojskowych."
Powołując się na paragraf w Podręczniku Marynarki Wojennej, Rozdział 1 : Działania Wojskowe mówi:
"Jeżeli zamienisz słowo 'wojna' na słowo 'oprogramowanie' to to po prostu pasuje! Ponieważ oprogramowanie jest jak walka na wojnie. A więc, koniec z tymi agilowymi bzdurami, spójrzmy na wojsko, jak robią to od tysięcy lat!"
I wtedy. I Wtedy. I WTEDY ...
"Czego nas może to nauczyć? Walka na wojnie nie jest dla starych ludzi! Starzy ludzie, jak ja, nie powinni być w tej branży."
Aby udowodnić swój punkt widzenia pokazuje wykres ze średnim wiekiem piłkarzy światowej klasy, który wynosi 27 lat +/- 1 rok. To ma oczywiste przełożenie na świat oprogramowania. To oczywiste, że twórcy oprogramowania są podobni, w każdy możliwy sposób, do piłkarzy światowej klasy. Te dwie branże są prawie identyczne w swoich celach i demografii. Prawda? Oczywiście.
"Chcę aby traktowano zespoły programistyczne jak zawodowe drużyny sportowe. Pomiędzy 22. a 32. rokiem życia, masz nie robić nic innego, tylko kodować! Koduj 24 godziny, 7 dni w tygodniu. Tak jak profesjonalny sportowiec."
O tak, oczywiście, to ma całkowicie sens. Programiści są wartościowi tylko w tym konkretnym przedziale wiekowym. Po osiągnięciu 32 lat ich ciało daje o sobie znać. Po osiągnięciu tego wieku wszyscy dostają Zespołu Cieśni Kanału Nadgarstka i nie mogą już więcej programować! Oczywiście!
"Wy, programiści, powinniście myśleć tylko o kodzie. Powinniście śnić o kodzie, jeść i pić kod."
I wtedy, następuje ostateczny cios. Mistrzowskie uderzenie. Mem, który wieńczy dzieło:
"Ale to także oznacza, że powinniście zarabiać tyle ile profesjonalny gracz w piłkę. Dlaczego, do diaska, Messi (piłkarz światowej klasy) zarabia szesnaście milionów dolarów rocznie, a ty, który piszesz kod, będąc profesjonalnym koderem oprogramowania tak samo utalentowanym jak Messi, co dostajesz? Sześćdziesiąt tysięcy Euro? Coś koło tego? To śmieszne! A więc powinieneś ruszyć dupę w troki i przez te dziesięć lat zarobić całą tę kasę i wtedy przejść na emeryturę."
Cóż, dlaczego ktoś mógłby odpowiedzieć "nie" na coś takiego?

Geniusz

W prezentacji dr Meijera jest tego więcej. Dużo więcej. Dla przykładu, gdy gdzieś w środku prezentacji mówi o strukturze zespołu i jak gówniany jest Agile, przerywa, aby zaprezentować wstęp do teorii sterowania i automatów Mealy'ego.
Na początku, oglądając Jego szalone wybryki, możesz mieć wrażenie, że troszeczkę odleciał. Potem możesz pomyśleć, że oszalał. Potem zatopisz się w głębi połączonych ze sobą nielogiczności, sprzeczności i emocji. Ale, na końcu, jeśli jesteś bystry, zaczynasz zauważać, że ten człowiek jest absolutnie genialny.
Jest genialny w przeprowadzaniu perfekcyjnej mistyfikacji.
Posłuchaj tłumu. Posłuchaj jak akceptują wszystko, co do nich mówi. Posłuchaj jak ich słabe umysły bezkrytycznie wskakują do tego niekończącego się pociągu śmiesznych pomyłek i nonsensu. Oni to łykają!
Dr Meijer wypełnił te czterdzieści pięć minut kompletnymi bzdurami i wszystkim się to spodobało. A to wymaga geniuszu.
Jestem pewien, że schodząc ze sceny chichotał tak mocno, że zmoczył sobie spodnie.

Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.

Tragedia Rzemiosła

uncle bob label image
Wydajesz się zamyślony.
Tak. Właśnie przeczytałem transkrypcję prezentacji Martina Fowlera otwierającą konferencję Agile Australia 2018. Nazwał to "Stan Agile w 2018".
Aaa, tak, wspaniała prezentacja.
  • Strzeż się Złożoności Agile-Branżowej
  • Dbaj o Techniczną Doskonałość
  • Produkty ponad Projektami
    Fantastyczne treści! No więc, co Cię martwi?

Poniższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.


W tej prezentacji powiedział, że uformowanie się ruchu Software Craftsmanship (Rzemiosła Programistycznego) było tragedią.
Tak. Ma rację.
Ma? Jak to? Myślałem, że Software Craftsmanship było dobrą rzeczą.
O tak, jest. To bardzo dobra rzecz.
No to o co chodzi?
Tragedią jest, że ruch Agile miał promować wartości Rzemiosła; i poniósł porażkę. Sromotną.
Nie rozumiem.
Ruch Agile tak bardzo zaangażował się w promowanie konferencji i certyfikowanie Scrum Masterów i Menedżerów Projektu, że porzucił programistów i porzucił wartości i dyscypliny Rzemiosła.
Ale myślałem, że to programiści zapoczątkowali ruch Agile.
Tak. Tak było. To jest największa ironia. To programiści rozpoczęli ruch Agile mówiąc: "Hej popatrz! Zespoły się liczą. Kod powinien być czysty. Chcemy współpracować z klientem. I chcemy wdrażać wcześnie i często."
Ruch Agile rozpoczęli programiści i profesjonaliści od oprogramowania, którym drogie były ideały Rzemiosła. Ale wtedy wpadli menedżerowie i powiedzieli: "Łaaał! Agile jest nowym sposobem, w jaki możemy zarządzać projektami."
Jest taka stara piosenka napisana przez Alana Shermana, nazywa się "J.C. Cohen". Opowiada o zawiadowcy kolejki metra, który pracował przy upychaniu ludzi do wagonów. Robił to tak dobrze, że wypchnął maszynistę z pociągu. To samo się stało z ruchem Agile. Wepchnęli tak wiele menedżerów, wypychając jednocześnie programistów.
To nie jest dokładnie tak, jak Martin Fowler to opisał. Powiedział, że ruch Craftsmanship powstał, bo grupa programistów powiedziała: "Ooo, potrzebujemy stworzyć całkiem nowy świat dla nas samych [...] gdzie możemy pójść, odejść od tych wszystkich ekspertów biznesowych, menedżerów projektów i analityków biznesowych, żeby móc w spokoju pogadać o sprawach technicznych"
Oooo, nie. Martin odebrał to całkowicie błędnie. Wyraźnie widać z Manifestu Rzemiosła Oprogramowania, że celem Rzemiosła jest podążanie i rozwijanie przesłania Agile. Rzemiosło Oprogramowania to nie jest jakaś forma Technicznych Mokrych Fantazji Nocnych. Rzemiosło Oprogramowania jest po prostu kontynuacją oryginalnych celów Agile.
Rzemiosło to Agile, które ruch Agile porzucił.
Porzucił? Porzucił, żeby robić niby co?
Żeby promować konferencje, certyfikaty, i fajne nowe sposoby zarządzania projektami.
Co jest złego w certyfikatach?
Ujmę to w ten sposób: Każdy, kto zaproponowałby dwudniowy kurs certyfikacyjny z Rzemiosła zostałby wyśmiany i wyrzucony z pokoju, wyśmiany i wyrzucony z miasta, wyśmiany i wyrzucony z kraju. Ten pomysł jest czystym absurdem.
OK, ale jak chcesz mieć ruch bez szumu, certyfikatów, sesji treningowych, konferencji? Czy nie potrzebujesz tych rzeczy, aby pozyskać uwagę ludzi?
Być może. Ale mam nadzieję, że ruch Rzemiosła nie porzuci swojego oryginalnego celu w sposób, w jaki Ruch Agile to zrobił.
Co to za cel?
Oryginalny cel Agile. Widzisz, Rzemiosło nie jest o nowych rzeczach. Rzemiosło mówi o starych rzeczach. Jest o poprawnym działaniu, o dodawaniu wartości, robieniu dobrej roboty. Jest o współgraniu, o komunikacji, o współpracy. Jest o produktywności i reagowaniu na zmiany. Jest o profesjonalizmie i o etyce. Jest o celu, który Kent Beck ustalił dla Agile.
Co to był za cel?
Podczas konferencji Snowbird w 2001 roku, gdzie Manifest Agile był napisany, Kent Beck powiedział, że jednym z naszych celów jest zasypanie przepaści pomiędzy programistami i zarządzającymi.
Ruch Agile porzucił ten cel przekształcając Agile w biznes, który promuje "nowy-lepszy" sposób zarządzania. Zamiast zbliżać do siebie programistów i menedżerów, Ruch Agile skupił się niemal w całości na zarządzaniu projektem - praktycznie wykluczając programistów.
I dlatego programiści się odłączyli?
Nie! Programiści się nie odłączyli. Programiści zostali na starym kursie! Programiści kontynuowali oryginalnie zapoczątkowane dążenie Agile. Przeczytaj zdanie otwierające Manifest Agile: "My odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych." My to znaczy Rzemieślnicy i Rzemieślniczki Oprogramowania, którzy kontynuują tę pracę. Nie menedżerowie projektów w ruchu Agile. Oni gonią za czymś innym.
Za czym więc oni gonią?
Za Nowością i Nowinkami. Dzisiaj ruch Agile jest o "Następnej Wielkiej Rzeczy" o "Całkowicie Nowej, Śmiałej Idei". Potrzebują nowości, żeby utrzymać poziom entuzjazmu i energii  bardzo wysoko. Potrzebują tego, aby ludzie zapisywali się na konferencje i certyfikaty. Chcą być postrzegani jako robiący - "postępy". Agile stał się biznesem; a biznes musi rosnąć.
Wydaje mi się, że osiągają sukces.
Osiągają. Nie osiągają jednak sukcesu w dziedzinie oryginalnych celów Agile. Porzucili te cele, aby zaspokajać potrzebę Nowości i Nowinek. Wynikiem jest, niestety, coś, co Fowler i Jeffries nazwali: "Błędnym Agile", "Mrocznym Scrumem", czy "Zwiotczałym SCRUMEM"
Ciężko mi w to uwierzyć.
Udowodnię Ci to. Co było pierwszym punktem prezentacji Fowlera - punkt o Złożoności Agile-Branżowej.
Powiedział coś, że ludzie najlepiej pracują, kiedy wybierają, w jaki sposób chcą pracować.
No właśnie. W zespole programistycznym, kto odwala najwięcej roboty?
Cóż, programiści oczywiście.
Jak dużo programistów było na sali podczas prezentacji Fowlera?
Cóż, użył słów "namiastka", "niewielu", "na pewno mniejszość".
C.n.d.. Kto chodzi na konferencje Agile? Na pewno nie programiści. Nie ludzie, którzy robią całą robotę. Programiści zapoczątkowali te konferencje. Programiści zapoczątkowali ruch. Programiści już tam nie chodzą. To nie programiści się zmienili. To konferencje, i co za tym idzie ruch się zmienił. Ruch Agile odszedł od programistów - odszedł od Agile. C.n.d..
Ale...
Zobacz. Agile nigdy nie było o zarządzaniu projektem; ale to jest to, w co to zamienili. Agile i zarządzanie projektem to całkowicie rozłączne rzeczy. Agile nie jest lepszym sposobem na zarządzanie projektem. Agile nie ma nic wspólnego z zarządzaniem projektem. Agile to zestaw wartości i dyscyplin, które pomagają relatywnie małym zespołom rzemieślników i rzemieślniczek oprogramowania tworzyć małe do średnich systemy.
Ale, czy to nie jest zarządzanie?
Nie! Na Boga Nie! Zarządzanie Projektem jest o datach, budżetach, deadlinach i kamieniach milowych. Jest o zarządzaniu personelem i motywacji. Dobre zarządzanie jest absolutnie potrzebne; ale nie ma nic wspólnego z Agile.
Tu masz. Spójrz na Manifest Agile. Przyuważ te cztery zdania i w jaki sposób są podzielone pomiędzy lewo i prawo. Co rozdziela od siebie te rzeczy po lewej i prawej stronie? Rzeczy po prawej stronie to zarządzanie. Rzeczy po lewej stronie to Agile. Menedżerowie odwołują się do procesów i narzędzi. Osoby w zespole Agile komunikują się ze sobą. Menedżerowie utrzymują wszechstronną dokumentację. Drużyny Agile budują działające oprogramowanie. Menedżerowie negocjują i ustalają kontrakty. Zespoły Agile współpracują z klientem. Menedżerowie upewniają się, że plany są wykonywane. Zespoły Agile reagują na zmiany.
No, ale czy Scrum Masterzy to niejako menedżerowie projektu?
O niebiosa, nie! Scrum Masterzy to doradcy, a nie menedżerowie. Ich rolą jest bronić wartości i dyscyplin. Ich rolą jest przypominać zespołowi, w jaki sposób przyrzekł sobie samemu pracować. Rola ta miała być dzielona pomiędzy zespół, a nie zawłaszczona przez menedżerów. Co kilka tygodni nowy członek zespołu mógłby, na ochotnika, pracować jako doradca - jeżeli byłaby taka potrzeba. Rola miała być tymczasowa. Dorosły zespół nie potrzebuje doradcy na pełny etat.
Łaaał, z całą pewnością teraz nie uczą tego w taki sposób. Czyli sądzisz, że to już koniec Agile.
Nie! Agile żyje, ma się dobrze i kwitnie w sposobie myślenia Rzemiosła. To tam Agile przeniosło się, kiedy menedżerowie projektu najechali i wzięli w niewolę ruch Agile.
No to czym naprawdę jest ruch Agile?
Dzisiaj, ruch Agile mógłby być nieoficjalną odnogą PMI. To jest biznes, który promuje konferencje, kursy i certyfikacje dla menedżerów projektu. A więc, jako takie, stało się przeciwieństwem do oryginalnego celu Beck'a. Ruch agile nie zasypuje przepaści pomiędzy programistami i menedżerami; on ją pogłębia.
Wydaje się, że chcesz powiedzieć, że ruch Agile nie jest Agile.
Nie jest. Stało się to już dawno. Dzisiaj ruch Agile jest o okropnie poronionym pomyśle mówiącym, że to zarządzanie projektem czyni zespół Agile.
Cóż, nie jest tak?
Nie, nie i jeszcze raz nie. Widzisz, zespół Agile to grupa rzemieślników i rzemieślniczek, którzy utrzymują wartości i dyscypliny drogie Agile. Zespół Agile będzie Agile, nie ważne w jaki sposób będzie zarządzany. Z drugiej strony zespół Agile nie stanie się Agile dzięki jakiejś nowej i fajnej strategii zarządzania projektem. Taki zespół będzie Błędnym Agile.
Czy chcesz powiedzieć, że dobry menedżer nie może poprowadzić zespołu, żeby był Agile?
To rzadko spotykany menedżer, który potrafi wpajać wartości i dyscypliny Rzemiosła. To nie jest niemożliwe; ale jest nieczęste. Zespoły Agile są najczęściej złożone z ludzi, którzy już podzielają wartości i dyscypliny Agile - wartości i dyscypliny Rzemiosła. Myślenie, że zespół może stać się Agile tylko dlatego, że Certyfikowany Scrum Master jest menedżerem projektu to marzenie ściętej głowy.
A więc, jaka będzie przyszłość?



Przyszłością będzie to, co było do tej pory zawsze. Wartości i dyscypliny Agile będą pomagały relatywnie małym zespołom programistycznym budować produkty od małych do średnich, i będą zasypywać przepaść dzielącą programistów i zarządzających. Dzisiaj, te wartości i dyscypliny są dochowywane przez ludzi, którzy, czy zdają sobie z tego sprawę czy nie, są związani z ideałami ruchu Software Craftsmanship.
Nie sądzę byśmy potrzebowali promowania ruchu Rzemiosła na poziomie organizacji. Nie sądzę, że potrzebujemy "Stowarzyszenia Rzemiosła". Myślę, że wszystko, czego potrzebujemy, jako ludzie dobrej woli - osoby, które wchodzą w interakcje i współpracują - to społeczność profesjonalistów, którzy pracują nad promowaniem zmian poprzez stałe dodawanie wartości. Myślę, ze idee Agile - idee Rzemiosła - są solidne na tyle, żeby rosnąć i rozprzestrzeniać się bez pomocy ze strony jakiejkolwiek organizacji.
A więc Rzemiosło Oprogramowania nie było tragedią?
Jak mogłyby ideały Rzemiosła kiedykolwiek być rozważane jako tragiczne? Są to odwieczne ideały, do których ludzie dążyli, odkąd stali się ludźmi. Tragedią było to, że ruch Agile stał się biznesem, który cisnął za siebie oryginalne wartości i dyscypliny Agile.


Powyższy tekst jest luźnym tłumaczeniem wpisu bloga Roberta Cecila "Wujka Boba" Martina ze strony :


Proszę o komentarze, jeżeli ta luźność jest zbyt daleko posunięta.