Zacznijmy o lansu:) W zeszłym tygodniu zostałem certyfikowanym Agile Project Managerem! Juhuu!…i SCRUM Product Ownerem! Jeszcze więcej Juhuu!!
Temat zwinnych metodyk stał się ostatnio na tyle modny, że mówią o nim nawet hipsterzy na mieście, przy burgerach.
Na czym polega trik?
Metodyki Agile w przeciwieństwie do tradycyjnych takich jak PRINCE2 charakteryzują się dużą iteracyjnością i inkrementacją.
Oznacza, że nie tworzymy danego produktu popularnym łoterfolem (bardzo ładne Polskie słowo), gdzie mamy wyraźnie wyróżnione, następujące po sobie fazy analizy, projektowania, implementacji i testów. Zamiast tego mamy następujące jeden po drugim cykle wytwórcze trwające od 2 do 4 tyg. W trakcie takiego cyklu wytwarzana, testowana i prezentowana jest wybrana część funkcjonalności. Nie ma żadnego przedłużania terminów, przekładania czegoś na później i niekończących się poprawek. Rozwiązanie musi być GOOD ENOUGH (nie mylić z „the best possible”:) w określonym harmonogramie. Nie ma zbędnych fajerwerków i wiecznego poprawiania. Czas i uwaga KOSZTY nie podlegają negocjacjom. Możemy za to manewrować zakresem, wywalając funkcjonalności, których nie udało się wdrożyć w terminie (poza tymi, które wchodzą w minimalny wymagany zakres) lub nie wpływające na główne funkcjonalności produktu.
Co zyskujemy?
Przede wszystkim nie czekamy (a właściwie sponsor nie czeka:) na obejrzenie finalnego produktu do końca projektu, tylko co parę tygodni dostajemy nową, większą część, która może zacząć już przynosić realne korzyści biznesowe. Po drugie nie tworzymy zbędnej dokumentacji do tej części produktu, której finalnie nie wytworzymy i po trzecie otrzymujemy produkt w czasie i budżecie założonym na początku projektu (mimo, że trochę wypatroszony z funkcjonalności:)
Jak to się ma do e-learningu?
Temat nie jest prosty bo wytwarzanie szkoleń e-learningowych to typowy przykład łoterfola, gdzie zazwyczaj mamy mocno zdefiniowany na początku zakres „projektu”. Tworzymy scenariusz (lub prototyp), następnie próbkę szkolenia i potem czekamy i czekamy..i czekamy na ostateczną wersję szkolenia. Gdy przekraczamy termin oddania, często zdarzają nam się jeszcze „drobne poprawki”, które przesuwają całość o tydzień:) Gdybyśmy chcieli zastosować metodyki zwinne to w ciągu pierwszych 1-2 tygodni mielibyśmy gotowy przykładowo scenariusz pierwszego modułu wraz odpowiadającą mu działającą na platformie częścią szkolenia. W kolejnej iteracji (sprincie) kolejny moduł itd.
Zalety? Zakładając, że szkolenie składa się z 4 modułów, po miesiącu mamy gotowe i przetestowane szkolenie uruchomione na platformie.
Wady? Nie mamy na początku gotowego scenariusza (jest on tworzony po kawałku w każdym sprincie) więc podczas całego projektu jest wymagane dużo zaangażowanie osób merytorycznych. Dodatkowo, jeżeli w kolejnych iteracjach wyjdzie nam, że musimy coś dodać do już istniejącego modułu, to wtedy musimy usunąć coś w zamian (czas jest nienegocjowalny), czyli możemy wylądować z niekompletnym szkoleniem.
Do tej pory uczestniczyłem w Agile’owym tworzeniu szkoleń systemowych, przy bardzo dużym projekcie, gdzie opóźnienie nie było opcją i trzeba było dostarczyć parędziesiąt godzin contentu, w bardzo krótkim okresie od wdrożenia.
A czy macie już jakieś zwinne przygody za sobą?:)
Żródło: http://www.inqbation.com/agile-methodology-of-web-development/
E-learning - newsy, wiedza, konsultacje, wdrożenia 
Gratulacje, Bartku! Cieszę się, że napisałeś na ten temat. Zagadnienie jest warte niejednego wpisu 🙂
Jakiś czas temu pisałem na podyplomówce pracę zaliczeniową nt. wykorzystania metodyk zwinnych w e-learningu. Doszedłem do podobnych wniosków jak Ty, ale w praktyce nie zawsze wygląda to tak kolorowo.
Pierwsza sprawa – co tak naprawdę jest zakresem projektu e-learningowego? Co jest e-learningowym backlogiem? Materiał merytroczny? Możliwe sposoby jego przedstawienia? Czy scenariusz jest tym samym co scrum’owy backlog? Jody Baty proponuje zaadaptować Scruma do projektów e-learningowych w taki sposób, aby rejestr wymagań (Product Backlog) składał się z ułożonych hierarchicznie efektów kształcenia, czyli celów szkolenia.
Druga rzecz – klient nie zawsze potrafi się odnieść do dostarczonego kawałka, ponieważ nie widzi tam jeszcze całej zawartości merytorycznej i np. nie słyszy lektora.
Tyle jeśli chodzi o problemy. Przekazywanie klientowi fragmentów szkolenia nie tylko pozwala dostawcy uchronić się przed pracochłonnymi poprawkami na koniec projektu, ale daje także klientowi najpełniejszą informację o postępie pracy.
Ważną wskazówką (wywodzącą się ze Scruma) jest ustalenie z klientem „definition of done”, czyli kryteriów akceptacji. W przeciwnym razie dostarczane fragmenty mogą być wielokrotnie odrzucane ze względu na niezgodność z indywidualnymi upodobaniami.
Zgodnie z podejściem Lean Software Development: „Marnotrawstwem jest wszystko, co nie dodaje wartości do produktu. Wartością jest to, co klient uzna za wartościowe” .
PolubieniePolubienie
Dopiero wyrabiam swoje best practice, ale Twoje pytania są celne:)
Ja bym chyba jako backlog brał cele szkolenia ale w sensie jaką wiedzę chcemy przekazać np. przy szkoleniu produktowym możemy mieć wiedzę teoretyczną, techniki sprzedaży, obsługa reklamacji itp. Każdy taki element wrzucałbym jako osobne wymaganie, któe później byłoby dalej rozbijane.
Jeżeli chodzi o problem w odnoszeniu się do kawałka produktu to jest to generalnie chyba problem Agile. Trzeba się do tego przyzwyczaić. Wszystko zależy od tego jaki „kawałek” finalnegon produktu wytworzymy w trakcie sprintu. Tutaj jest bardzo ważna rola Product Ownera, który powinien współpracować z biznesem i przedstawiać mu cały czas wizję produktu. Jeżeli chodzi o audio to według mnie powinno być nagrywane w każdym sprincie:)
Definition of done jest kluczowe. Nie widziałem jeszcze e-learningowego przykładu, ale na pewno trzeba by w niej zarzeć zarówno część techniczną, merytoryczną i projektową.
PolubieniePolubienie
Fajny artykuł! Bartek, może napiszesz coś więcej na temat twojego doświadczenia Agile’owego przy szkoleniach systemowych? Dlaczego AGILE? Nie było innej możliwości czy był to świadomy wybór?
Z chęcią poeksperymentuję w sumie. Tylko odważnego sponsora trzeba znaleźć…
Tutaj artykuł i link do warsztatów AGILE Instructional Design:
http://www.learningsolutionsmag.com/articles/1235/get-in-gear-with-launch-of-agile-instructional-design-course
dam znać czy warto.
pozdrawiam!
mz
PolubieniePolubienie
Moja przygoda była trochę przypadkowa:) Duży projekt w naszej firmie prowadzony był ta metodyką. Trzeba było dostarczać do niego gotowe szkolenia zaraz po wdrożeniu co uniemozliwiało ich wytworzenie po wdrożeniu.
PolubieniePolubienie