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ć.

bookmark_borderFundamentalny problem rozwoju oprogramowania

Gdyby zapytać, czym zajmuje jest programista? – większość osób odpowiedziałaby – pisaniem kodu programów. Niektórzy, bardziej zorientowani w temacie lub związani z branżą odpowiedzieliby – analizą wymagań, projektowaniem aplikacji, programowaniem, do pewnego stopnia też testowaniem i wdrażaniem. To widać. To perspektywa operacyjna.

To czego jednak nie widać, przynajmniej na pierwszy rzut oka, jest istotniejsze i skutkuje ogromem problemów związanych z rozwojem oprogramowania. 

Świat jest złożony. Nieskończenie omal złożony. Przedmioty złożone są z elementów, elementy z materiałów, materiały ze związków chemicznych, te z cząstek, dalej mamy atomy, cząstki elementarne i tak dalej. Z drugiej strony przedmioty skupiają się w miejsca, miejsca w miasta, dalej mamy regiony, państwa, kontynenty, planety, układy gwiezdne, ich skupiska, galaktyki, gromady galaktyk etc. 

Ludzie operują na uproszczeniach. Widząc świat – szacujemy. Opisując grupę ludzi mówimy: para, kilka osób, kilkoro, tłum. Nie liczymy ilości i nie mówimy 27 osób. Widząc kolory mówimy jasnozielony, ciepły lub zimny, ponury, pozytywny. Nie podajemy matematycznego opisu ilości  czerwieni, zieleni i koloru niebieskiego.

Komputery operują na wartościach. Nie możemy zdefiniować w nich samochodu albo benzyny. Musimy stworzyć abstrakcje tych przedmiotów, wybrać pewne wartości, które je opiszą w sposób uproszczony (objętość, liczba oktanowa), wyselekcjonować relacje między nimi (typ paliwa dla samochodu).

Ludzie I komputery są fundamentalnie odmienni. Oprogramowanie jest pomostem między dwoma światami. Programowanie jest budowaniem warstwy pośredniczącej między katastrofalnie nieprzystającymi do siebie rzeczywistościami.

Konsekwencje takiego stanu rzeczy są ogromne. Z uwagi na te różnice tworzenie oprogramowania jest trudne, długotrwałe i złożone. Z powodu tej odmienności programiści nie mogą się porozumieć z klientami. Z tej samej przyczyny nie powstały do tej pory znane z filmów sci-fi roboty, dlatego nie przeprowadzimy ciekawej rozmowy z Siri, a autonomiczne auta napotykają na problemy.

Co szczególnie zwraca moją uwagę po latach pracy nad tworzeniem oprogramowania to naturalna tendencja ludzka do oszczędzania energii (patrz: Prawo trywialności). Bardzo niewielka część populacji jest skłonna włożyć wysiłek w dogłębne przemyślenie tematu, nad którym pracuje. Większość osób spłyci wszystko najbardziej jak się da. Widać to w problemach programistów z testowaniem wyników własnej pracy. Mało który jest w stanie używać swojego oprogramowania inaczej niż w sposób w jaki je tworzył. Jest to najprostszy scenariusz, bo scenariusz znany. Tworzenie nowego wymaga wysiłku. Ta optymalizacja umysłowa widoczna jest również w pracy projektantów że strony biznesu. Zawsze omal, po jakimś czasie okazuje się, że wielu scenariuszy nie przewidziano, a ograniczono się do najprostszych. W zasadzie na chwilę obecną nawet zakłada się, że wszystkich możliwości nigdy się nie przewidzi (fundamentalnie odmienną zasadę przyjęto w zespole pracującym nad specyficznym projektem w postaci programu promu kosmicznego, a sam proces prac skutkujących – mimo dwóch katastrof – niewielką ilością błędów ciekawie opisano tutaj).

Dla rozwoju oprogramowania potrzebna jest niestety precyzja. Na każdym etapie od projektu przez implementację po testy potrzebny jest wysoki rygor umysłowy. I to jest główny wniosek, jaki płynie z fundamentów, z natury samej oprogramowania. Nie możemy sobie pozwolić na lenistwo. Musimy zawsze, w każdym momencie pracy być tak precyzyjni jak tylko możliwe. W przeciwnym wypadku dopadną nas konsekwencje – błędy, niedopatrzenia, luki. Tak, jak kompilator jest bezlitosny i w starciu z nim może mylić się tylko programista, nigdy zaś komputer, tak samo szeroko pojęty rozwój oprogramowania jest bezlitosny. Co zignorujemy – wróci do nas rykoszetem, raniąc.