Temat Agile software development (zwinne programowanie) Grupa ekspertów,zajmujących się programowaniem, zaniepokojona obserwowanymi zjawiskami, stworzyła zrzeszenie o nazwie Agile Alliance (2001 rok). Jej celem było popularyzowanie szybkiego i elastycznego wytwarzania oprogramowania. Po kilku miesiącach grupa ta wydała dokument pt The Manifesto of the Agile Alliance wskazujący możliwości rozwiązania niektórych problemów: Programiści i ich harmonijna współpraca jest ważniejsza od procesów i narzędzi Wyspecjalizowani ludzie są tu najważniejszym czynnikiem, żaden, nawet najlepszy proces nie uchroni przed porażką, jeśli danemu zespołowi nie można zaufać. Patrząc z drugiej strony, zły proces może spowodować porażkę nawet najlepszego zespołu. Członkiem zespołu nie musi być wybitny programista, tylko osoba posiadająca przeciętną zdolność programowania i zdolność współpracy z pozostałymi osobami z zespołu. Umiejętność komunikacji jest ważniejsza od talentów programistycznych. Wynika to z tego, że przeciętni programiści, którzy dobrze ze sobą komunikują mają większe prawdopodobieństwo odniesienia sukcesu niż grupa złożona z samych geniuszy nie potrafiących się ze sobą porozumiewać. Dobrze dobrane narzędzia maja wpływ tylko na ostateczny efekt realizacji danego projektu. Kompilatory, IDE, systemy kontroli wersji są kluczowymi narzędziami, które decydują o funkcjonowaniu zespołu programistów. Nie należy przeceniać roli oprogramowania. Nadmierna wiara w nie może tylko doprowadzić do fatalnych skutków, które można tylko porównać z ich brakiem. Na początku powinno się używać tylko prostych narzędzi, błędne jest myślenie, że bardzie rozbudowane i zaawansowane narzędzia będą lepsze od prostych. Na samym początku lepiej jest korzystać z darmowych systemów kontroli wersji, aż do czasu gdy wyczerpią się oferowane przez nich możliwości. Następnym przykładem jest używanie na samym początku tablic i kartek papieru aż do momentu, gdy nie będzie nam to wystarczać, możemy pomyśleć o zakupie pakietu CASE. Tak samo postępujemy w przypadku, gdy chcemy zakupić system do zarządzania bazą danych. Najpierw sprawdzamy czynie wystarczą nam zwykłe pliki. Nigdy nie powinniśmy zakładać, że większe, lepsze i droższe narzędzia, systemy, będą lepiej odpowiadały naszym potrzebom. Zazwyczaj większość z nich tylko utrudni nam pracę. Warto zapamiętać, że budowa zespołu jest ważniejsza od budowy środowiska. Wiele osób popełnia ten błąd. W pierwszej kolejności budują środowiska, a dopiero później zespół, mając nadzieję, że uda się wokół niego zgrać poszczególne osoby. Lepszym rozwiązaniem jest budowa zespołu i pozwolenie mu na organizację środowiska, które jemu odpowiada. Działające oprogramowanie jest ważniejsze od wyczerpującej dokumentacji. Kod źródłowy nie jest idealnym środkiem komunikacji. O wiele lepszym sposobem będzie uzasadnienie podejmowanych przez zespół decyzji w formie dokumentu. Trzeba pamiętać o tym, że za duża dokumentacja jest nawet gorsza od bardzo skromnej dokumentacji. Wytworzenie wielkich dokumentów pochłania olbrzymi nakład czasowy jak i pieniężny a w skrajnych przypadkach niemożliwa synchronizacji dokumentu z kodem. Dokumentacja, która jest niezgodna z kodem, jest niczym więcej niż wielkim zbiorem kłamstw, prowadzącym do nieporozumień. Rozwiązaniem tego problemu jest pisanie i utrzymywanie przez zespół krótkiego dokumentu, który uzasadniałby podjęte
decyzje i opisywałby strukturę systemu. Powinien być krótki i opisywać projekt ogólnie. Maksymalnie łby zawierać 20 stron i dotyczyć tylko najważniejszych decyzji projektowych i opisywać strukturę systemu na najwyższym poziomie. W przypadku dołączenia nowych osób do projektu, mając tylko krótka dokumentację, nie powinno się jej przekazywać nowym osobom do zapoznania. Transfer wiedzy o systemie musi polegać na wielogodzinnej i żmudnej pomocy nowemu programiście. Dzięki bliskiej współpracy możemy z niego uczynić pełnowartościowego członka zespołu. Najlepszym sposobem przekazania informacji jest kod źródłowy i sam zespół. Kod nigdy nie będzie sprzeczny ze swoim działaniem. Z drugiej strony mimo, że precyzyjnie określone funkcjonowanie systemu na podstawie samego kodu źródłowego może być trudne, to właśnie kod jest jedynym źródłem informacji. Cały zespół utrzymuje swoista mapę drogową stale modyfikowanego systemu. Wiele zespołów wpadło w pułapkę w pogoni za doskonałą dokumentacją, zapominając o właściwym programowaniu. Nie trzeba przedstawiać do czego takie podejście doprowadzi. Można tego uniknąć stosując następującą regułę: Nie pracuj nad żadnymi dokumentami, chyba, że w danym momencie bardzo ich potrzebujesz. Faktyczna współpraca z klientem jest ważniejsza od negocjacji zasad kontraktu. Oprogramowania nie można zamawiać jak towar w sklepie. Opisanie potrzebnego oprogramowania i szukanie kogoś kto za ustalona cenę i termin go wykona jest po prostu niemożliwe. Wiele projektów informatycznych przez takie postępowanie poległo. Bardzo często zdarza się, że kadra menadżerska chce tylko dwa razy spotkać się z zespołem programistycznym: pierwszego spotkania i drugiego, w którym oczekuję gotowego systemu(oczywiście zgodnego z oczekiwaniami zamawiającego klienta). W wyniku takiego podejścia produkt będzie fatalnej jakości albo zakończy się klęską. Wynikiem warunkującym sukces jest stała współpraca z klientem, w formie regularnych spotkań, w formie regularnych spotkań. Zespół programistów zamiast opierać się na kontrakcie, może współpracować z klientem, aby obie strony stale miały świadomość wzajemnych potrzeb i ograniczeń. Kontrakt zawierający wymagania, harmonogram i koszty tworzonego systemu od samego początku zawiera błędy. Zazwyczaj takie zapisy są już nieaktualne w czasie jego podpisywania. Najlepszą formą kontraktu jest taki, który przewiduje współpracę programistów i klientów. Dobrym sposobem jest podzielenie projektu na funkcjonalne bloki, które po ukończeniu są przekazywane klientowi do oceny. W przypadku potrzebnych zmian, wspólnie nadajemy priorytet tym modyfikacjom. Kluczem do sukcesu jest intensywna współpraca z klientem i zapisy kontraktu które nie definiowały szczegółowego zakresu, harmonogramu, ani kosztów, tylko regulowały zasady współpracy wykonawcy ze zleceniodawcą. Reagowanie na zmiany jest ważniejsze od konsekwentnego realizowania planu. O sukcesie bądź porażce de4cyduje zdolność częstego i szybkiego reagowania na zmiany. Tworząc plan realizacji projektu, powinniśmy się upewnić, że harmonogram umożliwia wprowadzanie zmian(zarówno technologicznych jak i biznesowych). Projektu informatycznego nie uda się
zaplanować szczegółowo. Trzeba liczyć się ze zmianą otoczenia biznesowego, które wpłynie na stawiane wymagania. Oprócz tego możemy być pewni, że kiedy system zacznie działać, to klienci zaczną wspominać o zmianach dotyczących wymagań. Nawet gdybyśmy mieli 100% pewność, że wymagania się nie zmienią, to i tak nie jesteśmy w stanie oszacować czasu ich realizacji. Niektórzy menadżerowie nanoszą projekt na arkusze papieru, które później rozklejają na ścianach. W ten sposób można łatwo śledzić wybrane zadania, wykreślać wykonane, obserwować daty realizacji zadań, a także reagować na odstępstwa w harmonogramie. Mimo przytaczanych zalet jest też i wada: Taka struktura szybko się zdezaktualizuje. Wraz ze wzrostem wiedzy zespołu dotyczącej budowanego systemu, rośnie także wiedza klienta o potrzebach samego zespołu, a część zadań staje się po prostu zbędna. W tym czasie można odkryć inne zadania, których zabrakło w schemacie i należy je dodać. Zmianie więc ulega nie tylko zadania ale także czas ich realizacji. O wiele lepszym rozwiązaniem jest tworzenie szczegółowych harmonogramów na następny tydzień i bardzo ogólnych planów na przyszłość. Zatem powinniśmy dokładnie wiedzieć o stawianych wymaganiach jakie będziemy, realizować w najbliższym tygodniu, szkice wymagań jakie będą realizowane w ciągu kilku miesięcy oraz mieć zarys o tworzonym systemie. Dzięki temu podejściu, więcej czasu poświęcamy na szczegółowe opisanie zadań, które będą realizowane w najbliższym czasie. Modyfikowanie raz opracowanego, szczegółowego planu jest trudne, bo w jego tworzeniu i zatwierdzaniu był zaangażowany cały zespół. Ponieważ taki plan dotyczy tylko najbliższego tygodnia, pozostałe zadania są elastyczne. Podstawowe zasady: 1.Jak najszybsze spełnienie oczekiwań klienta poprzez wczesne dostarczanie działającego oprogramowania. Im mniej funkcjonalny będzie początkowy dostarczony fragment systemu, tym wyższa będzie jakość wersji końcowej. Im częściej przekazujemy klientowi gotowy fragment funkcjonalności, tym wyższa będzie jakość produktu końcowego. W podejściu programowania zwinnego wymaga się wczesne i częste dostarczanie fragmentów programu. Od czasu przekazania pierwszej skromnej wersji oprogramowania, powinniśmy co kilka tygodni dostarczać klientowi coraz bardziej funkcjonalne warianty. W tym czasie możemy także otrzymywać wykaz oczekiwanych zmian. 2.Traktujmy zmiany wymagań ze zrozumieniem nawet jeśli następują w późnych fazach wytwarzania oprogramowania. W tym podejściu programowania następują zmiany wraz ze zmieniającym się uwarunkowaniami biznesowymi, w której funkcjonuje strona zamawiająca. Uczestnicy procesów zwinnych nie powinni obawiać się zmian, ponieważ prowadzą one do lepszego zrozumienia oczekiwań klienta. Zespół powinien utrzymywać i przeznaczać czas na elastyczną strukturę oprogramowania, dzięki której można zniwelować wpływ zmian wymagań na kształt budowanego systemu. 3.Działające oprogramowanie należy dostarczać klientowi możliwie często. Powinno się jak to tylko możliwe przekazywać klientowi pierwszą wersję przygotowanego oprogramowania i kontynuować ten proces na wszystkich etapach realizacji projektu. Nie wystarcza przekazanie tylko dokumentacji. Żaden dokument nie zastąpi, nawet cząstkowej funkcjonalności
systemu. Przecież ostatecznym celem jest dostarczenie oprogramowania które spełnia oczekiwania klienta. 4.Ludzie biznesu powinni ściśle współpracować z programistami na wszystkich etapach projektu. Warunkiem zwinności projektu jest częsta współpraca klientów, programistów ośrodków biznesowych zaangażowanych w finansowanie. W tym podejściu projekty muszą być stale kierowane. 5.Projekty należy planować wokół dobrze umotywowanych programistów. Należy im zorganizować niezbędne środowisko pracy, a także obdarzyć ich potrzebny, zaufaniem. To ludzie są najważniejszym czynnikiem, który decyduje o sukcesie, inne czynniki(środowiska i sposób zarządzania) maja drugorzędne znaczenie i są dostosowywane do potrzeb ludzi będących w zespole. 6.Najlepszą metodą do przekazywania informacji ( w obie strony) jest rozmowa w cztery oczy. W programowaniu zwinnym projekt podlegają na rozmowach prowadzonych członków zespołu. Zazwyczaj wystarczają bezpośrednie kontakty programistów, ewentualnie można spisać dokumenty i aktualizować je równolegle do rozmów. 7. Podstawowym miernikiem postępu prac nad projektem jest ilość i jakość działającego oprogramowania. Czyli miarę oprogramowania jest ilość zatwierdzonych przez klienta fragmentów systemu. O postępie możemy mówić, tylko wtedy, gdy funkcjonalność działa i spotyka się z akceptacją ze strony klienta. 8. Procesy zwinne ułatwiają utrzymywanie ciągłości wytwarzania Programiści powinni utrzymywać wysoką ale stałą szybkość pracy, zamiast od razu próbować osiągnąć maksymalną wydajność. Narzucenie zbyt wysokiego tempa spowoduje wypalenie psychiczne, a nawet upadek projektu. Stale tempo pracy umożliwia realizację najwyższej jakości standardów przez cały okres. 9. Pozytywny wpływ na zwinność projektu ma stałą dbałość o doskonałość techniczną i właściwy projekt. Wysoką jakość jest kluczem do dużej wydajności. Można to uzyskać poprzez przemyślaną i prostą strukturę oprogramowania. Wszyscy powinni koncentrować się na tworzeniu najwyższej jakości, na jakie pozwalają im umiejętności. Powinno eliminować źródła potencjalnych opóźnień w zarodku. 10. Kluczowym elementem pomyślnego zakończenia projekt jest prostata, czyli sztuka maksymalizacji ilości pracy, której nie wykonujemy. Staranie dochodzenia do celu możliwie najkrótszą drogą. 11.Źródłem najlepszych architektur, specyfikacji wymagań i projektów są zespoły, którym dano wolną rękę w zakresie organizacji.
Programiści powinni sami organizować swoja pracę. Odpowiedzialność za poszczególne zadania nie powinna być przydzielana wybranym członkom zespołu, tylko powinna być komunikowana całemu zespołowi. Sam zespół powinien decydować jak te zadania najefektywniej zrealizować. Członkowie zwinnego zespołu wspólnie pracują nad aspektami zleconego produktu, zaś każdy członek musi mieć możliwość wpływania na sposób realizacji., 12. W stałych odstępach czasu zespół zaangażowany w tworzenie oprogramowania powinien analizować możliwość usprawnienia pracy i dopasowywać swoje dalsze działania do wniosków płynących z tej analizy. Taki zespół cały czas udoskonala swoją organizację, reguły. Członkowie zdają sobie sprawę że środowisko, w którym pracuje ciągle się zmienia i wiedzą że ich zwinność w dużej mierze zależy od zdolności dostosowania się do tych zmian.