Wednesday, March 20, 2013

Po 33rd Degree '13

Nastrój konferencji był mocno filozoficzny. Niewiele tematów technicznych za to dużo ontologicznych rozważań kim jesteśmy? dokąd zmierzamy? i po co?. Tematy konferencyjne są zazwyczaj odzwierciedleniem nastrojów w branży. Zatem skoro krążą nam po głowach takie pytania, to dobrze że temat został podjęty. Poniżej moje osobiste wrażenia z prelekcji, w których uczestniczyłem.

Decisions Decisions, Dan North

Dla mnie osobiście, to była kwintesencja tej konferencji. Po ponad 10 latach Agile przeszedł z fazy buntu przeciw istniejącemu porządkowi i odrzucania autorytetów w fazę stabilizacji i wydoroślał. Zamiast kategorycznego "nie" przeciw owym "starociom", często mówi się "nie zawsze (...)", "nie, ale (...)", "czasem (...)".

W moim odbiorze ta prelekcja była ostrzeżeniem, abyśmy nie skupiali się fanatycznie na tym czy innym podejściu lecz przede wszystkim na sprawach klientów, które należy rozwiązać. W jednym zdaniu odebrałem to tak: "nie powiem Ci czy masz używać tdd czy nie, czy us czy uc, czy pisać testy czy nie(...) wszystko zależy od tego, co chcesz zrobić, dla kogo i po co".

Busy Developer's Guide to Iconoclasm, Ted Neward

Transformational Leadership nazwany inaczej z elementami retoryki w stylu Anthonego Robbinsa. Miał być wykop na początek i był. Jednak najbardziej zapamiętałem nazwanie jednego z uczestników idiotą. Zgrzytnęło mi w głowie po raz pierwszy.

Leading Technical Change, Nathaniel Schutta

Słowo "technical" jest tu opcjonalne. Jeśli planujesz wprowadzić zmianę w organizacji, to po pierwsze musisz zbudować koalicję rzecz zmiany. Po drugie musisz nieustannie informować ludzi, co robisz, bo inaczej będą wykonywać nerwowe ruchy. Bez umiejętności interpersonalnych i small talks się nie obejdzie. Dobrze by nam zrobiło, gdybyśmy zajrzeli do całych tomów dorobku konsultingu, chociażby tutaj. Naprawdę, te rzeczy już zostały wymyślone i sprawdzone. Nie ma potrzeby wymyślać ich na nowo.

Software quality – you know it when you see it, Erik Dörnenburg

Absolutna rewalacja! Prezentacja referencyjna, sam konkret, przykłady, jasne i klarowne. Sam Erik stwierdził, że żaden z tego "rocket science". Dla mnie był. Do tej pory brakowało mi czegoś co pozwoli rzucić okiem na tony kodu, porównać ze sobą jakość kodu w modułach, projektach między zespołami. Nie żeby dawało od razu odpowiedzi, ale żeby mieć ogólne rozeznanie w jakości kodu i szybko namierzać podejrzane miejsca. Tabelki ze wskaźnikami metryk nie są dla mnie specjalnie czytelne, a przedstawione wizualizacje bardzo. Dzięki!

Pragmatic Architecture, Ted Neward

Przestawienie myśli Scotta Amblera , a przede wszystkim postulatu There is nothing special about architecture. Ciekawa była definicja architektury: architektura to zbiór odpowiedzi, na które musi odpowiedzieć sobie programista, gdy tworzy software.

W trakcie prelekcji skupiałem się przede wszystkim na formie przekazu, którą stosuje Ted, nie na treści prezentacji. Zgrzytnęło mi w głowie po raz drugi. Ted Neward buduje kontakt ze słuchaczami za pomocą metafor, historyjek i żartów opartych przede wszystkim na różnicowaniu nas (IT, programistów) od nich(ludzi biznesu), na podkreślaniu jak bardzo się różnimy od siebie i jakie absurdalne może wydawać się innym to, co robimy ("programowanie to fikcja", "normalni ludzie tak nie robią"). Różnicując się z "nimi", Ted automatycznie buduje poczucie wspólnego "my" z uczestnikami na zasadzie "też jestem taki dziwny jak wy". I to działa, ludzie to kupują i rechotają z jego żartów.

Dlaczego na to zwracam uwagę? Dlatego, że nie w ten sposób ja rozumiem Agile. Różnicowanie się od "nich" i wprowadzanie Linii Maginota "My IT-oni biznes" to nie jest to, o co moim zdaniem w Agile chodzi. To zupełnie, ale to zupełnie odwrotnie. Mamy z biznesem współpracować, wychodzić do niego, a nie się z nim różnicować i podkreślać swoją odrębność. Jeśli Ted robi to celowo, aby mieć drive na widowni, to ok, ale ja tego stylu nie kupuję. Jeśli nie robi tego celowo, to gdzieś tu...no właśnie...zgrzyta.

Managing gang of chaotic software developers is complex, Piotr Burdyło

No, jeśli to rzeczywiście tak działa, jak zostało przedstawione to szacun. Zarządzanie przez wartości, wizję i Autonomy-Mastery-Purpose w całej firmie. Super, że takie rzeczy możliwe są też nad Wisłą. Chętnie usłyszałbym o innych firmach, które tworzą u siebie organizację tego pokroju. Na następnej konferencji chętnie posłucham o problemach podczas wdrażania.

The deconstruction of architecture in times of crisis, Jarosław Pałka

Również rozwinięcie myśli Scotta Amblera wzbogacone o ideę myślenia systemowego. Wbrew deklaracjom Autora, żarty wcale nie były niskiej jakości:) Prezentację można by streścić w słowach pewnego prezesa kierowanych do dyrektorów: "Myśleć, k**a, myśleć!".

Po słowie

Dziękuję tym, którzy podarowali mi godzinę swojego czasu i przyszli na moją prezentację. W przerwie, Piotrek zwrócił mi uwagę, że w przedstawiłem DDD w zbyt wykrzywionym kontekście (dzięki!), a potem powiedział ważną rzecz: musisz dobrze opanować, te wszystkie techniczne sprawy, żeby potem móc je zostawić i pójść dalej.

Przypomniało mi to film Hero i wypowiedź jednego z bohaterów na temat czym jest mistrzostwo miecza?.

Pierwszym celem tego kunsztu jest osiągnięcie jedności człowieka z mieczem.
Gdy zjednoczenie ma miejsce, nawet źdźbło trawy może być śmiertelną bronią.
Drugi etap następuje, gdy miecz jest niesiony w sercu,gdy nie ma go w dłoni.
Wtedy można atakować przeciwnika ze 100 kroków, nawet z gołymi rękoma.
Ostatecznym celem szermierskiej sztuki...jest całkowita nieobecność miecza, zarówno w sercu, jak i w dłoni. Taki szermierz pozostaje w harmonii z resztą świata. On nie chce zabijać. On sprowadza ludziom pokój


To jest właśnie to! Core mojej prezentacji! Jakiś czas temu miałem wystąpienie dla łodzkiej JUG pt. Od kodera przez developera do lidera


Przedstawiałem między innymi nasze perspektywy patrzenia na rozwój programisty, na których opieramy swoje usługi. Między innymi o tym, że na strukturę rozwoju programisty można patrzeć jak na warstwy: technologiczna, inżynieryjna, miękka. Podobnie jak w cytacie z filmu pierwszym krokiem mistrzostwa jest mistrzostwo w języku programowania, bibliotekach, frameowkrach, technologii. Wymiatamy. Lecz jeśli zatrzymamy się na tym etapie, to w pewnym momencie będzie to tylko (jak to zgrabnie pewien prelegent mawia:)) technologiczny...zabawa...

Potem tracimy zainteresowanie gadżetami, skupiamy się na bardziej abstrakcyjnych ideach. Drugim stopniem mistrzostwa jest mistrzostwo we wzorcach, czystym kodzie, omawianych podczas prezentacji frameworkach mentalnych w stylu *-Driven *. To naprawdę fantastyczne narzędzia. Lecz zatrzymanie się na nich prowadzi do uprawiania sztuki dla sztuki.

To jednak nie koniec. W pewnym momencie, opanowawszy te wszystkie rzeczy, możemy się od nich oderwać. Zapakować do zasobnika jako użyteczne narzędzia i pójść w kierunku biznesu i ludzi.

To właśnie z tego powodu napisałem książkę. Książkę o brakującym klocku w TDD, BDD, DDD, itd, o sztuce zadawania pytań. Sądzę, że tylko wychodząc w stronę biznesu i spotykając klientów i użytkowników tam, gdzie oni są, możemy zrobić prawdziwie dobry użytek ze całego nagromadzonego warsztatu. Wtedy przestajemy już programować, a zaczynamy pomagać ludziom. To ogromna różnica!



9 comments:

  1. Bardzo dobra była Twoja prezentacja. Mam w zwiazku z nią pytanie, bo przedstawione zostały 4 książki stanowiące tzw. kanon. Jedną z nich były wzorce Gang of Four. A trzy pozostałe ?

    ReplyDelete
  2. Hej, dzięki

    Poniżej książki, ale tak jak starałem się przedstawić: książki, książkami i warto jest znać, ale rozwijanie swojego doświadczenia jest ważniejsze:

    * Pattern-Oriented Software Architecture Vol 4 (i jako uzupełnienie Vol. 1, Vol. 2, Vol. 3), Praca zbiorowa
    * Patterns of Enterprise Application Architecture, Martin Fowler
    * Enterprise Integration Patterns, Gregor Hope

    A poza tym:
    * Essential Software Architecture, Ian Gorton
    * Server component patterns, Markus Volter
    * Domain-Driven Design, Eric Evans
    * Agile Software Requirements, Dean Leffingwell
    * Scaling Lean & Agile Development, Craig Larman
    * Beatifull Architecture, Diomidis Spinellis

    I na deser Lean Architecture Copliena

    ReplyDelete
  3. Można się spodziewać, że za jakieś 2-3 lata ktoś napisze książkę: "Zadawanie pytań niczego nie zmieni - jak pracować z quasi-programistami po kursie NLP, którzy nie znają podstawowych technik i narzędzi inżynieryjnych oraz frameworków mentalnych":PPP

    Później pewnie ktoś zauważy, że nie każdy chce/może zadawać pytania i po pewnym czasie stopniowo znowu wrócimy do przed-agilowego rozdzielenia kompetencji: analityk biznesowy, analityk systemowy, architekt korporacyjny, architekt rozwiązań, architekt systemowy, projektant, developer, koder, tester, wdrożeniowiec. A później znowu ktoś zacznie odciążać, itd, itd, itd...

    Widzę tutaj analogię do sinusoidy ilustrującej skrajności w epokach literackich.

    A nie można by tak mniej faszystowsko, więcej naturalnego balansu i podejścia do indywidualnego człowieka oraz zastanowienia się co, kiedy i po co...

    Ale tutaj mamy znowu błędne koło, bo aby wybrać trzeba mieć z czego, czyli potrzeba doświadczenia. A jak go nie ma, to cóż czynić? Instynktownie ufamy komuś/czemuś co wzbudza zaufanie i próbujemy naśladować... z czasem zacznie wychodzić...

    ReplyDelete
  4. @Sławek

    No, gdybyś był na prezentacji, to wiedziałbyś, że piszesz nie na temat i wbrew temu co mówiłem :)

    ReplyDelete
  5. Zgadza się, bo właściwie impulsem do komentarza była poranna lektura artykułu z programistamag - założyłem (sugerując się tytułem), że treść była zbieżna.

    Więc może bardziej ogólny komentarz: skąd wiadomo, że coś czegoś nie zmieni, a co innego coś zmieni?

    Czy stoją za tym badania na większych próbkach i analizy czy jedynie "wewnętrzne przeczucia" (badania metodą naukową są potrzebne po to aby zweryfikować takie zdroworozsądkowe przeczucia jak to, że Ziemia jest płaska i krąży wokół niej Słońce)?

    ReplyDelete
  6. @Sławek
    "Więc może bardziej ogólny komentarz: skąd wiadomo, że coś czegoś nie zmieni, a co innego coś zmieni?"

    Oj, drugiej części zdania to ja nie powiedziałem, ani też nie napisałem. W prezentacji mówiłem o priorytetach: (1) Najpierw świadomie buduj swoje doświadczenie projektowe (2) Potem korzystaj z narzędzi, technologii i tych frameworków mentalnych. Gdy tracisz te priorytet to też robi się z tego (jak ty to ujmujesz)..."zabawa" lecz nie technologiczny lecz na wyższym poziomie. W drugiej części artykułu opisaliśmy po prostu rozwiązania jakie obserwujemy. Nie wymyśliliśmy tego.

    "Czy stoją za tym badania na większych próbkach i analizy czy jedynie "wewnętrzne przeczucia"

    Takie same jak za wszystkimi tymi rzeczami, o których piszemy. Czyli najpierw mamy sformułowanie problemów, następnie sformułowanie hipotezy, potem informowanie o tym ludzi, a gdy się uznają, że te problemy występują u nich, to dopiero zaczynają się badania. O ile kojarzę to taka była ścieżka TDD. Jeśli na inne *-Driven* istnieją "naukowe" dowody, to chętnie poznam. W tej chwili mamy projekty, w których nasze podejście po prostu działa i problemy, które rozwiązało i widzimy w tym bardzo dużą powtarzalność. Czyli jest to mniej więcej tyle ile mieli ludzie o wielkich nazwiskach, a więc własne doświadczenie i priczing. Bez "badań" mogłeś zaufać im. Zaufaj i nam :)

    ReplyDelete
  7. Dzięki za wyjaśnienie... chyba jednak na początku nie zadałem sobie trudu aby zrozumieć co autor (Ty) miał na myśli i z pychą podszedłem do tematu myśląc, że rzutem oka ogarnę czyjeś kilkuletnie przemyślenia, po czym zbuduję ich słomiany model aby z łatwością je obalić:PPP

    "szejm on mi"

    No ale dobrze, że miałeś szansę się wybronić. Inni autorzy jej nie mają...

    Ale na poważnie:
    1. cieszy mnie, że obserwuję zmianę stanowiska w stosunku do ostatnich postów: z ataku na x-Driven do "wchłonięcia" i taktowania jako podbudowy do produktu
    2. odnośnie ostatniego akapitu: gdzieś chyba ostatnio czytałem o możliwym błędzie w sytuacji gdy dokonujemy indukcji na podstawie ograniczonych próbek swych doświadczeń a później dokonujemy dedukcji poza te doświadczenia (brzmiało to sensownie)

    ReplyDelete
  8. @Sławek
    "1. cieszy mnie, że obserwuję zmianę stanowiska w stosunku do ostatnich postów: z ataku na x-Driven do "wchłonięcia" i traktowania jako podbudowy do produktu"

    Cwaniak:)Nie było moją intencją krytykować DDD jako takiego, lecz "magiczne myślenie" o nim, które jak wiesz jest gęsto uprawiane; "no silver bullet" po prostu; oczekiwałbym zawsze wyraźnego podkreślania kontekstu: kiedy warto? kiedy nie? kto może? a kto zrobi sobie krzywdę? i że wbrew ambicjom nie wszyscy będą pisać core domain, lecz tylko wybrańcy:)

    "2. odnośnie ostatniego akapitu: gdzieś chyba ostatnio czytałem o możliwym błędzie w sytuacji gdy dokonujemy indukcji na podstawie ograniczonych próbek swych doświadczeń a później dokonujemy dedukcji poza te doświadczenia (brzmiało to sensownie)"

    Tu mnie masz:) Tak, to prawda, ale dyskusja na blogasku czy przy okazji artykułu rzuca mi więcej światła na słabe punkty tego co napisałem. Lepiej pomylić się na blogu niż na konferencji albo w książce.

    ReplyDelete
  9. @1: ja wcale nie obserwuję żadnego magicznego myślenia wokół DDD czy BDD. Wokół TDD owszem, jakiś czas temu bywały takie "zjawiska". A z moich obserwacji w DDD czy BDD wchodzą głównie ludzie/zespoły/organizacje wręcz krytycznie nastawione do branży jako takiej, więc ich nastawienie jest raczej typu: "może coś z tego wykorzystamy i w jakimś stopniu się przyda".

    @2: no tak, każda dobra "technika" to miecz obosieczny, więc świadczy to tylko o Twoim kunszcie i dodatkowo umiejętności jej przedstawienia (mam na myśli ostatni artykuł w programistamag)

    ReplyDelete