Jeśli nie Scrum, to co?

2 października 2013

Firmy zrażone ciągnącymi się latami projektami, które dostarczają nie to, co było potrzebne, są otwarte na alternatywy. Wykonawcy wychodzą naprzeciw oczekiwaniom (i swojej ciekawości nowych rozwiązań) proponując Scrum. Odtąd miejsce Waterfalla zastępuje Agile. Czy to zawsze najlepsza opcja? I czy jedyna alternatywa jaką mamy?
Modnemu ostatnimi laty Agile’owi przeciwstawia się tradycyjne sposoby pracy. Pod pojęciem tradycyjne wymieniane są jednym tchem takie pojęcia jak waterfall (cykl kaskadowy, PRINCE2, itp.). Mamy zatem dwa wyjścia – trwać w epoce starożytnej lub wejść w XXI wiek i stosować Scrum.
Cieszy, że dzięki popularności Scruma rośnie świadomość tego, że można wytwarzać systemy w sposób uporządkowany, nie chaotyczny. Świetnie by było, gdyby ta moda spowodowała też ciekawość innych rozwiązań, tak, abyśmy mieli wachlarz możliwości, nie przywiązywali się do jednego, które nie zawsze będzie najlepszym wyborem.

Mity

Przede wszystkim warto obalić kilka mitów, które stoją na drodze otwarcia na inne możliwości.

W Scrumie jest najszybciej

To zależy. Efekty widać co prawda szybko od momentu rozpoczęcia projektu. Kiedy jednak projekt zostanie zakończony? To zależy od tego ile niepewności jest w projekcie, ile niesprawdzonych tez biznesowych. Na pewno lepiej stosować takie wyjście przy tworzeni produktów na półkę (dla masowego użytkownika), start up’ach. Jeśli jednak mamy do czynienia z projektem, w którym wiele rzeczy jest z góry wiadomych, np. znane są przepisy księgowe, formularze ubezpieczeniowe, wnioski unijne, nie ma sensu „próbkować” i testować kolejnych iteracji. Szkoda na to czasu. Zamiast zawracać głowę klientowi recenzowaniem naszych strzałów wynikających z niewiedzy, zamiast wprowadzać ciągłe poprawki wynikające z późniejszego odkrywania powiązań w kolejnych modułach, dajmy spokój Scrumowi i weźmy inne rozwiązanie. Dobre zrozumienie, przemyślenie i opracowanie koncepcji na początku może znacząco skrócić późniejsze programowanie, bo nie ma tylu poprawek, nie ma powrotów, idziemy jak burza. Poniżej badania IBM na masie ich projektów.

Scrum jest do wszystkiego

Oczywiście, można w Scrumie próbować zrobić każdy projekt. Może się nawet udać. Pytanie czy to najlepsze, najtańsze rozwiązanie. Barry Boehm i Richard Turner prowadzący badania nad setkami projektów, konsultując się z najwybitniejszymi specjalistami, m.in. Grady Booch’em czy Alistair’em Cockburn’em (twórcą ruchu agile), odkryli, że w pewnych warunkach (np. >50 osób, duże powiązania między modułami, itd.) używanie Scruma powoduje więcej trudności niż korzyści. https://analizait.pl/2012/jak-nie-puscic-firmy-z-torbami/

Waterfall (= PRINCE2) << Scrum

Porównywanie waterfalla do Scruma jest nie na miejscu, bo waterfall to model wytwarzania (kaskadowy). W Scrumie mamy model wytwarzania spiralny. https://analizait.pl/2012/jak-wyglada-analiza-i-proces-wytwarzania/ Te dwie rzeczy można porównywać, wybierać ten, który w danym projekcie będzie lepszy.
Waterfall != PRINCE2. PRINCE2 podawany często jako przykład tradycyjnej (złej!) metodyki, w rzeczywistości wcale nie jest kaskadowy. Jedną z głównych zasad jest zarządzanie etapowe, a więc nie robimy projektu siadając na początku w styczniu i kończąc w grudniu. Równie dobrze możemy wytwarzać spiralnie czy przyrostowo.
Porównywanie PRINCE2 ze Scrumem jest nie na miejscu, bo PRINCE2 to metodyka zarządcza – mówi o tym, jak zarządzać projektem, nie wchodzi w szczegóły sposobu wykonania. Scrum mówi o tym, jak wytwarzać, zarządzać zadaniami i ich realizacją.

Scrum skupia się na tworzeniu, wszystko inne na tworzeniu tony dokumentów

Jeśli tworzysz tony niepotrzebnych dokumentów, to może być tylko jedna przyczyna:

Nie dostosowałeś metody prowadzenia projektu (m. in. jego produktów) do jego warunków – to Twój błąd, nie metodyki innej niż Scrum

Każdy dokument powinien czemuś służyć, coś wnosić. Jeśli jest za dużo stron, to znaczy, że nie umiesz uchwycić sedna, rejestrujesz tylko jak dyktafon, co mówi klient lub jakie materiały Ci dostarcza, bez zastanowienia, czy to ma sens i się ze sobą spina. Jeśli tworzysz kolejne strony, które nikomu nie są potrzebne, to znaczy, że zaplanowane przez Ciebie czynności są bez sensu. To Twój błąd, nie metodyki innej niż Scrum.
P.S. Jedym z głównych założeń PRINCE2 jest to, że skupiamy się na dostarczanym produkcie, nie na dokumentacji.

Wachlarz możliwości

Masz cały wachlarz możliwości, jeśli chodzi o dobór metodyki i modelu wytwarzania.
Przede wszystkim dobry project manager (czy inżynier procesu) powinien dopasować sposób realizacji do projektu. Ma tutaj cały wachlarz możliwości. Poczynając od gotowych metodyk, kończąc na wybieraniu najlepszych praktyk z różnych metodyk, wg potrzeby. Większość metodyk określa jako warunek konieczny ich stosowania, aby je przyciąć (np. PRINCE2!) – dostosować do projektu. Wielkość i złożoność metodyki każdej innej niż Scrum jest zazwyczaj jedną z najczęściej podawanych przyczyn rzekomej niemożliwości wdrożenia w projekcie. Nikt nie każe, wręcz zabrania się, stosowania ich w całości. Ale do tego trzeba już trochę tę metodykę poznać, siąść i z głową dostosować.
Przykłady metodyk zwinnych: https://analizait.pl/2012/sprint-przez-metodyki-zwinne-agile/
Przykłady metodyk sterowanych planem znajdziesz w książce: Boehm B., Turner R., Balancing Agility and Discipline, A Guide for the Perplexed, Addison-Wesley, 2004
Modele wytwarzania znajdziesz tutaj: https://analizait.pl/2012/jak-wyglada-analiza-i-proces-wytwarzania/
Chcę, żebyś zapamiętał z tego artykułu jedno: Twój wybór to nie wieloletni waterfall lub Scrum. Masz ogromny wybór!

Cześć, jestem Hania.

Jako strategiczny analityk biznesowy na pograniczu zarządzania i IT zapewniam, że projekty i działania w organizacji przynoszą wartość biznesową. Dostarczam kompetencji analitycznych managerom i zarządom z Polski, Niemiec i Szwajcarii przy tworzeniu strategii oraz wdrażaniu jej w kilkuset osobowej międzynarodowej organizacji.

Komentarze - 10

irek
2 października 2013, 21:54
wszystko super, tyle, że analizy biznesowej w scrum się włożyć po prostu nie da, a spike wcale sytuacji nie ratuje
Odpowiedz
1. Tomasz Tomaszewski
  3 października 2013, 06:04
  Nie widzę związku komentarza z artykułem.
  Natomiast merytorycznie. W mojej firmie łączymy analize biznesową i scrum. Nie widzę w tym nic nadzwyczajnego. Analiza biznesowa pozwala klientowi dobrze układać i zarządzać backlogiem.
  Odpowiedz
2. Hania Wesołowska
  3 października 2013, 07:00
  Zdaniem jednego z twórców Agile – Arie’ego van Bennekum – jak najbardziej się da – https://analizait.pl/2013/czy-dobra-analiza-gryzie-sie-z-agile/
  Odpowiedz
3. MKurleto
  24 października 2013, 13:22
  Właśnie z tego powodu większość polskich realizacji Agile (SCRUM, Kanban itp.) jakie miałem okazję oglądać konczą się koncepcją “posadźmy programistę z sekretarką powstanie system zarządzania bankiem”. Nie powstanie.
  Nie widzę żadnych przeszkód aby zastosować SCRUM w projekcie w którym realizowana jest rzetelna analiza biznesowa. Polecam tematykę łączenia RUP i SCRUM, iteracyjno-przyrostowy model wytwarzania, agile modeling i książkę “UML i wzorce projektowe. Analiza i projektowanie obiektowe oraz iteracyjny model wytwarzania aplikacji.” – Craiga Larmana
  Odpowiedz
  1. Tomasz Tomaszewski
    24 października 2013, 16:10
    Zgadzam się. My od dłuższego już czasu staramy się łączyć PRINCE2 i Scrum. Ma to oczywiście zarówno zalety, jak i wady, ale całkiem ciekawie to wychodzi. Będzie trzeba się kiedyś podzielić doświadczeniami n blogu 😉
    Odpowiedz
Daniel Turczański
1 listopada 2013, 14:55
Pracuję w projekcie SCRUMowym dotyczącym wniosków unijnych i nie wyobrażam sobie, żeby podejście bardziej tradycyjne wyszło projektowi na dobre. Zawsze jest dużo niewiadomoych wokół projektów. Przepisy unijne czy prawne to tylko jedna z wiadomych w projekcie.
A to, że analiza biznesowa jest wykonywana wcześniej rozumie się samo przez się. Na bieżąco też powstaje wiele wątpliwośći, które trzeba wyjaśniać.
Odpowiedz
1. Hania Wesołowska
  2 listopada 2013, 07:01
  A co jest przedmiotem projektu? Jakiś nowy produkt, który trzeba wymyślić i sprawdzić czy informowanie już istniejącej organizacji?
  Odpowiedz
  1. Daniel Turczański
    4 listopada 2013, 09:38
    Nowy produkt, który trzeba sprawdzić – owszem. Ale dla istniejącej organizacji, która ma już istniejący proces “w papierze”. Tak naprawdę każdy projekt jeśli ma być wygodny dla użytkownika i pozbawiony dziwnych rozwiązań wynikających ze złych założeń podpada mi pod SCRUM.
    Odpowiedz
    
    Hania Wesołowska
    4 listopada 2013, 10:18
    A mi podpada pod dobry projekt UX i weryfikowanie rozwiązania z klientem. Bez względu na to czy to Scrum czy nie 🙂
    
    Tomasz Tomaszewski
    5 listopada 2013, 11:58
    Dlaczego?