Na czym polega bycie zwinnym?

[Bycie zwinnym oznacza] umiejętne dostosowanie się do nowych okoliczności. / Tom Gib

  Zwinności nie tworzymy: albo jesteśmy zwinni, albo nie. Podstawą metodyk Agile są pętle sprzężenia zwrotnego. Im krótsza i szybsza jest taka pętla, tym bardziej zwinni możemy być. Gdy otrzymujemy informację zwrotną, możemy na nią zareagować i właśnie ten akt reakcji (albo jej braku) jest tym, co czyni nas bardziej (lub mniej) zwinnymi. Zawężanie pętli sprzężenia zwrotnego ułatwia szybsze dostrzeżenie problemu i przystąpienie do jego analizy. Agile nie rozwiązuje problemów, a tylko je wskazuje. Im szybciej zaprezentujemy użytkownikowi ekran lub funkcję aplikacji, tym wcześniej uzyskamy opinię na temat tego elementu. Używam tu terminu użytkownik jako pojęcia ogólnego. Może to być właściciel produktu, sponsor lub użytkownik docelowy. Pozyskiwanie informacji zwrotnych z wielu źródeł jest niezwykle istotne. Pewność co do komercyjnej wartości tego, co robimy, pomaga w minimalizowaniu ryzyka inwestycyjnego.   Przełom Idea Agile wywołała olbrzymi postęp w naszej branży. Bardzo szybko spotkała się z niemal powszechną akceptacją. Szybkie tempo zmian w nowoczesnym oprogramowaniu było frustrujące i kosztowne. Zwinność była lekarstwem na tę bolączkę. Zmienił się sposób myślenia. Tam, gdzie przedtem były sterty dokumentów, ustalone z góry szczegóły projektu (ang. Big Design Up Front — BDUF) i biurokracja, teraz mamy działające już od pierwszego tygodnia oprogramowanie. Przedtem reagowaliśmy na zmiany, teraz je uwzględniamy. Agile kompletnie zmieniło nasz styl pracy. Stare, hierarchiczne i bardzo sztywne podziały pracy w ramach zespołu realizującego projekt zaczęły zanikać. Profesjonalni twórcy oprogramowania uświadomili sobie, że pisanie kodu to tylko jedna z dziedzin, które powinni dobrze opanować. Deweloperzy, przedtem tylko realizujący plan, w końcu zrozumieli, jak ważne jest ich zaangażowanie w biznesową stronę projektu i dostarczanie klientowi dokładnie tego, czego ten oczekuje. Przełomem było uświadomienie sobie przez wszystkich, że to cały zespół odpowiada za wszystkie aspekty realizowanego projektu. Profesjonaliści od programowania zaczęli poszerzać swoją wiedzę i umiejętności. Zamiast ograniczać się jedynie do wypełniania kodem planu opracowanego (często błędnie) przez kogoś innego, deweloperzy zaczęli brać aktywny udział w pracach związanych z planowaniem, estymacją, opracowaniem wymagań, organizacją zespołu, analizą, architekturą, gotowością produkcyjną, ustalaniem priorytetów, prezentacjami i regularnym odbieraniem informacji zwrotnych od użytkowników i interesariuszy.   Poszerzanie kompetencji Hierarchia zespołu tworzącego oprogramowanie stała się płaska. Nie ma już kierowników zespołu ani podziału obowiązków. Zamiast kierownictwa przydzielającego poszczególnym pracownikom zadania i określającego terminy ich wykonania mamy teraz rejestr zadań z priorytetami ustalanymi przez właściciela produktu w porozumieniu z zespołem. Zgodnie z tymi priorytetami zespół decyduje, które zadanie należy wykonać jako następne, kto je będzie wykonywał i jak długo będzie to trwało. Wszystko to dzieje się w ramach procesu iteracyjnego, w którym pętla sprzężenia zwrotnego dla wszystkich zainteresowanych jest taka sama.   Ewolucja profesjonalizmu Aby dostosować się do nowego stylu pracy, profesjonalni programiści musieli się poddać procesowi ewolucji. Firmy przestały zatrudniać profesjonalistów o wąskich specjalizacjach, a zaczęły się rozglądać za fachowcami o szerokim spektrum umiejętności. Sprawne pisanie kodu to obecnie minimum, jakim powinien się wykazać profesjonalny twórca oprogramowania. Teraz wymaga się także umiejętności testowania aplikacji, przeprowadzania analiz, rozumienia biznesu, łatwego komunikowania się z innymi ludźmi i ekstrawertycznej osobowości.   Manifest Agile Poniżej przytaczam Manifest Agile w formie, w jakiej został opublikowany w internecie[1].  

Odkrywamy nowe metody programowania dzięki praktyce w programowaniu i wspieraniu w nim innych. W wyniku naszej pracy zaczęliśmy bardziej cenić:      ludzi i interakcje od procesów i narzędzi,      działające oprogramowanie od szczegółowej dokumentacji,      współpracę z klientem od negocjacji umów,      reagowanie na zmiany od realizacji założonego planu. Oznacza to, że elementy wypisane po prawej są wartościowe, ale większą wartość mają dla nas te, które wypisano po lewej.

  Poza manifestem jego twórcy ogłosili także dwanaście zasad zwinności.   Zasady uzupełniające Manifest Agile Dwanaście zasad programowania zwinnego brzmi następująco[2]:

  1. Najwyższy priorytet ma dla nas zadowolenie klienta dzięki wczesnemu i ciągłemu wdrażaniu wartościowego oprogramowania.
  2. Bądźcie gotowi na zmiany wymagań nawet na późnym etapie jego rozwoju. Procesy zwinne wykorzystują zmiany dla zapewnienia klientowi konkurencyjności.
  3. Dostarczajcie funkcjonujące oprogramowanie często, w kilkutygodniowych lub kilkumiesięcznych odstępach. Im częściej, tym lepiej.
  4. Zespoły biznesowe i deweloperskie muszą ściśle ze sobą współpracować w codziennej pracy przez cały czas trwania projektu.
  5. Twórzcie projekty wokół zmotywowanych ludzi. Zapewnijcie im potrzebne środowisko oraz wsparcie i zaufajcie, że wykonają powierzone zadanie.
  6. Najbardziej efektywnym i wydajnym sposobem przekazywania informacji zespołowi deweloperskiemu i wewnątrz niego jest rozmowa twarzą w twarz.
  7. Działające oprogramowanie jest podstawową miarą postępu.
  8. Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy.
  9. Ciągłe skupienie na technicznej doskonałości i dobrym projektowaniu zwiększa zwinność.
  10. Prostota — sztuka minimalizowania ilości koniecznej pracy — jest kluczowa.
  11. Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów.
  12. W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.

  Czas wdrażania zasad Agile Ogłoszenie manifestu i zasad Agile wywołało prawdziwą rewolucję w branży informatycznej — jedna po drugiej firmy zaczęły wchodzić w nową rzeczywistość. Firmy konsultingowe, a także doradcy indywidualni zaczęli się specjalizować w pomaganiu firmom pragnącym zaistnieć w świecie Agile. Powstała nowa profesja Agile coachingu. Agile coach przychodzi do firmy, analizuje jej problemy, procesy i zasoby ludzkie, a następnie wskazuje, co należy zrobić, aby funkcjonować w sposób zwinniejszy. Firmy zaczęły rozumieć, co jest powodem ich niskiej efektywności.   - - - A Wy jak podchodzicie do zasad manifestu? Realizujecie w pracy zasady Agile i czujecie się rzemieślnikami?   - - - [1]Przytoczona treść manifestu pochodzi z serwisu agilemanifesto.org — przyp. tłum. [2] Zasady te zostały opublikowane w serwisie agilemanifesto.org — przyp. tłum. - - - Tekst stanowi fragment książki "Software Craftsman. Profesjonalizm, czysty kod i techniczna perfekcja" Sandro Mancuso (Wyd. Helion 2016).