Metody agil'owe powstały jak odwrócenie sposobu myślenia, do metod kaskadowych. To co odniosło niesamowity sukces w fabrykach Forda, bardzo źle się sprawdza w przypadku produkcji oprogramowania. Znikoma liczba stałych elementów, "niewielka" modyfikacja przez klienta wymagań w czasie zaawansowanych pracy, albo niewykryty błąd projektowy, w jednym z modułów, często zmusza, do przeprojektowani całej architektury i wyrzuceniu dużej części tego co już stworzyliśmy. Agile to filozofia, która każe przyjąć pewien sposób myślenia: bądź otwarty na komunikację, pracę zespołową, samoorganizowanie, bądź otwarty na zmiany! Filozofia nie należy mylić ze sposobem postępowania.
Manifest Zwinnego Tworzenia Oprogramowania
* Ludzie i interakcje ponad procesami i narzędziami
* Działające produkty ponad złożoną dokumentację
* Współpraca z klientem ponad negocjacją kontraktu
* Reagowanie na zmiany ponad trzymaniem się planu
Filozofia Agile każe oswoić się ze zmiennymi wymaganiami klienta, bo każda zmiana jest dobra. Nie odbywa się to kosztem planu. Plan musi być dostosowywany za każdym razem do zmieniający się warunków środowiska.
Z filozofii Agile, wykuto kilka metod np.:
* Scrum (młyn w rugby) - metoda zarządzani projektami (nie tylko informatycznymi - scrum nie opisuje procesu wytwarzania oprogramowania, dlatego jest dopełniana czymś innym np. Extreme Programming)
* Extreme Programming (często stanowi dopełnienie metody Scrum), oparte na 4 wartościach: komunikacja, postacie, informacje zwrotna, odwaga.
* inne
Największą popularność zdobywa ostatnio Scrum:
- stawia na samoorganizację zespołów.
- "Sprint" - realizacja projektu w krótkich iteracjach (2 do 4 tyg. maks), wszystkie sprinty powinny mieć stałą długość
- "Daily Scrums" codzienne 15 minutowe spotkanie projektowe, gdzie każdy ma dać odpowiedź na pytania
* co robiłem wczoraj
* co będę robił dzisiaj
* czy występują problemy blokujące dalszą pracę
- spotkanie planistyczne na początku każdej iteracji
- prezentacja wyników iteracji wszystkim zainteresowanym
- podsumowanie przebiegu prac iteracji
Scrum definiuje także kilka ról projektowych:
- Scrum Master - (Mistrz Młyna) - trener, pomagający członkom zespołu w osiągnięciu najlepszej wydajności
- Product Owner - właściciel produktu, reprezentuje biznes, klientów lub użytkowników, pomaga zrozumieć ich punkt widzenia
- The Team - samoorganizujacy się zespół (5-9 osób)
Wzniosłe idee, ale całej tej filozofii, zagrażają całkiem ludzkie przywary.
Cała drużyna pracuje nad wspólnym sukcesem. W zespole wszyscy mają być równi, nie można dopuścić by jednostki dominujące, próbowały wpływać/dodawać nieformalnej roboty, jednostkom słabszym. To samo tyczy się wojen programista vs tester. Spóźnienia, absencje, żarty, monologi, podczas "Daily Scrums" wpływają na obniżenie morale w całym zespole. Preferowana jest komunikacja werbalna ponad formalną, a z lenistwa, ktoś może odmówić, jeżeli nie będzie miał czegoś na papierze.
Jeżeli w zespole, będzie zdrowa i otwarta komunikacja, sami się przekonamy, że mamy tam ludzi pełnych energii i chęci życia. Aj hołp.
