Manifest Agile
Nie pamiętam już kto, ale powiedział kiedyś, że tworzenie oprogramowania jest jedną z najbardziej skomplikowanych dziedzin inżynierskich. Stopień złożoności do jakiego dochodzą projekty jest wręcz niespotykany nigdzie indziej. Nic więc dziwnego, że już od dawna próbowano zapanować nad tym procesem. Od Lat 80-tych powstało wiele metodyk zarządzania projektami. Większość z nich była rozwijana lub bazowała na mechanizmach stworzonych w ramach projektów rządowych, które często wymagały bardzo obszernych dokumentacji i ścisłego procesu kontroli.
Do niedawna wydawał się, że bez tego żaden projekt, który ma osiągnąć sukces, nie może się obyć. Jednak mniej więcej w połowie lat 90-tych zaczęły się rozwijać metodyki/frameworki znacznie mniej restrykcyjne. Ich twórcy spotkali się w lutym 2001 roku w stanie Utah, na wspólną zabawę na nartach ( 
), a przy okazji opracowali słynny już dokument: Manifest Agile. Dokument, zgodnie z duchem Agile jest krótki w formie, ale bogaty w przesłaniu, w tłumaczeniu na język Polski:
Poprzez wytwarzanie oprogramowania oraz pomaganie innym w tym zakresie odkrywamy lepsze sposoby realizowania tej pracy. W wyniku tych doświadczeń zaczęliśmy przedkładać:
- Ludzi i ich wzajemne interakcje (współdziałanie)ponad procedury i narzędzia.
- Działające oprogramowanie nad wyczerpującą dokumentację.
- Współpracę z klientem nad negocjację umów.
- Reagowanie na zmiany nad realizowanie planu.
Oznacza to, że wprawdzie doceniamy to co wymieniono po prawej stronie, to jednak bardziej cenimy to co wymieniono po lewej.
Manifest Agile – Tłumaczenie z Wikipedia.org
Problemy tradycyjnych metodyk
Manifest jest w zasadzie idealnym podsumowaniem problemów, z którymi spotykamy się przy zarządzaniu projektami poprzez tradycyjne, zwane również ‘ciężkimi’, metodyki.
1. Problemy z komunikacją.
Tutaj chyba już nie trzeba się rozpisywać. Bo najlepszym opisem tego jest już słynny komiks zamieszczony po prawej stronie. Brak umiejętności przekazywania naszych oczekiwań i problemy ze wzajemnym porozumieniem się miedzy ludźmi ze ‘świata biznesu’ i ‘świata technologii’. Jeżeli dorzucimy teraz do tego brak możliwości rewidowania przez klienta tego co dla niego tworzymy we wczesnych fazach projektu, otrzymujemy efekt jak na obrazku. Przekłada się to nie tylko na rozczarowanie klienta, ale również zespołu realizującego.
2. Zbyt scentralizowane podejmowanie decyzji.
W tradycyjnych metodykach zarządzania projektami najczęściej większość decyzji podejmuje kierownik projektu, w zależności od znaczenia tej decyzji, możliwe, że będzie musiał skonsultować się najpierw z Komitetem Sterującym. Taka pionowa struktura zarządzania bardzo wydłuża czas podejmowania decyzji. Druga sprawą jest fakt, że zwykle osoby pracujące bezpośrednio przy danym problemie mają znacznie lepsze możliwości podjęcia słusznej decyzji.
3. Brak wprowadzania zmian zgodnych z oczekiwaniami klienta.
Jest to problem nadal często spotykany, choć wiele klasycznych metodyk wprowadziło już mechanizmy zarządzania zmianami wymagań. A już zdecydowanie, żadne metodyka ‘nie przyznaje się’ do tworzenia projektów w sposób kaskadowy. Mimo to zespoły realizujące projekty, często nie wprowadzają mechanizmów zarządzania zmianami wymagań w praktyce. Wynika to często z niechęci i nieumiejętności dobrego prowadzenia projektu iteracyjnego. Ludzie przyzwyczajeni do starego podejścia niezbyt chętnie przenoszą się na nowe.
4. Zbyt wielkie przykładanie wagi do dokumentacji
Klasyczne metodyki zyskały przydomek ciężkich, z uwagi na fakt powstawania przy ich realizacji bardzo obszernych dokumentacji. Dokumentacja ta jest często tworzona na wyrost i w praktyce nigdy nie wykorzystywana. Szczególnie problematyczne jest to przy tworzeniu małych, krótkoterminowych projektów. Wtedy koszty wytworzenia dokumentacji mogą stanowić nawet większą część kosztów całego projektu. (Mowa tu nie o dokumentacji technicznej czy użytkownika, a przede wszystkim o dokumentacji projektowej: plany zarządzania projektem, specyfikacje wymagań itp, plany zasobów itp.)
Scrum – Historia Właściwa
Biorąc pod uwagę wszystkie te wady klasycznych metodyk stworzono wiele alternatyw. Jedną z nich jest właśnie Scrum.
Historia tej metodyki sięga roku 1986. W artykule “The New New Product Development Game”, które ukazał się w Harvard Business Review, Hirotaka Takeuchi i Ikujiro Nonaka przedstawili ogólne założenia metodyki. Szukali oni optymalnego sposobu zarządzania projektami innowacyjnymi o ciężkim do przewidzenia efekcie prac.
Następnie w roku 1995, Ken Schwaber jeden z największych autorytetów metodyki Scrum dokonał jej formalnego opisu. Na jego stronie, można znaleźć oryginał tego opracowania. Od tego czasu Scrum stawał się coraz popularniejszy.
Nazwa metodyki wywodzi się od rodzaju zagrywki w rugby, która nazywa się właśnie ’scrum’, co można na Polski tłumaczyć jako młyn. Co ciekawe wiele razy spotkałem się ze stwierdzeniem, że nazwa Scrum pochodzi od młyna takiego do mielenia mąki.
