bookmark_borderProject managerowie go nienawidzą! Programista z korpo odkrył jeden prosty trik jak wysadzić projekt w powietrze przy użyciu Jiry.

Za górami, za lasami, za siedmioma routerami, był sobie projekt. Był dobry. Deadline był odległy, a budżet zatwierdzony. Zespół liczny, doświadczony. Pomysł na produkt miał ręce i nogi.

Co mogło pójść nie tak?

Zabraliśmy się do pracy. Spotkania, telekonferencje, ustalenia. Planowanie za planowaniem, meeting za meetingiem, sprint za sprintem. Szybko okazało się, że głównodowodzący projektem ma osobowość radiowego spikera. Człowiek ten uwielbiał rozmawiać, mówić, przemawiać i omawiać. Nie ma w tym nic złego. Dobrze jest być towarzyskim. Projekt był rozproszony geograficznie, więc siedziało się na słuchawce godzinami, ale jeśli trzeba coś omówić, to przecież naturalne.

Po rozmowie wypadałoby zacząć pracę, a ustalenia spisać. Nasz lider jednak lubił jedynie mówić. Zadania, jakie dla nas tworzył składały się zwykle z jednozdaniowego opisu staniowącego tytuł.

Projekt trwał i trwał, postępy nie były imponujące. Nadszedł sezon urlopowy. Nasz lider również postanowił udać się na zasłużony wypoczynek. Dwutygodniowy. Przed opuszczeniem biura zorganizował – a jakże! – spotkanie, na którym omówił zadania, jakie przed nami stały. Wydawało nam się, że zrozumieliśmy jego intencję. Dla uspokojenia przekazał nam kontakt do dwóch osób, które miałyby rozwiać nasze wątpliwości w razie, gdyby takowe zaistniały.

Przyszedł kolejny tydzień. Zajrzeliśmy do notatek, zajrzeliśmy do zadania (z jednozdaniowym opisem). Po kilkunastu minutach pojawiły się wątpliwości. Po godzinie rozmawialiśmy z pierwszą osobą, jaka miała nas wspomóc. Okazało się, że zrozumiała naszego lidera inaczej, niż my. Zaniepokoiło nas to. Zadzwoniliśmy do kolejnej. I ona zrozumiała inaczej. Tyle tylko, że nie inaczej niż my, ale również inaczej niż pierwsza osoba. Mieliśmy trzy interpretacje i dwa tygodnie bez autora.

Puenta okazała się zaskakująca. Gdy lider wrócił z urlopu i zaczęliśmy drążyć, jak konkretnie mamy wykonać zadanie i na czym ma ono polegać, po kikudziesięciu minutach kluczenia przyznał, że nie wie.

To najjaskrawszy, z jakim miałem do czynienia, przykład jednego z grzechów programistów – pobieżnego opisywania tasków. Oczywiście nie można być pedantem i opisywać ich przesadnie szczegółowo, ale pewien sensowny poziom detalu i dbałości jest wymagany, by projekt nie eksplodował spotkaniami.

Zastanówmy się. Bierzemy do ręki, na warsztat nowe zadanie. Czytamy opis i połowy z niego nie rozumiemy. Co robimy? Idziemy do autora. Jeśli autor jest z biznesu, to pewnie jest na spotkaniu i nie idziemy, a wysyłamy mail. Czekamy albo bierzemy inne zadanie. Jeśli inne są równie dobrze opisane, to piszemy kilkanaście maili zanim uda nam się zabrać do roboty. Jeśli natomiast autor jest programistą z zespołu to idziemy do niego i… odrywamy go od pracy w skupieniu, przychodząc z naszym  pytaniem.

W obu scenariuszach tracimy czas. Wszyscy. Czas i efektywność.

Opis zadań powinien być precyzyjny, napisany prostym językiem i wystarczająco dokładny, żeby zrozumiała go osoba, która nie posiada naszej wiedzy, a wiedzę wspólną dla członków zespołu. Nie możemy wychodzić z założenia, że jak nie wie to dopyta. To nieefektywne, szkodliwe, złe. To tworzy kulturę rozproszeń, chodzenia od biurka do biurka w nieustającym rytuale dopytywania, ustalania, marudzenia jeden drugiemu. Programista powinien móc jak najdłużej pracować w skupieniu. Tylko tak tworzy się sprawnie dobrej jakości oprograowanie.

Opisuj taski. Opisuj je dobrze. Jeśli nie umiesz ich dobrze opisać, to może nie wiesz w ogóle co jest do zrobienia?

Please follow and like us:

bookmark_borderModyfikowany agile

Nie zliczę, ile to już razy, przez wszystkie przypadki słyszałem odmienianie w ostatnich latach słowo Agile. Jesteśmy Agile, działamy zwinnie, wdrażamy Agile.

Przypomina to kuchenne dywagacje o siłowni. Tak, chodzę na siłkę, tak robię masę, jasne crossfit, cardio, aero, suple.

Tylko muskulatury nie widać. 

I tak samo efektów tej zwinności nie widać. Jak był chaos tak chaos jest, jak estymacje nie szły tak nie idą. A przede wszystkim jak był sztywny scope tak jest i jak deadline’y straszyły tak straszą. Dług techniczny jest zaciągany. Wdrożenia są bolesne. No, ale jesteśmy Agile.

Tylko, czy jesteśmy?

Chyba najgorsze co w Agile nie wyszło, to twierdzenie, że możemy go modyfikować. Tak oto, wracając do analogii siłowni, robimy masę, ale… Nie dbamy o dietę, bo lubimy jeść. Nie robimy ćwiczeń na nogi, bo w piątek idziemy na imprezę. Nie chodzimy na siłkę jak nas głowa boli, bo jeszcze nam żyłka pęknie.

I tak chodzimy przez dwa lata, a zamiast kaloryfera dalej bojler.

Czy można być zwinnym przy sztywnym scope? Czy można wdrażać co sprint jeśli nie ma do tego struktury organizacyjnej? Czy bez pokazywania klientowi co sprint przyrostu można budować lepsze oprogramowanie? Czy w ogóle można być zwinnym jak nie ma jeszcze klienta?

Może tak, może nie.

Na pewno jednak jeśli posuwamy z zasad Agile połowę, nie będzie benefitów, a problemy. Warto by być odpowiedzialnym developerem i nie ulegać zbyt łatwo pokusie zjedzenia ciastka będąc na diecie. Jak wiemy nie można go zjeść i nadal mieć.

Please follow and like us: