czwartek, 19 lutego 2009

Przyczyna źródłowa

Pisząc o koncepcji Jidoka napisałem tak “[pracownik ma obowiązek] znaleźć przyczynę takowego niepożądanego stanu rzeczy, wyeliminować ją i dopiero potem [podjąć z powrotem pracę]”. Po zastanowieniu dochodzę do wniosku, że to jest świetny materiał na rozważania o tym, co powinno być elementem sesji retrospekcji i co leży w obowiązku kierownika projektu, zwłaszcza realizowanego metodami agile. Chodzi o to znajdowanie i eliminowanie przyczyn źródłowych problemów.

Jak się popatrzy na obecne środowisko pracy w wielu organizacjach to jedyną reakcją na problemy stosowaną przez wyższe kierownictwo jest coraz większy nacisk na to, aby problemów nie było. Jeżeli projekt przekracza deadline’y to kierownictwo wyznacza większe bonusy za dotrzymanie deadline’ów. Jeżeli jest za dużo błędów to grozi się obcięciem pensji za ponowne wypuszczenie błędnej wersji oprogramowania. Problem w tym, że takie podejście tak naprawdę konserwuje to, co jest. Bo zakłada, że wszystko robiliśmy dobrze, tylko się nie staraliśmy wystarczająco dobrze. Więc jeżeli następnym razem się postaramy bardziej to będzie dużo lepiej. Hmm, bardzo odważne założenie. W rzeczywistości będzie zapewne tak, że jak teraz przy tych metodach które mamy trochę nam nie wyszło to jak je zastosujemy jeszcze bardziej dokładnie to jeszcze bardziej nam nie wyjdzie.

Tak naprawdę rzadko kto podejmuje się zadania proponowanego przez Japończyków (choć nie tylko ich) czyli znalezienia przyczyny źródłowej takiego a nie innego stanu rzeczy. Wysiłek ten podejmowany jest rzadko, bo nie jest to zadanie proste. Przyczyna źródłowa oznacza zadawanie pytania “dlaczego” tak długo aż dojdziemy do odpowiedzi, której już dalej nie da się podzielić. Co więcej bardzo często znajdowanie przyczyny źródłowej polega na odkrywaniu i kwestionowaniu podstawowych założeń, na których oparta jest nasza organizacja i jej sposób działania.

Jeżeli popatrzyć na metodyki agile to najodpowiedniejszym miejscem do znajdowania przyczyn źródłowych problemów wydaje się być retrospekcja. Wówczas poza zastanowieniem się co się stało warto by też zastanowić się nad przyczynami źródłowymi problemów. Ponieważ nie jest to łatwe ani proste nie można się zastanawiać nad wieloma przyczynami źródłowymi jednocześnie. Raczej spośród wielu problemów nękających projekt należałoby wybrać jeden, który najbardziej boli i skupić się na jego rozwiązaniu. Czyli najpierw znaleźć jego przyczynę źródłową a dopiero potem wdrożyć rozwiązanie.

Aha i tutaj jedna uwaga. Przyczyny źródłowe problemów w projektach mają to do siebie, że często są tzw. przyczynami systemowymi. Czyli wynikają wprost z tego jak skonstruowany jest system, w tym wypadku system zarządzania w danej organizacji. Jeżeli przyczyna jest przyczyną systemową to aby permanentnie ją wyeliminować należy zmienić system. A to niestety często jest poza zasięgiem kompetencyjnym osób pracujących w projektach. Jedyne logiczne rozwiązanie w takiej sytuacji to rzeczony przypadek udokumentować oraz przedstawić odpowiednio wysokim menedżerom w firmie. A następnie mieć nadzieję, że zależy im na tym, aby ich system zarządzania działał sprawnie.

Dwa narzędzia, które mogą pomóc w znajdywaniu przyczyn źródłowych to na przykład A3 Problem Solving Method (bazująca na rozwiązaniach Toyoty) oraz Current Reality Tree (bazująca na narzędziach myślowych teorii ograniczeń).

środa, 11 lutego 2009

Jidoka

Czytając wspomnianą tutaj już książkę “Implementing Lean Software Development” jeden element wybitnie wrył mi się w pamięć jako zupełnie dla mnie nowy. W ramach przedstawiania produkcyjnego lean’u i jego zasad autorzy opisali coś, co nazywa się po japonsku jidoka a po angielsku autonomation. Po polsku będzie chyba autonomizacja (?? choć po przemyśleniach nie wydaje mi się). Koncepcja jest tak prosta i tak oczywista, że wręcz dziwię się, że nigdy nie słyszałem o jej zastosowaniu do rozwoju oprogramowania.

W przypadku produkcji jidoka polega na tym, że każde odchylenie od pożądanego standardu jest natychmiast wychwytywane na bardzo niskim poziomie zarządczym a następnie usuwa się, uwaga, przyczynę powstania problemu a dopiero później powraca się do pracy. W praktyce oznacza to, że każdy z robotników pracujących przy taśmie jeżeli zauważy jakiekolwiek odchylenie od pożądanego stanu ma prawo i obowiązek natychmiast zatrzymać całą linię produkcyjną. Następnie znaleźć przyczynę takowego niepożądanego stanu rzeczy, wyeliminować ją i dopiero potem następuje ponowny rozruch linii. Ciekawe jest to, że te działania są podejmowane przez pracowników liniowych, bądź ich bezpośrednich przełożonych bez zwracania się o radę i decyzję do wyższego kierownictwa. Stąd termin autonomizacja - elementy organizacji uzyskują autonomię pozwalającą im podejmować działania podwyższające jakość bez konieczności czekania na decyzję wyższego kierownictwa.

Genialne. Głównie dlatego, że w ten sposób unika się powstawania wąskich gardeł decyzyjnych wyżej w strukturze firmy. Managerowie nie są zasypywani dużą ilością błahych i oczywistych spraw do rozwiązania, tylko mają czas myśleć nad rzeczami strategicznymi. A o jakość dbają ci, którzy są najbliżej czyli pracownicy.

Jak to się ma do rozwoju oprogramowania? Ano tak, że zgodnie z tą koncepcją każdy członek zespołu pracującego nad nowym oprogramowaniem miałby możliwość zatrzymania produkcji jeżeli tylko zobaczyłby, że nie spełnia ona jakościowych wymagań. Następnie miałby obowiązek znaleźć przyczynę wystąpienia tego odstępstwa oraz ją usunąć. Czyli na przykład jeżeli kodując funkcjonalność X przykładowy programista zorientuje się, że funkcjonalność Y nie działa zgodnie ze specyfikacją to ma obowiązek zatrzymać prace i zbadać dlaczego tak się stało. Może brakuje jakiegoś unit testu? To trzeba go dopisać, poprawić funkcjonalność Y i dopiero potem wrócić do pracy nad X. Oprócz unikania wąskich gardeł decyzyjnych ma to też taką oczywistą zaletę, że nie pozwala na zaniedbanie starszego kodu. Ma też tą wadę, że zakłada iż wymagania jakościowe są na tyle dobrze zdefiniowane, że każdy będzie w stanie wychwycić odchyłkę od normy. A to niestety często nie jest prawda. Niestety. Podkreślić tu bowiem należy, że niezależnie od przyjętej metody zarządzania projektem informatycznym te wymagania, które już weszły do produkcji muszą być na tyle dobrze zdefiniowane aby można było sprawdzić ich jakość. No ale to już temat na osobny post, który zresztą już chyba kiedyś się tutaj pojawił.

A jidoke zastosuję przy najbliższej nadarzającej się okazji :-)

czwartek, 5 lutego 2009

Dług technologiczny

Koncepcja długu technologicznego jest stara jak agile a ostatnio natknąłem się na nią przy okazji robienia czegoś zupełnie innego. Co to jest dług technologiczny? Oto jak kiedyś mi to wytłumaczono: cokolwiek co czyni Twój produkt trudnym do zmiany w przyszłości jest długiem technologicznym - możesz albo zapłacić pełną cenę technologiczną teraz (zrobić od razu rozwiązanie elastyczne) albo zaciągnąć dług i spłacić go później (zrobić rozwiązanie szybkie ale nieelastyczne a przy pierwszej konieczności zmiany mieć trudność z brakiem elastyczności). Dług ma to do siebie, że generuje odsetki. To znaczy, że jeżeli dzisiaj nie poświęcimy dwóch dni na uczynienie naszego produktu elastycznym, to w przyszłości jeżeli będziemy chcieli przeprowadzić zmiany nie będzie kosztowało to dwa dni, tylko dwa dni plus odsetki. Odsetki te niestety przyrastają zdecydowanie szybciej niż w popularnych bankach. Efektem skrajnym jest kiedy produkt staje się tak niepodatny na zmiany, że prościej jest takowy produkt zrobić od nowa niż zmienić stary (sam byłem w takiej sytuacji).

W szczególności dług technologiczny dotyczy kodu oprogramowania. Tam jest bardzo łatwo zrobić rozwiązanie, które jest mało elastyczne ale bardzo szybkie we wdrożeniu (np. użycie nieudokumentowanych funkcji - kto z nas tego nie robił ;-)). Zdecydowanie trudniej jest napisać kod, który jest elastyczny. Co więcej często wprowadzenie zmiany sprawia, że kod staje się mniej elastyczny. Wówczas, aby nie zaciągać długu należy przeprowadzić refaktoryzację i zmienić kod tak, aby elastycznym był. Pominięcie refaktoryzacji spowoduje pogłębianie się długu, produkt będzie coraz trudniejszy do zmian. Prędzej czy później trzeba będzie za to zapłacić. Z tego punktu widzenia czas poświęcony na refaktoryzację to nie jest koszt. Jest to raczej inwestycja. Dzisiaj inwestujemy dwa dni pracy po to, aby w przyszłości nie musieć inwestować 5 dni w przeprowadzenie prostej zmiany.

Agile w sposób naturalny wspiera eliminację długu technologicznego. Poprzez iteracyjność oraz fakt, że nikt w zasadzie nie wie nad jakim kawałkiem produktu będzie pracował w przyszłej iteracji wspiera się aktywnie tworzenie rozwiązania bardzo elastycznego. W zespołach bardzo często tworzenie rozwiązań elastycznych jest przyjmowane jako jedna z głównych zasad pracy. Niestety nawet w przypadku takim jak ten, kiedy metodyka wspiera takie działania można cały ten efekt zepsuć. Najprościej dzięki mało kompetentnym kierownikom projektów, którzy nie pozwalają własnym zespołom na pracę dobrą a wymagają tylko pracy szybkiej. Jeżeli jesteście w takiej sytuacji to wytłumaczcie proszę zarządzającym koncepcję długu technologicznego i odsetek od niego. Moje ostatnie doświadczenia wskazują, że takie podejście skutkuje.