Dlaczego drobne zmiany realizowane są wieczność?

Popatrz na poniższy rysunek.

Pokazuje on jeden z kłopotów związanych przygotowywaniem i tworzeniem małych porcji funkcjonalności. Kierunek strzałki od-do oznacza "skutkiem jest". Mamy zatem objaw, iż biznes naciska, aby rozpocząć pracę nad kolejnymi rzeczami, skutkiem jest, iż mamy nadmiar pracy, czego skutkiem jest, iż biznes musi długo czekać, aż rozpoczniemy zlecone prace, a tu z kolei skutkiem jest, iż biznes naciska, aby rozpocząć kolejne prace. I tak w kółko. Znasz to? 😃

Przykład bezwładnego procesu deweloperskiego

Pewnego słonecznego poranka, pewna firma zmieniła siedzibę. Przenieśli się z ulicy Polnej na Kwiatową, mniejsza o to w jakim mieście. W związku z tą poważną zmianą, w serwisie webowym rozwijanym przez firmę, w każdym miejscu, w którym występowało "Polna" należało zmienić tekst na "Łącka". Product Owner zdefiniował to trywialne zdanie w backlogu i poprosił zespół o oszacowanie. Po krótkiej naradzie, zespół podał estymatę - 2 dni pracy.

PO zdębiał. Ale, iż co?? Przecież to tyko podmiana napisu z jednego na inny. Dodatkowo oba napisy mają tę samą liczbę znaków, zatem wygląd strony nie powinien się rozjechać. O co tu kaman?

Żebyśmy dobrze się zrozumieli. Przypuśćmy, iż jeden dzień pracy zespołu kosztuje 2000zł. Zatem zmiana ulicy "Polnej" na "Łącką" na stronie internetowej będzie kosztował 4000zł. Tyle samo, ile położenie 20 m. kw. kostki brukowej (stan na sierpień 2023). Stoisz zatem przed wyborem albo zamiast "Polnej" zobaczyć "Łącką" albo mieć całkiem przyzwoity taras. Teraz czujesz kuriozum całej sytuacji? 😃

Miara bezwładności procesu

Zatrzymajmy się jednak na chwilę nad tym problemem. Dlaczego trywialna zmiana ma zająć aż 2 dni, przecież w story pointach to by było choćby mniej niż 1 ;P (zerknij na moje artykuły nt. story pointów: (Ach, te story pointy oraz ***** story pointy).

Development tegoż wymagania zajmie przecież chwilunię. W takim razie co zajmie resztę czasu z tych dwóch dni? Otóż resztę czasu zajmą: testowanie, akceptowanie, regresje, składanie paczki wdrożeniowej, audyt bezpieczeństwa, weryfikacja zgodności ze standardami, czekanie na możliwość wdrożenia, itd. Czyli wszystko to, co nie jest programowaniem.

Wobec powyższego można powiedzieć, iż koszt trywialnego zadania deweloperskiego stanowi miarę bezwładności procesu dostarczania oprogramowania. Owe 2 dni pracy podane przez zespół mówi o tym, jak bardzo ociężały jest nasz proces. Te 2 dni to nasza przestrzeń do usprawnień. Dokładnie tyle możemy "odzyskać" jeżeli poprawimy proces dostarczania oprogramowania.

Błędne koło

Z przytoczonych opowieści wynika, iż biznes stara się dopychać coraz więcej pracy, ponieważ proces dostarczania systemu nie jest wystarczająco sprawny. Przy ociężałym procesie nie ma również żadnego powodu, aby dzielić ficzery na mniejsze kawałki. Z perspektywy biznesu, który zleca prace, proces dostarczania o dużej bezwładności oznacza tylko tyle, iż trzeba jak najszybciej zakontraktować jak najwięcej pracy, bo na kolejną okazję trzeba będzie dłuuugo czekać.