Nie trzeba być geniuszem zarządzania, aby domyślić się, że dużego projektu nie da się wziąć "na chaps" i przygotować od A do Z w jednym wielkim etapie. To znaczy - można (w końcu "gdyby to było złe, to Bóg by inaczej świat stworzył"), ale nie jest to zbyt rozsądne i to z wielu konkretnych powodów, z których można wymienić chociażby:

• klient przez długi czas nie widzi efektów pracy, przez co niecierpliwi się i czuje, że nie ma kontroli nad projektem,
• klient nie ma momentu, w którym może zainterweniować i nakierować projekt na właściwe tory,
• zespół IT ma poczucie ciągłości pracy i braku światełka w tunelu, co bardzo demotywuje,
• w konsekwencji, tak prowadzony projekt ma większe szanse na zakończenie się klapą, co nie tylko obniża zaufanie klientów do nas, ale też generuje potężne straty finansowe dla obu stron.

Oczywiście, to nie wszystkie powody, ale już one wystarczą, aby stwierdzić, iż takie całościowe podejście (wywodzące się z modelu kaskadowego (ang. waterfall model)) mija się z celem dla choć średniej wielkości projektów. Dlatego zaczęto dzielić je na mniejsze części zwane etapami, kamieniami milowymi (zwłaszcza w tworzeniu gier) czy sprintami znanymi ze zwinnej metodyki Scrum. To ostatnie podejście jest najbardziej sformalizowane z omawianych i nim zajmiemy się w dalszej części tekstu. Ale żeby dojść do tego, o czym w ogóle chcę dzisiaj napisać, musimy krótko sobie powiedzieć, czym w ogóle sprint jest i jak wygląda jego "obsługa".

Jeden sprint to taki etap projektu o ściśle określonej długości trwania - zazwyczaj podaje się dwa tygodnie, ale wiele zespołów preferuje trochę dłuższe okresy, jak 3-4 tygodnie. Na każdy taki okres przeznacza się wcześniej ustaloną, stałą liczbę godzin - czasami nazywa się to "koszyczkiem", który ma pewną pojemność. Jak nietrudno się domyślić, zadania (wymagania lub nawet ich bardziej szczegółowe części) wyznaczone dla całego projektu i zebrane w rejestrze produktu (ang. product backlog), mają swoje oszacowania godzinowe. Zatem na każdy sprint powinny przypadać wymagania, które nie tylko mieszczą się w danym koszyczku, ale też przynoszą klientowi realną korzyść biznesową.

To nas prowadzi do innego przeznaczenia sprintów - każdy dostarcza działający produkt (oczywiście, w danej części), który już teoretycznie może być wykorzystywany przez klienta do pewnych działań, do jakich oprogramowanie ma być przeznaczone. Czyli, jeżeli tworzymy duży system do zarządzania drukarkami, a w pierwszym sprincie ustaliliśmy realizację logowania się i dodawania swoich drukarek, to oznacza to, że po oddaniu klientowi efektu pierwszego sprintu, ten już może oddać go swoim użytkownikom, którzy mogą przygotowywać drukarki w systemie, a przy okazji zgłaszać dalsze zapotrzebowanie (np. za pomocą Feedybacky'ego). A właśnie.

Bo kolejną ważną rzeczą związaną ze sprintami jest to, że - poza przypadkami, kiedy klient naprawdę nie ma czasu lub występują inne przeszkody - każdy sprint planowany jest razem, przez zespół IT i klienta, co ma zapewnić nie tylko "wykonalność" danego etapu (aby realne było jego wykonanie w założonym czasie), ale także wyartykułowanie przez klienta rzeczy, które w danym momencie są mu najbardziej przydatne. Oczywiście, jest to zawsze kwestia kompromisu i idealny scenariusz, ale tak powinno to wyglądać. Następnie trwa sprint, który jest niezmienny - w jego trakcie nie można ingerować w zakres zadań (poza ich doprecyzowaniem) i trzeba po prostu czekać na efekt końcowy. Po tej części następuje oddanie sprintu (słynny "release"), a więc przekazanie pracy klientowi do jego użytku. Często jest to połączone z tzw. retrospektywą, aby zrewidować swoje oczekiwania oraz wskazać rzeczy, które w implementacji projektu przeszkadzają. I dopiero w tym momencie następuje planowanie kolejnego sprintu. 

Taki przebieg ma ogromne znaczenie, gdyż w tym momencie klient może stwierdzić, że jakaś funkcja, którą wcześniej założono dla systemu, a która teraz mogłaby zostać zrealizowana, jednak się nie przyda i warto ją opóźnić lub pominąć (a więc zaoszczędzić cenny czas). Co więcej, w toku użytkowania dotychczasowego stanu projektu, często okazuje się, że brakuje jakiegoś wymagania, które jest potrzebne, a więc dodaje się je do rejestru produktu. Zatem widać, że produkt nie jest zamkniętą całością, która powstaje od A do Z, tylko że w częściach - jest dynamicznym tworem, który reaguje na rzeczywiste potrzeby klienta i zmiany. A wierzcie mi - często dopiero po przeklikaniu się przez częściowo gotowe oprogramowanie widać, co tak naprawdę jest potrzebne użytkownikom. Witajcie w świecie metodyk zwinnych - one właśnie powstały dla takich sytuacji.

Jak widać, sprinty nie są tylko dla zespołu IT, który wykorzystuje je do lepszej organizacji swojej pracy - dają też duże możliwości klientom, którzy w ten dość prosty sposób zyskują większą kontrolę nad czymś, za co płacą oraz widzą pośrednie efekty pracy, z których w dodatku już mogą korzystać. Oczywiście, wykonawca może tworzyć sobie wewnętrzne podsprinty, jeśli ma taką potrzebę, ale nigdy, ale to przenigdy nie zapominajcie o tym, że początek i koniec sprintów jest realizowany z udziałem klienta. Nawet, jeżeli zdarza się, że rejestr produktu jest zamknięty i sprinty są ustalane naprzód, to zawsze każdy powinien kończyć się oddaniem pracy płacącemu. Inaczej bardzo oddalamy się od końcowego sukcesu, czyli realnie wykorzystywanego oprogramowania i widoków na dalszą współpracę.

Pozdrawiam - Jakub Rojek