Temat Agile software development (zwinne programowanie) Grupa

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.