Trzy lata temu tak zaczynałem artykuł o wymaganiach i prawach autorskich:

Od czasu do czasu miewam dyskusje na temat tego, kto i co powinien wytworzyć w projekcie dostarczania oprogramowania. Pojawia się problem: czym jest ów projekt. Po drugie: kto jest autorem i czego. Po trzecie: czym jest ta dokumentacja. Problem w tym, że w projektach IT w wyniku analiz powstają ?jakieś wymagania? i tak na prawdę nie wiadomo czym one są? Dziwne? Czym jest produkt, którego ?cechą funkcjonalną jest możliwość wbijania gwoździ?? Otoczakiem, pneumatycznym młotem czy może prostym ręcznym młotkiem? (Prawo autorskie, szpiegostwo przemysłowe i projektowanie | Jarosław Żeliński IT-Consulting).

W ubiegły Czwartek odbyła się konferencja Agile Management. Dokładnie tak samo zaczęła się jedna z kuluarowych dyskusji na tej konferencji. Nie będę tu powtarzał treści tego artykułu, konferencja pokazała, że nie zdezaktualizował się (zainteresowanym prawem do kodu polecam jego lekturę). Prawo do powstającego kodu “raczej” ma autor pomysły, który potrafił ten pomysł dobrze udokumentować.

Przedwczorajsza konferencja,  była bardzo ciekawa także z innego powodu. Wśród wielu prezentacji, w moich oczach, dwie prezentacje były szczególnie ciekawe: Krystian Kaczor ? o swoich doświadczeniach i sprawdzonych metodach skalowania Agile do poziomu całego przedsiębiorstwa i mec. Łukasz Węgrzyn ? o nowym modelu współpracy i konieczności redefiniowania dotychczasowego podejścia. (Konferencja Agile Management 2014 – konferencja). Prezentacje te, każda w swoim obszarze, wskazywały na możliwe sposoby rozwiązywania problemów projektów nazywanych zwinnymi. Zwinność została okiełznana?
Obecnie zamawiane oprogramowanie jest coraz częściej bardzo złożone. Może to być oprogramowanie tworzone na indywidualne potrzeby lub tworzone z myślą o sprzedaży go na rynku. W obu przypadkach chcemy by powstało. Rosnąca złożoność oprogramowania to konsekwencja rosnącej wielkości i złożoności działania organizacji takich jak podmioty rynkowe czy instytucje publiczne.

Wodospad (waterfall) to nazwa procesu tworzenia oprogramowania polegająca na opracowaniu szczegółowego projektu by następnie rozpocząć jego realizację. Właśnie w tym momencie oglądam jeden z moich ulubionych programów w TV: Jak to jest zrobione. Tym razem jest to  tankowiec, którego konstrukcja składa się z ok. 100.000 elementów (tak sto tysięcy elementów!). Muszą one być wszystkie zaprojektowane przed rozpoczęciem budowania statku. Powód jest oczywisty: ryzyko całego projektu za duże, by pozwolić sobie na odkrycie problemu z elementami składowymi w toku montażu lub w morzu. Sam montaż (budowa tankowca) to ok. 16 miesięcy, projektowany jest znacznie dłużej i tu niebagatelną rolę, w skróceniu tego procesu (projektowanie od zera wszystkiego trwało by kilkanaście lat) odgrywają wzorce projektowe (o czym innym razem). Czy to można coś zrobić zwinnie? Nie bardzo, ryzyko jest zbyt duże, okupujemy to jednak tym, że czas od pomysłu do otrzymania gotowego produktu to, łącznie z projektowaniem, kilka lat.

Oprogramowanie to co prawda “materia” bardzo łatwo modyfikowalna (tylko korekta tekstu programu) ale nie znaczy to, że modyfikacje te odbywają się “niskim kosztem” (dobry programista zarabia nawet dwa razy więcej niż dobry spawacz w stoczni, po drugie znaczna część spawania jest zautomatyzowana, kodowania jeszcze nie zautomatyzowano). Rynek jednak zmusza firmy do stałego podejmowania prób uzyskania potrzebnego im oprogramowania “szybko”.  I tak powstała idea “zwinnego” tworzenia oprogramowania: zacząć tworzyć bez żmudnego i czasochłonnego projektowania bo “nie ma czasu”.  Poniżej kilka przemyśleń z konferencji.

Agile

Uznano, że projekt można rozpocząć nie mając pełnego zrozumienie problemu ani projektu. Jeżeli rozpoczynamy bez zrozumienia problemu i pomysłu na jego rozwiązanie, jesteśmy skazani na bardzo “zwinne” podejście, polega ono w “tradycyjnym zwinnym” podejściu, na tworzeniu oprogramowania z dużym udziałem zamawiającego (jedyne źródło wiedzy o tym co i jak chcemy uzyskać) metodą kolejnych prototypów. Niestety wynik jest nieprzewidywalny.

W takim przypadku pozostaje zaufanie, i bywa że ma to szanse powodzenia ale zespół “zwinnych programistów” to muszą być bardzo dobrzy specjaliści, tacy, którym można zaufać, że można uwierzyć to, że powstające kolejne przybliżenia nowego produktu są najlepsze z możliwych. Jak nie trudno się domyśleć: taka sytuacja to rzadkość.

Alternatywą jest mniej “zwinne” podejście czyli jednak wykonanie analizy przed rozpoczęciem projektu, której celem jest zrozumienie problemu i opracowanie koncepcji rozwiązanie, ale nie specyfikowanie szczegółów rozwiązania. Powodem, dla którego nie próbujemy projektować szczegółów jest, zbyt duża złożoność tych problemów i brak czasu.

Kolejna ważna rzecz w dużych projektach (Krystian Kaczor):  średni i większy projekt powinien jednak mieć architekta, żeby ktoś mimo wszystko miał pomysł na całość. Bez planu i wizji całości nawet najlepszy zespół zwinny, nie da rady bez opisanej i zarządzanej wizji całości. Rzucanie się na duży projekty bez uzgodnionej architektury całości, koncepcji integracji, prowadzi to nieustających i bardzo kosztownych zmian, przy każdej lokalnej zmianie związanej z integracją.

Dlatego kluczowe jest rozpoznanie rodzaju projektu na samym jego początku. Ocena ryzyka i określenie rodzaju projektu: “bungalow czy drapacz chmur”. Mając dość rozległy teren można pokusić się o budowę parterowego domu, efekt docelowy można potraktować jako wizję, w toku prac można dość swobodnie zmieniać wiele wymagań, wręcz tworzyć je w miarę trwania budowy.  Rozległy parterowy dom z reguły nie wymaga wyburzenia dotychczasowych efektów pracy gdy pojawi się nowy pomysł na pozostałą do zbudowania część domu. Gorzej jest w przypadku drapacza chmur. Tu budowa idzie w górę a całość stoi na jednym fundamencie. Zmiana koncepcji w toku budowy jest niemożliwa bez przebudowy tego co poniżej a to może być po prostu, z przyczyn czasowych i kosztowych,  już niemożliwe. Bardzo ważne jest więc jak najwcześniejsze odkrycie tego czy tak na prawdę budujemy wieżowiec czy rozległy bungalow. Niskie płaskie budowle nie stwarzają ryzyka konieczności wyburzenia całości w przypadku błędu lub zmiany koncepcji.

A teraz kwestia tego na co się umawiamy czyli zwinna umowa na wykonanie usługi

Zasady współpracy to kluczowy element umowy. Realizacja projektu to nie tylko obowiązki dostawcy ale także obowiązki zamawiającego, w końcu jest uczestnikiem projektu Agile. Tu kluczem jest jednak planowanie, agile to nie powinien być niekontrolowalny żywioł, to jednak umowa dwóch  stron i obie te strony mają obowiązki. Dostawca jednak powinien się do czegoś zobowiązać i nie może to być wyłącznie “będziemy się starać”.  Kluczem zwinnej umowy, mimo, że nie umieszczamy w niej setek szczegółów wymagań, jest to jak stwierdzimy, że projekt został zrealizowany. W tym miejscu, jako kontynuację lektury tego tekstu polecam doskonałą prezentację mec. Łukasza Węgrzyna z kancelarii Maruta o umowach “Agile”:

Ta konferencja przekonała mnie, że w sumie to jestem zwinny, bo: moje umowy mają zakres i harmonogram, praca jest iteracyjna, całość bazuje na wizji, opisuję jak stwierdzimy, że wykonałem swoją prace… a specyfikacje wymagań jakie opracowuję, mają nie setki i tysiące pozycji, a góra kilkadziesiąt. Swego czasu opisałem to tu:

Pamiętajmy, że zarządzanie zakresem projektu jest tym kosztowniejsze im więcej szczegółów ten zakres posiada. Projekt o 30 wymaganiach vs. projekt o 300 wymaganiach to nie projekt o 10-krotnie większym koszcie, ta różnica będzie znacznie większa (pomijam to jak w ogóle zdefiniujemy wymaganie). (Mega projekty czyli jak zjeść słonia | Jarosław Żeliński IT-Consulting).