Wodospadowy model wytwarzania oprogramowania zakłada długą
advertisement
Temat : zwinne programowanie - Agile software development Programowanie zwinne – grupa metodyk wytwarzania oprogramowania opartego na programowaniu iteracyjno-przyrostowym. Wymagania oraz rozwiązania ewoluują przy współpracy samozarządzalnych zespołów, których celem jest przeprowadzanie procesów wytwarzania oprogramowania. Pojęcie zwinnego programowania zostało zaproponowane w 2001 w Agile Manifesto. Metodyka i Ogólna informacja na temat zespołów Generalnie metodyka oparta jest na zdyscyplinowanym zarządzaniu projektem, które zakłada częste inspekcje wymagań i rozwiązań wraz z procesami adaptacji zarówno specyfikacji jak i oprogramowania. Metodyka ta najczęściej znajduje zastosowanie w małych zespołach programistycznych, w których nie występuje problem komunikacji, przez co nie trzeba tworzyć rozbudowanej dokumentacji kodu. Kolejne etapy wytwarzania oprogramowania zamknięte są w iteracjach, w których za każdym razem przeprowadza się testowanie wytworzonego kodu, zebranie wymagań, planowanie rozwiązań itd. Metoda nastawiona jest na szybkie wytwarzanie oprogramowania wysokiej jakości. Skład zespołów jest zazwyczaj wielofunkcyjny oraz samozarządzalny, bez zastosowania jakiejkolwiek hierarchii korporacyjnej. Członkowie zespołu biorą odpowiedzialność za zadania postawione w każdej iteracji. Sami decydują jak osiągnąć postawione cele. Metoda nastawiona jest na bezpośrednią komunikację pomiędzy członkami zespołu, minimalizując potrzebę tworzenia dokumentacji. Jeśli członkowie zespołu są w różnych lokalizacjach, to planuje się codzienne kontakty za pośrednictwem dostępnych kanałów komunikacji wideokonferencja, e-mail itp. Ciekawostka Warto dodać, że bez względu na wymaganą dyscyplinę rozwoju każdy zespół Agile musi posiadać w swoim składzie przedstawiciela klienta. Osoba ta jest powoływana przez zainteresowane strony do działania w ich imieniu i sprawia, że są oni jakby osobiście zaangażowani i są dostępni dla programistów, aby odpowiedzieć na mnożące się w trakcie iteracji pytania. Na końcu każdej iteracji, interesariusze oraz przedstawiciele klienta dokonują przeglądu postępów oraz ponowną ocenę priorytetów w celu optymalizacji tzw. zwrotu z inwestycji (ROI) i zapewniają dostosowanie do potrzeb klientów i celów firmy. Cele jakie spełniają zwinne metodyki Główne cele i zasady, jakie spełniają zwinne metodyki zostały spisane Manifeście Agile, który uważany jest obecnie za główne źródło wiedzy. Poniżej prezentujemy kompilację głównych celów i zasad przyświecająca stosowaniu zwinnych metodyk w ramach zarządzania projektami: tworzenie wartościowych i innowacyjnych rozwiązań zarówno dla firmy jak i konsumentów na każdym etapie projektowania; minimalizacja kosztów m.in. dzięki skróceniu harmonogramów procesu wytwarzania; koncentracja na członkach zespołu projektowego, wzrost motywacji wśród pracowników i bezstresowa realizacja projektów; ścisła współpraca z klientem - preferowany jest kontakt bezpośredni; prostota i samo-organizujące się zespoły; satysfakcja klientów dzięki szybkiemu i regularnemu dostarczaniu wartościowego produktu; minimalizacja ryzyka. Współpraca z klientem ponad negocjowanie kontraktów W klasycznym podejściu kontakt z klientem docelowym następuje na początku i na końcu cyklu wytwarzania oprogramowania. Zakłada się, że na początku zbiera się wymagania klienta, które pozostają niezmienne aż do samego końca. Natomiast na końcu projektu następuje walidacja wytworzonego oprogramowania. Niestety świat, a tym bardziej świat oprogramowania nie jest statyczny i w ciągu trwania projektu klient często zmienia swoje wymagania. Źródłem zmiany wymagań klienta jest potrzeba adaptacji do zmian w jego środowisko, np.: wejście w życie nowej ustawy, wdrożenie nowego systemu lub procesu... W efekcie końcowym okazuje się, że wytworzone oprogramowanie nie spełnia, częściowo lub w całości "nowych" wymagań klienta. Ponadto okazuje się, że część funkcjonalności, która na początku wydawała się ważna przestała być potrzebna. Wszystko to prowadzi do renegocjacji kontraktu lub dodatkowych zobowiązań ze strony wytwórcy oprogramowania celem utrzymania dobrych stosunków z klientem, co z kolei odbija się na budżetach wytwórcy oprogramowania jak i klienta. Zwinne metodologie bazują na zaangażowaniu i ciągłej współpracy z klientem oraz walidacji jego wymagań w czasie trwania projektu. Ma to na celu wyeliminowanie nieaktualnych, bądź mało istotnych wymagań przy jednoczesnym utrzymaniu budżetu projektu. Ciągła współpraca z klientem realizowana jest poprzez dostarczanie klientowi w regularnych odstępach czasu działającego oprogramowania zawierającego najbardziej wymagane funkcjonalności, a następnie analizowaniu informacji zwrotnej w celu aktualizacji priorytetów na liście pozostałych wymagań. Jednym ze sposobów dostarczenia oprogramowania klientowi jest przeprowadzenie dema najnowszej funkcjonalności lub wdrożenie jej bezpośrednio u klienta. Aby dostarczać działające oprogramowanie zawierające najbardziej wymagane funkcjonalności w regularnych odstępach czasu, zwinne metodologie zalecają implementowanie nowych funkcjonalności w stałych odstępach czasowych trwających od 1 do 4 tygodni (iteracje) oraz integrowanie ich z funkcjonalnościami poprzednio stworzonymi inkrementacje. Reakcja na zmianę O sukcesie bądź porażce decyduje 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. Najbardziej popularne odmiany zwinnych metodologii SCRUM Extreme Programming (XP) Feature Driven Development (FDD) Lean Software Development Rational Unified Process Crystal Dynamic Systems Development Method (DSDM) Działające oprogramowanie ponad obszerną dokumentację Wodospadowy model wytwarzania oprogramowania zakłada długą fazę analizy wymagań oraz projektowania całości systemu, która owocuje dużą ilością dokumentacji opisującą implementację w bardzo szczegółowy sposób. Niestety, na etapie planowania bardzo często umysł ludzki nie jest w stanie ogarnąć wszystkich aspektów złożoności oprogramowania jak i ograniczeń wybranej technologii. Kiedy przychodzi do fazy wytwarzania oprogramowania okazuje się, że cześć udokumentowanego projektu jest niemożliwa, bądź bardzo trudna do implementacji, co wymusza zmiany zarówno w projekcie, jak i w istniejącej już dokumentacji, co z kolei powoduje dodatkowy narzut czasowy. Dodatkowo, zazwyczaj zmiany architektury projektu w jednym miejscu pociągają za sobą zmiany w innej, zależnej części. To z kolei sprawia, że czas potrzebny na aktualizację dokumentacji znacząco się wydłuża. Ostatecznie okazuje się, że nie jesteśmy w stanie odzwierciedlić w dokumentacji wszystkich zmian architektonicznych, co czyni ją nieaktualną, a czas poświęcony na szczegółowe projektowanie jest czasem zmarnowanym nie mamy ani aktualnej dokumentacji ani działającego kodu. Zasady: 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. 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. 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. Ludzie biznesu powinni ściśle współpracować z programistami na wszystkich etapach projektu. 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. 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. 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. 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. 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. 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ą. Podsumowanie : Faza określania wymagań jest niezwykle istotnym elementem procesu tworzenia oprogramowania i żadna z metodologii rozwijania oprogramowania jej nie pomija, Różne metodologie różnie podchodzą do określania wymagań, zwłaszcza jeśli chodzi o formalizację procesu odkrywania i specyfikacji wymagań oraz o sposób dokumentacji wymagań. Wybór podejścia do określania wymagań powinien zależeć od charakteru projektu czy system jest mały, średni czy duży, czy jest tworzony przez różne firmy na podstawie jednego lub wielu kontraktów, czy musi gwarantować wysoki poziom niezawodności i bezpieczeństwa.
