Podczas rozważań nad czynnikami sukcesu projektu wdrożeniowego, na myśl przychodzi wiele elementów mających większy lub mniejszy wpływ na jego przebieg. Myślimy o budżecie, harmonogramie, kompetencjach zespołu, poziomie skomplikowania projektu. Jednak bardzo często zapominamy o metodyce lub frameworku. To one definiują i organizują pracę zarówno po stronie klienta, jak i dostawcy rozwiązania.
Jak wybrać odpowiednią metodykę do projektu?
Wybór metodyki nie może być przypadkowy, bądź podyktowany panującą modą. Pośród istotnych kryteriów wyboru wymieniane są między innymi:
- wielkość projektu,
- poziom znajomości rozwiązania oraz definiowalności celu,
- stabilność wymagań,
- dostępność klienta,
- elastyczność względem zmian w budżecie i zakresie wdrożenia,
- przewidywany czas dostarczenia produktu końcowego,
- czy też stopień skomplikowania integracji z systemami zewnętrznymi.
Dopiero po uwzględnieniu wszystkich powyższych czynników można świadomie wybrać metodykę wdrożenia.
Agile Manifesto – poznajmy założenia agile
Ogólnym przesłaniem Manifestu dla Deweloperów Oprogramowania jest skupienie na czynniku ludzkim oraz wszystkich wartościach, które przynoszą korzyści zarówno klientowi, jak i deweloperom. Ludzie i interakcje cenione są bardziej od procesów i narzędzi, działające oprogramowanie od szczegółowej dokumentacji, współpraca z klientem od negocjacji umów a reagowanie na zmiany od realizacji założonego planu. Działania podejmowane w ramach wdrożenia realizowanego w metodyce zwinnej planowe są etapami i z uwzględnieniem bieżących doświadczeń użytkowników. Efektem każdego kilkutygodniowego sprintu jest dostarczenie działającego fragmentu systemu, który może być na bieżąco testowany przez użytkowników końcowych. Daje to możliwość wprowadzania regularnych korekt rozwiązania zgodnie z pojawiającymi się na bieżąco potrzebami. Podejście zwinne daje również swobodę w sterowaniu budżetem oraz priorytetyzacji zadań. Zazwyczaj rozliczamy projekty na zasadach Time & Material. Dzięki temu koszty związane są wyłącznie z czasem i zasobami poświęconymi na wdrożenie.
Scrum a Agile – na czym polega różnica?
Stosowanie pojęć scrum i agile nie zawsze jest błędem. Odpowiednio stosowany Scrum (czyli taki spełniający 4 założenia Agile Manifesto oraz 12 zasad Agile) jest sposobem na osiągnięcie założeń zwinnego podejścia do wytwarzania oprogramowania, jednak nie jest to jedyny sposób. Istnieją również inne, takie jak Kanban, Crystal czy DSDM. Można więc stwierdzić, że Scrum jest jednym z członków rodziny metod zwinnych – Agile.
Twórcy Scruma określają go jako strukturę, bądź szkielet odchodząc od miana metody lub metodyki. Wynika to z braku narzucania konkretnych praktyk lub technik rozwoju oprogramowania, opisu konkretnego sposobu postępowania. Jest to zestaw wyraźnych ram, które pozwalają na szybkie wykrycie nieefektywności w procesie tworzenia oprogramowania, oparty na kilku podstawowych mechanizmach, takich jak: metoda sprawdź i dostosuj, samo-organizujące się zespoły, tworzenie restrospekcji.
– Metodyki klasyczne (np. waterfall) sprawdzają się w projektach, które zakładają implementację rozwiązań „pudełkowych”, czy systemów kompletnie zdefiniowanych pod względem wymagań. – tłumaczy Małgorzata Filipiak, Manager PMO i Scrum Master z DahliaMatic. Podejście to wymaga jednak zdecydowanie więcej formalności, obszernej dokumentacji, przygotowania procedur i procesów oraz trzymania się harmonogramu. W przypadku, gdy system dostosowujemy do biznesu klienta, zdecydowanie bardziej efektywne jest wykorzystanie metodyk zwinnych.
Kto jest kim? Role członków zespołu.
Jednym z fundamentów Scruma jest hierarchia ról i przypisanych im uprawnień oraz obowiązków wykonywanych w ramach projektu. Product Owner (w wolnym tłumaczeniu – Właściciel Produktu 😉 ) opowiada za podejmowanie decyzji w kwestii rozwoju produktu oraz dysponuje czasem Zespołu Developerskiego w taki sposób, aby zmaksymalizować ich efektywność. Zadaniem Development Teamu jest odpowiednie zaplanowanie, sprawna organizacja i właściwe wykonanie pracy. Natomiast Scrum Master pilnuje wprowadzenia i przestrzegania zasad Scrum podczas codziennej pracy oraz dba o ich właściwe zrozumienie zarówno przez Zespół, jak i całą organizacje. Wspiera również Team w codziennej pracy, usuwając pojawiające się utrudnienia i przeszkody, wspiera samoorganizację, moderuje spotkania.
Organizacja pracy według Scruma
Zespół dzieli życie projektowe na sprinty, czyli iteracje, podczas których tworzy kolejny przyrost produktu. Każdy z nich posiada swój cel ustalany przy planowaniu (Sprint Planning). Zazwyczaj trwają między jednym, a czteroma tygodniami. Nieodłącznym elementem codziennym jest Daily Scrum, czyli krótkie spotkanie mające na celu synchronizację pracy i ustalenie planu Sprintu. Każdy ze Sprintów kończy się przeglądem i retrospektywą. Celem przeglądu jest omówienie produktu, najczęściej poprzez zaprezentowanie działającej funkcjonalności, zebranie informacji zwrotnej oraz dyskusję. Z kolei retrospektywa poświęcona jest sposobowi pracy. Polega na jego analizie, która może doprowadzić do znalezienia możliwości usprawnienia działania.
– Scrum się sprawdza, ponieważ kładzie nacisk na współpracę z klientem. To nie jest tylko projekt klienta, to nie jest też projekt firmy wdrażającej – jest to współpraca, wspólny cel, obustronne zaangażowanie i odpowiedzialność za wyniki. Modyfikacje w założeniach czy ewolucja oczekiwań użytkowników są szansą do rozwoju i osiągnięcia jeszcze lepszych efektów końcowych projektu. To jedna z największych zalet tego podejścia. – dodaje Małgorzata Filipiak.
Czy metodologia Scrum sprawdza się w projektach wdrożeniowych ERP?
Scrum pozwala elastycznie reagować na zmieniające się wymagania i dostarcza funkcjonalności etapami. To szczególnie wartościowe w długich projektach ERP, gdzie potrzeby mogą ewoluować.
Jakie wyzwania niesie agile w projektach ERP?
Systemy ERP mają sztywną architekturę, co ogranicza elastyczność. Dodatkowo zespoły biznesowe mogą mieć problem z częstym podejmowaniem decyzji wymaganych w Scrum.
>