Jak pisaliśmy już w naszym Słowniku (kliknij) agile (z ang. zwinny) to sposób myślenia, filozofia życia, a także podejście do zarządzania oparte na hasłach takich jak: otwartość, dostosowywanie się, zaufanie, spójność, wsparcie i uczciwość.
Obecnie w biznesie agile i agility to słowa najczęściej kojarzące się z zarządzaniem projektami związanymi z nowymi technologiami. Stało się tak głównie za sprawą Manifestu Zwinnego Wytwarzania Oprogramowania (z ang. Manifesto for Agile Software Development) znanego bardziej pod nazwą Agile Manifesto. Dokument ten jest formą deklaracji zasad wspólnych dla zwinnych metodyk tworzenia oprogramowania i został opracowany w dniach 11-13 lutego 2001 roku w Snowbird w Stanach Zjednoczonych podczas spotkania, w którym uczestniczyło 17 reprezentantów nowego podejścia do rozwoju „software’u”. Byli to zwolennicy metodyk alternatywnych dla tych tradycyjnych opartych na tzw. modelu kaskadowym. Nowe zwinne podejście zostało oparte na iteracjach zamiast dostosowywania przygotowanych wcześniej planów i harmonogramów. Jego celem było zapewnienie rozwoju nowych produktów i usług w elastyczny sposób.
Twórcy Agile Manifesto podkreślili, że w wyniku swojej pracy, zaczęli cenić bardziej:
- 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.
Dokument składa się z 12 kluczowych dla zwinnego tworzenia oprogramowania założeń, które można znaleźć na agilemanifesto.org
Do metodyk zwinnych pod parasolem agile należą m.in: Dynamic Systems Development Method, Adaptive Software Development, Crystal Clear, Feature Driven Development, Pragmatic Programming, eXtreme Programmimg, Kanban.
Za jedną z najpopularniejszych metodyk uważany jest często Scrum, którego twórcy uciekają jednak od określenia „metoda” i definiują go jako framework, czyli pewien szkielet, ramy postępowania lub struktura umożliwiająca wytwarzanie wartościowych produktów poprzez zarządzanie procesami. Scrum nie narzuca żadnych konkretnych formuł lub technik wytwarzania oprogramowania (tak jak np. Extreme Programming). Znajduje on swoje zastosowanie podczas rozwijania „software’u”, ale pasuje również do innych kontekstów użycia.
Scrum nie jest jednak wcale podejściem „młodym”, gdyż ogólne jego założenia Hirotaka Takeuchi i Ikujiro Nonaka przedstawili już w 1986, a definicję w zastosowaniu do produkcji oprogramowania dookreślił i sformalizował Ken Schwaber w 1995.
Ramy Scrum zostały zbudowane z określonego zestawu podstawowych ról, wydarzeń i artefaktów. Zależności między nimi są określane przez podstawowe zasady spisane w aktualizowanym co jakiś czas Przewodniku po Scrum (ang. Scrum Guide – kliknij).
Role:
- Product Owner – „właściciel produktu”, który jest odpowiedzialny za podejmowanie decyzji w zakresie rozwoju produktu oraz wykorzystanie czasu Development Team w celu zbudowania jak największej wartości.
- Development Team – zespół deweloperski odpowiadający za zaplanowanie, organizację i wykonanie pracy.
- Scrum Master – osoba odpowiedzialna za wdrożenie Scrum, zrozumienie i przestrzeganie jego założeń oraz zasad. Wspiera zarówno Development Team (m.in. moderowanie spotkań, pomoc przy samoorganizacji i usuwanie przeszkód), jak i Product Ownera (np. w zarządzaniu Backlogiem).
Wszystkie powyżej wymienione role tworzą zespół Scrum, który powinien być współodpowiedzialny, międzyfunkcyjny i samoorganizujący się.
Wydarzenia:
- Sprint – iteracja (pętla czasowa) nie dłuższa niż jeden miesiąc kalendarzowy, w ramach której mieszczą się pozostałe wydarzenia. W trakcie sprintu Product Owner powinien cały czas pracować z Development Team nad jak najlepszym zrozumieniem wymagań nie ingerując jednocześnie w sposób ich wdrażania. Efektem każdego sprintu za każdym razem powinno być dostarczenie użytkownikom kolejnej działającej wersji produktu.
- Sprint Planning – określanie (na początku każdego Sprintu) najbardziej wartościowych „rzeczy do zrobienia” przez Development Team i estymowanie jak przebiegnie praca w ramach planowanej iteracji. Gdy sprint zostanie zaplanowany nie powinno się zmieniać jego zakresu.
- Daily Scrum – codzienne spotkania Development Team w celu sprawdzenia stanu realizacji pracy i podjęcia wspólnych decyzji, jakie kolejne działania powinny zostać podjęte danego dnia.
- Sprint Review – spotkanie podsumowujące (pod koniec Sprintu), na którym prezentowany jest wynik pracy zespołu, czyli prezentacja produktu wykonanego w ramach zakończonej właśnie iteracji. Na spotkaniu każdy członek Development Team może zabrać głos i wyrazić swoją opinię o produkcie.
- Sprint Retrospective – przyjrzenie się narzędziom, interakcjom, sposobom działania Development Team etc. podczas zakończonego właśni sprintu i stworzenie planu usprawnień na następny Sprint.
Artefakty:
- Product Backlog – lista rzeczy pozostających do zrobienia w ramach tworzenia danego produktu, jedyne miejsce, z którego Development Team bierze pracę. Product Backlog powinien być zawsze aktualny, żeby jasno pokazywać ile jeszcze jest rzeczy do zrobienia dla produktu.
- Sprint Backlog – lista rzeczy pozostających do zrobienia w bieżącym Sprincie. Tak jak Product Backlog, Sprint Backlog powinien również być zawsze aktualny, żeby jasno wskazywał postęp pracy nad produktem.
- Increment (przyrost) – suma wszystkich ukończonych podczas zakończonego właśnie Sprintu rzeczy (spisanych wcześniej w ramach Product Backlog) oraz wartość przyrostów wszystkich poprzednich Sprintów.
Podsumowując ogólny opis Scrum, warto odwołać się do słów autorów, którzy podkreślają, że korzystanie z tego podejścia jest darmowe, a opisane w Przewodniku zasady mogą stanowić również dobrą ramę dla innych technik, metodologii i praktyk.
