Friday, December 28, 2018

Dwie zasady skutecznego rozwiązywania problemów w prezencie noworocznym

Bez zbędnych wstępów.

Zasada 1.

Niemal każdy dylemat ma co najmniej dwa rozwiązania: dobre i praktyczne. Najczęściej są one od siebie różne.

Przykład: Znajdujesz się na skrzyżowaniu równorzędnym, który samochód ma pierwszeństwo? Jeśli odpowiedziałeś, że ten z prawiej, to masz rację. To dobra odpowiedź. Odpowiedź praktyczna jest taka, że pierwszeństwo ma ten większy...Samo życie.

Jeśli zatem przychodzą do Ciebie manager i Scrum Master z dylematem typu "czy dorzucanie zadań do sprintu jest adżajlowe, czy nieadżajlowe", to nie bierz udział w tej dyskusji. Zamiast tego pomóż im rozwiązać najbardziej palący aktualnie problem. Dobrze słyszałeś - zadanie kilku efemerycznych pytań o wartości Scruma nie wystarczy. Trzeba będzie doradzić, pokazać, albo część zrobić samemu.

Żeby przeanalizować czy coś jest dobre czy niedobre, potrzeba spokojnej głowy i refleksyjnego nastroju. Gwarantuję, że gdy zejdzie ciśnienie, związane z bieżączką, kwestię adżajlowości swojej pracy rzeczeni manager i SM rozwiążą sobie sami.

Zasada 2.

Albo inaczej nieskromnie - Wielkie Twierdzenie Bartyzela: "Każdy problem da się tak steoretyzować, że nie będzie istniało jego rozwiązanie, możliwe do znalezienia za pomocą aktualnie znanych metod badawczych".

Nie daj się wciągnąć w dywagacje "a jeśli mamy dużą liczbę transakcji na sekundę, która będzie przyrastać dość szybko, to XYZ, będzie lepsze niż ŃŚĄ". Niemal zawsze polegniesz.

Zamiast tego proś o konkretne kejsy i rozwalaj przypadek po przypadku. Pamiętaj, że hipotetyczne problemy mają hipotetyczne rozwiązania. Konkretne problemy mają rozwiązania konkretne.

Managerowie zagadują mnie często: "Czy manager może być Scrum Masterem?". Kilka razy zdarzyło mi się odpowiedzieć: "Nie, ale ty możesz". Case-by-case.

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ć