Manifest Agile – czyli co się pod tym kryje (część IV) – działające oprogramowanie

W poprzednim artykule z tej serii „Manifest Agile – czyli co się pod tym kryje (część III)” starałem się wyjaśnić znaczenie mojej odmiennej wersji tłumaczenia kładąc duży nacisk na indywidualności i interakcje występujące pomiędzy nimi. Tym razem przedstawię moją interpretację drugiego postulatu.

Agile działające oprogramowanie

Działające oprogramowanie ponad kompletną dokumentację

W języku angielskim słowo working jako przymiotnik ma następującą definicje: functioning or able to function, used as the basis for work or argument and likely to be developed or improved later, sufficient to work with at a basic level.

W tłuczeniach na język polski używa się słów: działający, sprawny, czynny, aktywny, funkcjonujący. I chociaż definicje tych słów są zbliżone, to jednak żadne z nich nie wyczerpuje tego co podaje angielska definicja. Prawdopodobnie dlatego wiele polskich opracowań i zagranicznych przedstawia działające oprogramowanie jako: zakodowany i skompilowany kod, który przeszedł wszystkie możliwe testy (modułowe, integracyjne, systemowe, akceptacyjne, itd..). Powołując się jednak na angielską definicję, uważam że takie podejście jest daleko przesadzone.  Działające lub zdolne do działania, używane jako podstawa do pracy lub dyskusji, mogące być rozwijane później, wystarczające na pracę na podstawowym poziomie (takie moje wolne tłumaczenie :) ), to trochę odmienna definicja. Na pewno istotne jest, aby oprogramowanie się uruchomiło, żeby funkcjonalności, które są już dostępne (na początkowych etapach to mogą być tylko ekrany z przyciskami), działały sprawnie. To, czy oprogramowanie jest working, ocenia klient, który to akceptuje wyniki pracy zespołu wytwórczego. Zazwyczaj dzieje się to podczas cyklicznych spotkań podsumowujących (w metodzie SCRUM będzie to Sprint Review) na bazie jego odczuć, oczekiwań i tego co zostało mu zaprezentowane. Oczywiście znam klientów, którzy uwielbiają mieć mnóstwo raportów, z których nie wiele wnioskują i na nic nie są im przydatne. Częściej jednak spotykam takich, którzy nigdy nie zostali zapytani czy i po co im to jest potrzebne. Postulat ten dotyczy obu stron. Wytwarzającym zwraca się uwagę na to, żeby od samego początku oprogramowanie już było i przedstawiało już jakąś wartość dla klienta. Z kolei klienta informuję się,  że zamiast sterty papierów potrzebne jest mu coś sprawnego, działającego, czym będzie mógł się pochwalić.

Drugim najczęstszym przekłamaniem z jakim się spotykam, to skupianie się na drugiej części tego postulatu: „ponad obszerną dokumentację”. Wielu ludzi słysząc Agile myśli „…a to takie wytwarzanie produktu, gdzie nie robi się dokumentacji – jest przecież zakazana przez manifest”. To straszne nieporozumienie bierze się zapewne z tego, że mało kto lubi wykonywać dokumentację. Prawda jest jednak taka, że bez względu na metodę jakiej używamy przy wytwarzaniu produktów, dokumentacja może być jednym z produktów cząstkowych potrzebnych do realizacji produktu końcowego i nie należy zapierać się przed jej robieniem. Postulat ten sugeruje, żeby nie robić zbędnej dokumentacji (np. kolejnych raportów z testowania, czy software architect document) jeśli nikomu nie są potrzebne. W zwinnym podejściu chodzi o ciągle działające (sprawne, czynne, funkcjonalne,…) oprogramowanie. Poprzez „ciągle” rozumiemy oprogramowanie, które spełnia oczekiwania klienta dla tego etapu prac i gwarantuje, że praktycznie każdego dnia jest on w stanie znaleźć taki pakiet instalacyjny, który z większą lub mniejszą ilością funkcjonalności będzie działał.

W kolejnym artykule z tej serii postaram się rozwinąć trzeci postulat „Kolaboracja z klientem ponad formalne umowy”, a tymczasem zachęcam do komentowania tego wpisu.

Wpis opublikowany w Dynamika Rozwoju BLOG i otagowany , , , przez .
Lukasz

O Lukasz

Absolwent wielu kierunków (Project Management, Inżyniera Oprogramowania, Informatyka Stosowana, Pedagogika), doktorant nauk o zarządzaniu na Uniwersytecie Ekonomicznym. Pracownik dużej międzynarodowej korporacji z wieloletnim doświadczeniem zdobytym na stanowiskach menadżerskich (Project Manager) i podczas pełnienia dodatkowych funkcji (Team Leader, Scrum Master, wewnętrzny trener trenerów). Członek Rady Dolnośląskiej Grupy IPMA (zastępca przewodniczącego), posiada szeroką wiedzę i kompetencje z obszaru zarządzania projektami, pracy zespołowej i rozwiązywania konfliktów - potwierdzone wieloma publikacjami i szeregiem certyfikatów (IPMA C/D, Scrum Master, ….). Aktywny zawodowo trener z wieloletnim doświadczeniem (setki przeszkolonych osób).

2 myśli nt. „Manifest Agile – czyli co się pod tym kryje (część IV) – działające oprogramowanie

  1. LoKost23

    Witam, chyba rozumiem co pan ma na myśli chodzi o kładzenie większego nacisku na pewne rzeczy a mniejszego na inne lub wedle potrzeby klienta. Nawiązując do pana wolnego tłumaczenia wyczuwam nutkę podejścia iteracyjnego czyli ciągłego udoskonalania oprogramowania dzieki czemu stwierdzenie „working software” nabiera nowego, bogatszego znaczenia z każdą iteracją, co pan o tym sądzi?

    1. LukaszLukasz Autor wpisu

      Tak, trafił Pan w sedno sprawy. Pozwolę sobie poszerzyć Pana komentarz o „iteracyjnym podejściu”, o dodatkowy termin „inkrementacyjne” (t.j. przyrostowe ). Ciągłe udoskonalanie, rzeczywiście jest dokonywane w kolejnych iteracjach, aczkolwiek długość czy regularność iteracji nie jest czymś ustalonym globalnie dla Agile. Oczywiście takie metody jak SCRUM czy XP sugerują czas trwania kolejnych iteracji, ale jak już wspomniałem nie jest to reguła dla całego Agile. Z tego powodu wspomniałem o przyrostowym i iteracyjnym podejściu. Z doświadczenia wiem, że o wiele łatwiej jest motywować zespół i zaspokoić potrzeby klienta gdy przyjmie się jakąś stałą wartość kolejnego cyklu wytwórczego. Po każdym takim mniej lub bardziej formalnym okresie, klient ma możliwość dokonania subiektywnej oceny tego czy w jego mniemaniu to jest „working software” i czy coś się zmieniło od ostatniego razu. Podobnie jest z zespołem wytwórczym i jego motywacją. Jeśli przyjmiemy, że tylko iteracje lub tylko przyrost są fundamentem oceny ich zaangażowania to możemy dojść do paradoksalnych sytuacji, gdy zespół nie widzi postępów prac gdyż iteracje następują zbyt szybko po sobie i wartość dodana jest zbyt mała, lub gdy iteracje stają się tożsame z przyrostem co skutkuje oceną pracy w bardzo długich okresach czasu gdzie nie widać zaangażowania w poszczególnych etapach (np. jeśli nowe wydanie oprogramowania następuje co pół roku to iteracja i przyrost są mierzone w pół rocznych okresach, co sprawia że tak naprawdę oceniane są ostatnie tygodnie).

Dodaj komentarz