Współczesne architektury aplikacji - kto chętny?

Przymierzam się do napisania książki odnośnie kilku typów architektur, wykorzystywanych w obecnych systemach informatycznych m. in. o klasycznej monolitycznej architekturze warstwowej, DDD, ports and adapters/clean architecture, microservices, reactive architecture, serverless.

Książka skierowana będzie do osób początkujących jeśli chodzi o dziedzinę architektury - programista, który ma rok, dwa doświadczenia programistycznego i chciałby złapać szerszą perspektywę architektoniczną, zrozumieć założeniu kilku popularnych podejść, rozumieć różnice, mieć wyobrażenie na temat tego jak architektura może ewoluować, jakie czynniki mogą decydować o tym, na jakie rozwiązanie się zdecydować w danym kontekście. Pewien zarys możecie znaleźć w artykułach z ostatnich numerów Programisty (kwiecień, maj, czerwiec), zainteresowanym mogę przesłać na maila.

Mam już za sobą napisane dwie książki i dziesiątki artykułów, natomiast tym razem do tematu chciałbym podejść inaczej. W związku z tym poszukuję osób, które chciałyby uczestniczyć w procesie tworzenia książki, osób które odpowiadają profilowi docelowego uczestnika, osoby dla których wspomniane tematy architektoniczne nie są znane, lub są znane powierzchownie, hasłowo, w niewielkim stopniu, ale za to mają pewne doświadczenie programistyczne (może nawet nie być komercyjne). Współpraca byłaby pewnego rodzaju barterem - uczestnicy będą mieli okazję zdobyć wiedzę i umiejętności związaną z tworzeniem architektury, brać udział w dyskusjach (w zasadzie cały projekt to będzie bardzo pogłębione szkolenie z architektury), dostawać feedback odnośnie tworzonych implementacji. Będzie też opcja otrzymania potwierdzenia nabytych umiejętności oraz informacja w samej książce. Dla mnie współpraca będzie źródłem informacji nt. temat tego, co potencjalnemu czytelnikowi jest potrzebne, jakie pytania się pojawiają, jakie problemy stają na drodze. Będzie to „drive” do pisania książki, doboru treści. Książka ma być przede wszystkim praktyczna i pragmatyczna, niekoniecznie będąc encyklopedią nt. architektury.

Jak by wyglądała współpraca:

• osób byłoby kilka, w zasadzie byłby to mały zespół biorący udział w projekcie
• kołem napędowym prac będzie implementacja przykładowego systemu w różnych architekturach (od najprostszej do najbardziej skomplikowanej), w tym również jego refaktoryzacja, projekt będzie miał kod otwarty w momencie wydania książki
• mniej więcej raz w tygodniu będzie odbywać się 2-3 godzinne spotkanie (hangout), w trakcie którego będziemy dyskutować konkretne tematy (rodzaj architektury, wzorzec architektoniczny), analizować stworzoną implementację, rozmawiać nt. zawartości treści książki,
• uczestnicy będą też recenzować powstającą treść książki.

Szacuję, że całe przedsięwzięcie potrwa ok. pół roku. Osoby które chciałyby się zaangażować musiałyby być w stanie wygospodarować przynajmniej kilka godzin w tygodniu i zadeklarować się na uczestnictwo. Start pierwsza połowa września.

Technologia (język) nie ma większego znaczenia, szczególnie jeśli nie masz oporów w liźnięciu czegoś, czego nie znasz. Choć dodam, że będzie to najprawdopodobniej Java.

Jeśli taka tematyka jest dla Ciebie interesująca, widziałbyś korzyść z udziału w tego typu przedsięwzięciu lub masz pytania, to napisz maila (m __ sieraczkiewicz __ bnsit __ pl - wstaw w odpowiednie miejsca małpkę i kropki):

• dlaczego chciałbyś wziąć udział w tym przedsięwzięciu,
• na jakie pytania chciałbyś znaleźć odpowiedzi,
• jakie jest twoje dotychczasowe doświadczenie: ile lat, jakiego typu projekty, jakie technologie, jaka rola,
• jakie masz pytania?

Obrazek: https://www.extremetech.com/wp-content/uploads/2017/05/471213-best-ebook-readers-640x360.jpg

Read More

Unknown 14:05  2 comments

Pośpiech czyli coś tu śmierdzi

Kiedy myślę sobie o różnych problemach, z którymi zmagają się organizacje, szczególnie o powtarzających się problemach, to zdecydowanie najbardziej charakterystycznym objawem tego, że coś jest nie tak, jest pośpiech.

"Nie damy rady zorganizować 3 godzinnego warsztatu, bo nasi menedżerowie są strasznie zajęci"
"Musimy zrobić jednodniowe szkolenie - bo nie wyciągniemy menedżerów aż na dwa dni"
"Nie przyjdę na Sprint Review, bo mam kilka tematów do dokończenia"
"Prześle Ci podsumowanie spotkania (tekstem), bo nie znajdę czasu, żeby Ci to wytłumaczyć"
"To musi być koniecznie zrobione teraz, bo jutro zarząd tego potrzebuje"
"Nie mamy czasu na doprecyzowanie historyjek, bo mamy mnóstwo własnych zadań"

Znacie to?

Coraz bardziej się przekonuję, że jeśli słychać w wypowiedziach osób, że nie mają czasu albo ktoś ważny dla ich projektu nie ma czasu, to jest to poważny problem, którego nie rozwiąże żadna technika, framework, zestaw narzędzi, szkolenie*, warsztat, trzęsienie ziemi. Nic!

* no chyba, że szkolenie z asertywności

Po co potrzebny jest czas? Widzę co najmniej kilka powodów:
1. Rozwiązanie poważnych problemów (organizacyjnych, procesowych, projektowych) wymaga refleksji, która wymaga zatrzymania, które wymaga czasu.
2. Dobra komunikacja wymaga czasu - po co szkolić się z komunikacji, jeśli każda osoba w firmie jest wiecznie zabiegana. Tak! Dobra komunikacja wymaga czasu, czasu na:

• wyjaśnienie problemowych sytuacji,
• odkrycie że jest problem i na czym on polega,
• zsychronizowaniu tego co wiedzą wszyscy zaangażowani w temat,
• zrozumienie celów i intencji innych.

Bez tego ani rusz!

3. Planowanie wymaga czasu, a w szczególności w celu jednoznacznego zdefiniowania i określenia, jakie są kryteria osiągnięcia celu.

4. Priorytetyzowanie wymaga czasu - selekcja rzeczy nieważnych. To jest główny punkt, jak nie masz czasu, robisz wszystko co popadnie, więc nie masz czasu. Odrzucanie, mówienie "nie"*, selekcja, zastanawianie się, gdzie jest owo 20% z zasady Pareto wymaga mnóstwo czasu, ale dzięki temu robisz 20% pracy a nie 95%.

* to po to, to szkolenie z asertywności

Jeśli nie masz czasu, to z ogromną dozą prawdopodobieństwa, marnujesz swój najcenniejszy w życiu zasób, jakim jest czas (poza samym życiem oczywiście ;-)).

Read More

Unknown 12:54  4 comments

Antywzorzec Adrenaline Junkie

Cały czas zastanawia mnie skąd biorą się takie sytuacje, że jest generowana presja i napięta sytuacja w projektów. Jednym z powodów jest to, że większość projektów jest zwyczajnie złożona – trzeba dogadać kilka, kilkanaście czasami kilkadziesiąt osób, trzeba przewidywać i planować z pewnym wyprzedzeniem to co się wydarzy, jakie zasoby będą potrzebne. Jak gatunek ludzki wcale nie jesteśmy w tym dobrzy (vide: David Rock – Twój mózg w działaniu) – w szczegółowym planowaniu długoterminowym.

Drugi mechanizm, który dokłada swoją cegiełkę do choasu, to syndrom adrenaline junkie. Termin ten pierwotnie został ukuty w kontekście sportowym i dotyczy osób, które świadomie szukają aktywności, który podnoszą poziom adrenaliny, sytuacji z lekka niebezpiecznych, których spora część osób wolałaby uniknąć. Uwielbiają kiedy coś się dzieje, kiedy sytuacja wymyka się spod kontroli, bo wtedy są niezbędni, wzrasta poziom adrenaliny i jest zabawa. Sytuacja staje się bardziej subtelna, kiedy adrenaline junkie ma na sobie garnitur i chodzi pod krawatem, a przynajmniej chowa się za kierowniczym stanowiskiem – wtedy dodatkowo ma duży poziom wpływu, który daje spore możliwości, aby wywoływać zamieszanie. To działanie nie jest świadome – po prostu tak się dzieje. (W kontekście projektów IT zostało do opisane w książce "Adrenaline Junkies and Template Zombies")

Po czym poznać adrenaline junkie? Taka sytuacja.

Siódma rano pobudka. Jeszcze 5 minut. Drzemka. Kolejna drzemka. Kolejna. Ok. 7.30 trzeba już w stać, bo o 8.00 powinienem być w pracy. Mam umówione spotkanie. Już praktycznie nie ma szans, żeby udało mi się zdążyć. Szybko biegnę pod prysznic, mycie zębów, w pośpiechu ubieram się. Cholera – jeszcze muszę wyprasować te spodnie. Wychodzę 8.53. Na pewno nie zdążę. Ile się spóźnię? 20 minut? Może się uda. Dzwonię do osoby, z którą się umówiłem. Będę 8.15. Wsiadam do autobusu. Cholera korki na drodze. Fakt – zawsze były korki. Autobus się wlecze. Chyba jednak nie zdążę na 8.15. Tyle razy sobie mówię, żeby nie siedzieć do 4 nad ranem. Dzisiaj już na pewno pójdę spać wcześniej. Docieram na spotkanie o 8.25. Mój rozmówca jest zdenerwowany. Staram się żartami nieco rozbroić sytuację. Spotkanie kończy się o 9.30. Później mam następne. Później następne. Później następne. Do 16.30 mam same spotkania! A kiedy pracować? 16.35 coś by się przydało zjeść. Nie mam czasu. Idę do najbliższego sklepu i kupuję 3 batony. Ale co za dzień! Tyle pomysłów wygenerowaliśmy, szykują się nowe tematy w projektach. Fakt, że po całym dniu spotkań, trzeba to wszystko jakoś zebrać, maile powysyłać, pospisywać zeznania. Ale teraz pędzę do domu, a w zasadzie do szkoły, żeby odebrać córkę. Chwila czasu dla rodziny. W międzyczasie ktoś dzwoni. Musiałem wyjaśnić kilka szczegółów, których nie udało się dogadać w ciągu dnia. Próbuję bawić się z dziećmi, ale cały czas to, co się wydarzyło w ciągu dnia wraca i zaczynam analizować, co jeszcze można by zrobić. Znowu dzwoni telefon. Dzwoni zdenerwowany klient, który chce zerwać współpracę, bo jest niezadowolony. Przerywam zabawę z dziećmi. Po pół godzinie udaje mi się uporać z klientem – jest udobruchany. No dobra, żeby teraz tylko dzieci poszły jak najszybciej spać – mam jeszcze tyle roboty. 21.30 uffff. W końcu spokój. Muszę przejrzeć, co mam jeszcze do zrobienia. Roboty chyba na kilka godzin. Nie ma co marudzić – trzeba działać. 22.30 trochę oczy mi się zamykają. Zrobię sobie króciutką drzemkę. Pobudka 23.00. O jak mi się nie chce wstawać, ale jakoś się dobudzam. Robię herbatę. Przeglądam fejsa. Po pół godzinie jestem już na rozruchu. Pierwszy mail, drugi, trzeci. Czuję wiatr w skrzydłach – kocham tę robotę. Godziny mijają nie wiadomo kiedy – 1.00, 2.00, 3.00.  Nie zauważyłem kiedy zasnąłem. Budzę się z bólem karku siedząc nad komputerem. Ok. Pora iść spać. Jutro o 8 mam spotkanie – tym razem nie mogę zaspać.

To typowy dzień adrenaline junkie. To typowy dzień niejednego kierownika projektu, właściciela firmy czy ambitnego lidera. Dla tych osób to co się dzieje, jest ok – przecież musi się coś dziać, żeby doprowadzić tematy do końca. Ciągle nie mają czasu, ale też ciągle generują sobie nowe tematy, nowe wyzwania, nowe zadania. Gdy poziom aktywności, a co za tym idzie, adrenaliny spada – robią się apatyczni,  niezainteresowani, znudzeni. Z drugiej strony są to często ludzie, którzy napędzają działania, są motorem napędowym zmian, lubią kiedy jest im niewygodnie, uwielbiają poświecenie się na 150%. Dlatego duża część z nich zostaje właśnie kierownikami czy dyrektorami, ale bardzo często oczekują podobnego poświęcenia od innych.

Adrenaline junkie to antywzorzec w kontekście pracy nad projektami czy produktami, ponieważ dla tego typu osób, produkt czy projekt jest drugorzędny, jest głównie pretekstem do tego, aby generować energie, poziom napięcia, wtedy pytania o sensowność czy wartość działań schodzą na drugi plan, bo ważniejsze jest to „żeby się działo”. Oczywiście w czasie realizacji działań, kiedy dużo się dzieje, tego nie widać w żaden sposób i powstaje sprytne złudzenie, że to co robimy jest ogromnie ważne i musimy to robić. Plusem takiej postawy jest generowanie energii, napędzanie innych do działania.

Powstaje oczywiście pytanie, co można z tym robić. I muszę przyznać, że nie znajduję łatwej odpowiedzi. W pierwszym odruchu chciałoby się powiedzieć: „zwolnić”, „pozbyć się”, „wymienić na kogoś innego, bardziej zrównoważonego”. Może to być trudne, jeśli dana osoba jest sponsorem czy też pomysłodawcą przedsięwzięcia. Takiej osoby nie będziemy w stanie przekonać o jej destruktywnym wpływie na całość. Zmiana tego typu postawy jest bardzo trudna, nawet jeśli tego dana osoba chciałaby coś z tym zrobić. Z dużym stopniu wynika z budowy i specyfiki układu nerwowego i hormonalnego. Spora część tego wzorca jest zakodowana w genach. Można by zasugerować, aby swoją energię upuszczali gdzieś indziej – na bieganiu maratonów, triathlonie czy sesjach boksu tajskiego. Ale prezesowi tego nie zasugerujemy, no chyba, że pijemy z nim wódkę. Osobiście, gdybym dostał się pod jurysdykcję takiego delikwenta – albo bardzo mocno ćwiczyłbym stawianie granic („OK, gościu – jeśli chcesz i cię to nakręca, to generuj sobie masę zajęć, natomiast ja chcę pracować 8 godzin. Kropka.” – powiedziane w ten lub bardziej dopasowany do rozmówcy sposób) albo zwyczajnie bym się zawinął, szukając bardziej przyjaznego miejsca.

Życzyłbym sobie, żeby takich adrenaline junkies było jak najmniej, bo takowi swoimi działaniami mocno erodują system. Z drugiej strony wiem, że gdyby nie oni, wiele fajnych rzeczy być może nigdy by się nie wydarzyło. Takie życie. Nic czarno-białe.

(image source: http://www.galwaydailynews.com/wp-content/uploads/2014/06/101001junkie_302.jpg)

Read More

Unknown 12:32  No comment

Perspective of the other side

While working with leaders I come accross the similar issue many times - they want somebody else to change their behaviour. For example:
How to deal with people that criticise my ideas?
How to force boss not to micromanage the team work?

We would like someone else to change, because we know that we are right, we have good intention and want to improve the work and the other side just disturb us. We believe that Agile/microservices/Product focus (not project)/whatever is the only idea that can help and everyone who doesn't agree is an enemy that should be ceased.
If somebody critices my ideas - must be wrong. If my boss try to micromanage he is an ignorant, because every book about management describe it as an antipattern.

But let's be honest - all ideas like:

• (the power of) teamwork
• limit work in progress
• authonomy (instead of micromanagement)
• timeboxing
• agile/kanban/lean
• TDD/BDD/ATDD/Spec by example
• (...place your lovely idea here...)

are just ideas. They are supported by a set of believes, but mostly subjective believes. You believe it or not, but you can't prove they are right. They are just models, theories, hypothesises, patterns, heuristics, strategies. Because they are applied in complex enviroments, there are contexts where they will be beneficial, and there are contexts where they will not, and sometimes it will be very difficult to evaluate their real value. So everytime you meet someone else who doesn't agree, be aware that s/he can be right. It is a first step neccessery to deal with the issue. It is secondary what you believe in, much more important is how you react when sb doesn’t agree or follow.

The most important obstacle to tacle the challenge is our tendency to look at the situation only from one perspective - "I" perspective. This perspective is subjective, because it is based on our current believes, expectations, state, knowledge and biasases. This is why it is so difficult to solve problems between people. If we really want to find a win-win solution, we need to try to see situation from the perspective of other side ("you" perspective).

If a person critices your idea, just try to find an answer "why"? But beware because we like to see negative intention in other people's behaviour. "He critices me because he wants to diminish me". In some rare cases it may be true but it is not the root inention. The root intention is in most cases positive, at least from the other side perspective.
S/he may criticise your idea because s/he wants ensure that the best possible solution will be applied. Or want to warn about potention problems that may arise.

In the second example, if boss want to micromanage, just ask "why is it important". He may want to ensure that work will be done correctly or will be done in standarized way. When you know the intention, it is easier to find a solution - different way how boss can ensure it not micromanaging.
If you just say "Micromanagement is evil", you will try to take something away from him what is important and give nothing instead.

So the next time when you don't like someones behaviour or attitude, try to look at the situation from its perspective asking question "why is it important for him/her? what is a positive intention" and then it will be much easier to tacle the situation. And remember most of the stuff you think is right way of doing things is just set of believes, subjective belives so don't be too much attached to it.

(Of course the subject is not specific only to technical leaders but can be attributed to whole human race.)

Image source: http://www.etcfn.com/wp-content/uploads/2015/04/Rainbow-over-Rabbit-Ears.jpg

Read More

Unknown 17:53  No comment

Simple things. Simple things. Simple things.

I have been yesterday to a great concert. The band is called domowe melodie. Here you can find one of their best know song. Of source the music was great, performance was great. But these things were not the only.

What hit me the most - these guys attitude to what they do. They just have a lot of fun from what they do. They play with it. They enjoy it and this is great and they do it in their own cute way. Just watch one of their videos. You get influenced immediately.

This reminded me what makes the juice of life. I wish we had so much fun and pleasure in our everyday jobs. The leaders (and everybody is a leader) can support making this happen. Be more emphatic, more smiling, more open. Life would be greater.

Don't do anything that isn't play - Marshall Rosenberg.

Read More

Unknown 15:16  No comment

Meetings in a hurry are not effective ones

The timeboxing is a fundamental technique for many Scrum activities. I can see a misunderstanding that meeting should be fast, a facilitator start to hurry up everybody to finish the meeting in the timebox. In the end problems are not discussed well and many uninformed decisions are made.

Time boxing in this case is about something different. It is for making conscious decision on choosing what and what not to talk about during the conversation. It is more for eliminating than for being in a rush.

In order to have effective timeboxed meeting as a facilitator:

1. ensure everybody agrees what is the goal of the meeting, what is expected outcome and what decisions should be made (eg. planning meeting - we want to have items discussed with defined acceptance criteria, estimated and have brush design),
2. ensure that agenda (structured) is agreed,
3. keep an eye on time,
4. if time is in danger, say it aloud and remind the goal, expected outcome and decision,
5. ask what participants think they should focus on or eliminate in order to get the results in the timebox,
6. if time is about to exceed the timebox, make an agreement for another time box (eg. we exceed the meeting for 30 minutes),
7. sum up the results,
8. sometimes it may be useful to make a short retrospective afterwards to find ways to improve the meeting.

image source: http://hubpages.com/health/How-to-Time-Box-your-life-Be-happier-and-healthier

Read More

Unknown 12:25  2 comments

Have a clear vision, stick to the intention and adjust the implementation

No matter if you are tech lead, Scrum Master, Product Owner or just (why just?) a member of the team, if you want to make your idea a reality I have a very simple (and of course very difficult to implement) advise:
Have a clear vision, stick to the intention and adjust the implementation

Let's consider an example. Let's suppose you believe that incremental work is cruciual and want to influence the team to work this way.

1) have a clear and strong imagination of the target state
The first thing is that you yourself really have to believe in it. And you have to be able to imagine what it would be like for your team .How the team could split the work into smaller increments, how to verify if something is a good small increment. You need some kind of reference in your experience, then it is much easier to have such a clear vision. If you don't the only thing you can do is getting more inspiration about the subject (reading the articles, books, listening the podcast, watching conference talks or just taking part in a conference) and then suggest an experiment. You can use Disney strategy to get more clearance.

1b) try to find as many WHY answers as possible.
First try to answer the question WHY yourself. Why is it really worth the attention?

Why increments?

• because it is easier to finish it in a short period of time
• because if you have many small pieces your overall estimations will be better
• if the increments are going to be very small, you may not need estimation at all
• increments (slices of functionality) improves your ability to finish done work
• you need to improve the way you work to be able to work in increments

Ok. But but then look for other resources - articles, books, blog posts and so on. And look for other arguments.
And then face these arguments (at the begging only in your mind) with your team. What would they answer? How that matches to the things important to them.

2) be patient and stick to intention
No matter how good arguments you have and how good they match team needs and how clear vision you have, others may not buy it. That's ok. Be patient. You just didn't find good enough way to show the value*.

Listen to the objections and look for the needs behind them.

Maybe they don't believe that they can organize work in increments. Maybe they don't know how to do it. Maybe they don't believe it is effective. Look for the way how to show it. Look for the way how to measure and compare both types of approach to items. Look for more inspiration.
Stick for the intention but not to solution. If you think about increments your intention is to slice the work vertically so that it can be integrated and deployed and the exact solution like BDD, TDD, the best slicing method are not so important. Be free about the implementation of the intention. Suggest the experiment, not the final solution.

3) adjust the implementation
If you managed to organize an experiment - do regular retrospectives (get feedback) and adjust the implementation. Maybe slicing one thing into 36 small items is not the best way. Let team find (and decide) a balnace in slicing.
No matter how the experiment is doing, regularly ask, what works, what not and why. What your team ca change to do it better. Getting back to the intention and revising  the implementation is your job. Local failures are just next step on the path of learnings. Failed? Just figure out what you learnt and make adjustments.

4) have a clear vision, stick to the intention and adjust the implementation
Yep, repetition. Repetition is mother of skills. So ... have a clear vision, stick to the intention and adjust the implementation.

* There is also a possibility that vision you have and/or share with others might not be a good option, so don't be eager to validate it from time to time.

Read More

Unknown 10:01  No comment