No to jak to z tą architekturą - up-front design czy ewolucyjna architektura?

W jakim miejscu obecnie stoi architektura? Można powiedzieć, że mamy dwa klasyczne podejścia:
    • klasyczne, które każe starannie zaplanować możliwie wiele szczegółów (up-front);
    • zwinne, które każe podejmować decyzje najpóźniej, jak to możliwe i rozwijać architekturę poprzez refaktoring.
Jak to najczęściej się odbywa w projektach? W dużej części przypadków tworzy się projekt mniej lub bardziej szczegółowy (w stylu up-front) i tak już zostaje.
Z drugiej strony liczenie na to, że uda się rozwinąć dobrą architekturę tylko i wyłącznie organicznie, poprzez naturalną ewolucję, też zazwyczaj się nie udaje. W dużych projektach jest to wręcz niezwykle ryzykowne, gdyż prowadzi często do rozwiązań lokalnych, które w pewnym momencie należałoby całkowicie przepisać (co najczęściej się nie dzieje).
W praktyce zdecydowanie najlepiej sprawdza się mieszane podejście tzn. na początku projektu, releasu, iteracji, tworzy się koncept i projekt rozwiązania, który stanowi bazę i punkt odniesienia do prac projektowych. Nie musi, a nawet nie powinien być to niezwykle szczegółowy projekt. Z drugiej strony nie należy zakładać że to, co zostało wymyślone na początku, będzie doskonałym rozwiązaniem, dlatego w ramach prac projektowych, dokonujemy bieżącej lokalnej modyfikacji założeń projektowych poprzez refaktoryzację.
Dzięki temu uzyskujemy naturalny proces rozwoju architekury, z jednej strony jest ona wstępnie zaprojektowana, dzięki czemu nie stracimy czasu i zasobów na ewolucyjne błądzenie. Ewolucję wykorzystujemy, to poprawienia pierwotnego projektu. Jeśli powiążemy to z procesem Naturalnego Porządku refaktoryzacji to jesteśmy w domu! Więcej w kolejnych wpisach.

Szkic procesu wygląda następująco:

Właściwość złożonych systemów

Dzisiaj rano jadąc samochodem do pracy natknąłem się na dużo dłuższy korek niż zwykle. "No tak, przy takim mrozie pewnie wszyscy jadą szczególnie ostrożnie" - pomyślałem i powoli się turlałem Trasą Łazienkowską. Po kilkunastu minutach, w pewnym momencie zauważyłem z daleka, że na jezdni w przeciwnym kierunku był wypadek i policja oraz pogotowie robiły, co swoje. Na moim pasie nic się szczególnego nie działo. Niby nic, a jednak... Kierowcy najzwyczajniej w świecie zwalniali, żeby zobaczyć co się dzieje na drugim pasie. Nikt się nie zatrzymywał, tylko patrzyli, co się dzieje. I z tego powodu fragment, który zazwyczaj przemierzałem w 5 minut, zajął mi tym razem 20 minut. Po przejechaniu tego punktu ruch znacząco przyspieszył i przebiegał normalnie.

Dlaczego o tym piszę? Od razu dostrzegłem analogię do projektów programistycznych :) Przedsięwzięcia programistyczne - ludzie, architektura, procesy - to złożony system. Często niewielkie zmiany, pozornie nieistotne elementy mają ogromny, kaskadowy wpływ na to co się dzieje w projektach.

Być może o jeden punkt decyzyjny za dużo, za mało, brak lub nadmiar dokumentacji, brak asertywności lub przyzwolenia o mówieniu o błędach, brak ścisłej współpracy lub zbyt swobodna współpraca bez ustalonych reguł mogą znacząco zmniejszać efektywność całego procesu. Warto o tym pamiętać!

W przypadku ruchu drogowego sytuacja jest nieco prostsza, bo łatwiej ją zmierzyć - jest to prędkość i czas przejazdu na tej samej trasie. Nie mamy tego luksusu w projektach, gdzie zazwyczaj to, co jest realizowane nie jest tak powtarzalne. Jednak możemy przybliżać się do oszacowania i porównywania. Szacując zadania oraz dodając relatywną miarę złożoności zadań (funkcjonalności).
Mniej formalną metodą są punkty (points, story points), które są jednostką względną, służącą raczej do porównania złożoności różnych funkcjonalności, niż do dokładnej analizy złożoności (która jest niezwykle pracochłonna, a i tak pozostanie tylko prognozą). Bardziej formalną metodą (gdzie dużo precyzyjniej należy argumentować podane szacowania) mogą być kilkuczynnikowe metody szacowania i pomiar zadań za pomocą punktów funkcyjnych.

Wtedy możemy obserwować czy nasza prędkość się zmienia, jak wprowadzane zmiany mają na nią wpływ.

Dlaczego Agile nie zadziała

Wprowadzenie metody z rodziny Agile nie jest w ogóle łatwe. Problemem zazwyczaj jest to, że menedżment powierzchownie dowiadując się o co chodzi, odbiera nową metodę jako obietnicę - od teraz w magiczny sposób wszystko zacznie lepiej działać. Nieważne, że mamy kiepskich ludzi i hołdujemy zasadzie "każdego specjalistę można zastąpić przez skończoną liczbę studentów". Nieważne, że kompletnie nie dba się o zarządzanie wiedzą i umiejętności w zespole, bo nigdy nie ma na to czasu. Nieważne, że osoby realizujące projekty są przerzucane między projektami - bo przecież chodzi o interdyscyplinarność i każdy się powinien we wszystkim orientować. Nieważne, że terminy ustala się apriori, z do końca niejasnych przyczyn lub zakłada się, że to jedyny sposób, żeby przekonać klienta, że jesteśmy profesjonalni, a w terminie się "jakoś zmieścimy". Nieważne, że nie znajdujemy czasu na to, aby utrzymywać architekturę i kod, bo przecież nie ma czasu na tego typu zbędne czynności.
Nieważne, bo przecież Agile obiecuje, że teraz będzie już tylko pięknie. Dokleimy etykietkę to tego co robimy teraz - niech się to nazywa np. "Scrum", zrobimy trochę więcej chaosu, bo przecież chodzi o zarządzanie chaosem - zatem każdy robi co chce i jak chce, przestajemy cokolwiek dokumentować. Przecież stosujemy Agile, wszystko się samozorganizuje.

I dlatego najczęściej Agile nie działa, bo ludzie, którzy po omacku go stosują lub menedżment, który wstępnie akceptuje korzyści z danego podejścia, stosują bardzo uproszczone myślenie - "Ok. Robimy Scrum. Ale tak naprawdę 8 z 10 elementów nam nie pasuje, więc wybierzemy sobie, to co pasuje (dwa elementy), a resztę będziemy robić tak jak do tej pory (czytaj wyżej).
I tak wszystko będzie tak jak było, albo gorzej.

ZATEM UWAGA: W takim przypadku nie należny, nawet nie WOLNO zacząć stosować Agile. Agile to zmiana, ogromna zmiana, to nie etykietka, która rozwiąże wszystkie problemy (w tym przypadku prawdopodobnie lepiej się sprawdzi butelka alkoholu).

Efektywne poznawanie tematu

Tym razem temat nieco wychodzący poza projekty informatyczne. Ostatnio dużo robię tzw. pracy researchowej, gdzie muszę na bazie dużej ilości źródeł wiedzy zbudować spójny ekstrakt praktycznych informacji. Po dłuższej pracy w tym temacie napiszę o kilku wskazówkach, które miałem okazję wielokrotnie wykorzystywać.

Jeśli chcesz zbudować wiedzę na pewien temat np. continuous integration, technologia X.
Cel: chcesz naprawdę dobrze zrozumieć temat.
Założenie: Nie znasz nikogo, kto mógłby Cie naprowadzić na dobrą drogę ;-)


1. Przeprowadź spike'a* (maks. kilka godzin) odnośnie źródeł informacji - gdzie co możesz znaleźć i jaki jest poziom materiałów (wiarygodność i szczegółowość):
a) sprecyzuj pytania, na które chciałbyś znaleźć odpowiedzi;
b) w pierwszej kolejności wybieraj książki - jeśli są dobre, znajdziesz tam wiarygodne i uporządkowane informacje;
c) w drugiej kolejności wybieraj materiały akademickie (prace doktorskie, prace z konferencji) - zaletą jest wiarygodność, czasem jednak są nieuporządkowane, czasami (jeśli autor jest kiepski) jest to zwykłe bicie piany;
c) blogi i artykuły wiarygodnych osób w branży (rozpoznawalnych i uznanych);
d) unikaj w miarę możliwości forów, blogów i luźnych informacji, których źródeł (osób) nie kojarzysz - dużo się naczytasz, niewiele dowiesz.
2. Kiedy już określisz listę wiarygodnych źródeł - określ minimum, które jest Ci potrzebne.
3. Jeśli zaczynasz czytać tekst (i dotyczy on Twojego minimum), czytaj go bardzo dokładnie, nie idź do przodu, jeśli nie rozumiesz, tego co przeczytałeś.
4. Wielokrotnie się przekonałem, że lepiej dowiedzieć się mniej, ale mieć wiedzę jak brzytwa, niż przeczytać "o wszystkim" po łebkach.
5. Rób notatki! To jedna z najważniejszych składowych! Wiele osób czyta dużo, ale nie robi notatek. Notatki zmuszają Cię do dokładniejszego zrozumienia tego co czytasz. Żeby zrobić notatkę (zazwyczaj) musisz coś zrozumieć. Niech notatka będzie parafrazą (czyli Twoim własnym sformułowaniem), nie cytatem.

*Spike - ograniczony czasowo, krótki okres na zbadanie tematu (maks. 2 dni), który jest Ci obcy lub mało znany.

Trzeba zrobić miejsce...

Z tomiku ... Poezja dla zaangażowanych w projekty

Trzeba zrobić miejsce

Nigdy nie ma dobrego czasu na pierwsze dziecko,
Nigdy nie ma dobrego czasu na drugie dziecko,
Nigdy nie ma dobrego czasu na budowanie domu,
Nigdy nie ma dobrego czasu na remont,
Nigdy nie ma dobrego czasu na ślub,
Nigdy nie ma dobrego czasu, żeby wprowadzić refaktoryzację,
I nigdy nie ma dobrego czasu, żeby zacząć pisać testy jednostkowe,
W każdym z tych przypadków, trzeba po prostu podjąć decyzję,
Zacząć to robić, a czas i środki się znajdą,
Bo będą musiały...

Klienci chcą być zwinni...

Jedno z ostatnich spotkań, gdzie ustalam (MS) sposób współpracy z klientem (szczegóły celowo nieco zmodyfikowane lub usuniętę, jednak bazujące na rzeczywistym przypadku). Klient (K) mówi:
K: To bardzo poważne przedsięwzięcie i zapowiadają się poważne koszty, prawdę mówiąc nasz sponsor ma spore wątpliwości, co to tej sumy. Nie będzie w stanie jej wydać. Projekt jest dość innowacyjny i nie wiadomo, jak odpowie rynek...
MS: To nawet dobrze się składa, ponieważ możemy zaproponować inny sposób współpracy. Cały system to rzeczywiście spora inwestycja i dość ryzykowna, gdyż produkt zwyczajnie może się nie przyjąć. Przyjrzyjmy się co jest esencją systemu... być może to będzie część, która nam podpowie co dalej zrobić.
(kilkadziesiąt minut wspólnej analizy i dyskusji)
MS: Świetnie! Zatem XYZ to jest to, co przyciągnie klientów, wszystko inne jest wtórne. To nazywamy corem biznesowym tego systemu. Zatem zróbmy tak: zakontraktujmy tę pierwszą część, co do pozostałych części przedstawiliśmy zgrubne szacunki, po tych pracach okaże się, na ile są trafne. Ale co najważniejsze po wdrożeniu core przekonamy się, jak rynek reaguje i czy reaguje, zbierzemy informację zwrotną. Wtedy podejmiemy dalsze decyzje.
K: Ok. To wygląda całkiem obiecująco. Zaryzykujemy tylko 1/4 całej początkowej sumy. Ciekawa sprawa, muszę o tym porozmawiać ze sponsorem.
(... klient zarażony, a konkurencja bez szans, bo ofertująca w tradycyjnym modelu - a tymczasem koncept klienta się zmienił :)

Czas na szkolenie z asertywności!

Tak się składa, że w poprzednim poście pisałem o asertywności w kontekście zarządzania czasem, natomiast analizując różne przypadki, z którymi miałem do czynienia, mogę z dużym przekonaniem stwierdzić, że brak asertywności (wliczam w to odpowiedni sposób komunikacji) jest przyczyną (źródłem) dużej części innych problemów w projekcie.
Weźmy za przykład presję. Zazwyczaj presja idzie z tak zwanej góry. Górą może być klient lub jakiś istotny dyrektor lub prezes (jakby mógł być jakiś nieistotny!). Presja ta jest zazwyczaj przenoszona na kolejne poziomy w dół aż dochodzi do zespołu projektowego (w typowym uogólnionym przypadku: klient/dyrektor=>kierownik projektu=>zespół projektowy).
I teraz uwaga powiem coś co może się niektórym nie spodobać, ale

TA PRESJA JEST POTRZEBNA!

Tak. Nie ma co psioczyć, że ktoś każe zrobić pracę w krótszym terminie. Z ekonomicznego punktu widzenia jest to bardzo rozsądne. Zresztą zgodnie z prawem Parkinsona , którego doświadczyłem wielokrotnie osobiście zarówno jako wykonawca jak i odbiorca czy obserwator, krótkie terminy są wskazane.
Nierozsądne jest poddawanie się tej presji. Jeśli masz przekonanie, że dany termin jest nierealny, powiedz to (asertywnie). Przygotuj się dobrze, przygotuj argumenty (pamiętaj o uwzględnieniu perspektywy swojego rozmówcy, a nie tylko Twojej) i przedyskutuj dlaczego to jest nierealne.
Bardzo często się przekonują, że kierownicy (czy inne osoby decyzyjne) są bardzo skłonni zaakceptować inne szacowanie, jeśli tylko jest ono dobrze uzasadnione. Choć również są i tacy, którzy nie są skłonni (ale nie oszukujmy się - jest ich może z 5%, więc jeśli myślisz, że to na pewno dotyczy Ciebie, to jest duże prawdopodobieństwo, że się mylisz!)

Jeśli więc zastanawiasz się, z czego się przeszkolić, to Twój typ powinien zmierzać w stronę asertywności ;-)