Pytanie niby absurdalne ale właściwie niektóre dyskusje skłaniają mnie do pochylenia się nad tym tematem. Otóż kiedy remontujemy mieszkanie i zapraszamy fachowców do wykonania usługi to zwykle dyskutujemy zakres prac i przedstawiamy nasze wyobrażenia na temat tego co chcemy uzyskać. Wtedy czasami (pomijam scenariusze typu nieuczciwy/leniwy fachowiec) możemy usłyszeć sugestie typu „w tym miejscu będzie to niewygodne” albo „to będzie dużo kosztować” itp.

W sumie taki trochę Agile – my mówimy co chcemy, fachowiec szacuje pracochłonność, sugeruje z doświadczenia jakieś lepsze rozwiązania dogadujemy się i robimy. Pomijam tematykę synchronizacji kilku zespołów wykonawczych „panie, ale panu to źle zrobili…”. Ale w podstawowym zakresie działa estymacja, wartość biznesowa i skłonność właściciela produktu do zmiany założeń na podstawie wiedzy fachowej.

Dlaczego w takim razie tak wielki problem powstaje z software deweloperami? Przy zatrudnianiu jesteśmy gotowi zapłacić krocie (bo tak trudno o dobrego software dewelopera) a kiedy przychodzi do dyskusji na temat wykonania to wszyscy mają tysiące pomysłów jak można ulepszyć/poprawić lub nawet wręcz zaprojektować funkcjonalność w systemie.

W tradycyjnym podejściu na porządku dziennym jest przecież nie tylko sugerowanie co powinno być osiągnięte ale również w jaki sposób. I nie mówimy to wstawkach typu „zobaczcie, chodzi mi o coś podobnego jak widziałem w rozwiązaniu x” tylko o chęci „wspomożenia” deweloperów gotowymi rozwiązaniami typu „dodajcie mi tutaj 2 pola z datą”. Z doświadczenia wiadomo, że 2 pola z datą po kilku iteracjach mogą rozrosnąć się w niekontrolowany sposób do niebotycznych rozmiarów w dalszym ciągu nie zapewniając pożądanej funkcjonalności użytkownikom.

W sumie jak się głębiej zastanowić to te zachowania są normalne – remontując kolejne łazienki i nabierając doświadczenia z fachowcami w którymś momencie sami zaczynamy się czuć specjalistą. Wtedy pojawia się chęć wspomożenia wykonawcy i wymyślenia za niego jak to powinno być zrobione. A w tworzeniu oprogramowania przychodzi to łatwiej, bo każdy kto zna więcej niż jedną aplikację czuje się specjalistą od UX, programowania i ogólnie tworzenia software’u

Scrum rozwiązuje ten problem w dużej mierze wymuszając bliską współpracę właściciela produktu z zespołem. Czyli właściciel produktu ma szansę usłyszeć ile kosztuje rozwiązanie jak również przedyskutować czy nie ma innych, lepszych lub tańszych alternatyw. Uważać jedynie należy (i edukować właściciela produktu), żeby unikać tego typu zachowań przychodzących z zewnątrz – czyli ze strony interesariuszy.