RE: Metodyka SCRUM czyli zwinne zarządzanie projektami - od kuchni
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):
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.