tag:blogger.com,1999:blog-17599162146380097072024-03-13T12:04:18.409+01:00Getting Things Programmed<em>Be mindfully present, utilize whatever happens, and do what you say</em>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.comBlogger205125tag:blogger.com,1999:blog-1759916214638009707.post-85183231148142470892019-02-07T12:19:00.000+01:002019-02-07T12:19:53.205+01:00Krótkie oświadczenieOświadczam, że z bloggera znikają mi czasem komentarze i nie mam bladego pojęcia dlaczego.<br />
Tak więc sorry, taki mamy klimat.Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com1tag:blogger.com,1999:blog-1759916214638009707.post-79586831592592178472019-02-07T10:07:00.000+01:002019-02-07T10:12:31.602+01:00Lekcja architektury prosto z CastoramyOdkryłem w Castoramie fakturomaty. Wow! <br />
<br />
Zawodowa ciekawość zmusiła mnie do skorzystania, a zawodowy talent unieruchomił fakturomat już w trakcie pierwszego użycia.<br />
<br />
Najpierw pojawił się komunikat "Archiwizowanie paragonu", a następnie "Błąd wystawiania faktury" czy coś w podobie.<br />
<br />
Poprosiłem o pomoc, Pani otworzyła dolne drzwi fakturomatu i oto widok jak na zdjęciu:<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-uyJaEmljXWI/XFv065IrlzI/AAAAAAAAGQI/uiecaxPR1sUS2iHu2jiMmiFTiSvQ7z3xACLcBGAs/s1600/to.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://1.bp.blogspot.com/-uyJaEmljXWI/XFv065IrlzI/AAAAAAAAGQI/uiecaxPR1sUS2iHu2jiMmiFTiSvQ7z3xACLcBGAs/s400/to.jpg" width="300" height="400" data-original-width="1200" data-original-height="1600" /></a></div><br />
Okazało się, że fizyczne <code>ArchiwumParagonów</code>, które chyba niechcący wyłożyłem, to kartonowe pudło do którego wpadają paragony po przeskanowaniu przez czytnik. Sama esencja <a href="https://pl.wikipedia.org/wiki/KISS_(reguła)">KISS</a> jak zgaduję.<br />
<br />
Pani pogrzebała w archiwum, feralny paragon się znalazł (heurystyka "mniej więcej po kwocie") i po ponownym przetworzeniu fakturomat wypluł fakturę.<br />
<br />
Wniosek praktyczny: <b>Jeśli user zgłasza, że Twój soft ma kłopoty z działaniem, upewnij się, że pod pięknym interfejsem, nie śmigają aby kartonowe pudła</b> :P (może to OK, a może nie)<br />
<br />
<i>Ogromny szacunek dla personelu Castoramy, który skutecznie uniemożliwiał mi zrobienie porządnej dokumentacji fotograficznej z miejsca zdarzenia :D </i>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com3tag:blogger.com,1999:blog-1759916214638009707.post-20797212311203100012019-01-30T00:16:00.002+01:002019-02-15T11:35:38.704+01:00Programiści NIE mają problemu z komunikacjąTaka rozkminka. <br />
<br />
Jakieś 17 lat temu dałem sobie wmówić, że programiści mają problem z komunikacją i powinni się szczególnie reformować w tym zakresie. Ostatnimi czasy pewne wydarzenie rzuciło mi nieco inne światło na tę kwestię, a było to tak...<br />
<br />
Prowadziłem rozmowę z jednym programistą, który jak tylko mógł bronił się przed zesłaniem na szkolenie z komunikacji. Uparcie twierdził, że on nie potrafi się komunikować, nigdy nie potrafił, nie chce i nie będzie.<br />
<br />
<i>No, nie zmuszam</i> - pomyślałem i już miałem zakończyć grilowanie biedaka, gdy moją uwagę przykuła pewna rzecz - obrączka na palcu. <br />
- <i>Masz żonę?</i> - zapytałem<br />
- <i>Mam.</i><br />
- <i>Hmmm, ale to siłą ją zaciągnąłeś przed ołtarz? Porwałeś z domu?</i><br />
<br />
Okazało się, że luba mojego rozmówcy dobrowolnie i bez żadnego przymusu dała się namówić na zamążpójście. Zdziwiło mnie to, po tym jak odmalował swoje kompetencje komunikacyjne.<br />
<br />
- <i>A macie dzieci, jeśli wolno spytać...?<br />
- Mamy. Dwie córki.</i><br />
<br />
I znów zdziwienie. Wyobraź sobie, że ten programista nie tylko rozmawia ze swoimi córkami, ale i bierze czynny i aktywny udział w ich wychowaniu.<br />
<br />
Nie wiem jak Tobie, ale mnie po tym dialogu wszystko się przestało kleić. No, do cholery jeśli ktoś potrafi przekonać drugą osobę do zawarcia formalnego związku, to chyba potrafi się komunikować, nie? <br />
<br />
Poza skończoną liczbą przypadków szczególnych, jeśli inżynier żyje w związku albo utrzymuje kontakty z rodziną, znajomymi, czy chociażby wspólnotą mieszkaniową, to spokojnie można założyć, że posiada podstawowy set kompetencji społecznych, które zapewniają mu przetrwanie.<br />
<br />
Tak więc, ten cudowny kontrprzykład na zawsze pogrzebał tezę, że programiści nie potrafią się komunikować. O co więc chodzi z tą łatką, którą się nam przykleja? Otóż przyczyny leżą zupełnie gdzie indziej.<br />
<br />
<h2>Uporządkowanie i praca głęboka</h2>Programiści preferują pracę według określonego porządku. Wszystko to, co zaburza ten porządek jest postrzegane negatywnie.<br />
<br />
Praca wykonywana przez inżynierów ma najczęściej charakter głęboki (chodzi o naturę rzeczy, nie o ocenę tej pracy). Oznacza to, że wymaga ona operowania dużą ilością szczegółów, dużego skupienia oraz skrupulatności.<br />
<br />
Można zaryzykować stwierdzenie, że programowanie to nadawanie pewnego porządku danym, które są nieuporządkowane.<br />
<br />
Odcięcie się od bodźców zewnętrznych sprzyja takiej pracy. Rozpraszacze i wrzutki z boku ją zaburzają. Łamanie porządku pracy jest odbierane jako bałagan. Powoduje też nieprzyjemne doznania w ciele. Serio!<br />
<br />
<h1>Lejek sprzedażowy</h1>Programiści są umiejscowieni niemal na samym końcu lejka sprzedażowego. Natomiast biznes jest niemal na samym początku tego lejka.<br />
<br />
Aby do programistów trafił jeden temat do realizacji, po stronie biznesowej należy "obrobić" tych tematów z pięćset. Z tego powodu w biznesie czas upływa subiektywnie szybciej niż w IT - więcej się dzieje. W IT rozdłubujemy jedną rzecz do ziarnistości atomu, bo tak trzeba, aby ją porządnie zrobić.<br />
<br />
<h1>Coś niespodziewanego</h1>- O w mordeeeee! Nie przeczytaliśmy zapytania do końca! Zaoferowaliśmy coś, czego nie mamy!<br />
<br />
Nie ma co się czarować, gdy się dużo dzieje, takie błędy się zdarzają. Będąc na górze lejka, biznes ma dużą ekspozycję na tego typu błędy. Niestety będąc na dole lejka, IT ma z takich błędów za***te koszty.<br />
<br />
<h1>Bounded Context</h1>Gdy pierwszy raz wybrałem się do mechanika z moim Suzuki Maruti '92, usłyszałem "bla, bla, blaa, osiemset trzydzieści", gdzie Maruti kosztował 1,3k. <br />
<br />
Gdy grupa ludzi pracuje razem, zaczyna wykształcać się lokalna gwara branżowa. Upraszcza ona komunikację w grupie, utrudnia poza grupą.<br />
<br />
<h1>Wnioski praktyczne</h1>No, dzięks, że wytrwałeś aż do tego momentu, bo wnioski ww. refleksji są dość ciekawe:<br />
<br />
<ol><li>Trudności komunikacyjne na lini BIZ-IT nie wynikają z tego, że ktoś (IT) jest mniej usklilowany miękko. Wynikają przede wszystkim z "architektury organizacyjnej", w której ludzie zostali umieszczeni<br />
<li>Analizowaną w poście "architekturę organizacyjną" można nazwać "klient-usługodawca". Jak długo będziemy ustawiać ludzi w relacji klient-usługodawca tak długo będą występować problemy komunikacyjne. I choćbyśmy ludzi przetrenowali miękko na wszystkie strony - nic to nie da. Problemy komunikacyjne są wpisane w relację klient-usługodawca, a nie w naturę poszczególnych ludzi<br />
<li>Z programistami jest wszystko w porządku - ich umiejętności miękkie są w normie. Zapewniam, że gdy programista idzie do mechanika samochodowego doświadcza tych samych trudności komunikacyjnych co osoba z biznesu odwiedzająca programistę<br />
<li>Należy zmienić priorytety. Zamiast wałkować 101 technikę udzielania feedbacku, należy reorganizować struktury współpracy tak, aby pozbyć się relacji klient-usługodawca<br />
<li><i>work in progress</i><br />
</ol><div class="separator" style="clear: both; text-align: center;"><a href="https://zbieranie-wymagan-edycja-5.evenea.pl" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-TbQYQMh-AHs/XGaUISXyt7I/AAAAAAAAGQ8/mBSCuXV1GQMkQVVJO_6t-PVZUfhbQKjGgCPcBGAYYCw/s640/zzw5-Q12019.png" width="580" height="290" data-original-width="1100" data-original-height="550" /></a></div>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com2tag:blogger.com,1999:blog-1759916214638009707.post-36053805557540072562018-12-28T23:00:00.000+01:002018-12-29T07:17:20.669+01:00Dwie zasady skutecznego rozwiązywania problemów w prezencie noworocznymBez zbędnych wstępów.<br />
<br />
<h1>Zasada 1.</h1>Niemal każdy dylemat ma co najmniej dwa rozwiązania: dobre i praktyczne. Najczęściej są one od siebie różne.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Ż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.<br />
<br />
<h1>Zasada 2.</h1>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".<br />
<br />
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. <br />
<br />
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. <br />
<br />
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.Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-43403009281397251602018-10-31T02:01:00.001+01:002018-10-31T02:01:50.114+01:00Odpowiedź: 42Świat IT jest pełen odpowiedzi...<br />
<ul><li>Jak pisać czytelniej? Dzielić algorytmy i metody na mniejsze kawałki. Pisali o tym McConnell, Beck, Martin.<br />
<li>Jak radzić sobie implementacją złożonego procesu? Można wydzielić współpracujące ze sobą obiekty. Pisał o tym Meyer.<br />
<li>Jak okiełznać złożoność domenową? Można zastosować wyróżnić bounded contexts itd. Pisali o tym Evans, Vernon, Dahan, Young i inni.<br />
<li>Jak dokładniej testować? Pisać mniejsze testy skupione na konkretnym zachowaniu. To, akurat mówią wszyscy...<br />
<li>Jak poprawić trafność oszacowania? Można dekomponować na podzadania. Pisał o tym McConnell.<br />
<li>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.<br />
<li>Jak skalować agility? Zacząć od skalowania produktu i podzielenia go na mniejsze podprodukty. Mówili o tym Poppendieckowie.<br />
<li>Jak poprawić swoją efektywność. Skupić się na mniejszej ilości spraw. To tłuką na konferencjach bez litości.<br />
<li>Jak uniknąć kosztownego refaktoringu i mądrzej ogarnąć architekturę? Wydzielić odpowiednio małe microserives. Mówił o tym Young.<br />
<li>itd.<br />
</ul>
Wymienione odpowiedzi są pożyteczne, ale chyba gdzieś umknęło pytanie.
Otóż podstawowym pytaniem, z którym boryka się uniwersum IT jest <b>pytanie o granulację</b>. Ile to jest mało, ile dużo, a ile odpowiednio? <br />
Jaki serwis będzie OK, a jaki za duży? I w jakim stopniu zależy to od kontekstu?<br />
<br />
Kłopot w tym, że żadne z wymienionych odpowiedzi, ani chyba też żadne, które znamy, nie adresuje tego podstawowego pytania.Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-24953436031930933602018-10-24T00:06:00.001+02:002018-10-24T00:06:37.040+02:00Dzię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.<br />
<br />
Dziękuję prelegentom za przygotowanie prezentacji. Szczególnie dziękuję za sumienne potraktowanie naszej prośby o przemyślenie take aways z prezentacji.<br />
<br />
Z mojej strony "utrzymać":<br />
<ul><li>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<br />
</ul>
I "do zmiany":
<ul><li>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; <br />
<li>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<br />
<li>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<br />
<li>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ć<br />
</ul>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-33886903908479538092018-10-12T23:50:00.000+02:002018-10-14T20:59:43.383+02:00Zwinność kulturowo rozmiękczona<p>Tu, nad Wisłą, ze zwinnością (<i>agility</i>) wydarzyło się coś niedobrego. Zapraszam to krótkiej rozkminki.</p><p>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."</p><p>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"</p><p>Dostrzegasz coś intrygującego?</p><h1><i>responsible</i> vs. <i>accountable</i></h1><p><i>Responsible</i> oznacza odpowiedzialność w takim sensie, że ktoś ma coś w swoich obowiązkach, bo na przykład zostały mu te obowiązki przydzielone.</p><p><i>Accountable</i> oznacza mocniejszy rodzaj odpowiedzialności np. prawnej, czyli odpowiedzialności za konsekwencje.</p><p>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 <b>rozliczony</b>". Jedno słowo wiele zmienia, co?</p><p>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.”</p><p>Zatem Zespół Deweloperski zostanie <b>rozliczony</b> za brak przyrostu (<i>increment</i>) produktu na koniec sprintu.</p><h1>Niuans kulturowy</h1><p>Moim zdaniem mamy tu do czynienia z różnicą kulturową. Anglosaska - jak mniemam - prosta i konkretna zasada <i>rozliczenia</i> została w polskim tłumaczeniu rozmyta i rozmiękczona w ogólną <i>odpowiedzialność</i>.</p><p>Zgaduję powód. Sęk w tym, że <i>rozliczyć</i> 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ł?"</p><h1>Głębiej o <i>accountability</i></h1><p>Powiem więcej. "accountability" oznacza taki rodzaj (silnej) odpowiedzialności (za konsekwencje), który został przyjęty <b>dobrowolnie</b>. Na przykład CEO jest <i>accountable</i> 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.</p><p>W tak rozumianym <i>rozliczaniu</i> nie ma nic negatywnego. Ktoś otrzymuje pełnię władzy: przywileje oraz konsekwencje. Prosty deal.</p><h1>Czego chce Scrum?</h1><p>Posługując się już przedefiniowanymi wyżej pojęciami, można powiedzieć, że Scrum chce od swojego praktyka pewnej dojrzałości.</p><p>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.</p><p>Rzecz jasna możliwość rozliczania implikuje ze strony organizacji konieczność przydzielenia autonomii, decyzyjności i tak ogólnie nie wpieprzania się w paradę.</p><h1>Kolorowy coach</h1><p>Tu kudos dla <a href="https://www.linkedin.com/in/bartosz-janowski/">Bartka</a> za insight.</p><p>Weźmy jeszcze jeden cytat na temat tego, co tam Scrum Master powinien: "Coaching the Development Team in self-organization and cross-functionality"</p><p>I po polskiemu: "Coachując Zespół Deweloperski w zakresie wykorzystania zasad samoorganizacji i międzyfunkcyjności".</p><p>No więc rzucili się ludzie na kursy kołczigu i adżajkołczują. No, ale looknijmy sobie na <a href="https://en.oxforddictionaries.com/definition/coach">OxfordDict</a> czymże jest ten <i>coaching</i>?</p><p>O, żesz w mordę, madafaka! Co ja paczę???</p><ul><li>"Train or instruct (a team or player)"</li>
<li>"Teach (a subject or sport) as a coach"</li>
<li>"Give (someone) instructions as to what to do or say in a particular situation"</li>
<li>"Give (someone) professional advice on how to attain their goals"</li>
</ul><p>Zatem jeśli Scrum Master <i>coach</i> 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.</p><p><b>Nie oznacza</b> 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.</p><p>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.</p><p>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.</p><p>Także, ten...wyluzuj. Po prostu wyluzuj.</p><h1><i>Continuous attention to technical excellence...</i></h1><p>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.</p><p>Między innymi taka: "Continuous attention to technical excellence and good design enhances agility". O co chodzi?</p><p>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?</p><p>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.<br />
Tak się nie da.</p><p>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...</p><h1>A na deser <i>międzyfunkcjonalność</i></h1><p>W oryginale: "Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment"</p><p>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."</p><p>Nie wiem czy tylko ja wymiękam z tą "międzyfunkcjonalnością"?</p><p>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?</p><p>Jeśli już kuć nowe słowa, to ideę oddawałoby "pełnokompetentny": "Zespoły Deweloperskie są <b>pełnokompetentne</b>, w swoim składzie posiadają wszystkie umiejętności niezbędne do wytworzenia Przyrostu produktu." Ewentualnie "pełnoumne" :)</p>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-83051640893898766302018-09-06T16:00:00.000+02:002018-09-06T20:40:30.160+02:00Jestem Scrum Masterem, co mam robić?Śmieją się developerzy ze ScrumMasterów, że ci nic nie robią. Niby żartem, niby po przyjacielsku, ale boli. Gdy ScrumMaster zostaje ScrumMaster jedne z pierwszych pytań, które sobie zadaje to:<br />
<ul><li>No i co ja mam teraz robić?<br />
<li>A co jeśli zapomnę jak się programuje?<br />
<li>A co jeśli znudzi mi się programowanie<br />
</ul>Jedna z dróg, którą może wybrać SM na wdrożenie Scruma wiedzie przez cztery następujące etapy: <ol><li>Framework by Guide<br />
<li>Jakość techniczna<br />
<li>Wartości i wyjście poza zespół<br />
<li>Nieustanny tuning DoD<br />
</ol>W tym modelu, SM może zająć się doprowadzeniem do zaistnienia następujących rzeczy: <ol><li><b>Framework by Guide</b><br />
<ul><li>Zaimplementowanie w pracy zespołu ról: SM, PO z biznesu, SM, DevTeam<br />
<li>Zaimplementowanie w pracy zespołu: sprintów stałej długości, DoD, Planningu, Review, Daily, Retro, regularnego refinementu PBL, Product Backloga, Spring Backloga<br />
<li>Biznesowe cele sprintów<br />
<li>Zaimplementowanie w pracy zespołu: biznesowego inkrementu produktu na koniec sprintu, współpracy między zespołem a PO, która nie wymaga sztywnego DoR<br />
<li>samoorganizacja Zespołu deweloperskiego<br />
<li>Doprowadzenie do tego, aby testerzy byli pełnoprawnymi członkami Zespołu scrumowego, a nie podzespołem w zespole<br />
</ul><li><b>Jakość techniczna</b><br />
<ul><li>Wdrożenie 1-3 metryk kodu oraz systematyczna praca nad ich poprawianiem; propozycja na początek CC oraz LOC na poziomie metod i klas<br />
<li>Zmierzenie długu technicznego, przygotowanie planu jego spłaty i wynegocjowanie tego z PO<br />
<li>Wdrożenie Continuous Integration -> Continuous Deployment -> Continuous Delivery<br />
<li>Wprowadzenie regularnego Code Review w zespole wraz z narzędziem, który je wspiera<br />
<li>Wdrożenie Test/Behaviour Driven Development<br />
<li>Wdrożenie automatycznych testów funkcjonalnych wraz z narzędziem, które je wspiera; nauczenie PO i/lub interesariuszy formułowania wymagań w formie scenariuszy<br />
<li>Wdrożenie Domain-Driven Design, nawiązanie współpracy z ekspertami domenowymi, wdrożenie Modelling Whirpool<br />
<li>Regularne Architectural Kata<br />
<li>Regularne Refactoring Kata<br />
</ul><li><b>Wartości i wyjście poza zespół</b><br />
<ul><li>Doprowadzenie do sytuacji, w której prace zespołu są niezależne od innych jednostek organizacji<br />
<li>Pomoc managerowi zespołu w na nowo zdefiniowaniu swojej roli w stosunku do zespołu scrumowego<br />
<li>Doprowadzenie do określenia zasad współpracy pomiędzy jego/jej zespołem a innymi zespołami i/lub jednostkami organizacyjnymi<br />
<li>Stymulowanie wewnętrznych inicjatyw typu "craftsmanship": wewnętrzne konferencje, warsztaty, szkolenia, mini-społeczności skupione w okół danych technologii albo ról (np. gildie)<br />
<li>Eksponowanie osiągnięć zespołu na zewnątrz organizacji: konferencje branżowe, artykuły w prasie i na portalach branżowych<br />
<li>Wdrażanie i promowanie empirycznego podejścia do pracy tj. wprowadzanie przejrzystych metryk przy jednoczesnym uczeniu organizacji jak z nich sensownie korzystać<br />
</ul><li><b>Nieustanny tuning DoD</b><br />
<ul><li>Doprowadzenie do sytuacji, w której "Done" oznacza "dostępne dla klientów"<br />
<li>Praca na skróceniem <i>time to markiet</i>, <i>time to feedback</i><br />
<li>Dążenie do sytuacji, w której ani zespół ani organizacja nie potrzebują Scrum Mastera, gdyż jego obowiązki zostały osmotycznie przejęte przez członków zespołu i innych pracowników organizacji, którzy bezpośrednio dostarczają wartość dla jej klientów<br />
</ul></ol>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-32174494315122076122018-08-28T22:26:00.002+02:002018-08-28T22:26:56.954+02:00SegFault<div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-05terfOof3U/W4Wrs5YReHI/AAAAAAAAGN0/MT-SjDfXFM0oy20GnwgqtsC-cJdnJzFfACLcBGAs/s1600/segfaultFaceBookArch%252Blogo.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-05terfOof3U/W4Wrs5YReHI/AAAAAAAAGN0/MT-SjDfXFM0oy20GnwgqtsC-cJdnJzFfACLcBGAs/s320/segfaultFaceBookArch%252Blogo.jpg" width="320" height="118" data-original-width="851" data-original-height="315" /></a></div><br />
<br />
Cieszę się, że to właśnie <a href="http://segfault.events/wroclaw2018/index.html#council">ONI</a> zrobili nową konferencję.<br />
Z każdym z chłopaków miałem okazję wielokrotnie współpracować i myślę, że łączą ich trzy rzeczy: <br />
<ul><li>absolutnie niedogmatyczne podejście do programistycznych mód<br />
<li>alergia na bullshit<br />
<li>olewczy stosunek dla autortetów<br />
</ul><br />
Nie wiem jak dla Was, ale dla mnie to pachnie totalną konferencyjną innowacją. Do zobaczenia we Wrocławiu!Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-89081578759338758322018-07-22T21:30:00.000+02:002018-07-22T21:30:02.244+02:00Zarządzanie "flow"<p>Miałem ostatnimi czasy nieprzyjemność gościć w hotelu <a href="http://victoriagroup.bg/hotel-royal-park-elenite/">Royal Park Elenite w Bułgarii</a>. Miejsce to do złudzenia przypomniało mi czasy przedszkolne w epoce słusznie minionej, gdy z całych sił starałem się "swoją nauką przynosić chlubę moim rodzicom oraz mojej ojczyźnie Polsce Ludowej"...<br />
</p><p>Jednak to, co bawiło mnie trzydzieści kilka lat temu, teraz mnie po prostu wnerwiało. Zarządzając tak dużym obiektem można schrzanić wiele rzeczy. Odniosłem wrażenie, że w <a href="http://victoriagroup.bg/hotel-royal-park-elenite/">Royal Park</a> dokumentnie schrzanili je wszystkie.<br />
</p><p>Żeby tam jakoś wytrzymać postanowiłem zająć się czymś interesującym. Zacząłem przyglądać się stołówce, czy też sali bankietowej - jak nazywano stołówkę. <br />
</p><p>Byłem naprawdę pod wrażeniem kreatywności designerów tej sali, która już przy niewielkiej liczbie gości rezonowała nieprawdopodobnym chaosem.<br />
</p><p>Poniżej wklejam poglądową mapę tejże sali.<br />
</p><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-bsrFE8jBsAM/W1O0q80GDJI/AAAAAAAAGK8/hRrmN8dACOkyYOLnWxSbfKWNYXrGGD_MwCLcBGAs/s1600/RoyalPark-2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-bsrFE8jBsAM/W1O0q80GDJI/AAAAAAAAGK8/hRrmN8dACOkyYOLnWxSbfKWNYXrGGD_MwCLcBGAs/s400/RoyalPark-2.png" width="400" height="231" data-original-width="1600" data-original-height="925" /></a></div><br />
<h1>Straty, straty, straty</h1><p>Zacznijmy od wylistowania zaobserwowanych przeze mnie start, czyli rzeczy, których w stołówce nie chcielibyśmy obserwować.</p><ul><li>długie i uciążliwe kolejki - na mapie zaznaczone czerwonymi trójkątami<br />
<li>częste kolizje obsługą albo z innymi gośćmi<br />
<li>goście pozostawiają dużo niezjedzonych potraw<br />
<li>długi czas kompletowania posiłku<br />
<li>masło i cukier zmieniają miejsce między obiadem a kolacją<br />
<li>gdy zostawisz skompletowany talerz na stoliku bez opieki, to może on zostać sprzątnięty jako "zużyty"<br />
</ul>
<p>Straty wydają się ze sobą niepowiązane. Przyjrzyjmy się im jednak z perspektywy stoiska z Wypiekami. Na tym stoisku:</p><ol><li>Pracuje jedna osoba<br />
<li>Nie nadąża z wypiekami za popytem na nie<br />
<li>W skutek czego powstaje kolejka<br />
<li>Gdy nastąpi dostaw wypieków, to czekający w kolejce nakładają sobie duże ilości<br />
<li>Zatem wypieki znów szybko znikają<br />
<li>I znów powstaje kolejka z powodu niezaspokojenia popytu na wypieki<br />
</ol><p>Przyjrzałem się ilości nakładanych potraw przez gości, a następnie sam sobie tyle nałożyłem. Mimo, że jestem zdrowym, silnym 96kg facetem, zmiękłem.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-6GNdhOWrNbk/W1QSOnf8f0I/AAAAAAAAGLI/oX10KaVCqtYcsKkFRViwfBP59PGdc69zACLcBGAs/s1600/Nadmiar%2Bjedzenia.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://4.bp.blogspot.com/-6GNdhOWrNbk/W1QSOnf8f0I/AAAAAAAAGLI/oX10KaVCqtYcsKkFRViwfBP59PGdc69zACLcBGAs/s320/Nadmiar%2Bjedzenia.png" width="320" height="133" data-original-width="1600" data-original-height="667" /></a></div>
<p>Nie dałem rady pochłonąć tego wszystkiego bez przeżarcia się. Nie mówiąc już o zakończeniu posiłku porcją słodyczy i miską lodów.</p>
<h3>Wnioski #1</h3>
<p>Na podstawie ww. obserwacji stawiam następującą hipotezę: <i>nieefektywność procesu produkcji prowadzi do kolejek, oraz zwiększonego popytu i szybkiego wysycania produktów, także do gromadzenia nadmiernych zapasów "na wszelki wypadek", co z kolei ponownie skutkuje niedostępnością produktów, a tym samym kolejkami.</i></p><p>Gdy zobaczymy to na diagramie przyczyn i skutków, od razu odkryjemy pętlę.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-r4s8P85Dq0g/W1QYpRKF3YI/AAAAAAAAGLU/NNP0c3DbBPU9ElouNlT9-JdaSwpSxNHuwCLcBGAs/s1600/Pe%25CC%25A8tla%2Bstrat.png" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-r4s8P85Dq0g/W1QYpRKF3YI/AAAAAAAAGLU/NNP0c3DbBPU9ElouNlT9-JdaSwpSxNHuwCLcBGAs/s320/Pe%25CC%25A8tla%2Bstrat.png" width="320" height="146" data-original-width="1236" data-original-height="564" /></a></div><p></p>
<h3>Wnioski #2</h3><p>Zarząd hotelu próbuje radzić sobie z kolejkami w ten sposób, że dzieli gości na dwie grupy. Pierwsza grupa przychodzi na śniadanie o godzinie 7, druga o 8.30. Zamieszczony diagram wskazuje, że jest to błędne podejście. Dzielenie na grupy zniweluje okresowo objawy problemów. Przyczyny pozostaną nietknięte ponieważ dzielenie na grupy nie likwiduje pętli.</p>
<h3>Wnioski #3</h3><p>Zastanawiałem się, gdzie się "wlewa" do tej pętli, co ją startuje. Po krótkiej obserwacji odkryłem winowajcę.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-LC13q_QDa54/W1QcO2LFrSI/AAAAAAAAGLg/9cM0DsFlv4kpke3sMppj0qCV7DX1kEMjgCLcBGAs/s1600/Przyczyny%2Bpe%25CC%25A8tli.png" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://3.bp.blogspot.com/-LC13q_QDa54/W1QcO2LFrSI/AAAAAAAAGLg/9cM0DsFlv4kpke3sMppj0qCV7DX1kEMjgCLcBGAs/s320/Przyczyny%2Bpe%25CC%25A8tli.png" width="320" height="136" data-original-width="1600" data-original-height="682" /></a></div><p>Dla przykładu stoisko z wypiekami obsługuje tylko jedna osoba, której zadaniem jest: ułożenie na blachę, włożenie do pieca, wyjęcie z pieca, a następnie ułożenie do wypieków w koszykach. Wypieków w trakcie śniadania są 3-4 rodzaje. Osoba obsługująca po prostu nie ma tylu rąk.</p>
<p>Druga obserwacja jest taka, że choć personel niezwykle się stara, to oni zwyczajnie nie wiedzą jak konkretnie powinni pracować. Ich praca nie została zaprojektowana. Jest spontaniczna. Sęk w tym, że spontaniczność bardzo słabo się skaluje.</p>
<h3>Wnioski #4</h3><p>Przypuszczam, że to iż tylko jedna osoba obsługuje Wypieki, wynika z oszczędności kosztów. Moim zdaniem jest to podejście błędne. Na podstawie diagramu przyczyn i skutków, uważam, że dołożenie dodatkowej osoby, zaprojektowanie ich współpracy oraz przeszkolenie skutkowałoby:</p><ul><li>Zmniejszeniem kolejek<br />
<li>Mniejszą ilością wyrzucanego jedzenia<br />
<li>Poprawą ogólnej satysfakcji gości<br />
</ul><p>Zatem co do pieniędzy - zwiększenie kosztów na dodatkowy etat zostanie zrekompensowane oszczędnościami na ilości wyrzucanego jedzenia.</p><p>Paradoksalnie może się okazać, że większą ilością osób będziemy przygotowywać mniejszą ilość jedzenia, gdyż poprawa płynności procesu dostarczania jedzenia zniechęci gości do gromadzenia nadmiernych zapasów na talerzach.</p>
<p>Skoro o procesie mowa...</p>
<h1>Dimityr idzie na śniadanie</h1><p>Popatrzmy na wycieczkę po restauracji jak na proces, w którym na kolejnych etapach, wędrujący przezeń gość otrzymuje jakąś wartość - potrawę, sztućce, itp.</p>
<p>Weźmy pod uwagę hipotetycznego gościa hotelowego - nazwijmy go Dimityr - który przyszedł z dzieckiem, aby zjeść śniadanie: ciepły posiłek, płatki dla dziecka, herbatę, trochę zieleniny, a na deser słodką bułkę ze stoiska z wypiekami</p>
<p>Poniższy rysunek pokazuje trasę Dimityra, którą przebędzie w stołówce, aby zjeść śniadanie.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-Td8i34MS5Fg/W1RT3pnwayI/AAAAAAAAGLs/_sGrmg3TnZgP6XJRAw5KVIslXb8NE5T7ACLcBGAs/s1600/Trasa%2Bs%25CC%2581niadaniowa.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-Td8i34MS5Fg/W1RT3pnwayI/AAAAAAAAGLs/_sGrmg3TnZgP6XJRAw5KVIslXb8NE5T7ACLcBGAs/s400/Trasa%2Bs%25CC%2581niadaniowa.png" width="400" height="232" data-original-width="1600" data-original-height="929" /></a></div>
<p>Jak można przypuszczać, przy przeciętnej setce gości na sali, prawdopodobieństwo kolizji z innymi głodnymi, kimś z obsługi, albo poślizgnięcia się na jakimś mokrym obrzydlistwie jest bardzo wysokie. Sam się kilkukrotnie niemal wyłożyłem niosąc dziecko na rękach.</p>
<p>Najbardziej niebezpieczny sposób rozwiązywania problemów w tym procesie można zobrazować przez to, co się dzieje z mlekiem do płatków śniadaniowych...Jeśli przyjrzysz się ponownie mapie, zauważysz, że tuż przy płatach stoi naczynie z zimnym mlekiem. Natomiast mleko ciepłe znajduje się w przeciwległym końcu sali, w okolicy ekspresów do kawy. </p>
<p>Odkryłem, że jest tak dlatego, iż w okolicy płatków brakuje gniazdka do podłączenia pojemnika, który podtrzymywał by jego temperaturę. Na tym polega właśnie dramat tego rozwiązania - na naginaniu procesu biznesowego pod ograniczenia techniczne. <b>Do zapamiętania:</b> nie wolno tego robić. To niemal zawsze prowadzi do chaosu.</p>
<p>Jeśli ograniczenia techniczne nie pozwalają na poprawne wsparcie procesu, już lepiej go okroić - czyli zrezygnować z wystawiania płatków. Albo wystawić tylko zimne mleko przy płatkach, a obok ze dwie mikrofale.</p>
<h3>Mityczna wartość biznesowa</h3><p>Zdefiniujmy, czym jest owa wartoś biznesowa. Dla mnie, jako uczestnika chaotycznej gonitwy po stołówce wartość biznesowa, czyli to czego przede wszystkim oczekuję od restauracji, do której przychodzę na śniadanie jest:</p><ul><li>odwrotnie proporcjonalna do łącznej drogi, którą muszę przebyć, aby skompletować śniadania i rozpocząć jedzenie<br />
<li>odwrotnie proporcjonalna do ilość kolizji z innymi uczestnikami procesu<br />
<li>odwrotnie proporcjonalna do sumarycznego czasu potrzebnego na skompletowanie śniadania (włączając w to oczekiwanie w kolejkach)<br />
</ul><p>Chociaż czas można w prostym przypadku wyprowadzić z drogi, to dla gościa restauracji czym innym jest dreptanie pomiędzy stoiskami, a czym innymi przedłużające się czekanie.</p>
<p>Uściślijmy zatem:</p><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-hT15hdWPhhI/W1TBMFuyANI/AAAAAAAAGMM/798TS4qWqAE9gzLpReAiiw7yfVbDdWxHACLcBGAs/s1600/VB.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-hT15hdWPhhI/W1TBMFuyANI/AAAAAAAAGMM/798TS4qWqAE9gzLpReAiiw7yfVbDdWxHACLcBGAs/s320/VB.png" width="320" height="86" data-original-width="1106" data-original-height="298" /></a></div><p>gdzie: <i>Vb</i> - wartość biznesowa, <i>L</i> - łączna droga, <i>t</i> - łączny czas, <i>n</i> - liczba kolizji, <i>k</i> - współczynnik proporcjonalności. Przyjmijmy roboczo, że <i>n = 1</i> jest po prostu wartością minimalną i nie oznacza kolizji.</p>
<p>Warto się przy okazji zastanowić, jaką interpretację fizyczną ma współczynnik proporcjonalności - <i>k</i>. Prawdą jest, że:</p><div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-FVhAdEH_c0I/W1TBUPapKgI/AAAAAAAAGMQ/gKBCP458HmMn7glxsEVRkG0GUD54FbQdACLcBGAs/s1600/k-constant.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://4.bp.blogspot.com/-FVhAdEH_c0I/W1TBUPapKgI/AAAAAAAAGMQ/gKBCP458HmMn7glxsEVRkG0GUD54FbQdACLcBGAs/s320/k-constant.png" width="320" height="61" data-original-width="950" data-original-height="180" /></a></div>
<p>Można więc przyjąć, że <i>k</i> jest jednostkową - minimalną - wartością oczekiwaną przez klienta, przy której wypadkowa czynników wpływających na wartość biznesową osiąga wartość minimalną równą 1.</p>
<h3>Wnioski #5</h3><p>Należałby by dążyć do tego, aby gość uzyskał wspomnianą podstawową wartość biznesową za jednym razem, z jednej lokacji na zasadzie "grab and go". Na przykład: mleko plus płatki, plus mikrofala albo gotowe hot-dogi.</p>
<h3>Wnioski #6</h3><p>Zatrzymajmy się jeszcze na chwilę przy kolejce do dań ciepłych. Jej przyczyna nie wynika z niedostatecznych dostaw, jak w przypadku stoiska Wypieki. Tu chodzi po pomieszanie przetwarzania szeregowego z równoległym.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-4KEJZ2IEGro/W1TLqU7H2XI/AAAAAAAAGMg/c_1rVbBMcvkS0drfeQ6kr9l8hH68tRoTgCLcBGAs/s1600/kolejka.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-4KEJZ2IEGro/W1TLqU7H2XI/AAAAAAAAGMg/c_1rVbBMcvkS0drfeQ6kr9l8hH68tRoTgCLcBGAs/s320/kolejka.png" width="320" height="111" data-original-width="1600" data-original-height="554" /></a></div>
<p>Zestawy dań powtarzają się trzykrotnie w rzędzie. Goście zaś ustawiają się w jednej kolejce do wszystkich dań. Większość gości nakładało sobie jedną bądź dwie potrawy. Zatem jeśli akurat brakowało tylko jednej potrawy, na którą czekała tylko jedna osoba, to blokowało to całą kolejkę. W ten sposób większość gości z kolejki oczekiwała na dostarczenie potrawy, której akurat nie chcieli sobie nałożyć.</p>
<p>Widząc bezsens tej sytuacji uparcie pomijałem kolejkę, co spotykało się z powszechnym niezrozumieniem.</p>
<p>Problem ten można by teoretycznie rozwiązać, jeśli powtarzające się zestawy dań rozmieści się równolegle zamiast szeregowo - na zasadzie wysp. Ułatwi to spontaniczne powstawanie wielu kolejek do jednej wyspy.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-dCqbg5m14J4/W1TP4NLmalI/AAAAAAAAGMs/-rOlRBhWvEMcUkJGTrs3UAKbbST0K_O6ACLcBGAs/s1600/wyspy.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://1.bp.blogspot.com/-dCqbg5m14J4/W1TP4NLmalI/AAAAAAAAGMs/-rOlRBhWvEMcUkJGTrs3UAKbbST0K_O6ACLcBGAs/s320/wyspy.png" width="300" height="320" data-original-width="1334" data-original-height="1422" /></a></div>
<h1>Podsumowanie</h1><p>Po opisanym przemyśleniu sprawy mam następujące rekomendacje:</p><ul><li>zredukować ilość serwowanych potraw; mniejsze urozmaicenie na rzecz płynniejszego procesu<br />
<li>zwiększyć liczbę osób przygotowujących potrawy na bieżąco, aby zapewnić większą ilość regularnych dostaw<br />
<li>tam, gdzie występują ograniczenia techniczne nie kombinować, tylko odciąć tę gałąź procesu np. zlikwidować płatki<br />
<li>wprowadzić miejsca potraw "grab and go, które nie wymagają kompletowania np. gotowe hot-dogi<br />
<li>preferować równoległe ustawienia potraw zamiast szeregowych<br />
<li>dążyć do takiego organizowania przestrzeni, aby preferować więcej małych kolejek niż mniej dużych<br />
<li>mierzyć ilość wyrzucanego jedzenia<br />
<li>mierzyć długość i częstość występowania kolejek przy stanowiskach z potrawami<br />
<li>przeszkolić personel i zapoznać go z oczekiwanym flow na stołówce<br />
</ul>
<p>Sprawy, którym należy się jeszcze przyjrzeć, to:</p><ul><li>ustawienie stolików w stosunku do potraw<br />
<li>trasy, po których porusza się personel z dostawami oraz ze zużytymi naczyniami<br />
<li>utrzymywanie czystej podłogi<br />
</ul>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-39794748387777861672018-02-05T23:58:00.002+01:002018-02-06T00:47:18.294+01:00Ścieżka Soft Skills @ 4Developers<br />
<a href="https://3.bp.blogspot.com/-jIMbTz55fwo/WnjiDUK3AKI/AAAAAAAAGHg/aTf94HiOlkU6GSbKHlttSBQZt7OFhRAFQCLcBGAs/s1600/logo3_176137_20171116150646.jpg" imageanchor="1" ><img border="0" src="https://3.bp.blogspot.com/-jIMbTz55fwo/WnjiDUK3AKI/AAAAAAAAGHg/aTf94HiOlkU6GSbKHlttSBQZt7OFhRAFQCLcBGAs/s320/logo3_176137_20171116150646.jpg" width="320" height="167" data-original-width="770" data-original-height="403" /></a><br />
<br />
W tym roku proponujemy Wam nowy format ścieżki Soft Skills<br />
<ul><li>talk trwa 12 minut<br />
<li>warsztat trwa 60 minut<br />
</ul><p>Może na początek wyjaśnię skąd ta zmiana. Jestem częstym bywalcem różnego rodzaju konferencji zarówno jako uczestnik jak i prelegent. Jeśli popatrzymy na ścieżkę konferencyjną jak na ciąg zdarzeń dostarczających wartości uczestnikom, to ja widzę następujące straty: </p><ul><li><b>zbyt długi czas opowiadania o sobie</b> - sorry, ludzie nie po to zapłacili za bilet po to, żeby posłuchać o biografii prelegenta, ile ma certyfikatów,<br />
w ilu meetupach się udziela itd; przyszli po to, aby: dowiedzieć się czegoś, posłuchać o czyichś doświadczeniach, skonfrontować swoje przemyślenia, ponetworkować<br />
<br />
<li><b>take aways</b> zakomitej większości prezentacji, które widziałem można zmieścić w kilkanaście minut jeśli nie mniej, reszta to wypełniacze i luźno powiązane z tematem historie, <br />
<br />
<li><b>OK, że Twoja firma szuka developerów</b>, ale zapraszamy do zostania partnerem konferencji <br />
<br />
<li><b>tak, istnieje rodzaj prezentacji</b>, w której celem jest wciągnięcie uczestnika w ciekawą historię i dostarczenie mu rozrywki - jako mentor ścieżki Soft Skills mam na nią inny pomysł; ma ona dostarczać wartość, rzeczy które będziesz mógł wykorzystać w swojej pracy; rozrywkę zapewni Ci before/after party<br />
</ul><p>Poniżej zamieszczam kilka wskazówek, jak przygotować talk/warsztat w nowej formule </p><h1>Daj się zgooglować</h1><p>Zminimalizuj część związaną z przedstawianiem się. W ciągu 12 minut naprawdę nie ma na to czasu. Jeśli z Twojej prezentacji uczestnicy dowiedzą się wyłącznie kim jest prelegent i czym się zajmuje, będzie to dla nich zerowa wartość. No, chyba, że jesteś sławnym piłkarzem czy kimś tego pokroju. Aczkolwiek, o ile się orientuję, nie mamy budżetu na takowych. </p><p>Daj się więc zgooglować. Zadbaj o swoje profile: LinkedIn, Twitter, GitHub, FB i pozwól uczestnikom samodzielnie podjąć decyzję, czy chcą się dowiedzieć o tobie czegoś więcej
</p><h1>Single Responsibility Principle</h1><p>Skup się na JEDNEJ rzeczy. Jeśli potrzebujesz głębszej inspiracji w tym temacie - przeczytaj <a href="http://www.empik.com/jedna-rzecz-keller-gary-papasan-jay,p1080694095,ksiazka-p">TĘ KSIĄŻKĘ</a>. </p><p>Lepiej dla uczestnika jeśli z Twojej prezentacji dowie się "wszystkiego o czymś" niż "coś o wszystkim".</p><h1>Sformułuj take away</h1><p>Jeśli przedstawiasz jakąś ideę, to uczestnik wychodzący z Twojej prezentacji musi mieć bardzo konkretną odpowiedź na pytanie: "I co ja mam teraz zacząć robić?". To jest "take away" z prezentacji. W związku z tym dokładnie przemyśl: czego uczestnik ma się nauczyć albo na jakie pytanie ma znaleźć odpowiedź w trakcie słuchania Twojej prelekcji. </p><h1>Rób to, co mówisz</h1><p>Gdy prowadzisz warsztat na temat autoprezentacji, to prezentuj się zgodnie z tym, co prezentujesz...Trudno o gorszy fail niż mówienie jednego, a robienie czegoś innego. To tak jakbyś krzyczał do kogoś: "Nie krzycz na mnie!". </p><p>Pamiętaj, że słowa uczą a przykłady pociągają. Na warsztacie oprócz tego, co powiesz, ważne jest również czy stosujesz względem uczestników to, o czym opowiadasz. Ludzie więcej uczą się przez obserwację niż poprzez przyswajanie treści. Zatem rób to, co mówisz. </p><h1>Tak, to jest trudne</h1><p>Przygotowanie i poprowadzenie wartościowej prezentacji 12 min. jest trudniejsze niż talk 1h. W trakcie godzinnej prezentacji możesz "zarzucić" słuchaczy dużą ilością informacji na różnym poziomie szczegółowości. A jeśli dodatkowo przepleciesz je dobrymi historiami albo żartami, uczestnicy będą mieli wrażenie, że "było dużo i było fajnie". Niestety jest to tylko wrażenie.<p><p>W ciągu 12 min. tak się nie da. Albo przekażesz konkret albo od razu widać, że "król jest nagi". </p><h1>Przetestuję na sobie</h1><p>Jako pomysłodawca tego eksperymentu, przetestuję go na sobie pierwszej kolejności. Poprowadzę pierwszą prezentację na ścieżce, więc jeśli coś ma pójść źle, to zbiorę feedback jako pierwszy i będziesz miał chociaż chwilę na wprowadzenie poprawek do swojej prezentacji :) </p><p>Jeśli nie będziemy mieli wystarczającej ilość zgłoszeń, aby zapełnić agendę, poprowadzę również 60 min. warsztat. </p><h1>Wizja ścieżki na 2019</h1><p>Od dłuższego czasu marzy mi się poprowadzenie takiej prezentacji, aby uczestnicy mogli dawać mi feedback w czasie rzeczywistym. Wyobrażam to sobie tak:</p><ul><li>prowadzę prezentację, a na ścianie wyświetla się wykres z poziomem zainteresowania uczestników słuchających wystąpienia <br />
<li>każdy z uczestników może na bieżąco np. poprzez apkę mobilną oznaczać swój poziom zainteresowania tym, co mówię np.: czerwony, żółty, zielony<br />
<li>moim zadaniem jest takie modyfikowanie sposobu prowadzenia on-the-fly, aby maksymalizować satysfakcję uczestników<br />
<li>mam nadzieję, że ten pomysł uda się zrealizować na przyszłym roku<br />
<li>proponuję następujące MVP: tylko moje wystąpienie poprowadzone w ten sposób albo tylko dla chętnych<br />
</ul>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-61018485832403355392017-11-18T00:17:00.000+01:002017-11-18T00:17:06.129+01:00Getting Things Programmed najlepszą książką informatyczną w 2017r.Wiadomość z ostatniej chwili!<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-eA5xkPrFIV8/Wg9tXuf0V7I/AAAAAAAAGA0/Lb3PmXTBf78Uyei1P0LqeIvJBSwmzAbygCLcBGAs/s1600/Snip20171118_5.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://1.bp.blogspot.com/-eA5xkPrFIV8/Wg9tXuf0V7I/AAAAAAAAGA0/Lb3PmXTBf78Uyei1P0LqeIvJBSwmzAbygCLcBGAs/s400/Snip20171118_5.png" width="400" height="248" data-original-width="1600" data-original-height="990" /></a></div><br />
Dziękuję za wyróżnienie! Przyznam, że najwartościowszą rzeczą, która przyszła razem z tą nowiną były dwie rzetelne recenzje od Kapituły Konkursu. Uwzględnię je w drugim wydaniu, o które Wydawnictwo ostatnio się dopytuje.Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-61983719921823478922017-11-18T00:03:00.003+01:002017-11-18T00:23:16.778+01:00Co z tym analitykiem?<p>Kiedyś napisałem na gorąco o <a href="http://blog.gettingthingsprogrammed.pl/2010/07/kilka-spraw-o-ktorych-powinien-wiedziec.html"><u>kilku sprawach, o których powinien wiedzieć analityk</u></a>. Już po siedmiu latach mam kolejną refleksję o roli analityka :)<br />
<br />
Jak wiadomo konsultanci nigdy nie mówią wprost, zacznijmy zatem od pewnej historii...<br />
</p><h3>Jak urządzić mieszkanie?</h3></p>Sęk w tym, że nie bardzo wiem jak. Moje kawalerskie kwatery przypominały koszary. Z tego względu dla uwicia rodzinnego gniazda postanowiłem skorzystać z profesjonalnej pomocy.<br />
<br />
Projekt wykonawczy - bo o tym mowa - został wyceniony przez architektów na 6,1k. OK, pomyślałem, jeśli ma być dobrze i full profeska, to niech będzie. <br />
<br />
Akcja rozpoczęła się od inwentaryzacji, a efektem - jak mnie pouczono - miał być PROJEKT WYKONAWCZY. Kompleksowa dokumentacja dla wykonawcy wykończenia, dzięki któremu będzie on mógł "zrobić" mieszkanie kropka w kropkę w zgodzie z zamysłem architektów. <br />
<br />
-- Czyli moja ekpia będzie wszystko wiedziała co i jak z tego projektu?<br />
-- Tak! - zdecydowanie potwierdzili architekci - Nie będą musieli zadawać żadnych pytań.<br />
<br />
Skąd ja to znam - przemknęło mi przez głowę. <br />
<br />
-- Więcej wiary! - skrytykowałem się w myślach - przecież budowle wznosi się od tysięcy lat. Architekci nie są w ciemię bici i wyłożyłem pierwszą ratę - 3,3k.<br />
</p><h3>Co z tą fugą?</h3><p>Projekt rzeczywiście robił wrażenie: gruby z zewnątrz, a w środku wszystko szczegółowo rozrysowane. Nawet rozłożenie płytek w łazienkach zostało precyzyjnie zaplanowane tak, że odniosłem wrażenie, iż sam bym sobie wykończył to mieszkanie, posługując się rzeczonym projektem. Bez słowa wyłożyłem drugą ratę - 2,8k.<br />
</p><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-6EZASTpAtqo/Wg9QpNqq9wI/AAAAAAAAGAA/DT7ozeBz2jQTPc6zAd5mBzE3pGXj8JdEACLcBGAs/s1600/Snip20171117_1.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-6EZASTpAtqo/Wg9QpNqq9wI/AAAAAAAAGAA/DT7ozeBz2jQTPc6zAd5mBzE3pGXj8JdEACLcBGAs/s320/Snip20171117_1.png" width="320" height="267" data-original-width="1600" data-original-height="1333" /></a></div><p>Któregoś dnia zadzwonił do mnie Pan Czarek - główny specmajster z ekipy wykonawczej.<br />
<br />
--Panie Michale, fugi się nie schodzą...<br />
<br />
Fugi nie schodziły w dolnej łazience. Rząd płytek drewnianych jakoś nie chciał spasować się z płytkami ceramicznymi. Ale łaj?<br />
</p><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-mjNeGWQenWU/Wg9RW-HUQmI/AAAAAAAAGAI/YsZxZ8quFs0s_BY1se0ECQ8Yb4MBqrW7gCLcBGAs/s1600/Snip20171117_2.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-mjNeGWQenWU/Wg9RW-HUQmI/AAAAAAAAGAI/YsZxZ8quFs0s_BY1se0ECQ8Yb4MBqrW7gCLcBGAs/s320/Snip20171117_2.png" width="320" height="155" data-original-width="1600" data-original-height="776" /></a></div><p>Wnikliwa analiza w składzie: ja, ekipa i architekt zaowocowała oczywistą odpowiedzią - do projektu wkradł się błąd. Płytki drewniane miały wysokość nie 30cm lecz 31,5cm !<br />
<br />
Jak to możliwe - zachodziłem w głowę. W projekcie za prawie 7 klocków takie rzeczy? Architektom trzeba oddać jedno, że sytuację uratowali - i tym razem i w kolejnych przypadkach.<br />
</p><h3>Panie Michale, nie jesteśmy idiotami</h3><p>-- Panie Michale, nie jesteśmy idiotami - zaczął majster Czarek. -- Przecież ja wiem, jak położyć płytki. No, ale kazał Pan robić wg projektu, a ja z projektem nie będę się kłócił. Po co oni tu piszą, że "drzwi mają być z podcięciem wentylacyjnym? Przecież wiadomo, że mają być podcięte. Po co piszą, że kibel ma być wiszący? Przecież jak go Pan przywiezie, to się okaże czy wiszący, czy stojący.<br />
<br />
Tu Pan Czarek pokazał mi, jak wyobraża sobie projekt wykonawczy.<br />
</p><div class="separator" style="clear: both; text-align: center;"><a href="https://2.bp.blogspot.com/-qUERMNteXJ0/Wg9cVJOD4SI/AAAAAAAAGAY/B3m-fnIDH0YxrJRtI58v7S-et215F8uvACLcBGAs/s1600/IMG_9225.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://2.bp.blogspot.com/-qUERMNteXJ0/Wg9cVJOD4SI/AAAAAAAAGAY/B3m-fnIDH0YxrJRtI58v7S-et215F8uvACLcBGAs/s320/IMG_9225.JPG" width="320" height="240" data-original-width="1600" data-original-height="1200" /></a></div><p>-- A gdzie reszta szczegółów? - zapytałem zdziwiony.<br />
-- Resztę, to sobie dogadamy.<br />
</p><h3>Coś tu poszło nie tak</h3><p>Mieszkanie zostało wykończone jak trzeba. Siedziałem zadumany na schodach, trzymając w ręku PROJEKT WYKONAWCZY - plik kartek, za który zapłaciłem 6,6k. Coś tu jednak poszło nie tak.<br />
<br />
Nie kwestionuję ceny za pracę architektów, wiadomo, że robota kosztuje. Kwestionuję cel, do którego wspólnie się skomitowaliśmy. Nie chciałem płacić za projekt, bo te rysunki nie mają dla mnie żadnej wartości. Chciałem zapłacić za doprowadzenie mieszkania do takiego stanu, jaki spodobał mi się na rysunkach. O to mi chodziło!<br />
</p><h3>A co z tym analitykiem?</h3><p>Analityk w zespole, analityk jako PO, analityk jako Proxy PO...itd. Każda z tych konfiguracji ma sens. Tyle, że analityku! Twoim celem nie jest wysmażenie BPMNów, UMLi, czy cholera wie czego tam jeszcze. Twoim celem jest dostarczenie tego, czego chce klient. Wespół z innymi wykonawcami na przykład z zespołem deweloperskim. Nie bez powodu na rynku pojawiły się biura architektoniczne mające własne ekipy.<br />
<br />
Zauważ, że w opisanym przykładzie nie można mieć żalu ani do architektów, ani do ekipy. Problem leżał w tym, że setup organizacyjny pracy był niewłaściwy. Architekci poprzez zakontraktowanie PROJEKTU mieli inny cel niż ekpia.<br />
<br />
Chociaż sam prowadziłem wiele szkoleń z UML, jestem raczej niechętny tego rodzaju formalnym notacjom. Ich intencja jest szczytna, ale prowokują one sytuacje, w których to chęć stworzenia poprawnego modelu zastępuje cele klienta. O wiele bardziej przemawiają do mnie nieformalne notacje "free form diagrams" prezentowane chociażby przez <a href="http://simonbrown.je"><u>Simona Browna</u></a> w <a href="https://leanpub.com/software-architecture-for-developers"><u>"Software Architecture for Developers"</u></a>.<br />
<br />
O tym, że, mało który deweloper używa UMLa zgodnie ze specyfikacją, nawet nie wspominam.<br />
</p>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-10934922045173385142017-11-14T23:47:00.003+01:002017-11-15T12:59:59.040+01:00Prosto ze spożywczaka ważna lekcja analizy<p>Proponuję ćwiczenie w terenie: odwiedź 5 małych sklepów spożywczych i obserwuj, jakie pytanie zadaje klientowi sprzedawca tuż po podaniu żądanego towaru.</p><br />
<p>Już?</p><br />
<p>Prawdopodobnie zauważysz, że zadawane jest jedno z dwóch pytań:<br />
</p><ul><li><i>Czy to wszystko?</i><br />
<li><i>Co jeszcze?</i> (w zlokalizowanej wersji na mojej dzielni brzmi to: <i>Co wincyj?</i>?)<br />
</ul><p>Gdybyś dodatkowo zliczał liczbę zakupionych produktów w zależności od zadawanego pytania, przekonałbyś się, że Ci którzy pytają <i>Co jeszcze?</i> sprzedają więcej. </p><h3>How it works?</h3><p><i>Co jeszcze?</i> jest pytaniem otwierającym proces i skłania klienta do zastanowienia się nad tym, czego jeszcze może potrzebować ze sklepu. </p><p><i>Czy to wszystko?</i> zamyka proces i skłania klienta do skupienia się na tym, czy produkty na ladzie są wystarczające do jego potrzeb? </p><h3>Tym czasem w trakcie analizy...</h3><p>Pytaj <i>Czy to wszystko?</i>, gdy formułujesz kryteria akceptacyjne. Chcesz przecież mieć możliwie mały zbiór kryteriów, który spełnia potrzeby interesariusza. </p><p>Pytaj <i>Czy to wszystko?</i>, gdy rozmawiasz z interesariuszem, który ma tendencję do dygresji. Od takiej osoby łatwo uzyskasz scenariusze alternatywne przypadku użycia, ale ze scenariuszem podstawowym może być kłopot. Zatem możliwie często staraj się domykać proces za pomocą pytania <i>czy to wszystko?</i> </p><p>Pytaj <i>Co jeszcze?</i>, gdy chcesz doprecyzować scenariusz podstawowy przypadku użycia. Wtedy przydaje się "pociągnięcie" procesu do końca za pomocą pytania <i>co jeszcze?</i> </p><h3>Co wincyj?</h3>Wincyj znajdzieta w mojej ksiunżce <a href="https://helion.pl/ksiazki/oprogramowanie-szyte-na-miare-jak-rozmawiac-z-klientem-ktory-nie-wie-czego-chce-wydanie-ii-rozsz-michal-bartyzel,opszm2.htm#format/d">"Jak rozmawiać z klientem, który nie wie, czego chce"</a> w rozdziale "7. Sztuka konwersacji z klientem".Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-82194476522344764222017-11-04T00:11:00.002+01:002017-11-04T00:15:22.714+01:00Poproszę kartę PayBack!<p><i>Poproszę kartę PayBack!</i> - z niezachwianą pewnością w głosie wypaliła dziś do mnie obsługa stacji BP.<br />
</p><p>Najpierw poczułem lekki niepokój - <i>Rany, nie mam karty PayBack!</i>, następnie poczucie winy, bo <i>przecież nie mam karty PayBack, a Pani prosi</i> i na końcu złość odbijająca się w mojej głowie głośnym WFT.<br />
</p><p>Szczęśliwie miałem jeszcze przed sobą chwilę jazdy, żeby zastanowić się na spokojnie, co tam się właściwie wydarzyło. <br />
</p><p><i>Poproszę kartę PayBack!</i> - to hakerskie zdanie, które zawiera w sobie ukryte założenie, że kartę PayBack posiadam. Aplikowanie klientowi takiego pytania wywołuje w nim - tak jak we mnie - wrażenie, że skoro akurat nie ma tej karty, to jest to nie w porządku i powinien ją czym prędzej założyć u życzliwiej - a jakże! - obsługi stacji benzynowej. W dodatku jest to polecenie do wykonania, a nie pytanie, co tylko potęguje nerw klienta. <br />
</p><p>Od razu przypomniałem sobie sytuację sprzed kilku lat, gdy dostałem telefon od jednego z ubezpieczycieli, a tam głos w słuchawce <i>Dzień dobry! Czy zależy Panu na bezpieczeństwie Pańskiej rodziny i umówi się Pan ze mną na rozmowę w sprawie ubezpieczenia na życie?</i>.</p><p>Było to diabelstwo level wyżej. Gdyż w jednym pytaniu zamkniętym - na <i>tak || nie</i> upakowane zostały dwa pytania. Pierwsze, na które oczywiście się zgodzę. Drugie zaś to właściwa intencja manipulanta z drugiej strony kabla. Hack polegał na tym, że odpowiadając automatycznie na całe pytanie, niechcący można zgodzić się na spotkanie, a gdy to już się stanie manipulant skorzysta z zasady konsekwencji i zaciągnie Cię do oddziału ubezpieczyciela.<br />
</p><p>Wróciłem na tę stację.<br />
<i>- Przepraszam, dlaczego powiedziała Pani do mnie "Poproszę kartę PayBack" zamiast najpierw zapytać "Czy ma Pan kartę PayBack?<br />
- Tak nam każą mówić. Nie wolno nam inaczej zwracać się do klientów</i>. <br />
No brawo za szczerość.<br />
</p><p>I tu dochodzimy już do poważnych spraw - do zasad. Na stronie BP można znaleźć ichni <a href="https://www.bp.com/content/dam/bp-country/pl_pl/pdf/CODE%20OF%20CONDUCT_2014.pdf">Kodeks Postepowania</a>, w którym stoi jak byk:<br />
</p><div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-j3s4ye6TSHE/Wfzs0labefI/AAAAAAAAF-0/1zqUGRsNZPE_vg4XjGHmhwxAUn7eh2VrgCLcBGAs/s1600/Snip20171103_17.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://4.bp.blogspot.com/-j3s4ye6TSHE/Wfzs0labefI/AAAAAAAAF-0/1zqUGRsNZPE_vg4XjGHmhwxAUn7eh2VrgCLcBGAs/s320/Snip20171103_17.png" width="320" height="91" data-original-width="1600" data-original-height="457" /></a></div><p>No, więc uwaga ludkowie od trenowania i pisania skryptów dla obsługi stacji benzynowych: strzelanie w klienta manipulacyjnymi komunikatami to rażący brak szacunku dla klienta i niezwykle mierne standardy etyczne. Czuć, że coś się rozjeżdża między deklaracją wartości a ich praktycznym stosowaniem. <a href="https://en.wikipedia.org/wiki/Bob_Dudley">Bob Dudley</a> nie jest z tego dumny. Słowo daję, że przy następnej prośbie o kartę PayBack kasier/ka usłyszy - <i>Czy przestał/a już Pani/Pan obnażać przed nieznajomymi?</i>.<br />
</p><p>Z podobnym numerem spotkasz się w Castoramie <i>Poproszę kod pocztowy!</i> - pyta kasjer z pewnością w głosie. Nie podawaj kodu, nie bierz udziału w badaniach marketingowych, za które Ci nie płacą :).<br />
</p>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-92629754620410272017-10-20T11:44:00.000+02:002017-10-20T11:48:46.346+02:00Dosypywanie pieniędzy - podstawowy problem zwinności<p>Przypomnij sobie (bądź wyobraź) urządzanie swojej własnej kuchni...<br />
Właśnie zamontowali piękne białe blaty i trzeba wypełnić otwór na zlewozmywak. Stoisz więc przed dylematem:<br />
</p><ul><li>zlewozmywak z blachy kwasoodpornej za ok. 300zł - w pełni funkcjonalny, no ale kolorem odbiega od białego blatu<br />
<li>biały zlewozmywak porcelanowy za ok. 1 500zł - pięć razy droższy, ale biały, doskonale pasujący do blatu<br />
</ul><a href="http://www.kuchenny.com.pl/obrazki3/zlewozmywak_ze_stali_nierdzewnej_Linea_Teka_Top_260117.jpg" imageanchor="1" ><img border="0" src="http://www.kuchenny.com.pl/obrazki3/zlewozmywak_ze_stali_nierdzewnej_Linea_Teka_Top_260117.jpg" width="320" height="290" data-original-width="702" data-original-height="637" /></a>
<p>Teraz zaczyna się liczenie budżetu i załóżmy, że na porcelanę sporo brakuje. Można oczywiście wstrzymać się z decyzją na bliżej nieokreślony czas. Jednak w tym okresie kuchnia będzie nie w pełni funkcjonalna. No, a przecież nie o to chodzi. Decydujesz się więc na zlew z blachy kwasoodpornej z nadzieją, że w przyszłości wymienisz go na porcelanowy. </p><p>To jest właśnie cecha zwinności: podejmowanie decyzji w aktualnej sytuacji i w aktualnych ograniczeniach. Podejmowanie ich tak, aby maksymalizować wartość z wykonanej pracy oraz minimalizować straty i nieużytki. </p><h2>Tylko, że w organizacjach taka sytuacja to rzadkość</h2><p>W organizacjach, gdy brakuje pieniędzy na prace, to się ich często dosypuje (podkreślam: "często" nie "zawsze" i nie "w każdym bez wyjątku" lecz w "bardzo wielu przypadkach") </p><p>A następnie:</p><ul><li>Zespół pracuje nad sprintem i nagle wpada jakiś ubermanager z innej galaktyki z superpilną wrzutką. Product Ownerze, robimy? No, robimy. Przecież to superpilne, a ubermanager przyszedł z workiem pieniędzy<br />
<li>Zespół regularnie nie dowozi sprintu. I co? I nic, biznes poczeka i dosypie trochę kasy.<br />
<li>Od roku żaden sprint nie ma sensownego celu. Luzik, mamy już zaklepane mendeje na kolejny kwartał.<br />
<li>Zespół jest maksymalnie zdemotywowany. Chce pracować, chce być zwinny, chce mieć FOCUS, chce OPENESS i inne też chce. Ale co z tego, jeśli cokolwiek nie zrobi i tak się nic nie stanie?<br />
</ul><h2>Tymczasem w małej firmie na dorobku</h2><p>W małej firmie na dorobku, Scrum wygląda nieco inaczej. Zarządzanie małą firmą na dorobku przypomina podtapianie się. Miesiąc w miesiąc zastanawiasz się, czy masz na wypłaty (dla pracowników, z wypłatami dla siebie to różnie bywa). I wtedy musisz podejmować decyzje i respektować ograniczenia, bo od tego zależy Twoje być albo nie być. </p><p>Konkludując: Chcesz, aby zespół pracował zwinnie? Nie dosypuj pieniędzy!</p>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-29595839422429085822017-09-25T23:44:00.001+02:002017-09-25T23:49:28.710+02:00Byte My Code 7. października<div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-FZ19ZmcTIsY/Wcl0b8xSoBI/AAAAAAAAF9o/DKV3KnUo8xMfW3Y5gaaWtpA4IEEp9Gi_gCLcBGAs/s1600/0DVRXPBwBfwctBkRo%252Cbytemycode_-_info_pl.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://4.bp.blogspot.com/-FZ19ZmcTIsY/Wcl0b8xSoBI/AAAAAAAAF9o/DKV3KnUo8xMfW3Y5gaaWtpA4IEEp9Gi_gCLcBGAs/s320/0DVRXPBwBfwctBkRo%252Cbytemycode_-_info_pl.jpg" width="320" height="180" data-original-width="800" data-original-height="449" /></a></div><p>No więc, co robisz 7. października? Pytam, bo właśnie zostałem partnerem konferencji <a href="https://bytemycode.pl">Byte My Code</a><br />
</p><h3>Spotkaj się z Mistrzami Java: Wrocław, 7 października!</h3><p>Nowa Javowa konferencja pod szyldem UBS odbędzie się we Wrocławiu już7 października. UBS Polska zaprosił do Wrocławia Mistrzów Java i Java RockStars, którzy podzielą się wiedzą związaną z najgorętszymi nowinkami ze świata języka Java - a jak wiadomo, w tej dziedzinie dzieje się teraz wiele! Kto stanie na scenie Byte My Code u boku dwóch <b>#JavaChampions</b>?<p><p><h3>Java Champions pojawią się we Wrocławiu już 7 października</h3><p>Na scenie <a href="https://bytemycode.pl">Byte My Code</a> zobaczymy m.in. dwóch Java Champions: Josha Long i Kirka Pepperdine. Mikrofon wezmą do ręki też Łukasz Szydło, Sebastian Malaca, Michał Kordasa i inni mistrzowie programowania. Prelegenci mają bogate doświadczenie w takich zagadnieniach jak:</p><ul><li>Java<br />
<li>Spring<br />
<li>mikroserwisy<br />
<li>architektura aplikacji<br />
<li>automatyzacja<br />
<li>Agile<br />
<li>Domain-Driven Design<br />
<li>testowanie oprogramowania<br />
<li>Groovy<br />
<li>JVM<br />
</ul><p>Między innymi tych tematów możecie spodziewać się podczas Byte My Code. Obserwujcie <a href="https://bytemycode.pl">stronę konferencji</a> oraz wydarzenie na Facebooku, by być na bieżąco z aktualnościami.</p><h3>Spotkanie Mistrzów tylko dla 250 osób</h3><p>Pierwsza edycja Byte My Code przewidziana jest na 250 uczestników. Nie czekaj i zarezerwuj swój bilet: <a href="https://bytemycode.pl">https://bytemycode.pl</a> - chętnych na spotkanie Java Champions nie brakuje! </p>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-63373831896444638402017-09-18T21:39:00.001+02:002017-09-18T21:39:45.253+02:00Koniec z przytulaniem drzewTaka sytuacja...oderwany od przyjemnego kodzenia, wbijasz na retro, a tu radosny ScrumMaster rzuca Ci przed nos plik łososiowych karteczek, długopis z biedronką, a potem całkiem poważnie pyta: <i>Jaki kolor miał ten sprint?</i><br />
<br />
No i już wiadomo, że ScrumMaster właśnie wrócił z nowej ekstraedżajlowej konferencji (no, wiadomo, że tam się kręcą sami ScrumMasterzy), gdzie zasilił się nowoczesnymi technikami na retrospektywy. <br />
<br />
Ostatecznie dostajesz do wyboru: przytulanie drzew albo poszukiwanie wewnętrznego dziecka...<br />
<br />
A gdyby tak zostawić te drzewa w spokoju i zająć się czymś ciekawszym np. architekturą? <br />
<br />
Na przykład w ten sposób.<br />
<br />
<h2>Przed retrospektywą</h2><ol><li>Deweloperzy z Zespołu czytają rozdział "From Mud To Structure" z <a href="http://eu.wiley.com/WileyCDA/WileyTitle/productCd-0470059028.html">Pattern-Oriented Software Architecture, 4th Volume</a>.<br />
<li>Product Owner czyta rozdział "Warehouse Management Process Control" z tej samej książki i opcjonalnie rozdział dla deweloperów.<br />
</ol>
<h2>W trakcie retrospektywy</h2><ol><li>Temat do dyskusji: w jaki sposób idee w tekście mają przełożenie na architekturę systemu, nad którym pracujecie<br />
<li>ScrumMaster dba o timeboxing i o to, aby pojawiające się pomysły zostały konkretnie nazwane<br />
<li>ScrumMaster dba, aby konsekwencje biznesowe poszczególnych pomysłów były zrozumiałe dla ProductOwnera<br />
<li>Pomysły spisujecie na osobnych kartkach (nie muszą być kolorowe ;) )<br />
</ol>
<h2>Na zakończenie retrospektywy</h2><p>Grupujecie pomysły według dwóch skal:</p><ul><li>mały/duży wpływ na rozwiązanie problemów w Waszym systemie<br />
<li>mała/duża trudność we wdrożeniu w życie<br />
</ul><p>Jako <i>action point</i> proponuję wybrać ten pomysł, który ma możliwie duży skutek oraz możliwie małą trudność we wdrożeniu.
</p>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-24745219755245210712017-09-08T00:14:00.000+02:002017-09-08T00:18:30.444+02:00Twórz wartość, zamiast ją kupowaćTym razem o finansach - tak dla odmiany.<br />
<br />
Jakieś dziesięć lat temu wkręciłem się w temat zarządzania finansami osobistymi, oszczędzania, inwestowania, itd.<br />
Straciłem trochę pieniędzy i o to przedstawiam mój własny, krwią i łzami nawożony wniosek: <b>Twórz wartość zamiast ją kupować</b>.<br />
<br />
Z książek czy kursów na temat finansów poznałem strategie inwestowania o różnych poziomach zarąbistości.<br />
Wszystkie one mają jedną rzecz wspólną - KUPUJ!<br />
<br />
Każą kupować obligacje, akcje, fundusze, kruszce, ziemię, monety, ubezpieczenia, obrazy, wino albo zwierzaki, a od czasu do czasu wrzucić coś na lokatę. Ostatecznie chodzi o kupowanie z nadzieją na wzrost wartości, który jak wiem z własnego doświadczenia, bywa, że nie nadchodzi.<br />
<br />
A teraz będzie jeb z dzidy i mój kontrprzykład. Napisałem <a href="http://gettingthingsprogrammed.pl">parę książek</a>.<br />
Do tej pory czytelnicy kupili ich 5905 (papierowe, ebooki i wypożyczenia). Moje łączne koszty na ich przygotowanie to ok. 2300zł, które poszło na obrazki do książek i na okładki. Z oczywistych względów nie wyceniam poświęconego czasu. <br />
<br />
Biorąc do obliczeń wyłącznie honorarium autorskie, mój "wynik inwestycyjny" wynosi 751%. Jeśli dodatkowo dodałbym do zysku wartość usług, które sprzedałem za pomocą tych książek, trzeba by zacząć dopisywać kolejne zera. W dodatku ta liczba może tylko wzrosnąć.<br />
<br />
Który doradca inwestycyjny tyle gwarantuje?<br />
<br />
Programista to wymarzony zawód, który pozwala na niczym nieograniczone tworzenie wartości. Twórz ją!Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-76535512801666785132017-07-16T22:29:00.002+02:002017-07-17T00:41:32.280+02:00Dzielenie User Stories z życia wzięte<p>Żona zakontraktowała ze mną poprawę sytuacji wieszaków na ubrania w garderobie. <br />
Garderoba jest tak wygospodarowana za pomocą ścianek kartonowo-gipsowych z powierzchni mieszkania, <br />
że znajduje się pod dość spadzistą częścią połaci dachu. <br />
</p><div class="separator" style="clear: both; text-align: center;"><a href="https://media.castorama.pl/media/catalog/product/cache/0/image/9df78eab33525d08d6e5fb8d27136e95/W/i/Wieszak_stojacy_pojedynczy_Ida-110782-56690_1.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://media.castorama.pl/media/catalog/product/cache/0/image/9df78eab33525d08d6e5fb8d27136e95/W/i/Wieszak_stojacy_pojedynczy_Ida-110782-56690_1.jpg" width="320" height="320" data-original-width="650" data-original-height="650" /></a></div><p>Konsekwencja tego była taka, <br />
jedyne wieszaki na ubrania jakie miały tam rację bytu ,to takie samodzielnie stojące w liczbie dwa.<br />
</p><p>Zgodnie z zasadą <i>safe-to-fail experiments</i> zacząłem od najtańszych. I gdy połamał się czwarty, czy piąty, <br />
a sumaryczny koszt wieszaków zbliżał się niebezpiecznie do 1kPLN otrzymałem, wspomniane zlecenie mojej PO.<br />
</p><p>Na naradę strategiczną zaprosiłem sąsiada, który rychło przekonał mnie do wykonania pracy samodzielnie.<br />
</p><p>No i się zaczęło:<br />
</p><ul><li>nie ma gdzie się rozeprzeć drążkami<br />
<li>prócz ciężaru ubrań na drążek będzie działać jeszcze szarpanie na boki, gdy ktoś nagle zapragnie<br />
wyciągnąć ubranie z samego końca składu - czyli karton-gipis nie wytrzyma szarpania <br />
<li>i inne mniej poważne rozważania budowlane<br />
</ul><p>Ostateczny plan działań rysował się następująco: </p><ul><li>usunąć listwę przypodłogową<br />
<li>na ścianę nakleić sklejkę 18mm, dodatkowo poprawić wkrętami, sklejka ma być oparta o podłogę<br />
<li>wieszak będzie przytwierdzony do sklejki i do podłogi<br />
</ul><p>Raźno wziąłem się do pracy, a pomocny sąsiad zorganizował potrzebną sklejkę. Wyglądało to tak: </p><div class="separator" style="clear: both; text-align: center;"><a href="https://2.bp.blogspot.com/-9XxMsWEOoTY/WWu5NXwBZcI/AAAAAAAAF38/yuNNq3fdmzcfXCkfh5KCGdCzxRDyl6l_gCLcBGAs/s1600/IMG_0079.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://2.bp.blogspot.com/-9XxMsWEOoTY/WWu5NXwBZcI/AAAAAAAAF38/yuNNq3fdmzcfXCkfh5KCGdCzxRDyl6l_gCLcBGAs/s320/IMG_0079.JPG" width="320" height="320" data-original-width="1600" data-original-height="1600" /></a></div><p>Jak to bywa, okazało się, że brakuje części, narzędzi i że praca zajmie kilka popołudni, zamiast jednego. Pokój przylegający do garderoby zaczął przypominać pobojowisko: </p><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-y2bCTqX0kIo/WWuae5zYZKI/AAAAAAAAF3U/vGTTnk1y3BsbA_wn2nM8s0KPrpMaOk6qgCLcBGAs/s1600/IMG_0075.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://1.bp.blogspot.com/-y2bCTqX0kIo/WWuae5zYZKI/AAAAAAAAF3U/vGTTnk1y3BsbA_wn2nM8s0KPrpMaOk6qgCLcBGAs/s320/IMG_0075.JPG" width="320" height="240" data-original-width="1600" data-original-height="1200" /></a></div><p>W tym momencie moja żona powiedziała STOP (nie jest to cytat dokładny). Okazało się, że bałagan w trakcie prac jest istotnym wymaganiem niefunkcjonalnym, które może położyć całe przedsięwzięcie. <p><h1>A co na to agile?</h1><p>Kocham wytwarzanie oprogramowania między innymi dlatego, że pomaga załatwiać ważkie sprawy codziennego życia. Takie jak chociażby montaż wieszaka w garderobie. </p><h2>Optymalizuj proces wytwórczy "pod klienta"</h2><p>Pierwsza zmiana w trybie pracy polegała na tym, by każdego wieczora po zakończeniu prac garderoba była gotowa do użytku, a pokój uprzątnięty. Mniej więcej tak: </p><div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-wk9l_1snLhs/WWuc9E7JUWI/AAAAAAAAF3c/zeF93MqDIe8mZClEiPYiOJKLIWT4NyP2ACLcBGAs/s1600/IMG_0084.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://4.bp.blogspot.com/-wk9l_1snLhs/WWuc9E7JUWI/AAAAAAAAF3c/zeF93MqDIe8mZClEiPYiOJKLIWT4NyP2ACLcBGAs/s320/IMG_0084.JPG" width="240" height="320" data-original-width="1200" data-original-height="1600" /></a></div><p>Z mojej perspektywy taki tryb pracy wymagał więcej wysiłku i trwał dłużej, a zatem był droższy. Najchętniej przeniósłbym żonę z dzieciakami na kilka dni do teściowej, a sam ogarnął temat w trzy pacierze. </p><p>Z drugiej strony obecność rodziny dawała pewne korzyści: </p><ul><li>informacje od żony: czy za wysoko, czy za nisko, czy wystarczająco miejsca do poruszania się<br />
<li>dzieciaki przeprowadzające testy obciążeniowe<br />
</ul><p>Nieustanna obecność klienta pozwoliła mi podnieść jakość produktu (w oczach tego klienta, rzecz jasna) i uniknąć poprawek na samym końcu, a w skrajnym przypadku całkowitego demontażu niefunkcjonalnego wieszaka. </p><p>A zatem w kontekście całości przedsięwzięcia (łącznie z odbiorem produktu i sprzedażą) było szybciej i taniej. Ode mnie zaś wymagało to takiego sposobu pracy, aby był on całkowicie zrozumiały dla klientki. </p><h2>Jak to zapisać w backlogu?</h2><p>Ten bardzo naturalny sposób pracy nie został wymyślony - został zaobserwowany. Zespołom trudno wpaść w ten tryb, no bo jak to zapisać w backlogu? </p>Jedną z najistotniejszych rzeczy w zwinności jest rozwijanie produktu w taki sposób, aby klient mógł obserwować postęp prac i nie musiał mieć do tego żadnej magicznej wiedzy. </p><p>Zapisywanie tegoż jest ważne, ale wtórne. Jeśli pracowałbyś w ten sposób, a w backlogu umieszczał wpisy postaci: </p><ul><li>Montaż wieszaka w garderobie - etap 1<br />
<li>Montaż wieszaka w garderobie - etap 2<br />
<li>Montaż wieszaka w garderobie - etap 3<br />
<li>Montaż wieszaka w garderobie - etap 4<br />
</ul><p>to będzie OK. Może jakiś neofita zwymyśla Cię na forum. Ale Twój klient będzie wiedział o co chodzi, bo będzie widział co się dzieje, więc będzie miał wpływ na to, co wytwarzasz i będzie wiedział za co płaci. I to jest zwinność. </p><h2>Czytelny backlog - większa przejrzystość</h2><p>Sąsiedzi odnotowali dwie rzeczy: moją absencję na placu zabaw oraz hałasy dobiegające z naszego mieszkania. Dopytywali więc żonę, co się dzieje. </p><p>Mogła odpowiedzieć: <pre><i>-Michał robi wieszak w garderobie i jest na etapie drugim.</i></pre>Ale czy to by ich zadowoliło? Czy hałasy nie były zbyt niepokojące? Powstał więc problem z przejrzystością mojej pracy. </p><p>Dla jej poprawienia mógłbym nieco przeformułować wykonywane zadania: </p><ul style="font-style:italic"><li>Jako Żona chcę zobaczyć różnicę między wieszakami stojącymi, a tym co robisz, żeby zrozumieć czy mi odpowiada pomysł<br />
<li>Jako Żona chcę powiesić chociaż puste wieszaki, żeby przekonać się jak tego można używać<br />
<li>Jako Żona chcę powiesić kilka lżejszych ubrań, żeby zobaczyć czy wygodnie się tego używa<br />
<li>Jako Żona chcę samodzielnie powiesić mniej używane ubrania, żeby zobaczyć czy mam wystarczającą ilość miejsca do poruszania się w garderobie<br />
<li>Jako Żona chcę powiesić tyle ubrań ile wlezie, żeby zweryfikować wytrzymałość wieszaka<br />
</ul><p>Zauważ, jak bardzo przeformułowanie zadań poprawia przejrzystość prac nad wieszakiem. Zwłaszcza z perspektywy mojej żony oraz pośrednich interesariuszy (zainteresowanych hałasem) w postaci sąsiadów. </p><p>Dzięki tej przejrzystości moja żona mogłaby sprawniej komunikować się z sąsiadami, a oni mogliby nagle zachcieć mieć podobny wieszak u siebie, gdyż otrzymali bardzo jasne informacje na temat tego, co się dzieje i co można zyskać na poszczególnych etapach prac. </p><h2>Czy to jest PSI?</h2><p>No sam powiedz, czy to PSI? </p><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-cW8Dfiue-UA/WWulmVhSRPI/AAAAAAAAF3k/1uyuMAkB04Yh-sca7YkLNBeOzl0RQl9XQCLcBGAs/s1600/IMG_0083.JPG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-cW8Dfiue-UA/WWulmVhSRPI/AAAAAAAAF3k/1uyuMAkB04Yh-sca7YkLNBeOzl0RQl9XQCLcBGAs/s320/IMG_0083.JPG" width="240" height="320" data-original-width="1200" data-original-height="1600" /></a></div><p>Mamy tu jakiś fragment wieszaka: mocowanie do ściany, ramię do wieszania, podpora oraz mocowanie do podłogi. Czy to już wieszak? W jakimś sensie tak, nie do końca o to chodziło, ale pewien typ ubrań można wieszać. </p><p>W PSI ważna jest literka P - potencjalnie. Gdyby ktoś chciał, to potencjalnie mógłby tego użyć, akceptując ograniczenia tej funkcjonalności. Dla mnie osobiście "P" oznacza, że klient ma wystarczający obraz tego, jak wieszak będzie wyglądał na końcu, aby dać zielone światło i pieniądze na dalsze prace. </p><p>W tym sensie ułomny pół-wieszak robi na kliencie o wiele lepsze wrażenie niż bałagan w pokoju, a w tle przerażający pisk szlifierki kątowej. </o> <h2>PSI zmienia się w SI</h2><p>SI, czyli <i>shippable increment</i>.</p><div class="separator" style="clear: both; text-align: center;"><a href="https://2.bp.blogspot.com/-sZpsGbEZ9ZQ/WWu0nilFKuI/AAAAAAAAF3w/nXyDccXZjb8uSRM1veNr-llBPwmb2ucwACLcBGAs/s1600/efekt%2Bko%25C5%2584cowy.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://2.bp.blogspot.com/-sZpsGbEZ9ZQ/WWu0nilFKuI/AAAAAAAAF3w/nXyDccXZjb8uSRM1veNr-llBPwmb2ucwACLcBGAs/s320/efekt%2Bko%25C5%2584cowy.jpg" width="320" height="213" data-original-width="800" data-original-height="533" /></a></div><h2>Czy tak trzeba, czy można robić?</h2><p>W zeszłym roku remontowałem łazienkę na działce, a wyglądało to tak. </p><div class="separator" style="clear: both; text-align: center;"><a href="https://2.bp.blogspot.com/-8kxClGXB46U/WWu4kFwVRWI/AAAAAAAAF34/-DZVm_kw-jQdb69wbchJX-FoSfbyaMNYgCLcBGAs/s1600/%25C5%2582azienka.gif" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://2.bp.blogspot.com/-8kxClGXB46U/WWu4kFwVRWI/AAAAAAAAF34/-DZVm_kw-jQdb69wbchJX-FoSfbyaMNYgCLcBGAs/s320/%25C5%2582azienka.gif" width="320" height="213" data-original-width="800" data-original-height="533" /></a></div><p>Żona i dzieci wypoczywali nad morzem. Żadnych szczegółowych wytycznych do łazienki nie było, prócz takiej, żeby ją w końcu naprawić. Więc rozoraliśmy z tatą pół domku, a po tygodniu łazienka była gotowa. Żadnego sprzątania na wieczór - proces wytwórczy zoptymalizowany "pod wykonawcę". </p><p>Podsumowując mamy dwa sposoby optymalizacji pracy nad oprogramowaniem: </p><ul><li>"montaż wieszaka w garderobie" - optymalizacja procesu wytwórczego "pod klienta"<br />
<li>"remont łazienki na działce" - optymalizacja procesu wytwórczego "pod wykonawcę"<br />
</ul><p>Który i kiedy wybrać? To będzie na deser ;) </p><br />
<br />
<br />
<br />
Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-37455644457405284362017-02-17T15:45:00.000+01:002017-02-17T15:45:00.215+01:00Uważaj na negatywne kryteria akceptacjiJeden z portali dostarczył sposobności, aby krótko przybliżyć niebezpieczeństwo negatywnych kryteriów akceptacji. Popatrzmy na rysunek:<br />
<br />
<div class="separator" style="clear: both; text-align: center;"><a href="https://2.bp.blogspot.com/-I3mzcpd2ci8/WKM-6W2S94I/AAAAAAAAFsw/XhUYQSAKzaw7CYQMDV0ghMaPQLKAoC0hgCLcB/s1600/Przechwytywanie.PNG" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://2.bp.blogspot.com/-I3mzcpd2ci8/WKM-6W2S94I/AAAAAAAAFsw/XhUYQSAKzaw7CYQMDV0ghMaPQLKAoC0hgCLcB/s320/Przechwytywanie.PNG" width="320" height="266" /></a></div><br />
No więc, <i>Są świadkowie, którzy nie słyszeli sygnałów dźwiękowych</i>".<br />
<br />
Zdejmijmy sobie schemat tego stwierdzenia: <i>Istnieją X, które nie odebrały informacji A</i>.<br />
<br />
I zastosujmy ten schemat w innym kontekście: <i>Są dinozaury, które nie zwróciły uwagi na nadlatujący meteoryt</i>.<br />
<br />
Czy w takim razie możemy wyprowadzić stąd logiczny wniosek, że meteorytu nie było?<br />
<br />
Bingo! Fakt, że coś się nie zdarzyło nie implikuje, że zaistniało coś przeciwnego. Jeśli klient <i>oczekuje, że nowa funkcjonalność ma nie być uciążliwa w użytkowaniu</i>, to niesie to za sobą informację o UX, ale nie mówi Ci co konkretnie ma zostać dostarczone.<br />
<br />
Idźmy dalej. Przekonwertujmy w/w schemat w inne logicznie równoważne schematy: <br />
<ul><li><i>Niektóre z X nie odebrały informacji A</i></li>
<li><i>Nie wszystkie z X odebrały informację A</i></li>
</ul><br />
i teraz ponowna aplikacja do tytułu portalowego newsa:<br />
<ul><li><i>Są świadkowie, którzy nie słyszeli sygnałów dźwiękowych.</i></li>
<li><i>Niektórzy świadkowie nie słyszeli sygnałów dźwiękowych</i></li>
<li><br />
<li>Nie wszyscy świadkowie słyszeli sygnały dźwiękowe</li><br />
</li>
</ul><br />
Które zdanie pobudza Cię najbardziej? :)<br />
<br />
Język naturalny pozwala na takie żonglowanie kontekstami i znaczeniami pojęć, aby tą samą informacją wywołać wrażenie innych pseudologicznych wniosków. Język wymagań ma dążyć do jednoznaczności.<br />
<br />
<br />
<br />
<br />
Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-38965131592778465402017-02-01T19:48:00.000+01:002017-02-01T19:48:58.459+01:00Getting Things Programmed - nominacjeMoja książka <a href="helion.pl/ksiazki/getting-things-programmed-droga-do-efektywnosci-michal-bartyzel,droppp.htm">Getting Things Programmed</a> została nominowana do konkursu wydawnictwa Helion jako:<br />
<ul><li>Najlepsza książka w kategorii Programowanie</li>
<li>Najlepsza książka roku 2016</li>
</ul><br />
Jeśli więc miałeś okazję się z nią zapoznać i uważasz, że jest warta Twojego głosu - to poproszę o ten głos.<br />
<br />
Więcej informacji na: <a href="http://helion.pl/osk-nom.phtml">http://helion.pl/osk-nom.phtml</a> i <a href="https://www.facebook.com/HelionPL/photos/a.181711655567.160975.177988375567/10154767308650568/?type=3&theater">Facebooku</a>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-60049108143227547892017-01-04T01:02:00.002+01:002017-01-04T01:02:55.859+01:00Jak dostarczać przetestowane zadania?Poniższe pytania i odpowiedzi są możliwie konkretne. Niestety im bardziej konkretna odpowiedź, tym mniejszy kontekst jej stosowalności. I jeszcze bardziej niestety duża szansa na zastosowanie odpowiedzi w niewłaściwym kontekście albo (z powodu nieuwagi autora) wyciągnięcie z tych odpowiedzi wniosków, których autor wcale nie miał na myśli.<br />
<br />
Z w/w powodów proszę aby, jeśli wyciągniesz z poniższego tekstu wniosek, który jest sprzeczny ze zdrowym rozsądkiem, Twoim doświadczeniem, Scrum Guidem itp., niezwłocznie mnie o tym poinformuj w komentarzu – w miarę możliwości doprecyzuję tekst.<br />
<br />
Problem:<br />
<ul><li>Sprint trwa 2 tygodnie<br />
<li>Zespół planuje prace na cały sprint<br />
<li>Po wykonaniu zadania PO zleca testy biznesowe osobom z biznesu i na tej podstawie odbiera zadania ze sprintu<br />
<li>Bywa, że osoby z biznesu nie zdążają przetestować zadania przed sprint review i zadanie jest undone<br />
<li>Jak zatem planować prace i współpracować, aby dostarczać zadania, które są done?<br />
</ul>
<h4>1. Czy powinniśmy zaplanować development tylko na 1. tydzień sprintu, dając tym samym biznesowi czas na przetestowanie w 2. tygodniu sprintu tego, co zrobiliśmy w 1. sprincie?</h4><p>- Nie. Tydzień siedzenia i czekania jest stratą czasu i pieniędzy.</p>
<h4>2. Czy w takim razie powinniśmy zorganizować prace tak, że testowanie biznesowe odbywa się w kolejnym sprincie?</h4><p>- Nie. Poprawki zgłoszone do zadań z poprzedniego sprintu będą zaburzać wasze prace w bieżącym sprincie.
Modelowo zespół pracuje time & material i otrzymuje wynagrodzenie na koniec sprintu za to, co dostarczył w sprincie. Z perspektywy zespołu nie ma sensu robić w sprincie pracy, która na koniec nie zostanie odebrana i opłacona.</p>
Jednym z kluczowych przesłanek za pracą w iteracjach i inkrementach jest ta, że PO po każdym sprincie może zdecydować się na wstrzymanie prac programistycznych, aby skupić się na biznesowym zarabianiu na produkcie. Może też zdecydować, że już osiągnął to, co chciał i współpraca z zespołem dobiegła końca. Planowanie testów na kolejny sprint odbiera mu tę możliwość.</p>
<h4>3. Ale nasz PO liczy mendeje, które spaliliśmy w sprincie. Musimy zaraportować prace na jakieś zadania.</h4><p>- Dobrze, że je liczy. Powinien również liczyć zysk z dostarczonej pracy. Jeśli zysk jest, to w czym problem?</p>
<h4>4. Wy tym, że przecież nie możemy przez dzień czy więcej siedzieć tylko i pić kawę.</h4><p>- Częściowo to prawda. Chodzi nam o subtelną zmianę priorytetów: przestajemy dążyć do maksymalnej utylizacji Waszego czasu pracy, zaczynamy dążyć do maksymalnej wartości Waszej pracy.
Jeśli zatem okazuje się, że wszystko jest done i macie jeszcze czas w sprincie, to warto zastanowić się nad zwiększeniem dostarczanej wartości np. poprzez planowanie większej ilości wartościowej pracy.
Poza tym PO nie płaci za wykonane zadania/user story/funkcjonalności, lecz za osiągnięcie celu sprintu.<p>
<h4>5. Przypuśćmy, że mamy taką sytuację: w pierwszym tygodniu sprintu zrobiliśmy zadania i poprosiliśmy PO o akceptację (a więc o biznesowe przetestowanie). Czym mam się zająć w następnej kolejności?</h4><p>- Kolejnym zadaniem ze sprint backloga.</p>
<h4>6. Ale wszystkie są już ‘in progress’</h4><p>- Pomóż kolegom/koleżankom sprawniej uporać się z ich zadaniami, abyście szybciej osiągnęli cel sprintu.</p>
<h4>7. Ale oni mówią, że w tej chwili nie potrzebują pomocy i że będziemy sobie przeszkadzać</h4><p>- Zacznij testować zadania kolegów/koleżanek.</p>
<h4>8. Ale oni już zaczęli swoje testy deweloperskie?</h4><p>- Zacznij testować biznesowo.</p>
<h4>9. Ale to analitycy z biznesu mają się tym zająć.</h4><p>- A kto ma otrzymać wynagrodzenie za pracę, która jest done – Wy czy analitycy z biznesu?</p>
<h4>10. Czyli analitycy mają nie testować biznesowo?</h4><p>- Nie wiem jak jest ułożona Wasza współpraca. Może i mają testować, ale odpowiedzialność za dostarczenie celu sprintu spoczywa na zespole.</p>
<h4>11. Ale nie mamy żadnej metody, żeby ich zmusić do testowania na czas</h4><p>- Co do zasady, to da się zmusić współpracowników do pewnego zachowania, ale wtedy cały czas musisz podtrzymywać bodziec przymuszający np. zagrożenie eskalacją.
Ostatnie 40 lat doświadczeń wskazuje, że postawienie na współpracę, budowanie relacji i podejście win-win daje w typowym środowisku biznesowym lepsze efekty.</p>
<h4>12. A co zrobić jeśli analitycy nie mają czasu na testowanie?</h4><p>- Zgłosić PO. Jeśli nie mają czasu odebrać zadania, to nie jest ono wystarczająco ważne albo nie zostało przez nich wycenione biznesowo.
Osobiście rozważyłbym niebranie na sprint zadań, co do których nie ma zobowiązania, że zostaną odebrane.</p>
<h4>13. Mówiliśmy im, że mają się zobowiązać, ale oni mówią, żeby ze sporym wyprzedzeniem podać kiedy mają testować bo muszą zaplanować swoje prace, a my nie jesteśmy w stanie tego przewidzieć</h4><p>- Czyli chcecie, aby biznes zaplanował swoją pracę „pod Was”, bo wy nie jesteście w stanie zaplanować swojej?</p>
<h4>14. To nie tak. Nie da się patrząc na zadanie podać nawet ‘mniej więcej’ kiedy będzie gotowe do testowania.</h4><p>- Prawdopodobnie zadania są zbyt duże. Prawdopodobnie należy się przyjrzeć refinementowi.
</p>
<h4>15. Nie da się ich bardziej podzielić.</h4><p>- Da się. Zróbmy warsztat na ten temat. Byle na Waszych przypadkach nie na ogólnych schematach.</p>
<h4>16. Powiedzmy, że chciałbym testować biznesowo, ale nie wiem jak, nie mam potrzebnej wiedzy.</h4><p>- Zapytaj analityków z biznesu.</p>
<h4>17. Mówią, że nie mają czasu.</h4><p>- Zapytaj jeszcze raz.</p>
<h4>18. Znów nie mają czasu.</h4><p>- Pytaj aż do skutku. Wpadnij na kawę, na lunch. Popracuj na ich piętrze.</p>
<h4>19. Nawet jeśli się czegoś dowiem, to testowanie idzie mi wolno nie wyrobię się do końca sprintu.</h4><p>- Do końca tego sprintu może i nie, ale za 2-3 może nabierzesz wprawy.</p>
<h4>20. A co jeśli do końca sprintu zostało 2 dni, czekamy tylko na wyniki testów biznesowych. Czy możemy zacząć nowe zadanie?</h4><p>- Zanim to zrobisz, to poświęć chwilę na refinement, poprawę jakości kodu, dopisanie koniecznych testów, spłatę długu technologicznego.</p>
<h4>21. Już to wszystko zrobiliśmy…</h4><p>- To dobierzcie zadanie z product backloga. Unikajcie w trakcie planingu wrzucania do sprint backloga zadań rezerwowych.</p>
<h4>22. Dlaczego? Przecież i tak dobieramy z backloga?</h4><p>- Ale z produktowego, a nie z napchanego sprint backloga.</p>
<h4>23. Co za różnica?
<p>- Taka, że jeśli na początku napchacie sprint backlog rezerwowymi zadaniami, to na koniec sprintu prawie na pewno zostaną Wam niewykonane zadania.</p>
<h4>24. Ale przecież chodzi o osiągnięcie celu sprintu, a nie o wykonanie wszystkich zadań.</h4><p>- To prawda. Jeśli cel jest osiągnięty i zostały jakieś zadania, to nie ma dramatu. Mimo to ludzie lepiej się czują jeśli zrobią wszystko, co sobie zaplanowali. Nawet jeśli doskonale rozumieją, że nie jest to celem, to niepusty sprint backlog ich ‘uwiera’.</p>
<h4>25. Czyli mamy planować tak, aby wykonać wszystkie zadania ze sprintu?</h4><p>- Nie. Tego nie powiedziałem. Powiedziałem tylko, żebyście unikali napychania sprint backloga rezerwowymi zadaniami. Tylko tyle. Popełniasz błąd wnioskowania polegający na niewłaściwym odwróceniu implikacji. Poczytaj o błędach poznawczych. np. <a href="http://dobreksiazki.pl/sztuka-myslenia-lojewskakrawczyk-maria,p311700?gclid=Cj0KEQiAtK3DBRCBxt-Yxduq5p4BEiQAbFiaPSD7wGyB-eyrI2ZnVm7xvHeokpFf3x5Uhe9cz-WiOncaAvDM8P8HAQ">Sztuka myślenia</a></p>
<h4>26. Przypuśćmy zatem, że dobierzemy jakieś zdanie z product backloga. W takim razie te zadania nie zostaną przetestowane biznesowo do końca sprintu.</h4><p>- To podzielcie na mniejsze i sami testujcie biznesowo.</p>
<h4>27. No, to powiedzmy, że zostało 2h do końca sprintu, dobrałem zadanie i na pewno nie zostanie ono przetestowane biznesowo do końca sprintu.</h4><p>- No, prawdopodobnie nie zostanie.</p>
<h4>28. Ale wcześniej napisałeś, żeby nie robić takich zadań, bo jak skończymy współpracę na tym sprincie, to nam nie zapłacą za nieodebrane zadania.</h4><p>- Istnieje takie ryzyko. Zmniejszasz je dobierając zdania z wierzchu product backloga w nadziei, że kolejny sprint jednak ruszy, dokończysz to zadanie i otrzymasz zapłatę.</p>
Lecz zanim zdecydujesz się rozgrzebać zadanie, które będziesz kontynuował w kolejnym sprincie, najpierw przeprowadź w/w 27-punktowy ciąg rozumowania ;)</p>Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-35246441549257835062016-10-10T06:23:00.001+02:002016-10-11T23:25:41.098+02:00A Lesson Learned form Publishing New Book<div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-ARK9xlBHLno/V_sR9ch5IjI/AAAAAAAAFoc/Q-CpkxHna8gQOuyirXwtOzlxE9LUPLFKQCLcB/s1600/Przechwytywanie.JPG" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://1.bp.blogspot.com/-ARK9xlBHLno/V_sR9ch5IjI/AAAAAAAAFoc/Q-CpkxHna8gQOuyirXwtOzlxE9LUPLFKQCLcB/s320/Przechwytywanie.JPG" width="234" height="320" /></a></div>A week ago <a href="https://www.infoq.com/">InfoQ</a> publisher released my new book: <a href="https://www.infoq.com/minibooks/conversation-patterns">Conversation Patterns for Software Professionals</a>.<br />
<br />
For those of you who asked me about an english versions of my writing - this is it. Whole book was designed for the English-speaking reader.<br />
<br />
Once I tried to publish outside Poland my <a href="http://helion.pl/ksiazki/oprogramowanie-szyte-na-miare-jak-rozmawiac-z-klientem-ktory-nie-wie-czego-chce-wydanie-ii-rozsz-michal-bartyzel,opszm2.htm">'How to Talk to the Clients Who Don't Know What They Want'</a> book. But concept of the book was refused by publishers I contacted with. <br />
<br />
Then I decided to release small pieces of the book wrapped in articles at InfoQ. I hoped someday I would be able to publish them in the form of a book. <br />
<br />
It took 2 years and 4 months - quite quickly, I think. Lesson learned: I over value my one-year capabilities, I under value my 10-years capabilities.<br />
<br />
eBook version is exclusively available for free at <a href="https://www.infoq.com/minibooks/conversation-patterns">InfoQ</a>. Printed (paid) version will be available soon at amazon.com and <a href="http://www.lulu.com/shop/micha%C5%82-bartyzel/conversation-patterns-for-software-professionals/paperback/product-22891113.html">lulu.com</a>.<br />
Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0tag:blogger.com,1999:blog-1759916214638009707.post-60151933575247111902016-09-26T09:00:00.000+02:002016-09-26T09:06:49.733+02:00Rethinking Software ArchitectureFrom time to time everybody feels that the architecture of the software one develop is quite closer to a <a href="https://en.wikipedia.org/wiki/Big_ball_of_mud">big bull of mud</a> that the <a href="https://8thlight.com/blog/uncle-bob/2011/09/30/Screaming-Architecture.html">screaming architecture</a>.<br />
<br />
I give you plan of a workshop you may lead with your team. This is a part of my <a href="http://bnsit.pl/szkolenie,architectural-kata-dla-zwinnego-zespolu">ArchitecturalKata for an Agile Team</a> workshop.<br />
<br />
<h1>What is the Goal</h1>We want to achieve agreed and clear vision of the architecture. I am really pragmatic person. So I am not going to push you to introduce some sexy solutions as: DDD, Clean Architecture, CQRS, Event Sourcing and stuff. It may happen it may not. <br />
<br />
There are many criteria to meet to achieve these architectures. Here, our goal is to move your architecture into a better place, even it mean a step forward. We want the architecture to be more testable, maintainable and more decoupled. That's all.<br />
<br />
<h1>What We Need?</h1><ul><li>a team who work on the system (recommend no more than 10 people)<br />
<li>1-2 days<br />
<li>silent classroom<br />
<li>space on the walls or on the floor<br />
<li>quite big table or space on the floor<br />
<li>couple blocks of sticky notes in many colors<br />
<li>colored markers<br />
<li>pair of scissor<br />
<li>printer paper<br />
<li>big flip-chart sheets<br />
<li>paper tape<br />
<li>a computer with a code baseline<br />
<li>beamer (useful but not necessary) <br />
</ul><h1>See Responsibilities</h1>Because flow of that workshop varies in some details depends on the software size and granulation, I give you an example for the quite big legacy system (developed from more than a decade, where primary building blocks are components containing many classes). <div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-9MNrwfPDzl4/V-Qa3NN898I/AAAAAAAAFms/a3CvODpiagEoTzNZCDgzNrxi0C0qVrq-wCLcB/s1600/Krok1.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://1.bp.blogspot.com/-9MNrwfPDzl4/V-Qa3NN898I/AAAAAAAAFms/a3CvODpiagEoTzNZCDgzNrxi0C0qVrq-wCLcB/s320/Krok1.jpg" width="320" height="181" /></a></div><ol><li>First, capture all your components. Write each on a sticky note. It may be hundred of them or more but not so much :)<br />
<li>Then look into the source code and try to name responsibilities. Responsibility is a role of the component and the way how it serve to others. So, you will find them looking at the public methods, events published, signals sent. Sometimes one strange method is one responsibility, other time group of related method define a responsibility.<br />
<li>That's important: <b>name only those responsiblities you see in the code, not those you think they are</b><br />
<li>Don't be too detailed with the granulation of the responsibilities. Be ready to regroup and rename them any time you want<br />
<li>Probably you know that in a legacy code components have many responsibilities, so name them explicitly and write them on small stickies. Next put small stickies on components they come from<br />
<li>You will see than you have two to four components which looks like stars with its satellites :) These are components where single responsibility principle was really abused. There is much code inside<br />
</ol><h1>Redefine Responsibilities</h1>Now its time to redefine responsibilities of the components. Organize your components obeying following rules: <ul><li>A component has exactly one coherent responsibility<br />
<li>You are allowed to add new components<br />
<li>You are allowed to remove components<br />
<li>You are allowed to rename components<br />
</ul><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-M6khYTN7M3Y/V-ROQgdW2mI/AAAAAAAAFnA/yaXvve2ZEHcGBCHXdIDWxo11T44vh62aQCLcB/s1600/Krok2.jpg" imageanchor="1" style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><img border="0" src="https://1.bp.blogspot.com/-M6khYTN7M3Y/V-ROQgdW2mI/AAAAAAAAFnA/yaXvve2ZEHcGBCHXdIDWxo11T44vh62aQCLcB/s320/Krok2.jpg" width="320" height="181" /></a></div>So now: <ol start="7"><li>Add/Remove/Rename components and reorganize responsibilities stickies<br />
<li>Repeat until every single component have sort of small stickies and all of them describe one coherent responsibility<br />
</ol><h1>Redefine Communication Between Components</h1><ol start="9"><li>Now draw directed lines representing communication between components and note purposes of a communication just right above the lines. A line starts from a component which initiate communication.<br />
<li>There is one rule during this exercise: <b>a line cannot cross an other line</b>. I will explain why at moment.<br />
</ol><div class="separator" style="clear: both; text-align: center;"><a href="https://2.bp.blogspot.com/-YPnHK01GVbY/V-RQ9Q8sdXI/AAAAAAAAFnM/O2S-GgEq3kMwEBsjW7m7e5321dqJXYQBQCLcB/s1600/Krok3.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://2.bp.blogspot.com/-YPnHK01GVbY/V-RQ9Q8sdXI/AAAAAAAAFnM/O2S-GgEq3kMwEBsjW7m7e5321dqJXYQBQCLcB/s320/Krok3.jpg" width="320" height="181" /></a></div><ol start="11"><li>Sometimes you will discover a cyclic dependency between components, so remove it, if needed.<br />
</ol><h1>Cluster Components</h1><div class="separator" style="clear: both; text-align: center;"><a href="https://1.bp.blogspot.com/-rJx_xXO39vg/V-RU1MKLC4I/AAAAAAAAFnY/Nw-ItgYX_Ecubc4XaVwMTYsDI-DusJ4RQCLcB/s1600/Krok4.jpg" imageanchor="1" style="clear: left; float: left; margin-bottom: 1em; margin-right: 1em;"><img border="0" src="https://1.bp.blogspot.com/-rJx_xXO39vg/V-RU1MKLC4I/AAAAAAAAFnY/Nw-ItgYX_Ecubc4XaVwMTYsDI-DusJ4RQCLcB/s320/Krok4.jpg" width="320" height="181" /></a></div><ol start="12"><li>The rule "don't cross the line" caused that components which work closely are stuck closely.<br />
<li>Try to circle clusters of closely related components. But there is important rule: <b>look for the clusters related to the functionality of the system</b>. Y<i>ou may ask yourself: What is the core cluster where we have minimal deliverable functionality? How to cluster components to extract potentially optional functionalities?</i><br />
<li>Name these clusters<br />
</ol><h1>Define Clusters API</h1>Now we want to see high-level view. We want to extract fine grained and decoupled clusters enclosed in modules, processes or separate applications. <div class="separator" style="clear: both; text-align: center;"><a href="https://4.bp.blogspot.com/-yvJFkcCh0nI/V-RbGWFwZDI/AAAAAAAAFno/FWw0EXPHW0kaSlXq80QvYwPgPvwPync0ACLcB/s1600/Krok4a.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://4.bp.blogspot.com/-yvJFkcCh0nI/V-RbGWFwZDI/AAAAAAAAFno/FWw0EXPHW0kaSlXq80QvYwPgPvwPync0ACLcB/s320/Krok4a.jpg" width="320" height="276" /></a></div><ol start="15"><li>First define an API for the clusters.Finally we want cluster-to-cluster communication instead of component-to-component. A component-to-component communication is fine inside the cluster, but not between them.<br />
<li>API receives communication from other clusters and distributes it inside of the cluster. It also translates the inside-cluster communication into outside one.Technically that translation layer will be some combination of facades and adapters.<br />
<li>Defining API remember that we have: exposed interfaces and required interfaces. Define both.<br />
<li>Also explain how the inside-cluster components talk to each other.<br />
<li>This is important: <b>obey the encapsulation rules: nothing from inside of the cluster is seen to the outside world</b><br />
</ol><h1>Define Communication Between Clusters</h1><ol start="20"><li>Draw communication between clusters. It will be API-to-API communication, it mean exposed interface to required interface.<br />
</ol><div class="separator" style="clear: both; text-align: center;"><a href="https://3.bp.blogspot.com/-urli48boweA/V-Rd_ty5dNI/AAAAAAAAFn4/QBsq5xETf2Ij7t-RLpH6ypX4o7bqzsJQwCLcB/s1600/Krok5.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="https://3.bp.blogspot.com/-urli48boweA/V-Rd_ty5dNI/AAAAAAAAFn4/QBsq5xETf2Ij7t-RLpH6ypX4o7bqzsJQwCLcB/s320/Krok5.jpg" width="320" height="207" /></a></div>This is it. Artifacts and discussions during that workshop bring quite clear understanding of the current state and well defined vision were want to be if about architecture of our software. <h1>How long it takes to refactor the code?</h1>Wel, it depends ;). I know the cases (software of that size) where it took a year or so total. Remember that visioning is a one thing, but bringing the vision into reality is completely different story. <h1>What Next?</h1>One of the next steps is a really tricky stuff. We need to prepare plan how to communicate our technical objectives to managers and all those people who have an authority to say YES or NO to our refactoring work. On the end we want them to support our new architecture.</br></br/>Working strategies to convincing sponsors are the key part of my <a href="http://bnsit.pl/szkolenie,architectural-kata-dla-zwinnego-zespolu">ArchitecturalKata for an Agile Team</a> workshop. If you want me to lead this workshop for your team, please contact me at the <a href="http://www.gettingthingsprogrammed.pl">contact form</a>.<br />
<br />
Anonymoushttp://www.blogger.com/profile/03968505875451301931noreply@blogger.com0