agile
(41)
anti-patterns
(17)
architecture
(33)
books
(10)
buissness analysis
(1)
cases
(1)
code speaks 2u
(3)
communication
(1)
conferences
(13)
consulting
(1)
conversation patterns
(26)
customer collaboration
(14)
ddd
(5)
design patterns
(15)
desing
(1)
dialogi
(1)
dsl
(2)
effectiveness
(19)
embedded
(1)
events
(22)
gtp
(4)
info
(2)
infoq
(5)
kanban
(2)
lean
(2)
master
(1)
measuring
(1)
orm
(2)
pea
(2)
product humanisation
(1)
refactoring
(13)
requirements
(7)
retrospections
(1)
retrospective
(1)
scrum
(9)
scrumguide
(1)
sm
(1)
soft skills
(4)
software craftsmanship
(14)
tdd
(1)
team
(20)
time management
(3)
tutorial
(1)
uml
(1)
user stories
(1)
visions
(28)
Tuesday, April 30, 2013
UniversalProblemSolver
Jeżeli Twój kod przypomina coś takiego w/w, to pamiętaj, że wkrótce skończy Ci się paliwo i możesz już na zawsze pozostać na orbicie okołoprojektowej ;)
Na początek możesz przeczytać artykuł Zawsze pracuj na twardych danych.
Tuesday, April 23, 2013
Wstęp do mierzenia efektywności zespołu
Szerszy artykuł na ten temat możesz przeczytać w bieżącym numerze programista.pl.
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.
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ć.
Tworzenie miar dla osób zwiększa ryzyko rozpoczęcia gry. Tworzenie miar dla zespołu zmniejsza to ryzyko.
A następnie zastanów się, co należy zrobić, aby zminimalizować negatywne skutki wprowadzenia miary.
Ś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:- Co właściwie mierzy miara? Jakie wielkości agreguje?
- Czego otrzymam więcej?
- 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:- Fazy procesu dostarczania
- Typy zadań
- Długość iteracji
- Granulacja zadań
Thursday, April 18, 2013
Scrum jest trudny...
Sam nie wiem od czego zacząć:) Może najpierw przeczytaj artykuł Kiedy Agile nie zadziała
Zawsze gdy chciałbym z pełną odpowiedzialnością powiedzieć Tak, Scrum Wam pomoże. Go! mam pewien dreszcz niepewności. Wynika on stąd, że osoba która jest odpowiedzialna za wdrożenie Scruma chciałaby wiedzieć: po czym konkretnie poznam, że Scrum działa? po czym konkretnie poznam, że jest lepiej niż poprzednio? jak długo potrwa zanim zobaczę konkretne efekty? no i, ile to mnie będzie kosztować?.
Może się zdarzyć, że po wdrożeniu w jednym zespole, w drugim oraz po przeszkoleniu, jak to się ładnie mówi" propagatorów zmiany, nic się nie dzieje. Dlaczego? Mam parę tropów.
Samoorganizujace zespoły się zdarzają. Najczęściej dziwnym zbiegiem okoliczności odpowiedni ludzie spotkają się w odpowiednim miejscu, gdyż tak jak wspomniałem, rzadko kiedy konstruuje się zespół w planowy sposób nie tyle pod kątem kompetencji technicznych, lecz pod kątem kompetencji "zespołowych" właśnie. Konstruowanie zespołu to kosztowna akcja wymagająca zaawansowanej wiedzy HRowej albo superwymiatacza z doświadczeniem, który zrobi to "na wyczucie".
Zawiązywanie się zespołu, przejście procesu grupowego to jakieś trzy miesiące. Scrum nastawia się na hodowanie zespołów i przydzielanie do nich projektów. W ilu organizacjach proces biznesowy jest tak ustawiony, że to jest możliwe? A w ilu zespół jest powoływany per projekt i rozwiązywany zanim jeszcze zdąży okrzepnąć.
Samoorganizaujacy się zespół to naprawdę wspaniała idea. I w dodatku idea, która bardzo dobrze działa. Ale to jest trudne...
Iteracje pozwalają na wybranie najistotniejszych rzeczy "na teraz", dostarczenie ich z możliwością używania. Acha, no właśnie: potentially shippable increment - czy Twoi klienci rzeczywiście używają funkcjonalności w swojej pracy, od razu gdy im dostarczysz? Czy pracują może "na starym" a "testowy" używają do poklikania?
Albo jak często zdarzają się wrzutki w trakcie iteracji i co one powodują? Jak bardzo można skrócić iteracje, aby być bardziej responsywnym? Na ile można je skracać, zanim się okaże, że testy, testy regresji itd. są zbyt kosztowne przy tak krótkich iteracjach?
Praca w zamkniętych iteracjach jest świetna. W dodatku to naprawdę działa w niektórych organizacjach. Ale to jest trudne...
Zmiany organizacyjne są długie, kosztowne i mogą się nie udać. Tak jak napisałem, Scrum jest naprawdę super, ale często okazuje się zbyt trudny do wdrożenia z zachowaniem oczekiwanych rezultatów.
A może Lean?. Nie chcę przypinać się do konkretnej implementacji Lean w wytwarzaniu oprogramowania, więc piszę po prostu Lean.
Punktem skupienia Lean jest optymalizacja procesu dostarczania, nie gotowy proces do wdrożenia, lecz jego optymalizowanie. Wychodzi nam, że dużo łatwiej zespołowi przestawić się na Lean. Ok, zespół jest również ważny, ale skupienie się na procesie dostarczania, pozwala jakoś żyć gdy zespół jednak trudno się samozorganizuje. Zazwyczaj pierwszym kluczowym krokiem jest przekonanie zainteresowanych do zredukowania WIP i coś już zaczyna działać. Gwoli wyjaśnienia: Lean nie jest oczywiście remedium na całe zło, ale po prostu start jest łatwiejszy niż ze Scrumem.
Zawsze gdy chciałbym z pełną odpowiedzialnością powiedzieć Tak, Scrum Wam pomoże. Go! mam pewien dreszcz niepewności. Wynika on stąd, że osoba która jest odpowiedzialna za wdrożenie Scruma chciałaby wiedzieć: po czym konkretnie poznam, że Scrum działa? po czym konkretnie poznam, że jest lepiej niż poprzednio? jak długo potrwa zanim zobaczę konkretne efekty? no i, ile to mnie będzie kosztować?.
Może się zdarzyć, że po wdrożeniu w jednym zespole, w drugim oraz po przeszkoleniu, jak to się ładnie mówi" propagatorów zmiany, nic się nie dzieje. Dlaczego? Mam parę tropów.
Samoorganizujący się zespół
Samorganizujacy się zespół jest możliwy. Nawet dwa czy trzy takie zespoły w życiu widziałem, a w jednym miałem przyjemność pracować. Ale to jest naprawdę duże wyzwanie stworzyć samoorganizujacy się zespół. Aby zespół się samoorganizował najpierw trzeba go świadomie zaprojektować, wyhodować. Mimo dużej wiary w ludzi trzeba uznać, że nie wszyscy ludzie w zespole mają jednakowe kompetencje. Nie każdy zespół, nie każdy jego członek podejmie odpowiedzialność.Samoorganizujace zespoły się zdarzają. Najczęściej dziwnym zbiegiem okoliczności odpowiedni ludzie spotkają się w odpowiednim miejscu, gdyż tak jak wspomniałem, rzadko kiedy konstruuje się zespół w planowy sposób nie tyle pod kątem kompetencji technicznych, lecz pod kątem kompetencji "zespołowych" właśnie. Konstruowanie zespołu to kosztowna akcja wymagająca zaawansowanej wiedzy HRowej albo superwymiatacza z doświadczeniem, który zrobi to "na wyczucie".
Zawiązywanie się zespołu, przejście procesu grupowego to jakieś trzy miesiące. Scrum nastawia się na hodowanie zespołów i przydzielanie do nich projektów. W ilu organizacjach proces biznesowy jest tak ustawiony, że to jest możliwe? A w ilu zespół jest powoływany per projekt i rozwiązywany zanim jeszcze zdąży okrzepnąć.
Samoorganizaujacy się zespół to naprawdę wspaniała idea. I w dodatku idea, która bardzo dobrze działa. Ale to jest trudne...
Iteracje
Gdy zapytałem jednego kolegę w trakcie szkolenia, czy nie może odmawiać wykonywania zadań spoza iteracji (wszak Odwaga to jedna z wartości Agile), odpowiedział następująco: "Kiedyś próbowałem, ale mój manager powiedział ::Ok, pośmialiśmy się, a teraz do roboty::".Iteracje pozwalają na wybranie najistotniejszych rzeczy "na teraz", dostarczenie ich z możliwością używania. Acha, no właśnie: potentially shippable increment - czy Twoi klienci rzeczywiście używają funkcjonalności w swojej pracy, od razu gdy im dostarczysz? Czy pracują może "na starym" a "testowy" używają do poklikania?
Albo jak często zdarzają się wrzutki w trakcie iteracji i co one powodują? Jak bardzo można skrócić iteracje, aby być bardziej responsywnym? Na ile można je skracać, zanim się okaże, że testy, testy regresji itd. są zbyt kosztowne przy tak krótkich iteracjach?
Praca w zamkniętych iteracjach jest świetna. W dodatku to naprawdę działa w niektórych organizacjach. Ale to jest trudne...
Dlaczego trudny?
Dlatego, że wymaga dość dużych zmian organizacyjnych, nie mówiąc już zmianie w sposobie myślenia. Scrum daje gotowy framework, który należy zaaplikować. A co ze skalowaniem? Tak, wiem, że wymyślono dobrze brzmiące nazwy. Ale skalowanie Scruma jest wciąż w powijakach. Czasem w ogóle się nie udaje i Scrum jest tylko z nazwy, czasem udaje się wystarczająco dobrze z pewną pomocą Prince2 albo PMI, a czasem udaje się znakomicie. Tak, są organizacje, którym udało się przeskalować Scruma. Ale to jest trudne...Zmiany organizacyjne są długie, kosztowne i mogą się nie udać. Tak jak napisałem, Scrum jest naprawdę super, ale często okazuje się zbyt trudny do wdrożenia z zachowaniem oczekiwanych rezultatów.
A może Lean?. Nie chcę przypinać się do konkretnej implementacji Lean w wytwarzaniu oprogramowania, więc piszę po prostu Lean.
Punktem skupienia Lean jest optymalizacja procesu dostarczania, nie gotowy proces do wdrożenia, lecz jego optymalizowanie. Wychodzi nam, że dużo łatwiej zespołowi przestawić się na Lean. Ok, zespół jest również ważny, ale skupienie się na procesie dostarczania, pozwala jakoś żyć gdy zespół jednak trudno się samozorganizuje. Zazwyczaj pierwszym kluczowym krokiem jest przekonanie zainteresowanych do zredukowania WIP i coś już zaczyna działać. Gwoli wyjaśnienia: Lean nie jest oczywiście remedium na całe zło, ale po prostu start jest łatwiejszy niż ze Scrumem.
Stakeholder Stories
User stories eksponują tę pracę do wykonania, która ma dawać business value dla sponsora. Zauważyłem że, zespołom, które posługują się US brakuje czasem szerszego kontekstu dookoła historyjek. Mam tu na myśli rzeczy takie jak:
Dla w/w rzeczy jakby nie było miejsca w backlogu, więc plątają się to tu to tam i każdy ma własny pomysł na ich przechowywanie. Brak jednolitego sposobu na przechowywanie wszystkich wymagań utrudnia ich komunikowanie, a zespołowi utrudnia złapanie szerszego kontekstu tego, co ma do zrobienia.
Format historyjki świetnie nadaje się do spisanie wszystkich punktów widzenia na tworzony produkt. Poniżej przykłady:
Jasne, że nie wszystkie wymienione historyjki idą na tablicę. Przynajmniej nie w pierwotnej postaci. Przede wszystkim:
Po za w/w wspomaganie się hisotryjową strukturą (Jako X, chcę Y, aby Z, bardzo pomaga w zbieraniu wymagań. Zazwyczaj jeśli, ktoś nie potrafi sformułować Z, czyli konkretnego powodu powiązanego z projektem, to sam z wymagania rezygnuje, bez większej przykrości.
- wymagania niefunkcjonalne - są dopisywane gdzieś na boku US, spisywane w SRSach albo są w głowach
- to, że nie wszystkie "wymagania" przekładają się na konkretne funkcjonalności
- epiki mogą dotyczyć rzeczy przekrojowych przez funkcjonalności (btw: dobra definicja epika "Since an epic becomes an epic if the team can’t commit to it")
- to, że wymagania mogą pochodzić z różnych źródeł i świadomość istnienia wszystkich interesariuszy wnosi lepsze zrozumienie pracy
Dla w/w rzeczy jakby nie było miejsca w backlogu, więc plątają się to tu to tam i każdy ma własny pomysł na ich przechowywanie. Brak jednolitego sposobu na przechowywanie wszystkich wymagań utrudnia ich komunikowanie, a zespołowi utrudnia złapanie szerszego kontekstu tego, co ma do zrobienia.
Format historyjki świetnie nadaje się do spisanie wszystkich punktów widzenia na tworzony produkt. Poniżej przykłady:
- Jako Klient chcę zamówić szkolenie, aby wziąć w nim udział
- Jako Zarząd chcemy dowiadywać się, jaki jest aktualny obrót, aby mieć informacje o aktualnych przychodach z portalu
- Jako Architekt chcę, aby system S czerpał informacje o klientach z naszego systemu V nadzorującego procesy biznesowe
- Jako Zespół chcemy pozbyć się ORMa, bo do tego typu projektu kompletnie się nie nadaje i spowalnia naszą pracę
- Jako Grafik, chcę aby używano Velocity zamiast JSP, abym mógł szybciej przygotowywać widoki
Jasne, że nie wszystkie wymienione historyjki idą na tablicę. Przynajmniej nie w pierwotnej postaci. Przede wszystkim:
- Zespołowi dają szerszy ogląd projektu
- Nie uciekają historyjki techniczne; niby powinny być podczepione pod US, ale zauważyłem, że jak coś nie jest wprost nazwane, to lubi się zagubić w mrokach niepamięci
Po za w/w wspomaganie się hisotryjową strukturą (Jako X, chcę Y, aby Z, bardzo pomaga w zbieraniu wymagań. Zazwyczaj jeśli, ktoś nie potrafi sformułować Z, czyli konkretnego powodu powiązanego z projektem, to sam z wymagania rezygnuje, bez większej przykrości.
Tuesday, April 16, 2013
Koder kodzi, architekt architekci
Na 4Developers odbył się Panel dyskusyjny nt. architektury, architektów i architekcenia:). Trudno powiedzieć, żebyśmy udzielili odpowiedzi na jakieś konkretne pytania, ale było miło. Chociaż padało pytanie o rolę/stanowisko architekta i jego miejsce w procesie, to wydaje mi się, że byłem odosobniony w zdaniu, że bez tradycyjnego architekta można się obejść. Podłapałem tę myśl od Scotta Amblera i po moich doświadczeniach z różnymi zespołami jestem przekonany, że to ma sens.
Ankietowałem kiedyś obsesyjnie, architektów (różne stanowiska różnie się się w firmach nazywają i mimo istniejących jakichś tam typologii, każdy nazywa je sobie po swojemu), aby namierzyć, co konkretnie robi osoba określana jako "architekt". Zbiorcze zestawienie przedstawiam poniżej.
Jeśli popatrzeć na wymienione obowiązki, to trudno oprzeć się wrażeniu, że z niemal wszystkimi z nich może sobie poradzić zespół jako taki i nie potrzeba do tego wydzielonego architekta. Jedyna różnica między w/w architektem a "zwykłym" programistą jest taka, że ma on architekt większe doświadczenie (ale nie to mierzone w latach) i większą wiedzę o systemie.
Wydaje się, że potrzeba powołania osoby w randze architekta wynika z potrzeby rozwiązania następujących problemów:
Można odnosić wrażenie, że tego typu architekt został wymyślony po to, aby wyousourcować w/w problemy. Sęk w tym, że staje się on wąskim gardłem procesu. Po prostu nie nadąża z pracą. Wtedy trzeba powołać kolejnego i kolejnego i kolejnego. Po pewnym czasie okazuje się, że architekci zajmują się głównie sprawami organizacyjno-konfiguracyjno-spotkaniowymi, a programiści przestają czuć się odpowiedzialni za architekturę, gdyż ta "należy" do architektów. I wtedy koder zaczyna kodzić, architekt zaczyna architekcić, a architektura zaczyna dryfować.
Ankietowałem kiedyś obsesyjnie, architektów (różne stanowiska różnie się się w firmach nazywają i mimo istniejących jakichś tam typologii, każdy nazywa je sobie po swojemu), aby namierzyć, co konkretnie robi osoba określana jako "architekt". Zbiorcze zestawienie przedstawiam poniżej.
Jaki jest Twój zakres obowiązków jako Architekta? |
|
Z jakimi pytaniami należy zwracać się do Architekta? |
|
Z jakimi pytaniami NIE należy zwracać się do architekta? |
|
Jeśli popatrzeć na wymienione obowiązki, to trudno oprzeć się wrażeniu, że z niemal wszystkimi z nich może sobie poradzić zespół jako taki i nie potrzeba do tego wydzielonego architekta. Jedyna różnica między w/w architektem a "zwykłym" programistą jest taka, że ma on architekt większe doświadczenie (ale nie to mierzone w latach) i większą wiedzę o systemie.
Wydaje się, że potrzeba powołania osoby w randze architekta wynika z potrzeby rozwiązania następujących problemów:
- niedostateczne komunikowanie architektury w zespole i pomiędzy zespołami
- brak nazwanego procesu rozwoju architektury działającego obok procesu dostarczania; o tym procesie pisaliśmy/mówiliśmy w Ewolucyjna architektura: Jak zorganizować proces rozwoju architektury? , Ewolucyjna architektura, Ewolucyjna architektura
- Brak użytecznej (nie wciąganej z kodu przez EA) dokumentacji architektury; o tym pisaliśmy nieco w Dokumentowanie architektury, Dokumentowanie architektury cz.2
Można odnosić wrażenie, że tego typu architekt został wymyślony po to, aby wyousourcować w/w problemy. Sęk w tym, że staje się on wąskim gardłem procesu. Po prostu nie nadąża z pracą. Wtedy trzeba powołać kolejnego i kolejnego i kolejnego. Po pewnym czasie okazuje się, że architekci zajmują się głównie sprawami organizacyjno-konfiguracyjno-spotkaniowymi, a programiści przestają czuć się odpowiedzialni za architekturę, gdyż ta "należy" do architektów. I wtedy koder zaczyna kodzić, architekt zaczyna architekcić, a architektura zaczyna dryfować.
Monday, April 8, 2013
Dogmat architektoniczny, czyli nie wkurzaj programistów
W pewnej organizacji, człowiek o na stanowisku Architekt Korporacyjny zrobił zebranie, na którym objaśnił nową wizję architektury, nazywając ją dogmatem architektonicznym.
Programiści odwdzięczyli mu się zamieszczonym zdjęciem oraz drobiazgową analizą pojęcia dogmat architektoniczny, którą za pozwoleniem cytuję w całości.
Dogmat (z greckiego dogma - mniemanie, osąd, postanowienie, nauka),
- W starożytności postanowienie prawne zgromadzenia ludu lub senatu, także twierdzenie filozoficzne uznawane przez przedstawicieli danej szkoły za nie podlegające dyskusji.
- W teologii katolickiej zdanie, które Kościół na mocy decyzji swego Urzędu Nauczycielskiego lub papieskiej albo soborowej definicji uznaje jednoznacznie za objawione przez Boga, dając równocześnie do zrozumienia, że zaprzeczenie mu oznacza popadnięcie w herezję. Dogmat nie podlega odwołaniu, choć w związku z tym, że ponadczasowe objawienie łączy z elementami uwarunkowanymi historycznie, może zostać poddany tzw. aktualizującej interpretacji lub "zapomniany" (przestaje być przywoływany).
- W teologii prawosławnej dogmat rozumie się podobnie jak w katolicyzmie, jednak prawo jego stanowienia przysługuje wyłącznie soborom. Ponadto Kościół prawosławny nie ogłasza dogmatów, które nie są bezpośrednią interpretacją faktów przedstawionych w Biblii (dlatego np. odrzuca katolicki dogmaty o niepokalanym poczęciu NMP).
- W religioznawstwie określenie końcowego etapu ewolucji doktryny religijnej - ta jej wersja, która uznana została przez hierarchię danej religii za oficjalną i ostateczną.
- Potocznie osąd lub pogląd akceptowany bezkrytycznie, wyłącznie z racji zawierzenie autorytetowi.
Architektura - etymologia terminu
Słowo „architektura” pochodzi od łacińskiego „ architectura” oraz od greckiego „αρχιτεκτονική” (architectu) i oznacza budowniczy, z kombinacji „αρχι-” (archi-), szef i τέκτων (tekton) budowniczy, stolarz. Podczas gdy główne znaczenie słowa „architektura” dotyczy środowiska budowy, przez rozszerzenie terminu oznacza sztukę i dyscyplinę tworzenia aktualnego planu każdego kompleksu lub systemu.
Dzieło architektury
Obiekt, dzieło architektury, powinien odpowiadać zamierzonej funkcji, celowości technicznej, wymaganiom ekonomicznym i estetycznym, a przede wszystkim, dążeniom i oczekiwaniom użytkowników jego przestrzeni lub przeznaczenia.
Realizacja zadań lub obiektów architektonicznych wymaga korzystania z osiągnięć innych dyscyplin, m.in. sztuki, filozofii, inżynierii, techniki, budownictwa, statyki, socjologii, psychologii, urbanistyki, nauk ekonomicznych. W ciągu wieków zmieniały się zarówno zakres obowiązków i koniecznej wiedzy architekta, jak i samo pojmowanie architektury.
Różne definicje architektury
- Potoczne rozumienie związane jest z pochodzeniem słowa architektura: architectura (łac.), zapożyczonego przez Rzymian z greckiego architekton – budowniczy.
- Według Witruwiusza (O architekturze ksiąg dziesięć) architektura polega na zachowaniu trzech zasad: trwałości (Firmitas), użyteczności (Utilitas) i piękna (Venustas)
- Według Egona Eiermanna (Grosse Architekten): Architektura nie ma nic wspólnego ze sztuką, stanowi czysty proces rozumowania. Architektura powstaje dziś wedle uwarunkowań ekonomicznych, konstrukcyjnych i funkcjonalnych
- Niektórzy ze współczesnych neomodernistów (jak np. Vacchini, Snozzi, Galfetti) definiują architekturę, jako rzecz bezużyteczną, która pojawia się dopiero wtedy, gdy potrafimy przekroczyć granice banalnej użyteczności
A zatem: Dogmat architektoniczny
Potocznie pogląd lub osąd akceptowany bezkrytycznie, wyłącznie z racji zawierzenia autorytetowi, definiujący architekturę jako rzecz bezużyteczną, która pojawia się dopiero wtedy, gdy potrafimy przekroczyć granice banalnej użyteczności.
Friday, April 5, 2013
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)
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.
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ć.
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:
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
Thursday, April 4, 2013
Wiedza odpływa z organizacji
Nie wiem, czy kryzys rzeczywiście był, czy go nie było, ale widzę skutki plotek o kryzysie. Departamenty IT dostały bana na zwiększanie kosztów stałych, czyli na zatrudnianie programistów. Backlog rzadko kiedy się skurczył, więc aby sprostać wymaganiom biznesu zastosowano najbardziej narzucające się rozwiązanie outsourcing.
Outsourcing jest ok, bo nie zwiększa kosztów stałych organizacji, lecz powiększa koszty projektów i jako taki jest widoczny w innej kolumnie arkusza kalkulacyjnego. W skutek tego "finansowego" zabiegu niby mamy programistów, ale ich nie mamy. Proste? :) No, na tym poziomie abstrakcji, to wszystko wydaje się proste i korzystne. Przyjrzyjmy się implementation details.
Skąd organizacja outsourcuje programistów? Ano od ousourcera, tylko że nie nazywają się już oni programistami lecz konsultantami i kosztują odpowiednio więcej. Excelowa kolumna kosztów projektu jest bardziej elastyczna niż kolumna kosztów stałych, więc w czym problem? W tym, że taki outsourcing ma swoje zasady:
W skutek w/w praktyk etatowi programiści przestają programować, a zaczynają "zarządzać". Właściwie to ich główne zadania polegają na:
Gdy przez dwa i więcej miesięcy nie rozwijasz kodu systemu, nad którym pracujesz, to zagadnienia, które wcześniej były oczywiste powoli zasnuwa mgła niepamięci. Dzień po dniu niepostrzeżenie zaczynasz wkraczać na orbitę około systemową z perspektywy której hurtownia danych i hurtowania makaronów to prawie jedno i to samo. Wszak i to i to jest hurtownią.
Utrzymujący się taki stan rzeczy ma następujące skutki:
Ostatecznie idealnym rozwiązaniem jest wyodrębnienie core domain i w jej rozwój zaangażowanie etatowców, a supporting domains oddanie do konsultantów bądź podwykonawców. W tym przypadku, prócz samej analizy może pojawić pewien NP-trudny problem: core domain nie ma albo nie istnieje ona w takiej postaci, aby wymagała by prac programistycznych. Słowem nie ma sensu utrzymywać zespołu programistycznego. Ups! Przymierzam się do wpisu nt. analizy domen, chwilowo godzina jest zbyt późna:)
Outsourcing jest ok, bo nie zwiększa kosztów stałych organizacji, lecz powiększa koszty projektów i jako taki jest widoczny w innej kolumnie arkusza kalkulacyjnego. W skutek tego "finansowego" zabiegu niby mamy programistów, ale ich nie mamy. Proste? :) No, na tym poziomie abstrakcji, to wszystko wydaje się proste i korzystne. Przyjrzyjmy się implementation details.
Skąd organizacja outsourcuje programistów? Ano od ousourcera, tylko że nie nazywają się już oni programistami lecz konsultantami i kosztują odpowiednio więcej. Excelowa kolumna kosztów projektu jest bardziej elastyczna niż kolumna kosztów stałych, więc w czym problem? W tym, że taki outsourcing ma swoje zasady:
- Konsultanci wykonują większość prac programistycznych
- Etatowi programiści nadzorują pracę konsultantów
- Jeśli dla konsultanta przez pewien czas (np. tydzień) nie można znaleźć zajęcia to trzeba go zwrócić do puli
- Konsultanci działają na zasadzie stateless, więc jeśli znów potrzebujemy konsultanta, to dostajemy nie poprzednio zwróconego, lecz pierwszego wolnego
W skutek w/w praktyk etatowi programiści przestają programować, a zaczynają "zarządzać". Właściwie to ich główne zadania polegają na:
- przyuczaniu konsultantów i nadzorowaniu ich pracy
- routowaniu maili między biznesem a konsultantami i ew. zewnętrznymi podwykonawcami
- przygotowywaniu dokumentacji wynikającej z procedur organizacyjnych, których początki są tak stare, że chyba już skamieniały
- analizowaniu logów systemowych, gdy coś się wywali
Gdy przez dwa i więcej miesięcy nie rozwijasz kodu systemu, nad którym pracujesz, to zagadnienia, które wcześniej były oczywiste powoli zasnuwa mgła niepamięci. Dzień po dniu niepostrzeżenie zaczynasz wkraczać na orbitę około systemową z perspektywy której hurtownia danych i hurtowania makaronów to prawie jedno i to samo. Wszak i to i to jest hurtownią.
Utrzymujący się taki stan rzeczy ma następujące skutki:
- Konkretna wiedza systemie, jego architekturze, problemach w kodzie migruje od programistów etatowych do konsultantów
- Rotacja konsultantów sprawia, że wiedza techniczna w ogóle odpływa z organizacji
- Nikt nie jest odpowiedzialny za rozwój architektury, która zaczyna dryfować
- Dla podkreślenia: nie, etatowi programiści nie zajmują się architekturą (choćby nawet takie były początkowe ustalenia) bo niby co to oznacza? rysowanie umli? etatowi programiści zajmują się organizowaniem zajęcia dla konsultantów
- Jakość kodu zaczyna się dramatycznie obniżać
- Dryfowanie architektury sprawia, że z każdą funkcjonalnością coraz trudniej dodawać nowe i modyfikować istniejące
- W pewnym momencie pojawia się osobliwość, czyli taki moment, w których za pomocą metod inżynierskich, architektury nie da się już naprawić; o czym pisałem trochę tutaj
Nie oddawaj core własnego biznesu
Z perspektywy organizacji, która nie jest softwarehousem takie postępowanie ma sens. Tworzenie oprogramowania nie jest core biznesu, więc spokojnie można je oddać komuś do podwykonania. Mam jednak wrażanie, że próbuje się z jednej strony mieć marchewkę i zjeść marchewkę. Z jednej strony chcemy sami tworzyć soft, aby móc go dostosowywać i być elastycznym (kolejne po "architektura") słowo-wytrych. Z drugiej strony chcemy outsourcować, aby zapłacić za to jak najmniej. Ostatecznie wydatkujemy więcej za kiepski produkt.Przeciwdziałanie
Można przeciwdziałać odpływowi wiedzy z organizacji przestrzegając pewnych zasad. Oczywiście nie jest to tak banalne jak poniższe sformułowania. Najtrudniejsze jest przecież wdrożenie i konsekwentne trzymanie się n/w wytycznych. O następujących rzeczach warto jednak pamiętać:- zatrudniaj konsultantów na długo i nie zwracaj ich do puli, gdy przez kilka dni nie mają nic do roboty
- dbaj, aby konsultantów było nie więcej niż etatowych programistów
- etatowi programiści pełnią tymczasowe role teamliderów w miniprojektach powoływanych na wdrożenie konkretnych funkcjonalności
- teamliderzy implementują jakąś część ticketów (tak, wiem, że kiedyś twierdziłem inaczej, ale złagodziłem nieco to zdanie
- dbaj, aby działał nazwany proces rozwoju architektury, czyli podczas dostarczania, można realizować itemy techniczne
Ostatecznie idealnym rozwiązaniem jest wyodrębnienie core domain i w jej rozwój zaangażowanie etatowców, a supporting domains oddanie do konsultantów bądź podwykonawców. W tym przypadku, prócz samej analizy może pojawić pewien NP-trudny problem: core domain nie ma albo nie istnieje ona w takiej postaci, aby wymagała by prac programistycznych. Słowem nie ma sensu utrzymywać zespołu programistycznego. Ups! Przymierzam się do wpisu nt. analizy domen, chwilowo godzina jest zbyt późna:)
Subscribe to:
Posts (Atom)