Zasada TAO – trzy cechy jeden zespół

W dużych firmach spotkałem się czasem z sytuacją, w której to różne zespoły (np.: analitycy biznesowi i programiści) wzajemnie się zwalczali poprzez wytykanie nieścisłości w dokumentacji, jej barki lub niezgodność z przyjętymi regułami/metodykami. Sytuacja ta niewątpliwie nie sprzyja produkowanemu oprogramowaniu jaki i pracownikom firmy. W takich sytuacjach polecam  zasadę TAO. Zasada ta nawiązuje do taoizmu, który zakłada (w bardzo dużym uproszczeniu) akceptację samego siebie, dążenie do spokoju ducha oraz harmonii z otaczającym nas wszechświatem. W inżynierii oprogramowania pod zasadą TAO rozumiem iż zespół projektowy kieruje się: Tolerancją, Autonomią  i Odpowiedzialnością.

Tolerancja oznacza iż każdy z nas postrzega świat inaczej a tym samym budowane modele, tworzona dokumentacja systemu przeważnie będzie inna niż gdybyśmy sami ją zbudowali. Każdy z nas inaczej postrzega świat stad i modele mogą być inne.  Tolerancja nie oznacza, ze akceptujemy wszystko. Jeśli czegoś nie rozumiesz zapytaj twórcę artefaktu co miał na myśli a nie oceniaj z góry na jakim to szajsie musisz pracować .

Autonomia to prawo do tego by każdy z członków zespołu dobierał takich narzędzi (czyt.: diagramów, modeli) oraz takiej perspektywy abstrakcji, które jego zdaniem w danym momencie są adekwatne do projektowanego systemu. Oczywiście można a nawet trzeba wymagań ustalonego minimum artefaktów, ale trzeba być także otwartym na to, że nasze ustalenia nie obejmują danej sytuacji. To analityk lub projektant ma prawo zadecydować o tym co i jak będzie zamodelowane.

Odpowiedzialność wzmacnia/ogranicza autonomię bo nie pozwala iść na skróty. Odpowiedzialny członek zespołu projektowego stara się przedstawić model sytemu z tylu perspektyw ile jest potrzeba by był on zrozumiały. Bierze on też pełną odpowiedzialność za swoje decyzje projektowe i dąży razem z całym zespołem do wspólnego celu.

TAO jest proste w zastosowaniu i nie wymaga rewolucji w organizacji. Czasem wystarczy tylko wziąć głębszy oddech i postarać się zrozumieć współpracownika.

Podobne wpisy

  • Dlaczego warto używać metod Agile? Metody Agile skupiają się na krótszych iteracjach, w których to oprogramowanie dość często jest doprowadzane do takiego poziomu jakości, który pozwala na jego wydanie, zazwyczaj trwa to od […]
  • Planowanie w projekcie w nurcie Agile Planując pracę  swoją czy też swojego zespołu staram się przestrzegać kilku zasad. Oto one: Plan szczegółowy buduję jedynie dla najbliższych zadań. Moim zadaniem użyteczne są plany […]
  • Demonstracja czyli o ważności informacji zwrotnej Jednym z moich zaleceń, związanych z nurtem Agile, jest: “Pokazuj to co zbudowałeś tak często jak się tylko da”. Należy zastosować to podejście, aby uzyskać informację zwrotną na temat […]
  • Kiedy nie działa zwinne modelowanie? Czy zwinne modelowanie działa zawsze? Otóż nie. Zazwyczaj z podejściem Agile są problemy gdy opisujemy procesy w dużych firmach, gdzie istnieje: duża ilość procesów problemy są oparte o […]
  • Iteracje w Agile Modeling Iteracyjny model wytwarzania oprogramowania by był bardziej skuteczny wymaga kilku zabiegów. Chodzi oto by w ujęciu agile być rozważnym i skutecznym. Stosuję je podczas zwinnego […]
Reklama

Leave a Comment

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *