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.
