Metodyka SCRUM czyli zwinne zarządzanie projektami - od kuchni

in #polish7 years ago

scrum.png

W dzisiejszych czasach często się słyszy pojęcie "Firma x wytwarza oprogramowanie w SCRUMIE". Wiele osób pewnie zastanawia się co to oznacza i co to jest ten cały SCRUM ? ;)

SCRUM jest niczym innym jak zbiór dobrych praktyk i działań, które przyczyniają się do wytworzenia końcowego działającego produktu. Przykładowo firma programistyczna dostaje zlecenie na zbudowanie giełdy z kryptowalutami coś na wzór portalu BitBay. Jeżeli firma nie korzysta ze SCRUMA, to wygląda to mniej więcej tak że ktoś zbiera wymagania i rozpisuje je w punktach w kolejności zadaniowej. Następnie programiści biorą z tak zwanej tablicy poszczególne zadania i je realizują. Czasami jest tak że zadania do poszczególnych osób przypisują przełożeni, którzy często nie wiedzą że zadanie A jest dużo bardziej złożone od zadania B i przypisują je do osób które mogą mieć problem z ich realizacją. Takie podejście w większości przypadków, wiąże się z pewnym ryzykiem. Ryzyko możemy podzielić na:

1) Wydłużenie czasu realizacji projektu
2) Kiepska jakość kodu
3) Błędne interpretacje funkcjonalności przez niedoinformowanych programistów

Te trzy powyższe punkty oznaczają pewną klęskę dla firmy i tutaj przychodzi na pomoc metodyka SCRUM. W praktyce wygląda to tak że najpierw tworzymy kompetentny zespół najczęściej od 3 do 10 osób, który będzie odpowiedzialny za przebieg realizacji wykonywanego oprogramowania. Najważniejszy jest oczywiście zespół który dzielimy na 3 role:
  • Product Owner, osoba odpowiedzialna za przekazywanie w sposób jasny i zrozumiały celu, jaki cały zespół musi osiągnąć. Jest to człowiek który reprezentuje klienta i jego wymagania. Tworzenie rejestru produktu to jego zadanie. Tak samo jak podejmowanie kluczowych decyzji i przekazywanie ich do zespołu developerskiego.
  • Scrum Master, osoba który pilnuje żeby każdy uczestnik w projekcie rozumiał SCRUMA i stosował jego zasady. Obowiązkiem Scrum Mastera jest wspieranie Product Ownera w zarządzaniu backlogiem oraz wycenia historyjki razem z zespołem developerów(Story Points). Jest kimś w rodzaju stróża i pilnuje żeby cały "młyn się kręcił". Scrum Master może również należeć do Development Team, tylko w przypadku, gdy obejmowane stanowisko nie przeszkadza mu w realizacji zadań przypisanych do Scrum Mastera.
  • Development Team, czyli tak zwany zespół developerski składający się z programistów, testerów, analityków oraz architektów. Zadaniem zespołu deweloperskiego jest realizacja przypisanych do siebie historyjek w danym Sprincie.

Osoby należące do Development Team mogą obejmować następujące stanowiska:


Programista - implementacja kodu źródłowego
Tester - testowanie wytworzonego kodu
Analityk - analiza wymagań biznesowych - pisanie historyjek
Architekt - pomoc w wyborze technologii, projektowanie rozwiązań, rozwiązywanie problemów wydajnościowych

Mając kompletny zespół musimy określić ramy pracy. Cały przebieg projektu dzielony jest na Sprinty. Sprint jest to krótki cykl, który ma na celu dostarczyć kolejne wersje produktu. Cykle mogą trwać od tygodnia do czterech. Ja osobiście pracuje w cyklach dwutygodniowych i uważam że jest to dobry kompromis między tygodniem a miesiącem ;) Te ramy czasowe ustalane są po to, żeby Product Owner wiedział że jak coś pójdzie nie tak, to nie jest w plecy 5 miesięcy tylko przykładowo dwa tygodnie. Poza tym, pozwala to na szybką reakcję w razie nieoczekiwanych problemów. Przykładowo dorzucenie kolejnego programisty do Development Team w sytuacji gdy zespół nie wyrabia się z realizacją zadań.

Na początku wystartowania Sprintu cały zespół spotyka się i robi planowanie sprintu(Sprint Planning) w którym ustalany jest Sprint Backlog czyli plan zespołu w jaki zamierza realizować cały sprint. Dodatkowo Scrum Master ustala termin codziennych spotkań(Daily Scrum). Zazwyczaj są to codzienne spotkania o tej samej porze, które nie powinno przekraczać 15 minut. Na tych spotkaniach poszczególni członkowie Development Team, opowiadają co zrobili w dniu poprzednim oraz jaki plan mają na dzień aktualny. Podczas "Daily" może również uczestniczyć Product Owner, ale nie jest to konieczne. Gdy mija termin zakończenie sprintu następuje spotkanie podsumowujące(Sprint Review). Podczas spotkania cały zespół omawia co zostało zrealizowane i co o tym sądzą sami zainteresowani jeśli zostaną zaproszeni. Następstwem tego spotkania jest kolejne planowanie Sprintu(Sprint Planning) i tak to się kręci jak w młynie. Dobrą praktyką są retrospektywy (Sprint Retrospective), gdzie zespół ustala co robił źle i jakie działania trzeba wdrożyć żeby było lepiej. Często wygląda to tak, że na tablicy wypisuje się pozytywy i negatywy, a następnie wywiązuje się dialog jak wyeliminować problemy i co zrobić żeby było lepiej.

Ja osobiście jestem programistą i Scrum Masterem jednocześnie. W swojej zawodowej pracy doświadczyłem, że wiele firm szczególnie tych małych nie stać na prowadzenie projektów w ten sposób. Niestety czasami warto podejść do tematu nieco szerzej i spróbować zastosować tą metodykę. Ile razy się słyszy że oprogramowanie tworzone było o kilka miesięcy za długo bez wykwalifikowanego zespołu. Czasami udało się oddać produkt i jakoś to było... Gorzej jak okazywało się że aplikacja już na samym początku została błędnie zbudowana i zmiany które trzeba nanieść wymagają przepisywania całych modułów, włącznie z przebudową bazy danych. Koszty które musi ponieść pracodawca żeby to wyprostować na pewno będą większe niż koszty związane z wprowadzeniem SCRUMA.



Poniżej graficzna prezentacja działania SCRUM, grafika zaczerpnięta z https://commons.wikimedia.org/wiki/
Scrum_diagram_(labelled).png

Pisząc ten artykuł starałem się przedstawić temat tak żeby nie tylko osoby z branży IT go zrozumiały :)

Pozdrawiam @mastek

Sort:  

Programista - implementacja kodu źródłowego
Tester - testowanie wytworzonego kodu
Analityk - analiza wymagań biznesowych - pisanie historyjek
Architekt - pomoc w wyborze technologii, projektowanie rozwiązań, rozwiązywanie problemów wydajnościowych

Ostatnimi czasy w projektach, których miałem okazję pracować, Programiści pełnili także rolę Architektów i po części analityków. Jeżeli programista nie rozumie co musi zaprogramować, to nie zrobi tego dobrze.

Ja osobiście jestem programistą i Scrum Masterem jednocześnie.

W przypadku małych zespołów, jest to nawet częsta zagrywka, natomiast muszę przyznać, że sam kompletnie nie rozumiałem potencjału tej roli, dopóki nie miałem okazji pracować z prawdziwym i profesjonalnym Scrum Masterem (pozdrowienia dla Izy). To w jaki sposób Scrum Master może odciążyć cały zespół, potrafi być naprawdę niesamowite.

Według mnie najciekawsze jest to, że jeżeli w zespole jest Scrum Master, to może on wziąć na siebie dużo obowiązków organizacyjnych. Najciekawsze jest to, że miałem okazję pracować przez rok w zespole, który nie miał oficjalnie szefa/project menagera albo team leadera. Oczywiście, po stronie klienta był Product Owner, jednak wszyscy programiści w zespole (pomijając staż i doświadczenie), mieli równy "status". Team leader nie był potrzebny. Zespół pilnował się sam nawzajem, sprawy organizacyjne z kolei przejmował Scrum Master, który bynajmniej nie był nad/pod programistami. Był po prostu częścią zwinnego zespołu.

Jeżeli scrum jest dobrze "zaimplementowany", to praca w nim to prawdziwa przyjemność :)

Dokładnie, cała sztuka w tym żeby to się zaczęło się kręcić, potem jest już z górki :)

Mnie się tak właśnie zdaje, że dzielenie na tradycyjne role (programista / tester / analityk) chyba nie jest częścią SCRUMa (każdy dobiera zadania jakie może wykonać - jeśli tradycyjny tester na początku nie ma nic do roboty, to bierze zadania analityczne, pod koniec projektu tradycyjny analityk pomaga w testach itd.). Stąd się też z kolei wzięli DevOpsi - podział horyzontalny i mieszanie kompetencji, łączenie ludzi w zespołu projektowe i rozbijanie tradycyjnych pionowych silosów kompetencyjnych (dział developerski, dział administratorów).

Z drugiej strony jak się pytam kumpli jakiej metodyki używają w swoich projektach to jeszcze nigdy nie usłyszałem SCRUMa, tylko między innymi (odpowiedzi autentyczne):

  • prawie SCRUMa,
  • SRAM-ish (w rozmowie po angielsku),
  • SCRUM-like (jak wyżej),
  • i najlepsze na koniec: zaczynamy SCRUMem i kończymy waterfallem (do dziś nie wiem czy to było na poważnie ;-D ).

Nie do końca rozumiem te odpowiedzi, przecież nie ma i nie może być metodyki, która będzie odpowiednia dla wszystkich projektów. Więc to co ludzie uznają za herezję, odejście od świętych zasad SCRUMa to właśnie jest ta zwinna elastyczność, która jest niezbędna aby ta czy inna metodyka działała. Trzeba je dostosowywać i implementować właśnie do swoich potrzeb. Zawsze oczywiście trzeba to robić z wyczuciem, żeby nie przesadzić nie utracić gdzieś zalet zwinności. I czasem trzeba zrozumieć, że są projekty i są klienci u których się tego nie da zastosować w ogóle i rzeczywiście trzeba to robić waterfallem.

Dzięki za zainteresowanie artykułem. Chodziło mi o to że SCRUM narzuca pewien porządek podczas tworzenia oprogramowania. Nie ma w nim miejsca na jakieś samowolki, a nawet jeśli coś takiego się wydarzy to na najbliższym Daily jest szansa to wychwycić i poprawić. Jeśli na Daily to nie wyjdzie to na zakończenie spintu już na pewno. A jak nikt tego nie kontroluje zespół nie współpracuje między sobą nie robią spotkań nie ma osoby odpowiedzialnej tylko kierownik który sprawdza ilość zamkniętych zadań to wtedy wychodzą właśnie takie sytuacje. Ja opisuje swoje doświadczenia. Często rozmawiam ze znajomymi programistami i słyszy się że jakaś firma dała ciała bo mimo dobrego zespołu nikt nie był w stanie tego dobrze zorganizować. Oczywiście nie musi tak być i znam firmy które dobrze działają w tak zwanych płaskich strukturach o których wspomniałeś.

Jeśli na Daily to nie wyjdzie to na zakończenie spintu już na pewno.

Powiedzmy sobie szczerze najbardziej kosztowne są błędy architektoniczne i źle dobrana technologia. W jaki sposób Daily i koniec Sprintu moją to wykryć skoro to wychodzi najczęściej gdy appkę trzeba skalować albo gdy istnieje potrzeba przebudowania/dodania modułu po jakimś czasie działania aplikacji - gdy już jest za późno czyli.

Jak ktoś coś zrobił wybitnie nie tak to to wyjdzie od razu na code review albo przy testach. Tutaj też daily czy zakończenie sprintu nic tak naprawdę nie daje. Przecież code review to nie jest tylko sprawdzenie kodu, przynajmniej nie powinno a można powiedzieć, że rozwiązanie drugi raz zadania.

Daily są krótkie mówiłeś to co robisz a i tak jak masz większy problem to musisz podejść do kolegi i on ci musi poświęcić czas na wytłumaczenie tak jak przy płaskiej strukturze.

Moim zdaniem to wszystko zależy od kompetencji zespołu, mówisz że nie ma miejsca na samowolkę w SCRUMie - to potrafi być dużą wadą. Przykładowo jako programista widzisz, że to co ci dał architekt do zrobienia jest bez sensu i trzeba to zrobić całkiem inaczej - typ ewidentnie nie wie co robi i teraz tak - Musisz iść do niego i się z nim kłócić albo musisz iść do scrum mastera i się poskarżyć. Scrum Master musi to przeanalizować - nie wiadomo czy będzie miał sam pojęcie - tak czy inaczej powiedzmy scrum master stwierdza, że masz rację więc musi iść do analityka i musi iść do product ownera, trzeba napisać nową historyjkę i tak dalej. Teraz jakby to wyglądało w płaskiej strukturze? Programista dyskutuje z innymi programistami, którzy pełnią również rolę architektów. Później mówią szefowi, że to będzie działało tak jak on chce ale z zmianami A i B bo ciężko by było je zaimplementować przy obecnej architekturze, szef mówi ok i wszystko jest zrobione.

W małych firmach często skąpią na dobrych programistów i dlatego te projekty są często fatalnie napisane. Wiadomo na SCRUMa sobie nie pozwolą bo za drogi, ale jestem ciekawy jakby wyglądała sytuacja gdy masz zawodników klasy A, którzy pracują w płaskiej strukturze i którzy pracują w SCRUMie - czy różnice byłyby znaczące a jeśli tak to czy na korzyść SCRUMa

Hej. Nie pracuje w IT ale znam Scrum i też w ten sposób pracuję. Pisałam posta o Agile - poznanie tej idei wpłynęło nie tylko na moje zycie zawodowe.

Rola Scrum Mastera wydaje mi sie powinna byc jednak oddzielona od jakiejkolwiek innej.Mam poczucie ze to zapewnia większą wydajność. Pozwala zastąpić w pełni instytucję Team Leadera- wszyscy równi- Scrum Master to nie lider, to ktoś kto pomaga :)

Ciesze się że również popierasz ta metodykę, jestem bardzo ciekawy Twojego artykułu na pewno go przeczytam :)

//

Dzięki za opinie, zgadzam się dlatego tak ważne jest dobranie odpowiedniego i kompetentnego zespołu łącznie ze SM. Ale dalej nie rozumiem dlaczego -100% ;)

Dlatego trzeba doboerze dobierac zespół. Zgadzam się jednak flagowanie chyba niepotrzebne:)

Czy oby na pewno przemyślałeś dobrze, czy należą się stu procentowe flagi użytkownikowi @mastek oraz @sisters? Czy zrobiłeś to w ogóle specjalnie? W moim przekonaniu, to dwa na prawdę świetne posty! :)

@adasq Moim zdaniem nie ma tu naruszeń, żeby dostać 100% Flagi. Prawidłową oznaką jest przedstawienie argumentów i ostrzeżeniem, a nie flagowaniem, bo mi się nie podoba coś. Tak samo mogę zrobić i skrzyknięciem kilkunastu bardzo dobrą reputacją, bo nie interesuje mnie Twoja tematyka.

FELICITACIONES SU PUBLICACIÓN HA SIDO COMPARTIDA POR @Untapentuoreja , será vista por 2741 esteemianos.