Cześć!
Obserwując obecne trendy, większość firm w swoich ogłoszeniach zachęca pracą w metodyce scrum. Jest to na tyle popularna technika, że nawet na studiach informatycznych czymś normalnym jest nauka o scrumie. Po wdrożeniu do projektu często okazuje się, że w praktyce organizacja pracy projektu nijak ma się z definicją tej techniki. W dzisiejszym poście chciałbym omówić największe wątpliwości…do dzieła!
Definicja
Scrum to Zwinne (Agile) podejście do tworzenia nowych produktów i usług. Produktem jest często oprogramowanie, ale może to być dowolna rzecz, która ma dla kogoś wartość. Na przykład kampania marketingowa, konferencja, video podcast albo samochód. Scrum opiera się na dostarczaniu produktu w małych przyrostach, co powoduje, że w dowolnym momencie wiemy gdzie jesteśmy i mamy działającą wersję produktu.
Scrum jest utopijny?
Do dzisiaj pamiętam jedno z pytań z egzaminu „Professional Scrum Master”. Pytanie brzmiało mniej więcej tak:
„Zbierasz stu programistów w jedno pomieszczenie. Ich wiek, doświadczenie i umiejętności miękkie są różne. Jak jako Scrum Master zorganizujesz tych programistów w dziesięć zespołów?”
Możliwe odpowiedzi były takie:
- dzielę programistów wg umiejętności oraz doświadczenia
- dzielę programistów wg wieku
- dzielę ich całkowicie losowo
- nie robię nic, niech sami się zorganizują w zespoły
Znając utopijne podejście scruma, odpowiedź 4 jest jak najbardziej prawidłowa. Sam będąc wielkim fanem tej techniki czasami nie rozumiem takiego podejścia. Wydaje mi się, że w praktyce, w firmie takie podejście nigdy nie będzie efektywne i dobre. Prawdopodobnie studenci (czyt. ludzie z mniejszym doświadczeniem i umiejętnościami) dobiorą się w swoje grupki, osoby bardziej doświadczone w swoje i powstaną z tego bardzo niezbilansowane pod względem umiejętności zespoły.
Jest to tylko jeden przykład utopijności z wielu.
Skoro Scrum jest częściowo utopijny, to po co go stosować?
Prawdopodobnie nie wszyscy się ze mną zgadzać ale uważam, że najlepszym rozwiązaniem jest wykorzystanie tych elementów scruma, które w danej sytuacji, projekcie i zespole będą jak najbardziej efektywne. Oczywiście nie do każdego projektu scrum będzie najbardziej optymalnym rozwiązaniem. Inne metody z których możemy skorzystać:
- Kanban,
- Programowanie ekstremalne
- Learn Software Development
- Waterfall
- Prince2
Jak widać, jest z czego wybierać. Uważam, że projekty w których nie wiadomo jakiej metodyki się używa oraz mało się rozmawia nie mają większego sensu – chyba, że programiści są zadowoleni z tego podejścia.
Dlaczego jestem fanem scruma i uważam, że to najlepsza technika?
Uważam, że czasami warto „stracić” dzień czy dwa na jak to niektórzy nazywają „bezsensownych scrumowych ceremoniach”. Dlaczego? Programowanie to nie tylko wytwarzanie oprogramowania ale szereg innych czynników, jak współpraca z innymi programistami, product ownerem czy np. wydawanie nowej wersji dla klienta (i wiele, wiele innych). Jeśli coś nie zostanie dokładnie omówione, często podczas codziennej pracy wychodzą różne niesnaski i dużo rzeczy zamiatane jest pod dywan ponieważ terminy gonią. Wiem, że niektórzy mogą skontrować to bardzo prosto „klient nie zawsze płaci za ceremonie scrumowe” – uważam, że wtedy jest to problem źle skonstruowanej umowy. Z perspektywy osoby, która dobija targu z klientem i zdając sobie sprawę, że mój zespół najlepiej pracuje w scrumie nie podpisywałbym umowy, w której ta technika nie będzie praktykowana. Programiści są różni. Jedni lubią rozmawiać i nie boją się wyrażać swojego zdania wprost a niektórzy czekają tylko na retrospektywę gdzie będą mogli anonimowo wypisać swoje karteczki, ponieważ nie mają takiego charakteru, żeby problem poruszyć na daily. Scrum wydaje się idealnym rozwiązaniem do tego, by usprawnić proces wytwarzania oprogramowania i uważam, że teoretycznie „stracone godziny” na spotkaniach odpłacą się podwójnie w przyszłości. Kiedy zbuduje się na tyle zgrany, dobry i samoorganizujący zespół to sukces produktowy to tylko kwestia czasu.
Podsumowanie
Reasumując, według mnie scrum jak najbardziej ma sens ale nie zawsze jest potrzebny. Najlepszym rozwiązaniem wydaje się stworzenie własnego „frameworka” i wykorzystanie najbardziej potrzebnych elementów w swoim projekcie. Pochwalcie się w komentarzach z jakimi Wy problemami mierzyliście się w związku Scrumem!
Pozdrawiam serdecznie,
biegajacyprogramista.pl
