Ostatnio zaprezentowałem w pigułce podstawy autonomii. Polega ona na wyznaczaniu granic odpowiedzialności pomiędzy zespołami, na zaufaniu że inni znają się na “swoich” rzeczach najlepiej. W związku z tym biorą za nie odpowiedzialność która wyraża się poprzez prawo podejmowania decyzji aby w danym zakresie.

Ale czego tak naprawdę ta autonomia może dotyczyć w praktyce dla każdej ze stron?

Strona techniczna jest odpowiedzialna za dostarczenie prawidłowo działającego rozwiązania zgodnie z dostarczonymi wymaganiami.

Strona biznesowa jest odpowiedzialna za dostarczenie wymagań biznesowych w formie które pozwolą rozpocząć pracę nad dostarczeniem rozwiązania.

Strony te muszą równie współpracować jak ufać sobie nawzajem gdyż ostatecznie dążą do tego samego celu.

Programiści będą więc podejmować decyzje dotyczące

  • Technologii – która pozwoli dostarczyć rozwiązanie które będzie łatwo napisać, testować, jak i potem utrzymywać.
  • Czytelności kodu –  czyli tego czy trzeba ją poprawić. To tylko zespół programistów jest w stanie zadecydować czy kod wymaga pracy nad poprawą czytelności, ponieważ w innym przypadku opóźni to dostarczenie rozwiązania (jego kolejnych wersji) oraz zwiększy prawdopodobieństwo błędów (albo już takowe zostały zauważone).
  • Testowalności kodu – To programiści wiedzą gdzie brakuje testów, które z istniejących scenariuszy wymagają poprawek i rozszerzeń o brakujące przypadki, tak aby zmieniając lub rozszerzając kod o nowe funkcjonalności nie popsuć tej już istniejącej która działa prawidłowo.
  • Reużywalności kodu – tutaj wystarczy proste pytanie : czy prędzej można re-użyć mały kawałek kodu czy duży tzw. ośmiotysięcznik? A jeżeli używamy ponownie kawałka kodu który już działa prawidłowo – a nie piszemy go od nowa to szansa na to że działa on prawidłowo ponownie jest większa. Tak więc z większych kawałków kodu trzeba wyciągnąć te mniejsze aby je móc “re-używać”.
  • Rozszerzalności kodu – kiedy kod jest czytelny, testowalny, reużywalny – to prawdopodobniej dużo łatwiej będzie go zmieniać a więc i rozszerzać o nową funkcjonalność, szczególnie bez dopisywania rzeczy które są potrzebne w nowej funkcjonalności ale… już są napisane.

Analitycy biznesowi będą podejmować decyzje dotyczące

  • Zakresu prac – czyli co ma być zrobione. To analitycy wiedzą najlepiej czego potrzebuje klient – to ich zadanie a nie programistów.
  • Kolejności prac – klient jak najszybciej powinien otrzymać działający produkt lub jego część działającą chociaż w ograniczonym zakresie. To pozwoli mu na ocenę czy produkt spełnia oczekiwania czy też plan prac wymaga modyfikacji na podstawie oceny przydatności otrzymanego rozwiązania.
  • Przydatności uzyskanego produktu – być może produkt działa zgodnie ze specyfikacją, ale co z tego, kiedy okazuje się, że jednak klient potrzebuje jednak czegoś innego więc plany trzeba zmienić.

Oprócz powyższych potrzebne jest jest coś wspólnego – współpraca i zaufanie że druga strona podejmuje najlepsze decyzje wg obecnie posiadanej wiedzy.

Tylko wtedy pracując razem i osobno można projekt doprowadzić do sukcesu.

Spread the word. Share this post!

Leave a comment