pl
enZwinne zarządzanie projektem w Scrum
Alexa Trachim
Karol Wegner
Linda i Paweł prowadzą swoje biznesy. Oboje osiągają sukcesy, ich firmy się rozrastają, jednak jakiś czas temu zyski zaczęły nagle spadać.
Postanowili poszukać nowych sposobów na dotarcie do większej ilości klientów oraz zwiększenie swojej widoczności na rynku i oboje postanowili stworzyć aplikacje mobilne w ramach swoich biznesów.
Spis treści
- Jak znaleźć dewelopera aplikacji z odpowiednim podejściem do Twojego biznesu
- Czym jest Scrum?
- Role w projekcie deweloperskim prowadzonym w Agile Scrum
- Zwinny framework
- Sprinty – krótkie, zwinne, produktywne
- Płacisz za to, co dostajesz – nie za obietnice
- Przejrzystość i transparentność
- Przewaga zwinności
Jak znaleźć dewelopera aplikacji z odpowiednim podejściem do Twojego biznesu
Paul znalazł firmę tworzącą aplikacje, otrzymał dokładną wycenę swojego produktu, a deweloper zaproponował zbudowanie aplikacji w modelu kaskadowym. Stworzenie dokumentacji wymagań, funkcjonalności oraz designu apki zajęło kilka miesięcy. W tym momencie Paweł może tylko czekać. Wkrótce otrzyma swój gotowy i działający produkt, za który sporo zapłacił. Wtedy dopiero będzie mógł docenić jego innowacyjność. Prawdopodobnie po jakimś czasie jego produkt będzie działał tak, jak sobie wstępnie zaplanował – bez fajerwerków, ale też bez problemów, ani bez potrzeby angażowania Pawła. Dostanie dokładnie to, co zamawiał – ale zajmie to dłuższą chwilę.
Linda postanowiła zwrócić się do dewelopera pracującego w Agile. Otrzymała wycenę aplikacji – firma zaproponowała development metodą Scrum.
Czym jest Scrum?
Scrum to zwinna metodologia wytwarzania oprogramowania. Procesy typu Agile są oparte o konkretny zestaw zasad i wartości. Scrum jako metoda wykorzystuje je i oferuje framework organizujący pracę w developmencie.
Po zaakceptowaniu estymacji projektu Linda stała się właścicielką produktu. Jej zaangażowanie w proces kreacji apki będzie miał przede wszystkim wymiar praktyczny, zwłaszcza na początku i zawsze wtedy, gdy będą wprowadzane zmiany i modyfikacje w projekcie.
Do projektu Lindy przypisano zespół oraz Scrum Mastera, a ona sama stała się częścią teamu! Właśnie tak działa metodologia Scrum. W wybranym przez nią software housie wyjaśniono jej, że praca w Scrumie wymaga współpracy pomiędzy właścicielem produktu, Scrum Masterem i zespołem programistycznym.
Jako że był to pierwszy zwinny projekt aplikacji, w którym uczestniczyła Linda, musiała się nauczyć zasad Scruma. Deweloperzy pracowali w tej metodzie od lat, nie było więc pytania, na które nie znaliby odpowiedzi.
Pytanie, które Linda miała w głowie od samego początku, brzmiało: jak to wszystko funkcjonuje? Firma wytłumaczyła jej, jak działa zwinne wytwarzanie oprogramowania.
Role w projekcie deweloperskim prowadzonym w Agile Scrum
Wszystko zaczyna się od przydzielenia konkretnych ról. Aby osiągnąć maksymalną produktywność, elastyczność i kreatywność zespołów Scrumowych, muszą być one samowystarczalne. Oznacza to, że właściciel produktu, Scrum Master i zespół developerski to jedyne, czego powinien potrzebować projekt, aby można było go ukończyć. Te trzy role składają się na wielofunkcyjną grupę posiadającą wszelkie kompetencje, aby pracować w projekcie.
Właściciel produktu
Product Owner (czyli klient) podejmuje decyzje podczas trwania procesu. Zadaniem Lindy jest powiedzieć całej reszcie, co jest potrzebne w jej aplikacji. Funkcjonalności, problemy, które muszą rozwiązać, terminy do dotrzymania. Jest ona także odpowiedzialna za akcept produktu na każdym etapie jego wytwarzania. Jeśli pojawi się potrzeba wprowadzenia zmian lub dodania czegoś, to ona powinna zakomunikować to reszcie zespołu (tzw. Single Point of Contact). Linda powinna dbać o to, aby zarówno produkt, jak i praca zespołu deweloperskiego reprezentowały odpowiednią wartość. Powinna mówić ludziom, co mają robić (ale nie jak to robić) i decydować, czy akceptuje przedstawione jej efekty.
Scrum Master
Scrum Master to jedna osoba, która dba o to, aby projekt przebiegał według zasad Scrum. To ważne, bo zwinność, ciągłe poprawki i potrzeba elastyczności są w tym wypadku codziennością. Zadaniem Scrum Mastera jest optymalizowanie pracy, rozporządzanie zasobami, komunikacja oraz ustalanie celów ze wszystkimi osobami zaangażowanymi w projekt. Filozofia Scrum Mastera opiera się o bycie do dyspozycji właściciela produktu i zespołu oraz organizację dążeń mających dostarczyć określoną wartość.
Zespół programistyczny
Wielofunkcyjna grupa specjalistów posiadająca wszystkie umiejętności potrzebne do ukończenia określonych zadań. Żaden członek zespołu nie jest określony sztywnym tytułem, wszyscy sobie pomagają w procesie developmentu w sposób holistyczny.
Zwinny framework
Gdy role zostały już objaśnione, Linda powinna nauczyć się wszystkiego na temat frameworka Scrum. Jej aplikacja ma być wykonana od podstaw. Zakres prac, planowanie, harmonogram, dostarczenie produktu, terminy, faktury – wszystko musi zostać określone. Jak to się robi w Scrumie?
Zwinny plan developmentu
Jak w każdym projekcie, development aplikacji Lindy rozpoczął się od fazy planowania. W metodologii Scrum wszystkie komponenty, funkcjonalności i wymagania są umieszczane w tak zwanym Backlogu Produktu. Jest to lista wszystkich warunków, jakie powinna spełniać wytworzona aplikacja. Backlog, w przeciwieństwie do klasycznej dokumentacji, jest bardzo elastyczny i można go dopasowywać do sytuacji. Dopracowywanie backlogu trwa przez cały czas i nie jest niczym ograniczone.
Zmiany, dodatkowe elementy i inne usprawnienia mogą być wprowadzane w każdym momencie trwania developmentu bez potrzeby wracania do wstępnej fazy planowania. Można powiedzieć, że Backlog Produktu nigdy nie jest skończony, lecz wciąż się go doskonali.
Wykonanie
Scrum to framework zakładający pracę w stosunkowo krótkich iteracjach. Po stworzeniu backlogu proces developmentu zostaje podzielony na Sprinty – ich długość jest szacowana w oparciu o poziom skomplikowania funkcjonalności. Sprinty zazwyczaj trwają od 1 do 4 tygodni i powinny dostarczać rezultaty w formie działających funkcji gotowych do przetestowania, zrecenzowania i zatwierdzenia przez właściciela produktu.
Krótkie iteracje dodają procesowi developmentu zwinności. Nowe wymagania, zmiany, dodatkowe zadania mogą być wdrażane jako kolejne sprinty, a praca nad nimi może się rozpoczynać natychmiast po zakończeniu właśnie trwającego sprintu.
Krótkie iteracje dodają procesowi developmentu zwinności. Nowe wymagania, zmiany, dodatkowe zadania mogą być wdrażane jako kolejne sprinty, a praca nad nimi może się rozpoczynać natychmiast po zakończeniu właśnie trwającego sprintu.
Sprinty – krótkie, zwinne, produktywne
Sprinty rozpoczynają się planowaniem, podczas którego tworzony jest Backlog Sprintu. Zawiera on zestaw wymogów zaczerpniętych z Backlogu Produktowego, ponieważ celem każdego sprintu jest spełnienie owych wymagań. Zespół ustala, w jaki sposób zorganizuje swoją pracę, aby dostarczyć efekty w określonym terminie.
Daily Scrum
Zespół spotyka się codziennie na krótkim spotkaniu Scrumowym w celu ustalenia celów na dany dzień.
Planowanie sprintów wymaga wglądu właściciela produktu i jego informacji zwrotnej – jednocześnie, powinno być uzgadniane przez cały zespół. Później można rozpocząć pracę nad ustalonymi celami. Pod koniec każdego sprintu efekty są prezentowane właścicielowi produktu, aby mógł je ocenić i zatwierdzić.
Po przeprowadzeniu sprintu organizowana jest Retrospektywa. W Scrumie ewoluujemy i dostosowujemy się do każdego projektu. Retrospektywa to idealna szansa na to, aby przyjrzeć się minionemu etapowi developmentu i zidentyfikować co zadziałało dobrze, a co wymaga usprawnienia.
Gdy sprint się zakończy, wszystkie cele zostaną osiągnięta, a potem zrewidowane i zatwierdzone, cykl się powtarza. Planowanie sprintu, dzienne spotkania Scrum, praca, rewizja. Każdy sprint dostarcza gotowe części produktu, więc na każdym etapie Linda może obserwować powstawanie i dopracowywanie aplikacji, co zbliża ją do finalnego produktu. W wielu przypadkach to okazało się kluczowe dla klienta.
Płacisz za to, co dostajesz – nie za obietnice
Metoda oparta na sprintach pomaga także na elastyczność w obszarze finansów. Każdy sprint można rozliczyć jako osobny “produkt”, więc Linda nie musiała płacić od razu za cały projekt, tylko dostaje faktury za każdy sprint. To daje jej dużo wolności i jednocześnie kontrolę nad budżetem firmowym. W ekstremalnych przypadkach mogłaby nawet zawiesić projekt, porzucić go lub poszukać bardziej efektywnego dewelopera w trakcie jego trwania. Płaci tylko za pracę wykonaną w konkretnym terminie, a nie pełną sumę za cały projekt.
Przejrzystość i transparentność
Z każdym sprintem Backlog Produktu się zmniejsza, a estymacje odnośnie szybkości progresu, pozostałego czasu i kosztów stają się dokładniejsze. Staje się jasne, czy projekt mieści się w harmonogramie oraz czy dodatkowe zmiany mogą jeszcze się zmieścić w budżecie lub czy jakieś można pominąć dla redukcji kosztów. Funkcjonalności, które nie zostały jeszcze wykonane można w każdej chwili usunąć z Backlogu i zastąpić je nowymi pomysłami lub propozycjami. Elastyczność pozwala na doskonalenie produktu zgodnie z wizją właściciela produktu, aby mieć pewność, że finalny produkt będzie odpowiadał oczekiwaniom.
Niespodziewane trudności
Zmiany, ulepszenia oraz nowe wymagania teoretycznie są dozwolone przez cały proces trwania developmentu, lecz w praktyce wprowadzenie ich pod koniec testów i implementacji może znacznie opóźnić moment wdrożenia produktu. Dla każdego nowego sprintu należy określić rozsądny harmonogram, aby współpraca była efektywna.
Im wcześniej nowe funkcjonalności zostaną zaproponowane i wpisane do Backlogu, tym szybciej można dokonać korekty wymagań i estymacji.
Rola właściciela produktu nauczyła Lindę, co naprawdę oznacza bycie częścią zespołu pracującego nad jej wymarzonym projektem. W trakcie trwania procesu mogła wymyślać nowe funkcje aplikacji, pozbywać się tych niepotrzebnych i mieć kontrolę nad każdym elementem produktu. Efekt końcowy przerósł jej oczekiwania.
Przewaga zwinności
Framework Scrum oparty jest na współpracy i inkluzywności, co daje mu sporą przewagę nad klasycznym developmentem kaskadowym. W tym drugim zaangażowanie osoby zamawiającej oprogramowanie w development uznawane jest za przeszkodę i utrudnia proces produkcji. Klasyczny development jest odpowiedni dla projektów ze szczegółową dokumentacją, sztywnymi wymogami i mocno zdefiniowanymi celami – w tym wypadku, po wstępnej fazie planowania wszystko jest zależne od deweloperów. Zredukowanie kosztów po rozpoczęciu projektu jest właściwie niemożliwe.
Metodologia Agile Scrum to podejście ewolucyjne, wytwarzanie oprogramowania w zwinny sposób. Efekty pracy w Scrumie dają wszystkim zainteresowanym satysfakcję z dostarczania indywidualnego produktu dostosowanego do potrzeb klienta. Łatwiej wprowadzać zmiany i rozszerzać listę wymagań w procesie. Redukcja kosztów ogólnych jest możliwa, na przykład poprzez anulowanie sprintów poświęconych funkcjonalnościom, które nie są już potrzebne.
Najczęściej zadawane pytania
Scrum jest frameworkiem metodologii Agile. Prościej mówiąc, to zbiór zasad postępowania, według których prowadzi się projekty wytwarzania oprogramowania. Powstał ponad 30 lat temu, a jego celem było tworzenie produktów dopasowanych do potrzeb klienta oraz wykształcenie optymalnego podejścia do rozwiązywania problemów. W Scrumie przywiązuje się ogromną wagę do jakości produkowanych rozwiązań, stąd jest to często wybierany przez firmy IT framework – pozwala on produktywnie kodować i uzyskiwać świetne rezultaty.
Przede wszystkim, co różni Scrum i inne metodologie Agile od podejścia typu wodospadowego (waterfall) to brak jednej określonej ścieżki, która ma prowadzić do określonego celu. To framework, który podpowiada, w jaki sposób powinni ze sobą współpracować członkowie zespołu oraz opisuje pewne działania, które muszą być obecne w projekcie i dzięki którym łatwiej jest go prowadzić (np. sprinty). W Scrumie każdy ma swoją określoną rolę, pracę dzieli się na konkretne jednostki czasu, a podejście do zmian jest dość elastyczne.
Scrum wdrażany jest przez większość software house’ów właśnie ze względu na swoją strukturę i sposób pracy w projektach. Ten framework nie narzuca, w jaki sposób ma być pisany kod, ale znacznie ułatwia współpracę w zespole, śledzenie postępów i radzenie sobie z trudnościami. Regularne spotkania pozwalają bliżej przyjrzeć się ewentualnym problemom oraz wprowadzać nowe rozwiązania. W Scrumie bardzo ważnym aspektem jest komunikacja – każda osoba zaangażowana w projekt jest dobrze poinformowana, ma dostęp do wszelkich materiałów i może zgłaszać swoje pomysły. To sprawia, że praca nad wytwarzaniem oprogramowania staje się naprawdę efektywna, a rezultaty zawsze odpowiadają oczekiwaniom klienta.
Klient, który zdecyduje się na współpracę z dostawcą usług programistycznych pracującym w Scrumie, ma naprawdę wiele do powiedzenia. W tej metodologii odchodzi się od podejścia, w którym właściciel produktu nie wie, co się dzieje w projekcie i przychodzi “na gotowe”. Scrum sugeruje, że klient staje się aktywnym członkiem zespołu, który podsuwa swoje pomysły, a także dzieli się swoimi przemyśleniami i wiedzą na temat branży, grupy docelowej czy konkurencji. Komunikacja w projektach Scrumowych jest właściwie ciągła, dzięki czemu zawsze wiadomo, jakie są postępy w projekcie i na co trzeba zwrócić uwagę. I choć na pierwszy rzut oka taki poziom zaangażowania nie dla każdego może się wydawać atrakcyjny, to wpływa on bardzo dobrze na efekty końcowe.
Ciesz się z owoców swojej pracy
Dla Lindy zwinne wytwarzanie oprogramowania w metodzie Scrum okazało się rozwiązaniem idealnym. Dostała swój własny produkt. Jej spostrzeżenia i uwagi zostały uwzględnione, zaoszczędziła nieco na zredukowaniu niepotrzebnych funkcji, a w międzyczasie dodała kilka innych. Oczywiście została z wybranym deweloperem do końca i zgłosiła chęć skorzystania z dalszej współpracy przy rozwoju aplikacji. Wiedziała, że znajdzie dodatkowe środki na kolejny sprint.
Nie zapominajmy jednak o Pawle i jego projekcie. Co tu dużo mówić – wciąż czeka na implementację.
