Kanban Board Needs the Goal

Please consider this blogpost as a continuation of my previous Kanban on The Fridge Door entry.

So I had my Kanban board first on the fridge door and finally on the kitchen wall. I put cards, I moved them through the board, I limited WIP, visualize work, and improve the flow.

Because of my frequent business trips I moved the board on Trello to share it remotely with my wife. Trello is, in my opinion, the best compromise between prize (for free) and functionality for an individual and for a team as well.

So, we bought a flat - big thing for a family, huh? Of course I created new board as below:

After couple of days I was overloaded by number of task, which (as my architect claimed) "absolutely must be doing NOW", but my budged was fixed. Those days I had thoughts I want to share...

#1 Kanban doesn't work

Yes, I blamed Kanban, because my project was to complicated to be managed by Kanban's approach. I thought that touching up the flat is VERY SPECIFIC project where Kanban didn't apply.

That's funny because many teams I work with have also VERY SPECIFIC projects/system/architecture/organization (choose most suitable), where all well known approaches don't apply. Despite of the fact that those approaches work perfectly well for the rest of the world.

#2 I need different tool

I also blamed Trello because it has just only one-column swimlanes, so that I couldn't see the big picture. In consequence I installed some addons to my FireFox to reach multi-column swimlanes and I started looking for better tool with smaller cards and bigger boards.

That's also funny, because many teams I work with, look for the tool/framework/library/programming language (choose most suitable), which is..., which is..., aaaaaaaaa, you know..., which is fuc*ing the best!

But...

I try to be devoted my FirstProgrammerRule - when something doesn't work, investigate your code first.
So I started wondering what was the reason I had so many cards? How I evaluated them? Damn, what the board was for?

Finally I realized that main goals of my board were to visualize work, to collect tasks in one place and to do them faster. But if doing faster is the only goal you end up with more output instead of more value.

To evaluate business value you need a purpose of the work, you need the goal of the board. That was the Aha-moment for me.

In my case the goal was: Move in (budget is fixed). Then everything made clear and simple, because the more a task made me closer to move in, the higher business value it had.

I need minimum stuff in the flat to move in with my family. I defined with my wife what the minimum meant for us and reorganized my board.

It turned out I need: floor, kitchen, one bathroom not two, one inner door not four, two wardrobes and some other stuff. The board started working perfectly well, even with Trello, even with Kanban :)

What happens when you reach the goal of your board. That's OK. This is end of the work. It's time to rest. Later on you will start up new board with new goal.

Frame-of-our-work

Working with a software and repeatable tasks, teams walk form a hard-coded solution to a generic framework and back with confusion. Let's search for the third way.

Table below presents some attributes of those two types of approaches:

	adding a new code	maintaining a design	redesigning	as time goes by...
comment	How much time is needed to add new functionality which respects a framework architectural boundaries?	Any piece of code must be maintained from now to the end	Sometimes new functionality is out of a framework architectural boundaries. So that one need to be redesigned and refactored	What will be happening with the code in the future?
hard-coded solution	offhand	n/a there's no a design	n/a there's no a design	maintaining becomes really hard
generic framework	easy if one knows how a framework works	needs some effort	might be hard and expensive	two scenarios might happen: a framework becomes more and more generic till someone decides to kill the project or a framework becomes more and more coupled with business-specific code and then it goes toward a hard-coded solution

Frame-of-our-work

If both of extremes are wrong what is the third possible way? This is: don't build THE FRAMEWORK. Build THE FRAME-OF-OUR-WORK instead. Please, pronounce these two words: framework and frame-of-our-work. I am serious. So now:

• What a responsibility do you you put on framework and frame-of-our-work?
• What is possible to do with framework and frame-of-our-work?
• What is impossible to do with framework and frame-of-our-work?
• What would you give up changing a focus from framework to the frame-of-our-work or opposite?

You know, naming is important. When you label a project you give a team the direction of work and it determines what kind of work will be done or undone. Focusing a team on building a framework you are at lots of cognitive biases. A framework word is so imprecise that you may do more work than you intended to. Besides we do really like to build frameworks - check Source Forge or Google Code :).

Frame-of-our-work focus you on what are we really doing now? You need to inspect tasks a team do, before you start building a frame-of-our-work. This is nothing but Single Responsibility Principle.

I put a characteristic a frame-of-our-work into the table:

	adding a new code	maintaining a design	redesigning	as time goes by...
comment	How much time is needed to add new functionality which respects a framework architectural boundaries?	Any piece of code must be maintained from now to the end	Sometimes new functionality is out of a framework architectural boundaries. So that one need to be redesigned and refactored	What will be happening with the code in the future?
hard-coded solution	offhand	n/a there's no a design	n/a there's no a design	maintaining becomes really hard
frame-of-our-work	fast	easy	needs some work but it's acceptable	it's sensitive on rapid changes of business processes because it's highly coupled with them
generic framework	easy if one knows how a framework works	needs some effort	might be hard and expensive	two scenarios might happen: a framework becomes more and more generic till someone decides to kill the project or a framework becomes more and more coupled with business-specific code and then it goes toward a hard-coded solution

Although a frame-of-our-work is not so sexy as a framework does, my observation is the cost of redesigning a frame-of-our-work is mostly lower than the cost of maintaining a generic design of a framework.

A simple example

You build desktop application and you search for a good way to implement the GUI logic. It's not trivial in Java:) Focusing on framework you might decide to implement a generic Presentation Model with fancy widgets binding. This is very flexible solution, but...what kind of flexibility do you really need in your project?

On the other side, building a frame-of-our-work you might decide to prepare very simple Presentation Model where you have one stupid POJO per one user screen.

Both are well known approaches, but the difference is how much work will be done.

At last...

What if you really discovered a generic domain and a generic framework would be very useful? What then? Fork the project, find a sponsor in your organization and build the framework. But never ever build a generic frameworks as a part of your regular workflow.

Maturity is the Key

Do you know why: architecture, leadership, agility, effectiveness are so widely discussed? Because nobody know what they exactly are:) Or precisely: these are as complex as these mean different for different people and every point of view gives us some useful knowledge.

We coach development teams and looking in the past I may observe some interesting fenomenas. Let' see (important: I'm writing about Poland):

8 years ago

Nowadays

Some heard about XP A leader aka PM was non-technical quy Some heard about GoF Patterns There was no terms "clean code", "implementation patterns" well known Some have read "Code Complete" When we talked about programmer soft skills we were understood as weirdoes

Teams declare using Scrum or "our own adaptive agile framework" Most leaders do have a technical background "patterns" is one of most discussed word in many meanings Software Craftsmanship movement encourage to searching for better ways to do what we do and to improveme the craft Honestly, there is so many books about "patterns", "agile", "software craftsmanship", "good enough", "code readability" I cannot handle it Soft skills are widely discussed, but narrowly applied :)

So, we see the craft is changing. Software developers are changing. Nowadays, trainees or couchees are more experienced and educated then eight years ago. Some problems from the past are not problems anymore. But, we are faced with some new challenges.

What I want to say? According to Manfred Spitzer learing takes time (esspecially if we talk about social and soft skills). It is trivial, but not understood enough. We want to get skills and knowledge RIGHT NOW!. But it is impossible. Learning starts with acting based on simple procedures and lead up to contextual knowledge and contextual skills.

The crux is learning takes more time than average project length. Sometimes one expects to learn, let' say, "patterns" in four-days training. One also wants to apply its correctly in the project which is coming soon. But during a four-days training one will get a seed and an individual is responsible for its growth.

So, conclusions:

• Software Craftsmanship is a lifelong challenge
• See your learning goals from the five, ten or more years perspective...
• ...but be aware that every single line of code is a small step leading you to some learning goal? Do you like this goal?
• It is impossible to apply "patterns" or whatever always correctly
• Yes, you will smell the code from time to time.
• Make the failure faster :)

Conversation Patterns for Software Professionals

This article is part of my work on Conversation Patterns for Software Professionals

---

Real understanding of our stakeholders needs comes with a conversation. So we want to develop and share the best ways to do it.

Some readers of my book (in polish) and clients as well found its content very usefull. They encourage me to translate it into English. I have thought about it for a year, but couldn't decided.

So, I sent a proposal to couple international publishers and I am waiting for feedbacks. Regardless of their decisions I'm to gonna translate the book as Conversation Patterns for Software Professionals in the form of website conversation-patterns.com (guess what my inspiration was? :))

Having the book written I noticed that conversating with domain experts, users or clients is still difficult for a software professional. It is not a piece of cake to have a good conversations. So, the conversation-patterns.com and some of posts from this blog are intended to challenge it. I've already written two entries on the subject:

• A User Story Template Revisited - its abot how small change in a user story structure you use might cause quality difference
• A Buffer of Useless Answers - it about of application the Drilling Question Pattern. It will help you to obtain quality answers from your stakeholder.

I have also a vision of a community around Conversation Patterns. There is a lot technical stuff we know. But a real understanding of what have to be done comes with a conversations. So, my dream is finding ways to do it effectively.

That is early stuff so any feedback is welcomed.

The most valuable lesson learned from GTD

Whole GTD framework is worth to familiarize yourself with. But the one thing was a rocket jump for me - tasks chunking.

David Allen advice is tasks should be actionable. It means they should be ready to do now. You may examine your tasks by asking: Is it a physical action? where physical means you may express it in the language of your senses and you body. For example 'Process input data' is not physical action. Why? Try to show a process activity by your hands:). Impossible.

In opposite to tasks above: 'Talk to Peter about object model for input data', 'Draw down sketch of classes', 'Write down steps of the data processing algorithm', 'Write initial unit tests for data processing service',... are more 'physical'. So if you are aware of the context these tasks are ready to do as they are now. And this is what we call task chunking.

When I start working on a project I write down some general epics, stories, goals. But I never start working on them unless I write down at least one actionable task. In fact one actionable task is the minimum you need. Ok, I do mistakes and sometimes I take a task which is too general to accomplish it and then I always fail. The only rescue is tasks chunking.

I have also my own actionability cirterion I call it Copy-Paste Test:
'copy' a task and 'paste' it into different context; the less sense it make the more actionable it is. The reason is that specific and actionable task are strongly coupled with its context. So 'copying' them into different context make them incomprehensibled.

Consider: 'Implement the finding service' fits to every context so it is unactinable, but 'Implement service for finding Employee entity by department and salary' is stronger coupled with its context and it is more actionable.

About tools

Personally I use a kanban board on my fridge, at work we currently use LeanKit.com/. These two help me to keep clarity and limit work in progress. For tasks chunking I use todoist.com.

Dekomponowanie zadań

Umiejętność dekomponowania zadań uważam za kluczową, jeśli chodzi o zarządzanie czasem. W różnych momentach prowadzenia szkolenia z tego tematu, starałem się formułować mniej lub bardziej zjadliwe procedury do przeprowadzania owej dekompozycji. W końcu mnie oświeciło i wpadłem na tę, jak sądzę, najprostszą, elegancką i skuteczną:)

Definiuj zadania maksymalnie czterogodzinne

Wiem, że brzmi to jak magiczna formułka na wszystkie problemy. Aczkolwiek to proste zdanie to tylko wierzchołek czegoś większego. Zauważyłem, że gdy wyodrębniając zadanie skupiamy się na tym, aby zajęło cztery godziny, przebiegamy w myślach przez kilka procedur i kryteriów dekomponowania, które tak usilnie starałem się wcześniej sformułować.

Trik polega na tym, że fiksując się na owych czterech godzinach, musisz wykonać eksperyment myślowy i dość szczegółowo wyobrazić sobie to, co ma być efektem zadania i jak to wykonasz. Czyli właśnie to, czego nie robią osoby mające kłopot z dekomponowaniem, a w konsekwencji i z dotrzymywaniem szacowań.

Cztery godziny to dość krótka perspektywa czasowa, którą w dodatku, jako homo sapiens, potrafisz dość dobrze percypować (@see Nie myj zębów, rób retrospekcje). Żeby więc to czterogodzinne zadanie wykonać, musisz być pewny, że da się je wykonać i formułujesz je bardzo konkretnie (przechodzi Test Copy-Paste). I to jest druga zaniedbywana sprawa.

Cztery godziny to, rzecz jasna, wartość umowna. Chodzi o to, aby perspektywa czasowa, była na tyle bliska, aby ze spokojem się na niej skupić i realnie o niej myśleć. Poeksperymentuj z godziną, dwoma, trzema - sprawdź, co będzie. Czy z większymi liczbami też? Moim zdaniem - nie.

Sądzę, że raczej nie jesteśmy w stanie wiarygodnie oszacować na np. 8 godzin. Wiarygodnie tzn. ze powtarzalną trafnością.No, może z wyłączeniem zadań typu: przybij tysiąc stempli na kopercie, napisz walidację not null dla pięćdziesięciu textfieldów na stronie, gdzie obowiązuje proste mnożenie.

Zachęcam gorąco do eksperymentowania i postępowania wg własnego uznania:)

---

UPDATE 30/08/13
Komentarz do posta uświadomił mi, że powinienem jeszcze kilka słów dodać:)

Moja teza nie brzmi "szacuj na max, 4h bo powyżej tego źle oszacujesz", lecz "jeśli wyodrębniasz zadanie z wystarczająco krótką perspektywą czasową, to zrobisz to konkretnie, gdyż wymusi to przemyślenie przedsięwzięcia i być może utrzymasz szacowanie - lecz nie z powodu szacowania, a konkretności właśnie"

Tak jak napisałem, 4h przyjąłem arbitralnie. Co do trafienia w większe oszacowanie, to różnie bywa (por. "Szacowanie oprogramowania", Steve McConnell). Jednakże zwróciłem uwagę, że gdy szacujemy, to zazwyczaj szacowania wyglądają np. tak: 8, 8, 24, 16, 8, 12, 24.

Gdy położyłem przed sobą wiele takich szacowań, to zaważyłem, że niemal wszystkie to wielokrotności jakiejś bazowej liczby: często 8 bądź 6.

Wnioski były dla mnie takie:

• szacując operujemy jakimiś tam idealnymi interwałami (osobodniami, efektywnymi dniami), za pomocą których próbujemy odwzorować czasochłonność zadania
• raczej nie szacujemy czasu, lecz rozmiar zadania - jak duże ono jest

Gdyby chcieć podawać rzeczywiste oszacowania, trzeba by zaprzęgnąć jakaś metodę analityczną np. PERT.

Wg mnie sensowna metoda szacowania polega na retrospektywnej analizie zadań. Najpierw musisz popracować, zobaczyć z czym masz do czynienia, szacować na wyczucie. A potem zaprzęgasz statystykę, analizujesz dane, wyodrębniasz klasy zadań i estymujesz przyszłość z założonym prawdopodobieństwem.

Wtedy dopiero wychodzi, jak bardzo szacowanie wrażliwe jest na zmiany kontekstu, środowiska. Innymi słowy, gdy nie mogę sobie zbudować jakiegoś punktu odniesienia i wszystko absolutnie wszystko się zmienia, to szacowanie jest tylko złudzeniem. Lubimy wierzyć w to złudzenie, bo to łatwiejsze, niż przyznanie, że jednak przyszłość nie będzie wyglądać tak, jakbyśmy chcieli.

Niejednorodny zespół

Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule - napisali niegdyś mądrzy ludzie i zespół w tej postaci jest super. Jednakże robiąc przegląd inwentarza, możesz dojść do wniosku, że stan rzeczy rzeczy w Twoim zespole oraz zasoby, którymi dysponujesz, odbiegają od tego docelowego obrazka. Co wtedy?

Co jest?

Może się dla przykładu okazać, że "dostałeś" pięciu programistów, trzech testerów, analityka oraz Scrum Mastera z nadania, który ostatnimi czasy poświęcał się wyłącznie zarządzaniu.

W takiej konstelacji możesz się spodziewać następujących objawów:

• Polaryzacja między testerami a programistami; nie piszę "wrogość", lecz właśnie polaryzacja my-wy: wy zrobiliście błąd, wy skopaliście testy, my coś zaimplementowaliśmy, itp.
• Programiści mają chroniczny opór przed testowaniem
• Testerzy biorą znikomy udział w planowaniu
• Analityk nie za bardzo może znaleźć swoje miejsce w zespole
• Pojawia się zastanawiająco dużo spadów z poprzednich sprintów

Może się okazać, że po przeprowadzeniu małego śledztwa, ma miejsce następujący związek przyczyn i skutków:

Jak mogłoby być?

Długoterminowym celem mogłoby być oczywiście doprowadzenie do sytuacji, w której każdy jest wspomnianym "developerem", ale o tym na początku lepiej nie mówić głośno:)

Co pomiędzy?

Sądzę, że w takiej sytuacji kluczowe jest, nie tyle męczyć ludzi, aby byli idealnym zespołem, co wydobyć tu i teraz to, co najlepsze. Bardzo dobrym początkiem będzie przeorganizowanie sposobu planowania. Otóż:

• Planujcie podgrupami dzielonymi względem testerów, np. tester+2*programista
• Każda grupa otrzymuje swoje US, które dzieli na zadania
• Analityk chodzi i doradza :)
• Wyodrębniajcie zadania: programistyczne, testerskie, analityczne
• Po zakończeniu dekomponowania grupa przedstawia swoje US, a reszta zadaje pytania kontrolne Czy uwzględniliście to, a to? i jeśli nie, to dodajemy kolejne zadania (uwaga celowo jest tu odwrócenie: grupa nie przedstawia swoich zadań, lecz odpowiada na pytania kontrolne zespołu, gdyż w przeciwnym razie zamęczycie się i zanudzicie

Pytania retrospekcyjne po wprowadzeniu w/w zmiany (po jednej bądź dwóch iteracjach):

• Jak oceniam współpracę między testerami a programistami?
• Czy wciąż mówimy o sobie my-wy?
• Czy będziemy mieli spady w najbliższej iteracji?
• Jak dużo zadań doszło w trakcie iteracji? Jakiego rodzaju były to zadania?

Kilka słów o roli analityka
Analityk bywa w Scrumie czasem zagubiony. W jaką rolę ma się wcielić Proxy Product Owner, Scrum Master, Product Owner? Jedną z powtarzanych przyczyn zmieszania analityka są te cholerne straty w projekcie. No bo jeśli jedyna wartością jest "działające oprogramowanie", reszta to strata, a jemu kazali pisać dokumentację, to ma poczucie, że wykonuje bezsensowną i bezwartościową pracę.

Myślę, że te "straty" wymagają małego komentarza. Analityku, jeśli w założeniach projektu stoi napisane, że ma być dokumentacja analityczna w projekcie, bo tak wymaga klient, ustawa czy ktokolwiek inny, to dokumentacja również jest wartością w projekcie i również dodaje punty do business value.

Przykładowe zadania, w których analityk może wspierać zespół:

• współpraca i mediacje:) z PO
• backlog grooming
• prowadzenie Product Canvas; ciekawe linki: tutaj, tutaj i tutaj.

Ćwiczenie dla zespołu

Retrospekcje dość często opierają się na wrażeniach. Dyskutujemy o naszych spostrzeżeniach i o zmianach. Wrażenia dają wiele informacji, lecz dla równowagi chciałbym zaproponować Twojemu zespołowi retrospekcję opartą na liczbach.

W najbliższej iteracji podejmijcie jedną praktykę: ilekroć karteczka trafi do kolumny IN PROGRESS, oznacz datę umieszczenia w tej kolumnie oraz datę umieszczenia w kolumnie DONE.
Podczas retrospekcji wybierzcie zadania, które przebywały w IN PROGRESS maksymalnie jeden dzień (typ A) oraz te, które przebywały tam trzy dni i więcej (typ Z), i odpowiedzcie na następujące pytania:

• Ile było zadań typu A? Ile było zadań typu Z?
• Na ile początkowo były szacowane zadania typu A oraz Z?
• Dla których zadań, A czy Z, błąd oszacowania jest mniejszy?
• Czy zadania typu A są sformułowane inaczej niż zadania typu Z? Na czym konkretnie polega różnica?
• Które z zadań są formułowane pełnym zdaniem? (z czasownikiem i rzeczownikiem)
• Czy któreś z zadań sformułowane jest w trybie rozkazującym?
• Które z zadań przechodzą Test Copy-Paste?*

I na koniec wnioski: w jaki sposób następnym razem należy formułować zadania.


*) Test Copy Paste - to dość dobry sposób weryfikowania konkretności zadania. Jeśli przeniesiesz swoje zdanie do innego kontekstu i wciąż ma ono sens, to prawdopodobnie jest mało konkretne. Na przykład zadania: Napisz test, Przygotuj dokumentację, Zaimplementuj serwis wyszukujący pasują wszędzie. Nieważne czy pracujesz nad CRM, portalem e-bankowości, czy sterownikiem klapy od sedesu - te zadania mają sens, w każdym z wymienionych kontekstów. Aż się prosi o ich zdekomponowanie.

Lecz zadania: Napisz test do porównywania dochodów klienta na wniosku z danymi biura nieruchomości, Zaimplementuj podgląd wniosku windykacyjnego zdefiniowanego w BAF po przeniesieniu do innej przestrzeni problemu tracą swój sens. Tracą go ponieważ ich sformułowanie jest na tyle związane z tym konkretnym kontekstem, że bez niego trudno jest zadania zrozumieć. Takie zadania mają bardzo wysokie actionability, są na tyle konkretne, że łatwo je wykonać OD RAZU. Oczywiście Test Copy-Paste nie jest zero-jedynkowy, lecz wyznacza pewne continuum konkretności i actionabilitności :) zadań.

Nie myj zębów, rób retrospekcje!

Trudno zauważyć korzyść z robienia retrospekcji, bez ich robienia. Trudno znaleźć argumenty, zachęcić kogoś do regularnego poświęcania czasu na analizę swoich działań. Mimo wszystko chciałbym Cię namówić właśnie do regularnych (czyt. codziennych) retrospekcji.

Fakty nam "uciekają"

Gdy zastanawiamy się nad tym, co robimy, zazwyczaj popełniamy (przynajmniej) jeden kardynalny błąd. Ulegamy złudzeniu, że to co myślimy, to racjonalny i w miarę obiektywny osąd tego, co się wydarzyło. Wydaje nam się, że gdy skupimy się mocno i wytężymy szare komórki, to z możliwym do oszacowania błędem potrafimy nawet przytoczyć dane liczbowe na temat tego, co zrobiliśmy. Dlaczego myślę, że ulegamy złudzeniu?

Od dzieciństwa używasz liczb do ilościowego wyrażania rzeczy. Wszystko, co skończone można przeliczyć. Mimo, że sprawnie posługujemy się liczbami, to gdy myślimy o ilości, ma miejsce pewne zniekształcenie.

Liczby, jak sądzę, nie są czymś, czym umysł operuje w naturalny sposób. Liczby to twór abstrakcyjny. Aby ująć coś liczbowo, należy przeprowadzić złożony proces myślowy. Gdy naturalnie zastanawiasz się nad licznością, np. ile maili dziś dostałem? Twoja naturalna percepcja wygląda mniej więcej tak: jeden, dwa, trzy, cztery, wiele. Gdy pracujesz w zespole liczącym kilkanaście osób i dostaniesz pytanie: ile pączków trzeba kupić, aby wystarczyło dla wszystkich? to o ile wcześniej nie ujmowałeś liczbowo swojego zespołu, czyli: nie policzyłeś osób i nikt głośnio nie powiedział ilu/e Was aktualnie jest (poważnie! większość z nas wcale nie ma tej liczby ot tak, na zawołanie), to oczywiście podasz właściwą odpowiedź, że potrzeba siedemnaście pączków. Jednak nie przypomnisz sobie liczby, tylko pomyślisz o każdej osobie z zespołu po kolei, a dopiero potem policzysz. Co ciekawe, gdy za jakiś czas, ktoś ponownie zapyta o liczność zespołu, ze zdziwieniem odkryjesz, że nie pamiętasz. Nie jest to wiedza konieczna do pracy zespołowej, więc po prostu ulatuje.

Podobnie jest z myśleniem o czasie.

Gdy myślisz o czasie, to myślenie przebiega mniej więcej tak: dzisiaj, jutro, pojutrze, kiedyś, pewnego dnia albo dzisiaj, wczoraj, przedwczoraj, kiedyś tam, dawno temu. Bądź też orientujesz się wg istotnych wydarzeń: po wakacjach, przed tym jak się tu zatrudniłem.

Co może Cię zaskoczyć?

Analizując każdego dnia swoje działanie i zadając sobie wciąż te same pytania retrospekcyjne, nagle orientujesz się, że zanim podejmiesz jakieś działanie, już nie myślisz dzisiaj, jutro, pojutrze, kiedyś lecz na przykład dzisiaj, jutro, pojutrze, za rok, za pięć lat, kiedyś.

Twoje postrzeganie czasu poszerza się. Żeby dobrze to podkreślić: nie tylko podczas retrospekcji widzisz szerszą perspektywę, lecz zaczynasz jej doświadczać w ciągu dnia, w trakcie wykonywania swoich obowiązków. To trochę tak jakby pojawiały Ci się w głowie myśli w stylu: jeśli napiszę taki kod teraz, to przewiduję, że za rok pojawią się takie, a takie konsekwencje. Tego typu "wglądy" wiele zmieniają. Zwyczajnie nie masz ochoty podejmować niektórych działań, ponieważ aż do szpiku kości czujesz kłopoty, które z tego powodu mogą Cię spotkać. I analogiczne z działaniami mającymi pozytywny wpływ.

Podobnie ma się sprawa z naszym postrzeganiem liczności. Dzięki retrospekcjom wyraźniej dostrzegasz co?, jak? i ile? robisz.

Jakiś czas temu odkryłem ciekawe pytanie retrospekcyjne: kim się staję?. Było to mniej więcej tak, że w pewnym momencie zacząłem zauważać, że regularnie powtarzam jakieś tam zachowanie. Jednocześnie zastanowiłem się dlaczego właściwie tak postępuję? skąd się to bierze? Dotarło do mnie, że postępując w jakiś określony sposób, liczmy, że będziemy jacyś. Pretendujemy do jakiejś tożsamości, do bycia postrzeganym jako: profesjonalny programista, charyzmatyczny lider, gracz zespołowy, odpowiedzialny pracownik, przyjaciel, dobry ojciec, itd.

Liczmy więc na to, że poprzez nasze zachowania stajemy się bardziej tacy, jacy chcemy być. Ponieważ zazwyczaj nasze postrzeganie czasu oraz liczności jest mocno ograniczone do teraz i najbliższych okolic, na co dzień raczej nie zdajemy sobie sprawy, czy nasze postępowanie sprawia, że zbliżamy się do pożądanej tożsamości.

Zupełnie inaczej mają się sprawy, gdy zaprzęgniesz do działania retrospekcje. Patrzysz wtedy szerzej, wyraźniej, z odleglejszej perspektywy. I gdy każdego dnia zadajesz sobie pytanie kim się staję?, to może się zdarzyć, że na przykład zawsze chciałeś być świetnym programistą, a poprzez to, co robisz, stajesz się średnim liderem... Z własnego doświadczenia powiem, że odpowiedź na pytanie kim się staję? najczęściej robi w głowie wielkie buuum.

Z tego, co wiem, to niektórzy ludzie w jakimś momencie przeżywają owo wielkie buuum, które ktoś kiedyś nazwał kryzysem wieku średniego:) Wydaje mi się, że dzięki retrospekcjom udaje się w kontrolowany sposób adresować te wszystkie pytania, które w trakcie kryzysu zwalają się na głowę wszystkie na raz. Ale jak to będzie, zobaczymy:)

Od czego zacząć?

Istnieje z pewnością wiele sposobów retrospekcji. Wiele z nich to całe schematy postępowania i kłopot polega na tym, że gdy jeszcze nie czułem w czym rzecz, to rozbudowane checklisty mnie nudziły i nic konkretnego nie potrafiłem z nich wyczytać. Proponuję więc zacząć od czegoś znacznie prostszego.

Od prostej odpowiedzi na pytanie: Jak wykorzystałem dzisiaj czas? i spisania tego na kartce. Tak wiem, że od razu przychodzą do głowy pytania: na kartce? a nie lepiej w pliku? a może w mindmapie? a jak to będę przechowywał? czy się nie pogubię? czy danych nie będzie za dużo? a co z archiwizacją? oraz moje ulubione pytanie: jakie narzędzia to wspierają?:)

Stop! Moja odpowiedź na wszystkie te pytania brzmi: nie wiem, być może. Wiem jednak na pewno, że nie ma co zaprzątać sobie tym głowy teraz.

Jeżeli już nie będziesz mógł bez tego zacząć, to powiem, że ja na przykład używam zwykłego książkowego kalendarza. Akurat taki miałem pod ręką. Czasem moje retrospekcje to kilka punktów, a czasem cała strona zapisana drobnym maczkiem. To zależy od tego, co akurat danego wieczoru mam sobie do powiedzenia. Prowadzę retrospekcje w tej formie od dokładnie 13. lutego i muszę stwierdzić, że jest to najlepsza forma, jaką udało mi się dotąd wymyślić. Czy przejdę kiedyś na formę elektroniczną? Nie sądzę. Kalendarz mam ze sobą zawsze. Telefon czy notebook nie. Natomiast robienie wstecznych retrospekcji mija się z celem. No, ale jak mawiała moja lektorka angielskiego: never say never and don't always say always. :)

Dlaczego w formie pisemnej?

Jeśli kilka ostatnich lat spędziłeś w klasztorze albo właśnie zakończyłeś zaawansowany i intensywny kurs panowania nad umysłem, albo po prostu od urodzenia potrafisz w sposób świadomy zarządzać każdą myślą, która przyjdzie Ci do głowy, to oczywiście pisanina nie jest Ci wcale potrzebna.

Umysły większość z nas są jednak mocno niezdyscyplinowane. Jeśli postanowisz przeprowadzać retrospekcję w myślach, w trakcie kąpieli to Twój dialog wewnętrzny będzie prawdopodobnie przebiegał w następującym stylu: yyy zaimplementowałem funkcjonalność... [tutaj Twoją uwagę odwraca zbyt zimna woda] o woda zimna jak w Bałtyku..., podczas ostatnich wakacji... [tu przypominasz sobie o retrospekcji] no, więc byłem na spotkaniu z... [ale przypomina Ci się, że] o cholera! miałem zadzwonić do X! [tu biegniesz do telefonu] ok, skończyłem retrospekcję, dzisiaj było ok..

Z takiej retrospekcji nic nie wynika. Myśli uciekają, rozpraszają się i wychodzi zwykłe bla, bla, bla, bla. Retrospekcja musi mieć swój czas i swoje miejsce. Pisanie pomaga się koncentrować, nadać myślom kierunek i wydobyć z nich użyteczną treść.

Dlaczego codziennie?

A to trudne pytanie:) No bo dlaczego nie co tydzień albo co miesiąc? Porównałbym tu robienie retrospekcji do naliczania odsetek na lokacie. Wiadomo, że lokata z dzienną kapitalizacją przynosi większe zyski niż z miesięczną, ponieważ już po jednym dniu możesz dodać wypracowane odsetki i powiększyć kapitał, od którego są one liczone w dniu kolejnym i tak dalej. Wnioski retrospekcyjne to takie naliczanie kapitału, już następnego dnia możesz skorzystać z tych wniosków.

Poza tym podstawowy rytm człowieka, którym odmierza rzeczywistość to, jak sądzę, rytm dobowy. Powtarzanie jakiejś czynności każdego dnia, staje się elementem codzienności (ang. daily routine) i szybko wchodzi w nawyk.

Przecież ja nie mam na to czasu!

No i na koniec obiekcja, która pojawia się najczęściej: Nie mam czasu! Naprawdę chciałbym, ale nie mam czasu. No bo kiedy? Praca, dom, rodzina, wyjazdy itd. Jeśli Ty również, chciałbyś robić retrospekcje, ale nie masz czasu, to mam dla Ciebie radosną wiadomość: specjalnie dla Ciebie opracowałem autorską technikę, dzięki której znajdziesz czas potrzebny na codzienną retrospekcję. I to znajdziesz już dzisiaj!

W poszukiwaniu owego czasu skontaktowałem się z zaprzyjaźnionym stomatologiem i zapytałem go, przez jaki czas można bez większych szkód nie myć zębów :) Zżymał się, zżymał, lecz udało mi się z niego wydusić, że o ile odżywiasz się normalnie czyli unikasz: sacharozy, fruktozy, maltozy, dekstryny, maltodesktryny, dekstrozy, aspartamu i syropu glugozowo-fruktozowego, to spokojnie możesz odłożyć szczoteczkę i pastę na miesiąc bądź dwa, zastępując mycie szybkim "przepłukaniem":)

Oto więc mój prezent dla Ciebie: czas, który przeznaczałeś na mycie zębów, przeznacz na robienie retrospekcji. Dwa miesiące codziennych retrospekcji to wystarczający czas, aby zauważyć tyle z nich korzyści i nabrać takiego nawyku, że brak retrospekcji stanie się dla Ciebie równie wstrętny, co brak higieny jamy ustnej. A więc do dzieła! Nie myj zębów, rób retrospekcje! :)

Wstęp do mierzenia efektywności zespołu

Szerszy artykuł na ten temat możesz przeczytać w bieżącym numerze programista.pl.

Środowisko pracy

Kluczowym czynnikiem wpływającym na efektywność zespołu jest środowisko, w którym pracuje. A zatem:

• Wymagania
• Klient
• Architektura
• Typy zadań
• Charakterystyka zespołu
• Technologia

Aby poprawić efektywność zespołu, w pierwszej kolejności pracuj nad poprawą środowiska pracy. Nawet najefektywniejszy programista będzie nieefektywny w nieefektywnym środowisku.

Nie porównuj ze sobą zespołów, które pracują w różnych środowiskach.

Efektywność zespołu

Efektywność zespołu to jego zdolność do zrealizowania celów, z których rozliczany jest lider zespołu przez swojego przełożonego. Właśnie tak, nie wierzymy w bezwzględne miary efektywności. Takich miar zostało zdefiniowanych setki. Każdy lider ma taki pogląd na efektywność, który wspiera realizację celów, z których on sam jest rozliczany.

Lider chce, aby zespół zrealizował jego cele. Sposób wpływania na zespół zależy od lidera, definicja efektywności i miary również. Dwóch różnych liderów (np.: transakcyjny i transformacyjny) realizujących te same cele, będzie miało inne pomysły na zespoły.

Jeżeli w ogóle można porównywać ze sobą zespoły to nie za pomocą miar, lecz poprzez to czy i jak realizują cele swoich liderów.

Ponieważ cele wyznaczane liderom się zmieniają zatem i definicja efektywności wraz z miarami musi się zmieniać. Miary mają sens "teraz", "później" mogą już go nie mieć.

Dostajesz więcej tego, co mierzysz

Jeśli mierzysz ilość linii kodu, otrzymasz więcej linii kodu. Czy aby na pewno o to chodziło? Dobieraj miary tak, abyś dostawał więcej porządanych zachowań.

Miary skupiają uwagę

zespołu na tym, co jest mierzone. Czasem, choć nie jest to regułą, czynność mierzenia może sprawić, że ludzie staną się uważniejsi i zmniejszą ilość określonych zachowań.

Miara agreguje wiele czynników

Miara to wynik zagregowany. Najczęściej zawiera w sobie kilka informacji, nie tylko jedną.

Rozliczanie rozpoczyna grę

Każda forma rozliczania ludzi z osiągnięcia współczynników skutkuje stworzeniem gry, której celem jest uniknięcie kary lub zdobycie nagrody, a zasady gry polegają na osiągnięciu określonych wartości współczynników. Więcej o powstawaniu gry znajdziesz w artykule W co gra się w projektach?

Tworzenie miar dla osób zwiększa ryzyko rozpoczęcia gry. Tworzenie miar dla zespołu zmniejsza to ryzyko.

Używanie miary

Używaj miary do obserwowania postępu, jako przesłanki do zadania pytania "dlaczego?", wskazówki do rozpoczęcia coachingu. Nie używaj miary do oceniania ludzi.

Weryfikowanie miary

Gdy już zdefiniujesz miarę, która pomoże ukierunkować zespół na osiąganie przydzielonych Ci celów, zadaj następujące pytania:

1. Co właściwie mierzy miara? Jakie wielkości agreguje?
2. Czego otrzymam więcej?
3. Jakie gry mogą się rozpocząć?

A następnie zastanów się, co należy zrobić, aby zminimalizować negatywne skutki wprowadzenia miary.

Od czego zacząć?

Od mierzenia. Jeśli nie masz żadnej miary dla zespołu, zacznij od określenia niezmienników. Niezmienniki to pewne ustalone wielkości, które dla zespołu i projektu będą zawsze stałe. Niezmienniki są bazą względem której będą odbywać się pomiary. W pierwszej kolejności rozważ następujące niezmienniki:

1. Fazy procesu dostarczania
2. Typy zadań
3. Długość iteracji
4. Granulacja zadań

Kiedy misja, wizja, wartości działają na szkodę architektury?

Misja, wizja, wartości to jedne tych narzędzi, w których lubują się organizacje za radą modnych strategii zarządzania. Pisaliśmy o tym w kontekście zespołu w artykule Brakujący 1% – Zarządzanie zaangażowaniem programistów. Dla przypomnienia, krótka tabelka, co jest czym i o co chodzi. Dla ustalenia uwagi posłużę się przykładem portalu, który znalazłem w sieci po wpisaniu "misja, wizja". Jest to portal studentmed.pl (btw: nigdy nie miałem kontaktów zawodowych z tym portalem)

Wizja	Jak wyobrażamy sobie świat z perspektywy biznesu, w którym działamy	Za 6 lat każdy student w Trójmieście objęty będzie kompleksową i bezpłatną opieką medyczną w STUDENT-MED
Misja	Jaka jest nasza rola w urzeczywistnieniu naszej wizji?	(...) przynoszenie ulgi w cierpieniu i chorobie w dogodnym dla Studenta czasie. Zapewniamy pełną opiekę medyczną – nie tracisz czasu na bieganie między różnymi przychodniami (...)
Wartości	Co musimy stawiać na pierwszym miejscu, aby realizować naszą misję?	Zdrowie, czas, spełnianie oczekiwań, pozytywne relacje, profesjonalne usługi, dobro pacjenta, wygoda pacjenta
Zasady	Tego na studentmed.pl nie ma. Chodzi o operacjonalizację wartości, czyli co konkretnie mamy robić, aby w/w wartości realizować w naszej pracy?	Tu wymyślam: Umawiamy pacjenta zawsze na konkretną godzinę, a czas oczekiwania wynosi max. 10 min., Nasi pracownicy prowadzą krótkie small talks z pacjentami, Wstępny wywiad prowadzimy telefonicznie, być może uda się postawić wstępną diagnozę, bez konieczności stawienia się w przychodni

Podobne sformułowania stosowane są również softwarehousach i organizacjach mających w swoich strukturach zespoły programistyczne. Jeśli rozejrzysz się po korytarzu w swoim miejscu pracy, to z pewnością zauważysz kolorowe plakaty z wartościami Twojej organizacji. Być może nawet masz je na wygaszaczu ekranu...

Koledzy, z którymi rozmawiam, często nie traktują tego zbyt poważanie, żartują sobie z tego wewnętrznego PR, ale jako osoba z zewnątrz muszę przyznać, że to działa. Ludzie tym przesiąkają zwłaszcza wtedy, gdy wartości są konsekwentnie komunikowane. Gdy otrzymuję zlecenie zawiązania zespołu i pracujemy nad wspólnymi wartościami, to niepostrzeżenie w tym, co wypracowują uczestnicy pojawiają się komunikowane wartości organizacji. Tak więc ludzie tym przesiąkają na wskroś i zaczynają zgodnie z wartościami działać.

Sławomir Lachowski, twórca pewnego banku, miał następującą recepturę na sukces: rekrutuj ludzi, szkól ich, zaufaj im. Szczególną wagę przykładał do rekrutacji. Stawiał na rekrutację tylko tych ludzi, którzy pasują do organizacji. W swojej książce Droga ważniejsza niż cel napisał, że ludziom którzy popełnią błąd zawsze trzeba dać drugą szansę. Jednak z ludźmi, którzy nie wyznają wartości organizacji należy się rozstać. W ten sposób, po pewnym czasie organizacja skupia programistów, którzy w jakimś zakresie utożsamiają się z wizją, misją i wartościami organizacji oraz postępują zgodnie z wyznaczonymi Zasadami.

Co z tego wynika dla architektury?

Kłopoty zaczynają się wtedy, gdy wśród wartości pojawiają się sformułowania w stylu:

• Zadowolenie klienta jest zawsze na pierwszym miejscu
• Nigdy nie pozwalaj klientowi czekać
• Klient jest najważniejszy
• Spełniamy marzenia klienta

Same sformułowania wyglądają super i pozornie mają sens na kapitalistycznym rynku, wszak klient nasz pan. Sęk w tym, co robią zespoły wyznające podobne wartości i do czego to doprowadza. Na rysunku znajduje się diagram RCA, w którym wyszedłem od problemu ze złą jakością kodu. Okazało się, że jej skutkiem jest to, że klienci od nas odchodzą, a powodem to, że Zadowolenie klienta jest zawsze na pierwszym miejscu. Hmmm...czy to nie sprzeczność? Nie, to po prostu kaskada skutków i przyczyn, które zainicjowane wartościami, działają w organizacji.

W/w wartości lokalnie mają sens, lecz jednocześnie działają antysystemowo. W szerszym kontekście i w dłuższej perspektywie mogą doprowadzać do pogarszania tego, co zamiarowały poprawić.

Co z tego wynika?

Choćby to: dobieraj wartości tak, aby wspierały działanie całego systemu (organizacji) oraz analizuj systemowy wpływ misji, wizji, wartości, zasad na to co robią i wytwarzają zespoły.

No i na koniec: co w zamian? Jakie wartości będą miały bardziej pozytywne systemowo działanie niż wymienione. Celowałbym w następujące rzeczy:

• zamiast "klient" promować nastawienie na "klienci; być może skupi to uwagę na takim zorganizowaniu zespołów, aby brać pod uwagę "całość" klientów, a nie tylko tego "na teraz"
• zamiast nastawienia na "zadowolenie klienta" promować "skupiamy maksymalny wysiłek na tym co jest najważniejsze"; być może zbuduje to przyzwolenie na limitowanie WIP
• zamiast nastawienia na "klienta" promować "skupiamy najwięcej uwagi na najważniejszych klientach"; sad but true, szacowanie klientów to normalka i nie ma się czego wstydzić
• zamiast "spełnianie marzeń klientów" promować "odnajdujemy to, co przynosi naszym klientom największą korzyść"; ponownie skupienie na priorytetach

Gdy programista zostaje liderem

Napisano już tony książek na temat leadershipu i efektywności, które z pewnością masz gdzieś na dysku. Nie będę się więc silił na sformułowanie ogólnych zasad do wszystkiego, bo albo ktoś to już zrobił albo takowe nie istnieją :) Mam jednak parę spostrzeżeń na temat, tego o czym warto pamiętać, gdy do tej pory byłeś przede wszystkim programistą, a teraz zostałeś liderem programistów.

1. Akcja powoduje reakcję

Bywa, że programista zostający liderem, w przypływie entuzjazmu zaczyna mylić proaktywność z hiperaktywnością. Często myśli sobie: "do tej pory znosiłem ten kod, ale teraz wszystko się zmieni" i zaczyna zmieniać.

Sęk w tym, że każde rozpoczęte działanie, co jakiś czas "domaga się uwagi". Jeśli komuś coś zlecisz, to w końcu przyjdzie on z jakimś pytaniem na temat zadania. Im więcej działań rozpoczniesz, tym więcej aktywności będziesz musiał później podejmować - wykładniczo więcej. Świeżo upieczony lider, próbuje wprowadzić zmiany zakładając, że zmiana jest to proste przeprowadzenie stanu aktualnego w stan docelowy. Tymczasem jest to nieco bardziej złożone. Model wprowadzania zmiany podobny jest do tego przedstawionego na rysunku (w tym poście tylko skrótowo). Zainicjowanie zmiany to tylko początek, po jakimś czasie przychodzi kryzys, przez który należy zespół przeprowadzić. Bez aktywności lidera, zespół wróci do stanu początkowego, gdyż wtedy "jest źle, ale przynajmniej wiemy co trzeba robić". Z tego względu początkowa hiperaktywność prowokuje zbyt wiele kryzysów w zespole. Lider nie jest w stanie ogarnąć wszystkich i zmiana się nie udaje. Młody lider ma zazwyczaj wyrzuty sumienia. Myśli, że się nie nadaje do nowej roli i chce znów być programistą (@see kryzys w zmianie). Problem zazwyczaj nie tkwi w konkretnej osobie, lecz w niewłaściwym działaniu. Zacznij więc od wprowadzenia jednej zmiany, a gdy się ustabilizuje, pomyśl o kolejnych. Zanim zaczniesz jednak zmieniać, zastanów się co? i po co?.

2. Naucz się rezygnować

Tak to już jest, że najchętniej lubimy robić rzeczy, które nam wychodzą. Jeśli jesteś świetnym programistą i uczysz się jak być liderem, to będziesz często odczuwać pokusę, aby osobiście implementować zadania, z którymi nie mogą poradzić sobie programiści albo będziesz przydzielał sobie tyle samo zadań programistycznych co do tej pory. O tym, czy lider zespołu powinien programować i jak to godzić z zadaniami wynikającymi z roli lidera toczy się wiele dyskusji i jest wiele podejść do tego zagadnienia. Ja jestem przekonany co do jednego: niezależnie od tego, czy programujesz, czy nie Twoja optyka powinna być zawsze nakierowana na zespół. Twój sukces nie oznacza już sukcesu indywidualnego, lecz wprost zależy on od sukcesu zespołu, któremu przewodzisz. Możesz mieć co do tego pewne obawy, więc napiszę o nich wprost. Tak, nie będziesz programować tyle, co do tej pory. Tak, będą okresy, że nie będziesz programował w ogóle. Tak, możesz przestać być na czasie z nowinkami technologicznymi. Tak, szczegółowe zagadnienia dotyczące technologii, frameworków, mogą zacząć blaknąć w Twojej pamięci. Nie, nie zapomnisz jak się programuje. Tak, zaczniesz zauważać, że pewne klasy problemów rozwiązuje się w podobny sposób. Tak, jeśli wprowadzisz proces wymiany wiedzy, będziesz korzystał z wiedzy i doświadczenia programistów, aby na ogólnym poziomie być zorientowanym w temacie. Tak, będziesz zauważał, że niektórzy programiści popełniają błędy podobne do tych, które ty popełniałeś. Tak, rozwijanie umiejętności innych jest równie fascynujące jak rozwijanie własnych.

3. Nawyki są ważniejsze niż cele

Żyjemy w obsesji celów. Na każdej rozmowie rekrutacyjnej pytają o największe osiągnięte cele i porażki. Cele same w sobie są nudne. Większość z nas posiada umiejętność "spięcia się w sobie" i osiągnięcia jakiegoś tam celu. Jest jednak coś ważniejszego niż cele - nawyki. Gdyby nawyki i cele położyć na szali, to relacja między nimi jest taka, jak relacja między wartościami po prawej i po lewej stronie w Manifeście Agile. Czyli: wiemy, że cele są ważne i doceniamy je, lecz nawyki cenimy bardziej. Ironia polega na tym, że osiąganie celów bez nawyków (czyli jednorazowe pospolite ruszenie) może być męczarnią. Ale dzięki nawykom cele osiągają same. Jaki z tego pożytek dla lidera programistów? Ano, na przykład taki:

• nie zmuszaj ludzi, aby wymienili się wiedzą i za dwa miesiące byli zespołem cross-functional (jak to zmierzyć?), zamiast tego wprowadź zwyczaj regularnych (dobrze określonych w czasie) spotkań i dyskusji na tematy techniczne
• nie baw się w strażnika, który zagania ludzi do pracy, zamiast tego rób codzienne stand-up meetings
• nie ogłaszaj, że za pół roku system ma być zrefaktoryzowany w całości, zamiast tego wprowadź zwyczaj code review.

4. Wielkie problemy biorą się z małych zaniedbań

Nie chodzi o pedantyzm graniczący z obsesją. Chodzi o świadomość, że nasze działanie to niezliczone ilości ciągów przyczynowo-skutkowych, a końcowy skutek może stać się przyczyną dla kolejnych ciągów przyczynowo-skutkowych. Zupełnie jak to domino. Kiedyś napisałem wpis o refaktoryzacji "Myjcie swoje kubki", w którym chodziło o to, że lepiej regularnie robić drobne refaktoringi (@see nawyk), niż raz na jakiś czas wybebeszać pół systemu (tak, wiem, czasem jest to nieuniknione). Z perspektywy lidera jest podobnie. Jeśli coś Ci się w funkcjonowaniu zespołu rozstraja, reaguj od razu. Nie zwlekaj do momentu, aż drobny kłopot stanie się przyczyną kolejnego ciągu, i kolejnego, i kolejnego, aż możliwość reakcji przekroczy Twój zakres kompetencji.

5. Wielkie osiągnięcia biorą się z małych ulepszeń

Lider często ma marzenie, aby poustawiać wszystko tak, aby było dobrze i niech to to tak już zawsze działa. Po pierwsze nie ma żadnego "dobrze" i nie ma żadnego "na zawsze". Próba zorganizowania pracy zespołu tak, aby potrafił wykonać każde zadanie przypomina trochę implementowanie superelastycznych rozwiązań "na wszelki wypadek". Rzeczywistość tak niestety nie funkcjonuje, co nie oznacza, że jesteś tu bezradny. Pilnuj dwóch głównych zasad:

1. Szybko rozwiązuj problemy lokalnie
2. Lokalne rozwiązania standaryzuj tak, aby stały się częścią całego procesu

6. Wprowadzaj FRAMEworks i workFLOWs

(Nie mówimy teraz o bibliotekach programistycznych) Główną perspektywą patrzenia na zespół są procesy w nim działające. Słowa "framework" i "workflow", których częścią jest słowo "work" elegancko oddają, jak lider powinien organizować ową "work" w zespole. Przede wszystkim dla pracy powinien być zdefiniowany "frame". Ludzie muszą widzieć, że coś się dzieje według jakiegoś schematu. Na przykład tablica scrumowa nadaje "frame" pracy zespłu - "coś (karteczka) gdzieś musi się znaleźć (tablica), to coś na jakiejś podstawie (definition of done) przechodzi do kolejnego etapu (done), itd". Ludzie wiedzą: co mają zrobić, jak mają robić i kiedy skończyli.
Drugie słowo uwypukla "flow" procesu. Proces ma być płynny, bez zbędnych przestojów, bez zatorów, z optymalną ilością wykonywanej pracy. Na przykład "flow" w Scrumie stymulowane jest poprzez narzucenie stałych iteracji, mierzenie prędkości zespołu, nacisk na regularność, rytm, szybki feedback.

7. Działa tylko to, co robisz

Na koniec najcenniejsze, ale jak to zazwyczaj bywa - najbardziej oczywiste spostrzeżenie - żeby coś zadziałało, musisz to robić. Zadziwiające, że czasem gdy pracuję z zespołem omawiamy konkretne techniki, to wszyscy kiwają głowami - tak to jest ok, to jest ważne, a potem nikt nic nie robi i jednocześnie wszyscy są przekonani, że nie działa. Entuzjazm po szkoleniu trwa jakiś tydzień, potem się kończy i często kończy się noworozpoczęte działanie (@see kryzys w zmianie). Pamiętaj, konkretne techniki działają jeśli je robisz. Jeśli ich nie robisz, nie będą działać. Na przykład Daily Scrum. Zespoły, często robią, potem trochę im się spotkania przeciągają, czasem spotkanie odwołają, a w końcu stwierdzają, że wystarczy jedno w miesiącu. Jednocześnie wszyscy mają miliony racjonalizacji dlaczego to jest ok. Owszem, powody są nieraz ważkie, ale powiedzmy jasno: nie, nie, nie i jeszcze raz nie. W ten sposób Daily Scrum nie będzie działał. I to nie Scrum jest zły, tylko ktoś przed zastosowaniem nie przeczytał ulotki i teraz jest zaskoczony, że pojawiły się skutki uboczne. Myśl długo nad wprowadzeniem danej praktyki do zespołu, ale jeśli już wprowadzisz, to konsekwentnie ją kontynuuj i daj jej szansę zadziałać.

Zawsze pracuj na twardych danych

Czasem zdarza Ci się spotkać z jakimś problemem związanym z algorytmem, architekturą, sprawami organizacyjnymi itp. Sporo pracuję z ludźmi nad rozwiązywaniem problemów tego rodzaju i zauważyłem, że czasem umysł albo nasze własne przyzwyczajenia utrudniają nam znalezienie rozwiązania. Poniżej spisałem kilka rzeczy, o których warto pamiętać, gdy szukasz rozwiązania jakiejś kwestii. Być może te rzeczy wydadzą Ci się oczywiste, ale zdążyłem się już przekonać, że oczywistych rzeczy nauczyć się najtrudniej. Oczywiste jest na przykład, że korzystniej dla zdrowia swojego i innych być zrelaksowanym, a mimo to obroty z leków uspokajających są obrzydliwie wielkie. Rzecz trudną i oczywistą poznasz po tym, że wszyscy o niej mówią i wszyscy wiedzą, ale mało kto ją robi.

Myśleć o problemie, czy o rozwiązaniu?

Lubimy czasem powtarzać zasłyszane frazesy. Jednym z nich jest "myśl o rozwiązaniu zamiast o problemie". To mądre zdanie w powszechnym użytku staje się frazesem. Na czym polega frazesowanie, tej światłej myśli? Otóż przede wszystkich chodzi to o "koncentrowanie się" na problemie. O sytuacje, w których tak obsesyjnie myślisz o danym błędzie lub sprawie do rozwiązania, że to myślenie przesłania kreatywności i nie pozwala dostrzec rozwiązań. To trochę tak, jakbyś spędził kilka dni na projektowaniu warstwy dostępu do danych z użyciem Hibernate, stosując najbardziej wyrafinowane mapowania i ani razu nie zastanowił się nad pytaniem Czy Hibernate jest tu w ogóle potrzebny?

Przede wszystkim pamiętajmy, że nie znajdziesz rozwiązania, jeśli nie rozumiesz natury problemu, z którym masz do czynienia. Najpierwszejsze pytania, które trzeba sobie zadać, to O co właściwie chodzi? Z czym właściwie mam do czynienia? Jak to działa? Co po kolei się wydarza, że jest taki a taki rezultat?

Posługuj językiem twardych liczb

I tu najczęściej jest klops. Pewien programista, z którym ostatnio pracowałem mierzył się ze złośliwym problem. Miał stworzyć transformaty migrujące dane z jednego systemu do drugiego. Z różnych powodów posiadał w tamtej chwili szczątkową wiedzę na dany temat, co więcej polecono oszacować mu czas realizacji zadania. Do tego momentu jeszcze wszystko w miarę gra.

Sformułowanie problemu jest kluczowe
Kłopot tkwił w tym, w jaki konkretnie sposób ten programista podchodził do pracy. Otóż, gdy tłumaczył mi na czym polega rzecz mówił mniej więcej tak "powiedzmy, że mamy obiekt A i A'. A' znaczy w tym systemie co innego niż w tamtym A. I teraz nie do końca wiemy jak stworzyć taką trasnformatę, jak zmapować obiekty na siebie. Jakie są podejścia do tego typu zadań?" Odpowiadam: nie ma żadnych podejść. I nie wynika to z natury problemu, lecz z błędnego jego sformułowania.

Zauważ, że programista sformułował problem na dość wysokim poziomie abstrakcji. Uogólnił go, jeszcze nie w pełni rozumiejąc w czym rzecz. W ten sposób przeszedł do bardzo abstrakcyjnego myślenia. I tak powiem...konkretne sformułowanie problemu => konkretne rozwiązanie, abstrakcyjne sformułowanie problemu => abstrakcyjne rozwiązanie. Dlaczego? Dlatego, że przy tego typu sformułowaniach, za każdym razem, gdy wpadnie Ci do głowy jakieś rozwiązanie, jesteś tak zteoretyzować problem, że znajdziesz takie konteksty i takie przypadki szczególne, że rozwiązanie będzie do bani.

Na ogólnym poziomie nie ma rozwiązań, problemów, owszem, jest od groma. Rozwiązania istnieją tylko w konkretnych rzeczywistych mierzalnych danych. A zatem zawsze pracuj na twardych liczbach, gdy tylko próbujesz rozwiązać jakiś problem. Dopiero potem, gdy będziesz już mieć wystarczająco wyraźny obraz rzeczywistości, będziesz mógł postawić hipotezy rozwiązania, a następnie próbować je w ogólnym przypadku. W tej właśnie kolejności: najpierw konkret, potem abstrahowanie. Nigdy odwrotnie.

Procedura postępowania

Jak zatem wygląda procedura działania? Posługując się w/w przykładem z transformatami, mamy:

1. Zrozum wszystkie przypadki szczególne (Co reprezentują poszczególne obiekty w każdym systemów? Jakie jest ich znaczenie biznesowe? Jakie informacje przechowują? Jakie są reguły spójności danych?)
2. Zbuduj rozwiązanie dla najprostszego przypadku (Napisz transformatę dla konwersji pojedynczych pól)
3. Zbuduj rozwiązanie dla każdego przypadku szczególnego (Stwórz transformatę dla: konwersji prostego obiektu, dwóch obiektów w relacji 1-1, dwóch obiektów w relacji *-1...)
4. Poszukaj części wspólnej (Czy, któraś z kolejnych transformat, "załatwia" poprzednie? Czy można napisać jedną transformatę dla 90% przypadków, a pozostałe 10% przypadków obsłużyć małymi transformatami?)
5. itd

Tak, to zajmuje czas. Czasem dużo czasu. Ale z każdą godziną, rozwiązanie pokrywa coraz większą część problemu. Przeciwnie, gdy od samego początku próbujesz rozwiązać teoretyczny ogólny problem, to z każdą godziną problem się komplikuje, a rozwiązań nie ma.

3 kluczowe przekonania i 1 umiejętność

Trzy kluczowe przekonania skutecznego "zarządzania czasem" (do uszczegóławiania w dalszej przyszłości):

1. Wielkie problemy biorą się z małych zaniedbań.
2. Wielkie osiągnięcia biorą się z małych ulepszeń.
3. Żeby coś zacząć robić, trzeba coś przestać robić.

Kluczowa umiejętność: aserytwność. Żadna technika zarządzania czasem nie zadziała, jeśli pozwalasz sobie wepchnąć każde zadanie i jesteś zwyczajnie przeładowany. Nie daj sobie wmówić, że powinieneś robić jeszcze więcej, jeśli Twój bufor się przepełnia. Z drugiej strony pamiętaj, że każdy z nas potrafi świetnie racjonalizować dlatego nie ma czasu na zajęcie się nowym zadaniem. Ta chwiejna równowaga jest elementem cennej postawy jaką jest samoświadomość.

I jedno pytanie do przemyślenia. Wszyscy mówią: "rób przede wszystkim rzeczy ważne, uważaj na rzeczy pilne, żeby nie wypełniły Ci całego dnia". Proste pytanie: Jak?

• Po jakich konkretnie atrybutach poznasz, że dane zadanie jest pilne?
• Po jakich konkretnie atrybutach poznasz, że dane zadanie jest ważne?
• Macierz Eisenhowera mówi: rzeczy pilne deleguj. A jeśli nie masz komu delegować?
• Czy jeśli cały dzień robię tylko rzeczy ważne, a pilne przesuwam to jest ok?
• Macierz Eisenhowera mówi: rób rzeczy ważne zanim staną się pilne. Czy to znaczy, że pilne nigdy nie stają się ważnymi? A jeśli tak, to kiedy?

Duch i litera

Trochę w nawiązaniu do posta W co gra się w projektach.

W okolicach wyborów słyszałem w radiu zażartą dyskusję nt. czy obecnemu rządowi wolno rządzić do końca roku czy nie. Premier się upierał, że chce spokojnie dokończyć prezydencję w UE i argumentował, że jest to zgodne z konstytucją, natomiast konstytucjonaliści ripostowali, że owszem jest to zgodne z konstytucją, lecz nie jest zgodne z jej duchem.

Otóż to, pomyślałem. Wdrażanie procedur/procesów/standardów w zespole kończy się niepowodzeniem, gdyż ludzie rozumieją ich literę, ale nie widzą ducha. Autorzy procedur mieli oczywiście bliski kontakt z duchem, a literę stworzyli po to, aby przekazać swoje odmienne stany świadomości. Ergo - przy okazji wdrażania czegokolwiek ludzie muszą nawiązać kontakt z duchem.

Zostawiwszy w spokoju spirytualistyczne metafory, trzeba wyraźnie powiedzieć, że ludzie muszą znać intencję wdrażania nowych standardów, czyli: po co to robimy, dlaczego to jest ważne, co z tego będziemy mieli. Dobrym pomysłem, w tym obszarze jest standaryzowanie tego co już działa. Jeśli w zespole samoczynnie wykształciła się jakaś praktyka, która przynosi dobre rezultaty, to wartą ją zinstytucjonalizować w postaci obowiązującego standardu - dwie pieczenie na jednym ogniu.

Planowanie to nie problem

To miał być długi, pracowity wieczór. Nazbierało mi się sporo zadań do wykonania. Gdy tylko drzwi hotelowego pokoju za mną się zamknęły, przystąpiłem do działania według najlepszych prawideł sztuki planowania. Komputer zostawiłem w spokoju dla uniknięcia rozproszeń. Czystą kartę zapełniała powoli acz konsekwentnie rosnąca lista tudusów. Lista to została następnie starannie przepisana na nową kartkę, w już posortowanym według priorytetów porządku.

Tak uzbrojony, włączyłem notebooka i rozpocząłem działania. Pomyślałem, że zerknę co tam przed wyborami. Nic nowego. Ok, zabieram się do pracy. Ponieważ najpierw musiałem odszukać mail na podstawie, którego mam coś tam opracować - odpalam TB. Zaraz po uruchomieniu klienta poczty, automatycznie ściągają się czekające maile. No, tylko rzucę oczkiem....O, siostra przysłała mi przepis na zupę dyniową. Hmm, że niby ja mam to gotować? O, Grzesiek odpisał na facebooku. O, ktoś ma dla mnie ofertę pracy...ups nie, tam już pracowałem. Kurcze, ten mail to mnie wkurzył, muszę odpisać, bo nie zdzierżę!

Ok, jeszcze tylko załączę piosenkę na rozpęd i już się zabieram do pracy. Odnajduję na youtube stary teledysk Ronniego Dio. Naprawdę, koleś miał głos jak dzwon. Szkoda, ze zmarł. Kiedy to było? A, 16 maja..o wtedy, kiedy urodziny mojej siostry. Tak na marginesie o co chodzi z tą zupą dyniową? Jeść mi się zachciało. Jedno jabłuszko tylko, bo wieczór. Na noc jeść nie zdrowo. Nightwith - włączę cicho. O, ciekawe czy są jakieś nowe wtyczki do foobar2000. Zaraz zaraz, która godzina. Północ? A moje zadania? Szlag!

Zadania dryfują

Już nie raz łapię się na tym, że planowanie to bułka z masłem w porównaniu z konsekwentnym podążaniem za planem. Obstawiam, że gdyby nawet najmizerniejsze plany były realizowane w 100%, to osiągalibyśmy znacznie więcej niż obecnie. Kłopot w tym, że zaraz po przystąpieniu do działania, naszą uwagę przykuwa wiele rzeczy, które wywołują serię skojarzeń, które to z kolei kuszą nas do zajęcia się wszystkim tylko akurat nie tym, czym planowaliśmy się zajmować.

Ktoś mi kiedyś powiedział, że przedmioty "wysyłają" do ludzi oferty. Przedmioty starają namówić Cię, abyś z nich skorzystał, wszedł w interakcję. Ładna metafora i chyba oddaje istotę rzeczy. Największym wrogiem dotrzymywania terminów (zakładam, ze sensownych :)) nie jest wcale nieumiejętność planowania, lecz nieumiejętność realizowania planu. Cierpimy na chroniczny brak umiejętności skupienia się i utrzymywania skupienia, choć dawni belfrzy z twardą trzciną w łapie powiedzieliby, że to brak samodyscypliny.

Wielokrotne powtarzanie opisanego na wstępie schematu prowadzi do nawyku silnego jak u mitycznego psa Pawłowa. Po jakimś czasie okazuje się, że po prostu nie sposób zacząć pracy bez godzinnego onetowego rytuału.

Weź pigułkę

Przyczyna tkwi chyba w pigułkowatej mentalności otaczającego świata. Zewsząd wmawia się nam, że istnieją proste rozwiązania na wszystkie problemy. Wcale nie potrzeba pracy nad sobą, wyrzeczeń, poświęcenia. Wystarczy wziąć "pigułkę"np:. przeczytać książkę, która odkrywa sekret, pójść na szkolenie, gdzie wleją nam wszystko do głowy albo pić ziółka i chudnąć 5kg/tydzień. Ostatnio nawet widziałem w TV reklamę, której sens można oddać następująco: "żryj do woli, jak się rozchorujesz to weź pastylkę X i żryj dalej".

Nie inaczej jest z planowaniem i wykonywaniem zadań. Karykaturalnie wykrzywiając powiedzenie "chcieć to móc" wmawia się nam, że po zastosowaniu sprytnych tricków, poradzimy sobie z każą ilością zadań. Gdyby wyobrazić sobie dobę jako koło, to każde z jego wycinków oznacza część doby przeznaczoną na coś.

Przeciętny człowiek ma zajęte całe koło, bo zawsze coś tam robi mniej lub bardziej aktywnie. A tu nagle każą nam sprawić, aby kąt pełny miał więcej niż 360 stopni. Brutalna prawda jest taka, że aby zacząć coś robić, coś trzeba przestać robić albo czegoś robić mniej. To nie żadne hokus pokus, tylko zdrowy rozsądek.

Niestety zaczynamy wierzyć w taką pigułkowatą naturę rzeczywistości. Zaczynamy oczekiwać, że można coś osiągnąć bezkosztowo, że można zjeść ciastko i mieć ciastko jednocześnie. Efektem nie jest jednak natychmiastowy i oszałamiający sukces lecz frustracja, miernota i rozczarowanie.

Terapia

Leczenie z nadmiernego pobudzenia otaczającym światem, które sprzyja rozproszeniu i odciąga od tego, co rzeczywiście należy zrobić, jest możliwe.
Wydaje mi się, że warto zacząć od paru praktyk ograniczających wspomniane oferty przedmiotów:

• Zadania zaczynaj od pierwszego na liście. Nie od RSS, newsów, maili itp. (wrzucanie RSSów do listy się nie liczy:))
• Wyłącz komunikator, klienta poczty i włączaj je tylko w ściśle ustalonych porach (wiem, że to czelendż, ale warto spróbować)
• W kliencie poczty wyłącz automatyczne odbieranie poczty przy starcie i co 10 minut
• Z umiarem stosuj smartfony. Naprawdę nie musisz być on-line non stop.
• Jeśli już koniecznie musisz poczytać newsy zrób to na końcu listy zadań, nie na początku
• Słuchanie muzyki podczas pracy nie jest takie dobre jak się o tym mówi; Jest ok przy prostych powtarzalnych zdaniach. Jeśli zdania wymagają kreatywności, to angażują prawą półkulę mózgu, tą samą co muzyka. Zatem Twoje zadanie konkuruje o zasoby fooobarem2000
• Jak najszybciej zamykaj zadania i jak ognia unikaj zostawiania ich rozgrzebanych i niedokończonych. Lepiej jest mieć 50% czegoś konkretnego niż 100% świetnych niezrealizowanych pomysłów

Nawyki programisty

Artykuł ukazał się w kwietniowym numerze Software Developer's Journal

Jak myślisz, co ma wpływ na Twoją skuteczność, kiedy programujesz? Wśród wielu czynników z pewnością wymienisz: wiedzę, umiejętności techniczne, doświadczenie, motywację, zaangażowanie, współpracę, chęć uczenia się i wiele, wiele innych. Na ogólnym poziomie wymienione rzeczy dzielą się na dwie grupy: czynniki techniczne oraz czynniki nietechniczne. Zakładamy, że skoro jesteś programistą, to doskonale wiesz, czego potrzebujesz w obszarze umiejętności technicznych. Dlatego proponujemy Ci przyjrzenie się umiejętnościom z drugiej grupy – umiejętnościom nietechnicznym.

Rzucamy wyzwanie

Zaprezentujemy kilka prostych czynności, które konsekwentnie stosowane każdego dnia mogą wprowadzić ogromną jakościową zmianę w Twojej pracy.
Nie próbujemy Cię przekonywać, nie prosimy, abyś uwierzył na słowo. Sprawdź
i przekonaj się sam.

Zawrzyjmy kontrakt, że przez najbliższe trzydzieści dni będziesz stosować opisywane nawyki, a potem ocenisz efekty. W tym względzie wymagamy sumienności. Trzydzieści dni to trzydzieści dni i ani jednego mniej. To bardzo niewielkie wymaganie, biorąc pod uwagę fakt, że jakość Twojej pracy znacząco wzrośnie. Jeśli zrobisz przerwę w trakcie eksperymentu, to zacznij odliczanie od nowa. Mamy umowę?

Nawyk 1. – Rozpoczynaj pracę o stałej porze

Nie bez powodu metodyki z nurtu Agile zalecają trzymanie się ustalonej długości iteracji. Gdy wykonujesz rzeczy regularnie, w określonym porządku – nabierasz rytmu. W ten sposób skupiasz się na rzeczach najistotniejszych i nie zaprzątasz sobie głowy nieustannym organizowaniem swojego dnia pracy, ponieważ masz pewien nawykowy schemat postępowania.

Wielu programistów ma elastyczny czas pracy. Muszą być być na swoim stanowisku, np.: od 10 do 16, a pozostałe godziny mogą odpracować w domu. To bardzo wygodne rozwiązanie, ale powoduje, że dużo energii poświęcają na zorganizowanie każdego dnia, ponieważ każdy dzień jest inny. Stosowanie stałego rozkładu dnia pozwoli Ci skoncentrować się na rzeczach najważniejszych. Na początek rozpoczynaj dzień pracy o stałej porze.

Nawyk 2. – Planuj swój dzień

Jak często zdarza Ci się mówić: Nie mam czasu? To zdanie to bardzo dobry pretekst lub wymówka. Masz czas. Masz dokładnie tyle samo czasu, co każdy inny programista na Ziemi – 24 godziny w ciągu doby (życie na innych planetach pomijamy). Najważniejsze pytanie brzmi – co robisz z czasem, który masz do dyspozycji?

Przeprowadź eksperyment. Przeznacz jeden dzień na przyglądanie się wszystkiemu, co robisz w trakcie pracy. Zanim cokolwiek zrobisz – zapisz to. Przykładowe czynności, które możesz zanotować: napisanie testu metody, napisanie implementacji metody, wdrożenie aplikacji na serwer testowy, wyszukanie informacji w Internecie, rozmowa telefoniczna, sprawdzanie poczty, rozmowa, problemy z oprogramowaniem lub sprzętem.

Zapisanie zajmie najwyżej kilka sekund, zatem koszt naszego eksperymentu jest znikomy. Na koniec dnia powinieneś mieć spis rzeczy, które robiłeś w ciągu dnia. Następnie oblicz, jaki procent czasu przeznaczyłeś na programowanie. Jak bardzo zdziwił cię wynik?
Niech planowanie dnia stanie się Twoim codziennym rytuałem. Zanim zaczniesz pracę zaplanuj, co będziesz robić danego dnia i ustal, co jest dziś najważniejsze. Przeanalizuj jak wiele zrobiłeś i zaznacz wykonane zadania w swoim planie. Być może właśnie postanowiłeś, że najpierw przeczytasz jakąś supermądrą książkę na temat zarządzania czasem, zainstalujesz odpowiednie oprogramowanie i dopiero wtedy będziesz gotowy do działania zgodnie z planem. Nic z tych rzeczy, absolutnie tego nie rób. Jesteśmy bardzo dumni z Twojej kreatywności, ale książki i oprogramowanie nie są Ci w tej chwili potrzebne. Wystarczy kartka papieru i długopis. Zachowuj te kartki, niech to będzie Twój Osobisty Dziennik Sukcesów.

Nawyk 3. – Opracuj rozwiązanie przed implementacją

Słynny fizyk John Wheeler powiedział kiedyś: Nigdy nie zabieraj się do obliczeń, dopóki nie znasz odpowiedzi. Możemy sparafrazować tę myśl: nigdy nie zbieraj się do programowania, dopóki nie znasz rozwiązania. Dość często programiści rzucają się do implementowania, nie zadając sobie sobie podstawowego pytania: Czy to ma sens?. Gdy programujesz pod wpływem impulsu, napotykasz szereg problemów, na które nie jesteś przygotowany. Poświęcasz na ich rozwiązanie wiele energii i jednocześnie odczuwasz frustrację, że to zajmuje aż tyle czasu. Po kilku godzinach lub co gorsza po kilku dniach okazuje się, że funkcjonalność najlepiej zaimplementować w zupełnie inny sposób. Dochodzisz wtedy do wniosku, że wykonałeś kawał wspaniałej, lecz niepotrzebnej roboty.

Nigdy nie zabieraj się do programowania, dopóki nie znasz rozwiązania. Najpierw przemyśl swój pomysł, naszkicuj kilka diagramów, zbadaj konsekwencje rozwiązania, zastanów się nad alternatywami. Czasem kilkanaście minut prac koncepcyjnych oszczędza wiele godzin programowania.

Nawyk 4. – Szacuj zadania

Wykonanie zadania zajmie przeważnie co najmniej tyle czasu, ile na nie przeznaczysz. Jeśli na zaimplementowanie jakiejś funkcjonalności przeznaczysz 16 godzin, a uda Ci się zakończyć zadanie w 10, to kolejne 6 spędzisz na udoskonalaniu i poprawianiu rozwiązania albo nawet na sześciogodzinnej refaktoryzacji. Co więcej, znajdziesz bardzo wiele racjonalnych powodów, dla których było to absolutnie konieczne.

Zanim przystąpisz do programowania, oszacuj czas potrzebny na to zadanie. Prawdopodobnie miałeś już do czynienia z podobnymi zadaniami, a nawet jeśli nie, to znasz kogoś, kto robił coś podobnego. Będziesz mieć punkt odniesienia dla szacowania. W skrajnym przypadku oszacuj intuicyjnie. Od razu uprzedzamy, że często będziesz się mylić – to nieuniknione. Wszelkie informacje dotyczące odchylenia od przewidywanego czasu zapisuj w swojej bazie szacowań. Zaglądaj do niej często i koryguj przewidywania według zapisanych obserwacji. Bardzo szybko staniesz się ekspertem w tym obszarze.

Nawyk 5. – Odłącz się od internetu

Internet jest niecenioną pomocą w naszej pracy, lecz potrafi przykuć uwagę na długie godziny. Zastanów się jak często poszukujesz informacji w sieci i jak często kończysz surfowanie, gdy znajdziesz potrzebne rzeczy. Czy odsyłacze do innych stron nie kuszą Cię? Czy podczas zapoznawania się z API danej metody, nabierasz chęci zapoznania się z całą dostępną dokumentacją biblioteki lub frameworka? Jeśli tak,to odłącz się od internetu na czas pracy. Być może przychodzą Ci teraz do głowy myśli, że nie możesz dobrze pracować bez internetu, że będziesz potrzebował absolutnie niezbędnych informacji. Jeśli tak właśnie myślisz, to zajrzyj do notatek, które zrobiłeś w trakcie ćwiczenia dotyczącego planowania dnia (lub zrób je jeszcze raz na bardziej szczegółowym poziomie). Ile czasu poświęcasz poszukiwanie informacji potrzebnych do pracy, a ile na czytanie ciekawych artykułów nie związanych z tym co aktualnie robisz, na sprawdzanie poczty co pięć minut, na korzystanie z komunikatorów internetowych? Porównaj wyniki z czasem, który przeznaczasz na odnajdywanie informacji związanych z Twoim bieżącym zadaniem.

Aby pożytecznie korzystać z internetu, najlepiej podporządkować to aktualnemu zadaniu. Proponujemy następując schemat postępowania:

• Zaplanuj swój dzień (patrz: Nawyk 2.);
• Opracuj rozwiązanie przed implementacją (patrz: Nawyk 3.);
• Zdobądź informacje potrzebne do wykonania zadania;
• Odłącz internet i programuj przez dwie godziny;
• Zrób przerwę, przeanalizuj to, co udało się wykonać i przejdź do kolejnej części zadania.

Musimy wyjaśnić jeszcze jedną rzecz. Przyczyną naszej propozycji odłączenia się od sieci nie jest internet sam w sobie, a celem wskazanego sposobu postępowania nie jest odcięcie Cię od źródła informacji. Naszym zamierzeniem jest zapanowanie na nawykowym i częstym, niż to potrzebne, korzystaniem z internetu, które rozprasza programistę i negatywnie wpływa na jego efektywność.

Nawyk 6. – W pierwszej kolejności poszukuj błędów w swoim kodzie

Za chwilę przeczytasz bardzo kontrowersyjny akapit, zatem zrób krótką przerwę. Przerwij na chwilę czytanie, popatrz na drzewa, zanuć ulubioną piosenkę.

Uwaga! Z naszego doświadczenia i z doświadczenia liderów, z którymi współpracujemy wynika, że większość przyczyn błędów w oprogramowaniu leży po stronie programisty, natomiast ten poszukuje ich na zewnątrz: w technologiach, w bibliotekach, w niedociągnięciach innych programistów, w złośliwości rzeczy martwych.

Przed Tobą ostatnie i najtrudniejsze ćwiczenie. Najtrudniejsze, ponieważ dotyka Twoich przekonań. Wiemy, że to niełatwe zdanie. Odwagi, uda Ci się!
Za każdym razem, gdy napotkasz irytujący błąd w kodzie, nad którym pracujesz, załóż, że to Ty zrobiłeś coś, co go spowodowało. Poszukuj przyczyny przez założony czas i dopiero, gdy to nie przyniesie efektu, przyjmij, że możesz szukać na zewnątrz.

Nie ma drogi na skróty

Być może zadajesz sobie pytanie: Ile czasu mam poświęcić, aby stać się wysoce efektywnym programistą?. Odpowiedź brzmi: Tyle, ile trzeba. Nie ma drogi na skróty. Nabywanie nowych umiejętności i rozwijanie ich wymaga czasu, pracy, cierpliwości i sumienności. Jeśli zaakceptujesz ten fakt, nauka stanie się łatwiejsza i przyjemniejsza. Nawyki, które opisaliśmy, mogą pomóc Ci skoncentrować działanie na ważnych rzeczach i zorganizować sposób pracy, lecz odpowiedzialność za ich wprowadzenie w życie leży po Twojej stronie – Ty decydujesz.

7 Kroków Zła w Projektach IT

Wersja PDF

Czy zastanawiałeś się już jak to się dzieje, że na początku projektu jesteś maksymalnie zmotywowany, piszesz wspaniałe testy (wszystkie są oczywiście green-bar), używasz swojego najpiękniejszego stylu kodowania, klasy, interfejsy metody, ba! nawet pola mają swoją własną, niepowtarzalną odpowiedzialność. Rysujesz piękne diagramy, używasz wzorców projektowych w rozsądnej ilości, a Twój kod czyta się jak najbardziej przejrzystego ebooka. A potem...potem pojawia się niewielki, ledwo zauważalny zgrzyt, mała rysa na wspaniałym krysztale projektu. Ignorujesz to, bo przecież nic się nie stało. Rysa rośnie, a przez nią wsączają się kolejne niedociągnięcia i niedoróbki, aż po jakimś czasie nie poznajesz już tego wspaniałego projektu, siadasz do niego z największym obrzydzeniem i myślisz tylko kiedy to się skończy? Lecz projekt się nie kończy, wciąż są nowe wymagania, wciąż trzeba go utrzymywać. I to, mój przyjacielu, jest Programistyczne Piekło!

Jako przestrogę podam Ci kilka prostych wskazówek jak się tam znaleźć. Ścieżka prowadząca wprost do Programistycznego Piekła jest szeroka, gładka i bardzo prosta. Wystarczy siedem kroków.

1. Bądź obojętny
   Czy to ja powinienem zająć się tym //FIXME? Nieee, to nie ja pisałem, niech ktoś inny to zrobi.
   Czy często zdarza ci się rozumować w ten sposób? Jeśli tak, to gratuluję! Osiągnąłeś pierwszy poziom wtajemniczenia. Obojętność wobec niewielkich rys na projekcie to początek drogi w dół. Być może pomyślisz: oj, jeśli w jednej klasie będzie niewielki bałagan, to przecież nic się nie stanie. Pamiętaj, że małe rzeczy się kumulują. Nie zauważysz od razu różnicy pomiędzy metodą nazwaną divideByTwo(), a div2()
   , bo łatwo umyka wśród reszty kodu. Lecz z pewnością dostrzeżesz różnicę za pół roku, gdy tego typu nazewnictwo będzie obecne w całym projekcie. Ziarnko do ziarnka...
2. Bądź w miarę wierny swoim ideałom
   Cóż, w zasadzie stosuję wzorce projektowe...to znaczy w niektórych projektach. Tych w domu. Piszę też testy...prawie wszystkie przechodzą. Piszę zgodnie ze standardem kodowania...właściwe to w 30%, bo reszta jest niepotrzebna. Odpowiedzialność? Taa, fajny koncept, ale moim zdaniem....
   Znasz to? Czy uważasz, że techniki programowania obiektowego teoretycznie są bardzo dobre ale faktycznie się nie sprawdzają? Jak wyrobiłeś sobie takie zdanie? Acha, przetestowałeś to, rozumiem. Wiesz, to że nie działają, to tylko jedna możliwość. Druga to taka, że używasz ich niewłaściwie. Co wybierasz?
3. Postępuj zgodnie z procedurami
   Pokrycie kodu ma być co najmniej 90% więc w tym tygodniu już nie muszę pisać żadnego testu! Ta metoda jest nieczytelna...no, ale CheckStyle się nie czepia. Diagramy muszą być tylko do istotnych elementów systemu...moja jest chyba nieistotna?
   Procedury, reguły, zasady są dobre. Precyzują sposób pracy i optymalizują sposób wytwórczy. Często jednak, niemal automatycznie, uważa się, że stosowanie procedur w zupełności wystarczy, zatem można zwolnić się z myślenia. Kłopot w tym, że nawet najbardziej wyrafinowane zasady nie przewidują wszystkich sytuacji, które mogą wystąpić w życiu. Bardzo wiele problemów, z którymi się spotkasz, nie da się rozwiązać za pomocą Księgi Procedur używanej w twoim zespole. Jednak z każdym z nich można sobie poradzić przy użyciu zdrowego rozsądku.
   
4. Graj dla zespołu
   Nie wychylaj się. Bezkrytycznie akceptuj opinie bardziej doświadczonych kolegów. Postaw cele zespołu nad swoimi własnymi
   Przede wszystkim: dlaczego pracujesz w tym zespole? Wymień dziesięć przyczyn. Zrób to teraz!
   Jeśli praca, która wykonujesz nie jest zgodna z twoimi osobistymi celami, nie prowadzi cię do jakiegoś wyżej postawionego celu, to prędzej czy później, zaczniesz sabotować to, co robisz. Krok po kroku, niepostrzeżenie, zaczniesz wprowadzać w życie misterny plan obniżania jakości swojej pracy. Być może już teraz warto wybrać się na rozmowę z samym sobą.
   
5. Dziel się odpowiedzialnością
   Jest błąd w mojej części kodu? ...ale Paweł kazał mi tak napisać...powiedział, że będzie działać...
   Zadziwiające, że jeśli chodzi o sukces, to chętnie podpisujemy się pod nim sami. Jeśli chodzi o wzięcie odpowiedzialności za błąd i niepowodzenie chętnie dzielimy się odpowiedzialnością z innymi.
   
6. Ceń ludzi takich jak ty
   MY programiści i ONI analitycy. MY javowcy i ONI .NETowcy. MY od kluczowego projektu i ONI od maintenance. MY starzy pracownicy i ONI nowi...
   Dzieląc swoich i innych sprawia, że nadajemy grupie osób wspólne cechy odróżniające ich od nas samych, czyniących w jakimś stopniu gorszymi. Etykietowanie zapewnia poczucie bezpieczeństwa i porządkuje świat. Daje złudzenie, że nie zginiemy w zespole jako indywidualność. Jak na ironię, takie postępowanie likwiduje indywidualność członków zespołu i blokuje efekt synergii, obejmującą ludzi nic nie znaczącą etykietą oni.
   
7. Wierz w najlepsze rozwiązanie
   Ok, pracujemy w Agile, teraz już będzie dobrze. JEE rozwiąże wszystkie problemy. Nowy framework sprawi, że praktycznie kod będzie pisał się sam.
   Gdyby istniało rozwiązanie/technologia/framework rozwiązująca wszystkie problemy to już dawno by zostało wymyślone i żylibyśmy w świecie, w którym nie byłoby wojen, nikt nie przekraczałby prędkości, a programy by się nie zawieszały. Nie istnieje najlepsze rozwiązanie (w ogóle). Co najwyżej może istnieć rozwiązanie najlepsze, w sensie: najbardziej odpowiednie i optymalne, w danej chwili, dla danego problemu, w danym zespole. Jedyne co może zrobić nowa technologia, framework, biblioteka, czy język to przenieść ciężar problemu w inne miejsce. To coś jak dźwignia pozwalająca zużyć mniej energii do uzyskania tego samego efektu. Pamiętaj jednak, że zawsze istnieją dwie strony medalu. Coś co rozwiązuje jedne problemy zazwyczaj generuje nowe.
   

Tekst powstał z inspiracji artykułem Philipa Zimbardio Evil's Seven Step Seduction Scenario opublikowanym w Charaktery 9/2008

Metaprogramy w tworzeniu oprogramowania

Wersja PDF

Jeśli jesteś programistą albo w jakikolwiek inny sposób związany z branżą IT, to najprawdopodobniej po przeczytaniu tytułu, spodziewałeś się porcji informacji technicznych. Muszę Cię zaskoczyć, artykuł będzie o innych programach i o innym programowaniu niż sobie wyobrażasz.

Ludzie posługują się swoimi myślami w zorganizowany sposób. Dzieje się to często na poziomie nieświadomym. Gdy o czymś myślimy, w umyśle pojawiają się różnego rodzaju obrazy, odczucia czy dźwięki. Choć nie zawsze zdajemy sobie z tego sprawę, w ten właśnie sposób przetwarzamy informacje docierające z zewnątrz (i z wewnątrz).

Psycholingwistyce zawdzięczamy badania nad tą wewnętrzną organizacją codziennych doświadczeń. Okazuje się, że można wyróżnić pewne schematy, że ludzie posługują się pewnymi wzorcami zachowań, które nazwano metaprogramami. Metaprogramy zostały pogrupowane w przeciwstawne, uzupełniające się pary scenariuszy w następujący sposób:

• Unikanie – Dążenie
• Autorytet wewnętrzny – Autorytet zewnętrzny
• Podobieństwa – Różnice
• Ja – Inni
• Informacje szczegółowe – Informacje globalne
• Proaktywne – Reaktywne
• Opcje – Procedury

Dla osoby skoncentrowanej na unikaniu, bodźcem do działania będzie chęć uniknięcia niepożądanych sytuacji. Przeciwnie, dla osoby posługującej się metaprogramem Dążenie, ważniejsze będzie osiągnięcie wyznaczonego celu. Czytelników zainteresowanych dokładnym poznaniem metaprogramów odsyłam do literatury.

Preferowane metaprogramy

W praktyce nigdy nie jest tak, aby dany scenariusz np. Unikanie występował w czystej formie. Jest tak przede wszystkim dlatego, że procesy myślowe są w swej naturze zbyt skomplikowane (i jeszcze wiele jest do odkrycia), by opisać je za pomocą tak prostego modelu jakim są metaprogramy. Koncept metaprogramów należy traktować zatem jako pewne przybliżenie rzeczywistości o ograniczonym zakresie stosowalności.

Używanie metaprogramu jest zależne od kontekstu (kontekstualizm), środowiska w którym znajduje się człowiek. Ktoś na co dzień skoncentrowany na Dążeniu może radykalnie zmienić sposób myślenia, gdy ucieka przed goniącym go psem – wtedy najprawdopodobniej skupi się na uniknięciu niebezpieczeństwa, bez znaczenia w jaki sposób.

Bardzo istotne jest to, że metaprogramy nie podlegają ewaluacji. Żaden z nich nie jest lepszy lub gorszy – są inne. Jedyne co można powiedzieć to, że dany scenariusz może być mniej lub bardziej użyteczny w określonej sytuacji. Zadaniem artykułu jest, przede wszystkim, pobudzenie do refleksji nad własnym stylem pracy.

Choć obserwując zachowania ludzi, można wskazać pewne przejawy każdego z metaprogramów to jednak poszczególne osoby mają osobiste preferencje. Najczęściej 1 do 3 metaprogramów dominuje, pozostałe pojawiają się sporadycznie. W dalszej części zastanowimy się, które z metaprogramów są najistotniejsze w pracy programisty.

Zbieranie wymagań

Zbieranie wymagań oraz modelowanie systemu są czynnościami o tyle ważnymi, że kierunkują dalsze prace zespołu. Prace nad projektem rozpoczynają się (powinny się rozpoczynać) od stworzenia jego wizji. Wizja, w postaci metafory, jest metacelem, do którego zmierzać będzie projekt w kolejnych fazach rozwoju. Dalej wyłania się zbiór wymagań, zestaw procesów, w których może brać udział użytkownik. Pojawia luźny koncept rozwiązania i będzie uszczegóławiany w dalszych krokach.

W opisanym wyżej procesie projektowania zauważamy, że prace odbywają się na poziomie ogólnym. Programiści/projektanci wykazują w tym miejscu tendencję do skupiania się na konkretnym rozwiązaniu. Podczas rozmowy z potencjalnym użytkownikiem, od którego należy zebrać wymagania, deweloper stara się podążać za tokiem myślowym rozmówcy. Jednocześnie zastanawia się, czy i jak konkretne wymaganie zostanie zrealizowane. Myślenie o rozwiązaniu jest jak najbardziej w porządku tyle, że nie na to jest miejsce podczas zbierania wymagań, gdy należy się skoncentrować na zrozumieniu wyobrażeń użytkownika o sposobie pracy z przyszłym narzędziem. Z tego względu zbieranie wymagań warto przeprowadzać w sesjach, np.: godzinę rozmowy z użytkownikiem, a następnie pół godziny na analizę wymagań i formułowanie dodatkowych pytań.

W artykule Klient, który wie, czego chce rozważałem różnice w sposobie myślenia analityka i klienta. Głównym wnioskiem było to, że klienci jednak wiedzą, czego chcą. Opisują to jednak w postaci procesów, natomiast analityk widzi system jako strukturę. Podążając za procesem łatwiej dokonywać w nim zmian. Z kolei zmiany wprowadzane w strukturze wymagają przeanalizowania całej koncepcji od nowa. Podczas zbierania wymagań klient często zastanawia się nad pożądanym sposobem pracy. Próbuje różnych alternatywnych przebiegów tego samego procesu i oczekuje od analityka pomocy w wyborze najlepszego rozwiązania. Jeśli analityk nie podąża w procesie za klientem, lecz percypuje system jako strukturę, to ma nie lada kłopot. Alternatywne ścieżki procesu klienta zazwyczaj mają istotny wpływ na domniemaną strukturę systemu i/lub implementację.

Dochodzimy do kolejnego, istotnego w pracy programisty, metaprogramu: Opcje – Procedury. Najczęściej klient chce próbować różnych możliwości – jest nastawiony na opcje. Analityk powinien wyjść naprzeciw tym oczekiwaniom. Należy przypomnieć fakt, że nastawienie na opcje może nie być głównym metaprogramem klienta. Jednak w kontekście zbierania wymagań, gdy zastanawia się on nad sposobem pracy z narzędziem i analizuje różne procesy, najczęściej chce mieć możliwość wybrania najlepszego rozwiązania spośród dostępnych.

Podsumowując część o zbieraniu wymagań stwierdzamy, że w tym kontekście pracy programisty ważne jest nastawienie na Ogół oraz na Opcje. Te sposoby myślenia pozwalają pozostać na odpowiednim poziomie abstrakcji i skupić się na wizji i celu istnienia systemu zamiast brnąć w konkretne technologie i rozwiązania tylko po to, aby w następstwie późniejszych decyzji w pośpiechu się z nich wycofywać.

Programowanie

Po zebraniu wymagań i zaplanowaniu prac przychodzi czas na implementację. W chwili obecnej role projektanta oraz programisty przenikają w projekcie. Myślę, że to dobrze, gdyż można w pełni wykorzystać potencjał tkwiący w programistach. W tej sytuacji deweloperzy dostają pewne wytyczne z projektem systemu i mają dość dużą dowolność w implementowaniu poszczególnych klas oraz metod.

Implementacja złożonego systemu informatycznego, gdzie współpracuje ze sobą wiele niezależnych bytów, jest skomplikowanym zadaniem. Na tym etapie programujemy już konkretne zachowania i procesy. Od programisty oczekujemy, że będzie potrafił uzasadnić wybór tego, a nie innego rozwiązania. Dodatkowo należy przestrzegać obowiązujących w zespole konwencji kodowania, zasad projektowania, wytycznych pisania testów, itp. Nie ma tu miejsca na swobodną twórczość albo raczej ma ona miejsce drugorzędne. Ważniejsze jest przestrzeganie określonych zasad – procedur. Ujawnia się nam kolejny scenariusz pomocny programiście: Procedury. Osoba, sprawnie posługująca się procedurami, rozważa rzeczywistość jako ciąg logicznych następstw, gdzie każde zdarzenie ma swoją przyczynę oraz konsekwencje. Intuicyjnie czujemy, że Procedury to jeden największych sprzymierzeńców programistów. Możemy być dumni z faktu, że wykorzystujemy metaprogram do tworzenia wspaniałego oprogramowania.

Warto jeszcze poruszyć jeszcze jeden aspekt programowania, istotny w kontekście rozważania metaprogramów. Mowa o abstrahowaniu. Języki obiektowe dają sposobność budowania złożonych zależności pomiędzy klasami dzięki np. dziedziczeniu, polimorfizmowi, interfejsom. Możliwości te, aż same zachęcają do ich korzystania. Istota kwestii leży w sposobie korzystania z tych udogodnień. Gdy programista implementuje daną funkcjonalność ma tendencję do tworzenia całej gamy abstrakcyjnych bytów „na wyrost”. Efekt jest taki, że w projekcie każda klasa implementuje specyficzny interfejs (nie używany nigdzie indziej) oraz posiada, do niczego nie potrzebną, klasę abstrakcyjną. Z kolei podczas używania danych klas i tak wszędzie następuje rzutowanie na obiekty konkretne. Przyczyną takiego tworzenia kodu jest „zachłyśnięcie się” paradygmatem reużywalności i elastyczności komponentów. Oczywiście paradygmat ten jest jak najbardziej słuszny, lecz sposób jego egzekwowania już nie. Błąd programisty polega na próbie zaprojektowanie stworzenia maksymalnie rozszerzalnego kodu i „zapomina” że każde rozwiązanie ma ściśle określone granice stosowalności. Programista próbuje stworzyć komponenty możliwe do zastosowania wszędzie (Golden Hammer). Popatrzmy na poniższy kod:

public interface Problem {
//...
}
public interface Solution {
//...
}
public interface UniversalProblemSolver {
public Solution solve( Problem problem );
}

Właściwie każda klasa mogłaby implementować interfejs UniversalProblemSolver, prawda? Gdy tworzymy kod, który ma dostarczać określoną funkcjonalność i koncentrujemy się przede wszystkim na jego uniwersalności, zamiast na konkretnym zadaniu które ma wykonać, popadamy w opisaną wyżej pułapkę. W takiej sytuacji myślimy poprzez Ogół i tworząc abstrakcyjne byty, zmierzamy do celu wyjątkowo krętą ścieżką.

Optymalne programowanie wymaga podejścia od strony Szczegółu. Najpierw tworzymy konkretne rozwiązanie implementujące żądaną funkcjonalność. Jeśli w trakcie tworzenia kodu zajdzie potrzeba abstrahowania: wydzielenia hierarchii dziedziczenia, interfejsów – refaktorujemy kod. Praca odbywa się zatem od Szczegółu do Ogółu – w odwrotnym kierunku niż w przypadku zbierania wymagań i modelowania systemu. Ten styl programowania wymaga od deweloperów wewnętrznej samodyscypliny. Warto skorzystać z technik programowania np. Test-Driven Development, które wspomagają ten styl pracy. TDD, dzięki filozofii pisania testu funkcjonalności przed jej implementacją, zabezpiecza przed nadmiarowym „rozdmuchiwaniem” klas i dokładaniem kodu, być może użytecznego, lecz zbędnego z punktu widzenia tworzonego systemu.

Przenoszenie metaprogramów

Powyżej wyróżniłem dwa konteksty pracy programisty, w których pożądane jest posługiwanie się odmiennymi scenariuszami metaprogramów Ogół – Szczegół oraz Opcje – Procedury. Ta właśnie potrzeba przełączania się pomiędzy różnymi scenariuszami rodzi wiele kłopotów i frustracji. Jest tak przeważnie dla tego, że „uruchamianie” odpowiedniego metaprogramu odbywa się w sposób nieświadomy. Drugą przyczyną, jak na ironię, jest zdolność do uczenia się. Przypuśćmy, że ktoś uczy się programowania. Po jakimś czasie wykształca sobie pewien sposób myślenia i sprawnie posługuje się scenariuszami Procedury oraz Szczegół. W umyśle człowieka rodzi się skrót myślowy: jeśli TO zadziałało w TYM przypadku, z pewnością zadziała również w TAMTYM. Ów człowiek, za pomocą metaprogramu, dobrze działającego w jednym kontekście (praca) próbuje wykonywać działanie w zupełnie innym kontekście (np. relacje międzyludzkie). To zjawisko może prowadzić do niepożądanych skutków. Praca nad własnymi metaprogramami uwrażliwia nas na podobne sytuacje i uczy efektywnego funkcjonowania w różnych kontekstach.

Korzyści

Najważniejszą, moim zdaniem, korzyścią ze znajomości i rozwijania określonych metaprogramów jest rozszerzenie spektrum możliwych reakcji na sytuacje pojawiające się podczas prac nad projektem. Umiejętność posługiwania sposobami myślenia innymi niż nasze własne sprawia, że efektywniej współpracujemy z klientami, użytkownikami oraz z innymi członkami zespołu. Poniżej wymieniam dodatkowe korzyści:

• pomoc w formowaniu zespołu projektowego
• wyznacznik dla osób rekrutujących programistów
• skrócenie czasu zbierania wymagań
• poprawa komunikacji w zespole
• pomoc podczas projektowania ścieżki rozwoju dla programistów

Podsumowanie

W artykule wyróżniłem metaprogramy Ogół – Szczegół oraz Opcje – Procedury jako bardzo istotne w pracy programisty. Zdaję sobie sprawę, że istnieje wiele punktów w procesie rozwoju oprogramowania, które nie zostały tu wspomniane. W obszarach tych również korzystamy ze specyficznych metaprogramów i wiedza o nich będzie nieocenioną pomocą. Dalszą eksplorację tego zagadnienia rezerwuję sobie na najbliższą przyszłość. Warto wskazać czego potrzeba opracowaniu tego typu, aby stanowiło rzetelną pomoc w pracy dewelopera:

• kompletny opis procesu wytwarzania oprogramowania z punktu widzenia wykorzystywanych metaprogramów,
• opis efektywnych technik pracy na każdym z etapów,
• zestaw ćwiczeń pozwalających rozwijać pożądane metaprogramy.

Każdy krok w kierunku rozwoju własnego warsztatu pracy uświadamia, że istnieje coś poza technologią, coś co porządkuje poszczególne umiejętności i pozwala korzystać z ich jeszcze efektywniej. Odkrywanie tych zasobów jest fascynującą podróżą ku doskonałości.