W ostatnich latach, szczególnie w branży IT wśród firm zajmujących się produkcją oprogramowania, rośnie popularność innych niż tradycyjne, oparte o fazowy model realizacji projektu, metod realizacji prac programistycznych oraz zarządzania takim projektem. Te inne metody określane są zwykle mianem metod "lekkich" lub "zwinnych", określanych angielskim terminem: agile development lub agile project management (APM).

Powstanie tych metod związane jest z ciągle powtarzającymi się problemami w projektach produkcji oprogramowania: niedotrzymywaniem zakresu – planowanej funkcjonalności systemu, opóźnieniami w realizacji produktu, czy też niezadowoleniem klientów. Poszukiwania rozwiązania tego problemu wskazały na iteracyjne oraz inkrementacyjne podejście do tworzenia produktu oraz na nieco inne podejście do niektórych zagadnień zarządzania projektem. Znalazły one następnie odzwierciedlenie w deklaracji programowej twórców tych metod, nazwanej Manifestem Agile (Manifesto for Agile Software Development, 2001). Manifest ten jest skrótowym opisem celu dla którego metody te zostały stworzone.

Manifest Zwinnego (Agile) Tworzenia Oprogramowania stwierdza, co następuje: "Odkrywamy coraz to lepsze sposoby tworzenia oprogramowania, robiąc to i pomagając innym to robić. W tej pracy zaczęliśmy szczególnie cenić:
•    Ludzi i ich wzajemne interakcje ponad procedury i narzędzia
•    Działające oprogramowanie ponad wyczerpującą dokumentację
•    Współpracę z klientem ponad negocjowanie kontraktów
•    Reagowanie na zmiany ponad trzymanie się planu.
Doceniamy wagę elementów z prawej strony, jednak te po lewej cenimy bardziej".

Najbardziej znane metody "lekkie" to: SCRUM, eXtreme Programming (XP), Feature Driven Development, Rational Unfied Process (RUP), czy Adaptive Software Development. Nie są to metodyki zarządzania projektami, gdyż bardziej przypominają one opis cyklu życia projektu, zwłaszcza cykl życia projektu wytwarzania oprogramowania SDLC – Software Development Lifecycle. Extreme Programming (XP) jest zbiorem praktyk, które układają się w iteracyjny cykl życia projektu. SCRUM natomiast to raczej zbiór generalnych zasad zarządzania tworzeniem produktu. Metody te mogą być jednak wykorzystane do zarządzania projektem, jako zbiór zarówno generalnych, jak i szczegółowych zasad i praktyk.

Te główne, generalne zasady wykorzystywane w Agile Project Management to:

• Silny akcent na zwrot z inwestycji, dostarczanie wartości projektu nie w sposób jednorazowy, lecz poprzez kolejne produkty cząstkowe (czyli w sposób inkrementacyjny) oraz myślenie wszystkich uczestników projektu zorientowane na własności produktu, dostarczające korzyści organizacji
• Dostarczanie oczekiwanych produktów dzięki silnemu zaangażowaniu klienta we współpracę z zespołem projektowym, częste interakcje z klientem, a tym samym uczynienie klienta właścicielem produktu
• Akceptacja istnienia niepewności oraz zarządzanie tą niepewnością poprzez stosowanie iteracji, przewidywania oraz adaptacji
• Wykorzystywanie kreatywności i innowacyjności poszczególnych członków zespołu, dzięki stworzeniu środowiska sprzyjającego takim postawom
• Podniesienie efektywności prac projektowych dzięki przeniesieniu odpowiedzialności za rezultaty projektu na zespół projektowy, kierownik projektu fasylitatorem i moderatorem

No dobrze, a szczegółowe metody i rozwiązania? Takie, które mogą być wykorzystywane w praktyce projektowej? Poniżej znajdziecie kilka podstawowych metod i podejść stosowanych do zarządzania projektem w metodzie SCRUM:

• Interdyscyplinarny, 5-9 osobowy, w praktyce samo-zarządzający się zespół, którego członkowie zaangażowani w projekt na 100% z tzw. Scrum Masterem, którego głównym zadaniem jest usuwanie przeszkód w pracy zespołu, a nie typowe zadania kierownika projektu, współpracujący bardzo aktywnie z właścicielem produktu (ang. Product owner), reprezentującym klienta i zapewniającym że zespół pracuje z uwzględnieniem perspektywy biznesowej projektu
• Podział projektu na tzw. przebiegi (ang. Sprint) – podstawowe jednostki pracy zespołu, a jednocześnie jednostki projektu - zwykle 4-6 tygodniowe, które mają dostarczyć użytkownikowi kolejną działającą wersję produktu
• Rejestr wymagań produktu (ang. Product backlog), zawierający spriorytetyzowaną przez zamawiającego listę wymagań, plan wydań (ang. Release plan), będący odpowiednikiem tradycyjnego harmonogramu oraz rejestr zadań przebiegu (ang. Sprint backlog) zawierający listę zadań do zrealizowania w ramach jednego przebiegu
• Codzienne, zwykle poranne i nie trwające więcej niż 15-20 minut spotkanie zespołu (ang. Sprint meeting) podczas którego każdy z członków zespołu odpowiada na trzy pytania: "co zrobiłem wczoraj?", "co będę robił dziś?" i "co mi przeszkadza w pracy?"
• Wykres spalania dla przebiegu (ang. Sprint urndown chart), podstawowe narzędzie kontroli postępów prac, pokazujący na osi czasu (zwykle dla przebiegu) szacowaną pracochłonność (roboczogodziny) prac, jaka pozostała do zrealizowania prac przebiegu.

Proste? Nieprawdaż? Na pewno jednak myślicie: proste, tylko jak te podstawowe zasady zastosować w praktyce projektowej. Oraz: a co z innymi elementami tradycyjnego zarządzania projektami? Trochę cierpliwości: opowiemy o tym w naszym kolejnym tekście.