Wednesday, October 31, 2018

Odpowiedź: 42

Świat IT jest pełen odpowiedzi...
  • Jak pisać czytelniej? Dzielić algorytmy i metody na mniejsze kawałki. Pisali o tym McConnell, Beck, Martin.
  • Jak radzić sobie implementacją złożonego procesu? Można wydzielić współpracujące ze sobą obiekty. Pisał o tym Meyer.
  • Jak okiełznać złożoność domenową? Można zastosować wyróżnić bounded contexts itd. Pisali o tym Evans, Vernon, Dahan, Young i inni.
  • Jak dokładniej testować? Pisać mniejsze testy skupione na konkretnym zachowaniu. To, akurat mówią wszyscy...
  • Jak poprawić trafność oszacowania? Można dekomponować na podzadania. Pisał o tym McConnell.
  • Jak ogarnąć mega złożone interfejsy UI? Podzielić ma mniejsze lepiej zarządzalne kawałki i skomunikować między sobą. Zrobili np. w robotlegs framework.
  • Jak skalować agility? Zacząć od skalowania produktu i podzielenia go na mniejsze podprodukty. Mówili o tym Poppendieckowie.
  • Jak poprawić swoją efektywność. Skupić się na mniejszej ilości spraw. To tłuką na konferencjach bez litości.
  • Jak uniknąć kosztownego refaktoringu i mądrzej ogarnąć architekturę? Wydzielić odpowiednio małe microserives. Mówił o tym Young.
  • itd.
Wymienione odpowiedzi są pożyteczne, ale chyba gdzieś umknęło pytanie. Otóż podstawowym pytaniem, z którym boryka się uniwersum IT jest pytanie o granulację. Ile to jest mało, ile dużo, a ile odpowiednio?
Jaki serwis będzie OK, a jaki za duży? I w jakim stopniu zależy to od kontekstu?

Kłopot w tym, że żadne z wymienionych odpowiedzi, ani chyba też żadne, które znamy, nie adresuje tego podstawowego pytania.

Wednesday, October 24, 2018

Dzięki za 4Developers w Łodzi!

Nie ma co ukrywać ścieżka Soft Skills & Business Relations wyszła świetna. Przez większość slotów sala była nabita ponad wymiar.

Dziękuję prelegentom za przygotowanie prezentacji. Szczególnie dziękuję za sumienne potraktowanie naszej prośby o przemyślenie take aways z prezentacji.

Z mojej strony "utrzymać":
  • formułę krótkich prezentacji; planowaliśmy 12 min. wyszło ~15; wiem od prelegentów, że to trudne zmieścić ogrom swojego doświadczenia w tak krótkim czasie; robiłem sobie jednak losowe exit poll śród uczestników - ta forma bardzo im odpowiada; zarekomenduję Proidei utrzymanie takiej formy ścieżki
I "do zmiany":
  • musimy poprawić timing; przerywanie prelegentowi nie jest miłe ani dla jednej ani dla drugiej strony; uwierzcie mi jednak, że uczestnicy tego oczekują i zgłaszali nam takie prośby w trakcie konferencji;
  • Od wielu prelegentów dostałem prośbę o feedback nt. ich wystapień; mam taki pomysł, aby na najbliższym 4Developers każdy z prelegentów mógł go otrzymać o ile wcześniej wyrazi taki życzenie; będę uczestniczył we wskazanych wystąpieniach jako obserwator, robił notatki i przekażę prelegentowi/prelegentce swoje obserwacje: start-stop-continue
  • kolejny pomysł polega na tym, aby prelegent, który otrzyma najlepsze noty od uczestników został poproszony na kolejnym wydaniu konferencji o rozwinięcie swojego tematu w dłuższym slocie np. 30-45 min. Skoro uczestnicy deklarują, że chcą go/jej słuchać, to idźmy za tym
  • na końcowych talkach ubywało osób głównie z tego powodu, że niektórzy wyjeżdżali; nie wiem co z tym zrobić

Friday, October 12, 2018

Zwinność kulturowo rozmiękczona

Tu, nad Wisłą, ze zwinnością (agility) wydarzyło się coś niedobrego. Zapraszam to krótkiej rozkminki.

Weźmy taki cytat ze Scrum Guide (dotyczy on roli Product Ownera): "The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable."

I z polskiego tłumaczenia: "Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu pozostaje za nie odpowiedzialny"

Dostrzegasz coś intrygującego?

responsible vs. accountable

Responsible oznacza odpowiedzialność w takim sensie, że ktoś ma coś w swoich obowiązkach, bo na przykład zostały mu te obowiązki przydzielone.

Accountable oznacza mocniejszy rodzaj odpowiedzialności np. prawnej, czyli odpowiedzialności za konsekwencje.

Zatem tłumaczenie oddające sens angielskiego zdania powinno brzmieć: "Właściciel Produktu może wykonywać powyższe zadania samodzielnie lub zlecać je Zespołowi Deweloperskiemu, jednak to Właściciel Produktu zostanie z nich rozliczony". Jedno słowo wiele zmienia, co?

Podobnie rzecz się ma Zespołem Deweloperskim: „Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.”

Zatem Zespół Deweloperski zostanie rozliczony za brak przyrostu (increment) produktu na koniec sprintu.

Niuans kulturowy

Moim zdaniem mamy tu do czynienia z różnicą kulturową. Anglosaska - jak mniemam - prosta i konkretna zasada rozliczenia została w polskim tłumaczeniu rozmyta i rozmiękczona w ogólną odpowiedzialność.

Zgaduję powód. Sęk w tym, że rozliczyć ma w języku polskim mocno pejoratywne konotacje. "Rozliczę cię" oznacza mniej więcej tyle: "Słuchaj gościu, jak coś pójdzie nie tak, to ty za to bekniesz. Poniał?"

Głębiej o accountability

Powiem więcej. "accountability" oznacza taki rodzaj (silnej) odpowiedzialności (za konsekwencje), który został przyjęty dobrowolnie. Na przykład CEO jest accountable za organizację i zostanie rozliczony za ew. sukcesy i nieprawidłowości. Ważne jest to, że on o tym wiedział od samego początku i zgodził się na to "rozliczanie" w momencie przyjęcia nominacji.

W tak rozumianym rozliczaniu nie ma nic negatywnego. Ktoś otrzymuje pełnię władzy: przywileje oraz konsekwencje. Prosty deal.

Czego chce Scrum?

Posługując się już przedefiniowanymi wyżej pojęciami, można powiedzieć, że Scrum chce od swojego praktyka pewnej dojrzałości.

Chce, aby PO, DevTeam czy SM, zanim podejmą decyzję, że używają Scruma, zatrzymali się na moment. Niech się zatrzymają, popatrzą na możliwe przywileje, na potencjalne konsekwencje i świadomie powiedziedzą: "Tak, chcę być rozliczony za swoją pracę."...albo nie.

Rzecz jasna możliwość rozliczania implikuje ze strony organizacji konieczność przydzielenia autonomii, decyzyjności i tak ogólnie nie wpieprzania się w paradę.

Kolorowy coach

Tu kudos dla Bartka za insight.

Weźmy jeszcze jeden cytat na temat tego, co tam Scrum Master powinien: "Coaching the Development Team in self-organization and cross-functionality"

I po polskiemu: "Coachując Zespół Deweloperski w zakresie wykorzystania zasad samoorganizacji i międzyfunkcyjności".

No więc rzucili się ludzie na kursy kołczigu i adżajkołczują. No, ale looknijmy sobie na OxfordDict czymże jest ten coaching?

O, żesz w mordę, madafaka! Co ja paczę???

  • "Train or instruct (a team or player)"
  • "Teach (a subject or sport) as a coach"
  • "Give (someone) instructions as to what to do or say in a particular situation"
  • "Give (someone) professional advice on how to attain their goals"

Zatem jeśli Scrum Master coach Zespół Deweloperski, to oznacza, że ten Scrum Master jest naumiany Scruma i generalnie ogarnia temat. Następnie jego zadanie polega na tym, aby nauczyć Scruma zespół. No i może ludzi poza zespołem, przynajmniej na takim poziomie, żeby kumali o co chodzi.

Nie oznacza to, że statutową metodą pracy Scrum Mastera jest "metoda coachingowa", czyli zadawanie pytań tak, aby delikwentom samo wyjajiło się, co im dolega. Może to robić, jak będzie ku temu powód. Moje doświadczenie podpowiada mi jednak, że takich chwil jest naprawdę niewiele.

Nawiasem mówiąc "metoda coachingowa" zakłada, że klient ma pełnię kompetencji do rozwiązania swoich problemów. No więc życzę powodzenia w pracy tą metodą, gdy zespół nie zna i nie umie Scruma.

Ej, a wiecie jak deweloperzy mówią na takich adżajlkołczów, co to w każdym próbują znaleźć wewnętrzne dziecko i proszeni czy nie proszeni serwują sesje coachingowe tuzinami? "Kolorowe pisaki"...sam słyszałem.

Także, ten...wyluzuj. Po prostu wyluzuj.

Continuous attention to technical excellence...

No więc jak taki #kolorowyCoach w pośpiechu przygotowuje się do certyfikatu, to czytając po łebkach adżajlmanifesto, skupia się tylko na wartościach, zapominając, że jest tam też parę bardziej szczegółowych wytycznych.

Między innymi taka: "Continuous attention to technical excellence and good design enhances agility". O co chodzi?

Coraz częściej dochodzę do wniosku, że pierwszym blokerem do uzwinnienia się jest architektura. Co z tego, że nasz supersystem powstał w sprintach i nawet miał wizję i rołdmapę, skoro to monolit liczący 2MLOC?

Gdzieś popełniliśmy błąd. W którymś momencie zwinność odkleiła się od technologii i stała się wyłącznie: kulturą, mindsetem i procesem.
Tak się nie da.

Biznes dzieje się szybko. Żeby szybko produkować dla tego biznesu potrzeba metod, architektur, technologii i skilla, które umożliwią osiągnięcie tej szybkości. Bez tego zostają tylko kolorowe pisaki...

A na deser międzyfunkcjonalność

W oryginale: "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment"

I w rodzimym dialekcie: "Zespoły Deweloperskie są międzyfunkcjonalne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu."

Nie wiem czy tylko ja wymiękam z tą "międzyfunkcjonalnością"?

Neologizm - jak przypuszczam - "międzyfunkcjonalność" należałoby rozumieć przez analogię do np. "międzywydziałowości", czyli jako coś co się dzieje "pomiędzy granicami wyznaczonymi przez funkcjonalności". Czy ja wiem?

Jeśli już kuć nowe słowa, to ideę oddawałoby "pełnokompetentny": "Zespoły Deweloperskie są pełnokompetentne, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu." Ewentualnie "pełnoumne" :)