blog.testowka.pl

Samoorganizacja i korki uliczne

opublikowany przez 18, Lut, 2013, w kategoriach Agile, Kanban, Scrum

Często przykłady samoorganizacji czerpie się z ruchu ulicznego – to samo zamierzam zrobić i ja. Najlepszym dowodem istnienia samoorganizacji w ruchu drogowym są wszelkiego rodzaju skrzyżowania o ruchu okrężnym – ronda. Mało tego samoorganizacja działa całkiem nieźle także na zwykłych skrzyżowaniach. Dobrym przykładem jest tutaj kilka skrzyżowań w ścisłym centrum Krakowa (między innymi okolice, Galerii Krakowskiej oraz Teatru Bagatela) gdzie awaria sygnalizacji świetlnej jakiś czas temu pokazała, że bez niej przestały się tworzyć w tych miejscach korki uliczne a ruch zaczął odbywać się dużo płynniej niż wcześniej. Miało to pozytywny wpływ nie tylko na najbliższą okolicę tych miejsc ale także bardziej odległe drogi dojazdowe. Na szczęście ewenement ten został zauważony przez odpowiednie osoby i sygnalizacja została tam wyłączona na stałe – na co nikt chyba już nie narzeka.

Jak to się dzieje, że jako kierowcy potrafimy się samemu zorganizować i efektywnie działać na drogach?

Możliwe jest to dzięki wspólnym dla wszystkich, transparentnym, jednoznacznym i przede wszystkim prostym zasadom. Niestety nawet te zasady nie uchronią nas przed korkami ulicznymi.

Co tak właściwie jest przyczyną korków? Na temat tego jak korki powstają przeprowadzono wiele badań i wyciągnięto równie wiele wniosków. Naukowcy są na pewno zgodni co do jednego – na korki wpływ ma ilość samochodów. Każda droga ma swoją przepustowość czyli ilość samochodów, która może się na niej znajdować w danym momencie tak by możliwy był płynny ruch.

W zarządzaniu organizacjami często mówi się o wykorzystywaniu zasobów. Zarządzanie zasobami miało swoje początki w czasach manufaktur i rewolucji przemysłowej kiedy to niezwykle istotnym było wykorzystywanie maszyn w 100% na 3 zmianach, gdyż koszty wszelkiego rodzaju przestojów były bardzo wysokie.

Niestety te metody sprzed kilkudziesięciu o ile nie kilkuset już lat wielu managerów próbuje stosować również dzisiaj do zupełnie innych celów. Często mówi się o ludziach jako o „zasobach” – czego nie znoszę! Pomijając dehumanizację i uprzedmiotowienie człowieka, tego typu język powoduje błędne, stereotypowe myślenie, które prowadzi do niewłaściwego stosowania niewłaściwych narzędzi – na przykład właśnie wspomnianego zarządzania zasobami ludzkimi.

O ile w przypadku maszyn w fabrykach wykorzystanie zasobów w 100% miało sens o tyle na drogach jak i w organizacjach, gdzie liczy się praca umysłowa jaką jest między innymi wytwarzanie oprogramowania tego typu podejście się nie sprawdza. Autostrada wykorzystana w 100% wygląda tak jak na obrazku powyżej.

Według Scrum zespoły powinny być samo-organizujące się – podobnie jak ruch uliczny. W Scrum Guide jest również napisane, że zespoły powinny pracować w stałym, stabilnym i niewyśrubowanym tempie (ang. sustainable pace).

Wracając do skrzyżowań bezkolizyjnych – przeważnie działają całkiem nieźle. Ale zdarzają się sytuacje, gdy działać przestają. Nawet na rondzie może utworzyć się korek. Z czego to wynika?

Przede wszystkim ilość samochodów wjeżdżających na rondo nie może być zbyt duża. Podobnie w zespołach developerskich – jeśli ilość zadań jest zbyt duża to praca będzie przebiegała znacznie wolniej oraz pojawią się problemy.

Równie problematyczny jest brak miejsca za rondem, gdzie samochody mogłyby zjechać. Jeśli praca zespołów developerskich nie jest odbierana regularnie i nie jest dostarczany feedback na temat poprawności ich pracy to wszelkiego rodzaju problemy i wątpliwości będą się gromadzić aż zablokują przepływ zadań w procesie. Jest to niezwykle istotne, gdyż tak jak i z ronda mamy wiele zjazdów i jest wiele dróg którymi możemy dotrzeć do celu tak i w produkcji oprogramowania jest wiele możliwości osiągnięcia tych samych efektów. Gdy widzimy, że za rondem droga jest zablokowana możemy podjąć decyzję o wybraniu innej drogi.

A co jeśli na rondzie będzie miała miejsce jakaś stłuczka (to też się czasem zdarza)? Co jeśli komuś zepsuje się samochód i zablokuje skrzyżowanie? W produkcji oprogramowania dosyć często pojawiają się różne problemy, które również mogą zaburzyć przepływ zadań. Takie problemy powinny być rozwiązywane w pierwszej kolejności by w jak najmniejszym stopniu zaburzać proces. Potrzebna jest tutaj praca całego zespołu by nie skończyło się to tak jak na zdjęciu obok. Jak trudne jest usunięcie zepsutego samochodu z drogi wie każdy właściciel samochodu takiego jak mój :). Na szczęście kilkukrotnie spotkałem się z bardzo uprzejmymi gestami ze strony innych kierowców czy też przechodniów, którzy widząc mój problem od razu oferowali swoją pomoc, a czasem nawet bez słowa pomagali mi zepchnąć moje auto na pobocze. Za co serdecznie dziękuję! Podobnie w zespole Scrum potrzebna jest tego typu bezinteresowna i naturalna pomoc w rozwiązywaniu problemów. Problem jednego członka zespołu zawsze jest problemem całego zespołu a nawet całej organizacji. Dlatego rozwiązywanie bieżących problemów, poprawianie bugów, naprawianie testów automatycznych i leżących buildów oraz problemów z infrastrukturą powinny być priorytetowe.

Na rondach pojawiają się problemy jeszcze z jednego powodu. Podobnie jak na innych skrzyżowaniach tak i na tych z ruchem okrężnymobowiązują pewne zasady (między innymi zakaz wjazdu na skrzyżowanie jeśli nie ma możliwości jego opuszczenia). Wystarczy, że jedna osoba tych zasad nie będzie przestrzegać a problemy bardzo szybko się pojawią i będą narastać. Potrzebne są też pewne ograniczenia – jak na przykład klomb z kwiatami na środku ronda niepozwalający na przejechanie przez nie na wprost. Takie ograniczenia narzuca metodyka – np. Timeboxes w  Scrum i WIP limit w Kanban.

Żadna metodyka, tak samo jak przepisy uliczne nie sprawi, że nie trzeba będzie myśleć. Być może doczekamy czasów w których samochody będą jeździły same a procesy wytwarzania oprogramowania będą całkowicie zautomatyzowane ale do tego czasu myślenie i wysiłek umysłowy zarówno na drogach jak i podczas wytwarzania oprogramowania to podstawa!

Czasem zdarza się też tak, że drogę blokuje stado baranów… Samoorganizacja będzie miała szanse działać tylko jeśli zostanie wytworzona odpowiednia przestrzeń i zespół nie będzie rozpraszany i blokowany przez innych. W Scrum rolę pasterza owiec pełni Scrum Master, który nie pozwala im wchodzić w drogę zespołowi.

Na drodze pojawiają się też różne przeszkody i tutaj też istotna jest rola Scrum Mastera który niczym robotnik drogowy będzie te przeszkody jak najszybciej usuwał.

Są jeszcze dobre praktyki, których stosowanie pozwala nam na przykład na bardziej ekonomiczną i bezpieczną jazdę, dzięki której nasze auto będzie nam służyło dłużej. Tutaj przydaje się Scrum Master w roli coacha zachęcającego do poprawiania swojego stylu jazdy – wytwarzania oprogramowania. Cel jest jasny – chcemy wykorzystywać drogę lepiej i móc jeździć po niej szybciej.


4 Comments for this entry

  • Konlin

    Wg mnie analogia ronda do samoorganizującego się zespołu jest zupełnie chybiona. Na rondzie, tak samo jak np. na skrzyżowaniu równorzędnym, ruch nie jest samoorganizowany przez kierowców tylko przez jednoznaczne zasady. W przypadku ronda – ten znajdujący się na rondzie ma pierwszeństwo. Na skrzyżowaniu – puszczamy tego z prawej. To że nie ma świateł nie znaczy że kierowcy ad hoc tworzą organizację ruchu która jest lepsza niż opisana w KRD.
    Jeszcze gorzej (z punktu widzenia analogii) sytuacja wygląda ze skrzyżowaniami bezkolizyjnymi. Tam z założenia nie ma czego organizować bo ich konstrukcja jest taka, że pasy ruchu są od siebie w pełni niezależne. Jak mają się samoorganizować kierowcy jak przed skrzyżowaniem po prostu wjeżdżają na wiadukt i ich droga nie przecina się z żadną inną?

    Tyle krytyki, generalnie wpis fajny i obrazowy 🙂

  • streser

    Ależ oczywiście tak jak napisałem – samoorganizacja na rondzie zachodzi właśnie dlatego, że są pewne proste reguły, które na nią pozwalają – KRD. W Scrum też są pewne proste reguły, których stosowanie pozwala na samoorganizację.

    Co do skrzyżowań bezkolizyjnych – chodziło mi głównie o rondo (bo wydawało mi się, że jest to przykład skrzyżowania bezkolizyjnego – ale sprawdzę to jeszcze).

    Dzięki za feedback!

  • Seban

    A gdyby tak pójść w analogii trochę dalej i używać znaków drogowych do komunikowania tego co dzieje się w zespole? Popsuty build na CI znak z przewróconym samochodzikiem, stop. Masz jakieś pomysły jak można by pewne sytuacje przenieść na znaki drogowe?

  • Łukasz Herok

    Rondo – samoorganizacja w ramach ustalonych reguł (procedur) 🙂 – i to ma prawo działać.

    Ps.
    Analogia trafna, ale trochę za długi wpis.

Skomentuj