Metodyki prowadzenia projektów e-commerce

Co to są metodyki prowadzenia projektów e-commerce?

Metody kaskadowe (z ang. Waterfall) inaczej zwane tradycyjnymi

Model kaskadowy prowadzenia projektów zakłada podział zadania projektowego na sekwencje kroków, które muszą zostać zrealizowane w pełnym zakresie w określonym z góry czasie. Bardzo rygorystyczne podejście do zadań, czasu i projektów zostało opisane w 1970 roku przez Winstona W. Royce`a i dotyczyło projektów informatycznych. Projekt składa się z czynności a każda czynność to kaskada (schodek).

Prowadzenie projektu przebiega wg następującego harmonogramu:

1. Określenie specyfikacji wymagań czyli stworzenie planu.
2. Sprawdzenie możliwości realizacji, analiza specyfikacji.
3. Projektowanie zadania.
4. Wdrożenie zadania.
5. Testy i sprawdzenie poprawności działania.
6. Wdrożenie gotowego produktu oraz administracja.

Każdy etap jest restrykcyjnie sprawdzany i weryfikowany. W przypadku jakiegokolwiek niepowodzenia zespół uczestniczący w pracach cofa się i tak długo poprawia etap, aż będzie on w pełni gotowy.

Wadą tej metodyki jest niewątpliwie bark elastyczności oraz możliwe zwiększone koszty (np. czas pracy) przez powtarzanie tych samych czynności od nowa. Kaskadowe podejście blokuje też  swoich założeniach przejście do kolejnych etapów projektu, co w niektórych zadaniach może być czynnikiem hamującym rozwój.

Metodyka Waterfall mimo swojego wieku oraz braku elastyczności wynikającej głównie z niedopasowania się do nowoczesnych metod i kultury pracy ma swoich zwolenników i nadal jest używana w przypadku np. projektów, w których wszystko jest dokładnie opisane, przejrzyste a każda z kaskad możliwa do realizacji.

Metoda szczególnie dobrze sprawdza się w powtarzalnych projektach, w których pewne etapy cechują się powtarzalnością. Kluczem do sprawnego korzystania z metody klasycznej jest szczegółowy plan, z podziałem na kolejne etapy. Rygorystyczne przestrzeganie terminów i kosztów szczególnie dobrze sprawdza się w projektach inżynieryjnych (np. w trakcie budowy), czy też projektach IT, które raz wdrożone w konkretnej firmie przenoszone są do innych przedsiębiorstw z zachowaniem etapów implementacji krok po kroku. Waterfall wymaga zachowania standaryzacji i stabilności w przedsiębiorstwach, gdzie jest stosowany ale w efekcie jego stosowania możemy mieć pewność braku odstępstw od założeń, co jest największą zaletą metody.

Zalety t między innymi pewność otrzymania oczekiwanych wyników, stały i dokładnie określony rytm pracy oraz dokładność i rygor podczas prac.

Do wad należy zaliczyć niską elastyczność, brak możliwości wprowadzania modyfikacji podczas prac a testy poprawności wykonuje się na samym końcu.

Metodyki Waterfall stosowane w praktyce:

• Metodyka PRINCE2 (Project IN Controlled Environment) – projekty w sterowanym środowisku

Prince2 to znana od 1983 metoda zarządzania projektami w oparciu o produkty.

Procesy Prince2 można podzielić na:

• przygotowanie projektu
• inicjowanie projektu
• zarządzanie strategiczne projektem
• sterowanie etapem
• zarządzanie wytwarzaniem produktów
• zarządzanie końcowym etapem
• zamykanie projektu

Silnymi stronami metodyki Prince2 jest jasne od samego początku podejście do projektu, pełna kontrola nad rozpoczęciem prac, czasem trwania i zakończeniem zadania. Restrykcyjne przestrzeganie kolejnych etapów i porównywanie postępów oraz pewność, że projekt ma uzasadnienie biznesowe.

• PMBOK Guide (ang. A Guide to the Project Management Body of Knowledge), czyli standard zarządzania projektami w oparciu o cykl życia projektu.

PMBOK określa 49 procesów w całym cyklu projektu, który jest podzielony na:

1. Procesy inicjowania (startu) – procesy w trakcie definiowania nowego projektu
2. Procesy planowania – ustalenie zakresu i celów oraz określenie zadań, które trzeba podjąć celem ich realizacji
3. Procesy realizacji – realizacja prac zaplanowanych we wcześniejszych etapach
4. Procesy zakończenia i zamknięcia projektu.

Metodyki zwinne

Metodyki zwinne (agile) w odróżnieniu od tradycyjnych dzielą projekt na zbiory mniejszych zadań, które stale mogą się zmieniać w zależności od potrzeb. Metody tego typu zakładają elastyczne dopasowywanie się do zmiennej sytuacji i odpowiednia reakcja celem osiągniecia jak najlepszych rezultatów.

Manifest agile to zbiór zasad, które opracowano w 2001 roku, który ustala hierarchię ważności składników projektów:

• ludzie i interakcje ponad procesy i narzędzia
• działające oprogramowanie ponad obszerną dokumentację
• współpraca z klientem ponad formalne ustalenia
• reagowanie na zmiany ponad podążanie za planem

Metodyki zwinne nadają się do realizacji wielu projektów, chociaż początkowo były stworzone z myślą o projektach informatycznych. Główne zasady agile to:

1. Priorytetem jest zadowolenie klienta poprzez wczesne i ciągle dostarczanie cennego oprogramowania.
2. Pozytywne przyjmowanie zmieniających się potrzeb, nawet poźno w rozwoju oprogramowania.
3. Działające oprogramowanie jest dostarczane często (z reguły tygodniowo).
4. Bliska współpraca pomiędzy interesariuszami a deweloperami.
5. Projekty są tworzone wokół zmotywowanych osób, którym powinno się ufać.
6. Komunikacja „twarzą w twarz” jest najlepszą komunikacją.
7. Działające oprogramowanie jest podstawowym miernikiem sukcesu.
8. Stały rozwój, umożliwiający równe tempo.
9. Ciągłe skupianie uwagi nad techniczną doskonałością i dobrym projektem.
10. Niezbędna jest prostota – sztuka maksymalizowania ilości pracy niewykonanej.
11. Najlepsze wymogi i projekty wychodzą z zespołów, które się samoorganizują
12. Niezbędne jest ciągłe poprawianie wydajności poprzez analizowanie możliwości poprawy oraz dostosowanie ich do uzyskanych wniosków.

Metody zwinne stawiają na interakcje między uczestnikami projektu, elastyczne dopasowywanie się do zmian i wymagań oraz stałą współpracę (np. z klientem). Empowered team czyli zespół mający możliwości decyzyjne i odpowiednio zmotywowany według tych metodyk nie potrzebuje silnego nadzoru. Techniki elastycznego dopasowania do zmiennej sytuacji mają pomóc przy ewentualnych problemach.

Mocnymi stronami zwinnych metodyk jest elastyczności szybkość działania, brak wymogu rozpoczynania całego procesu projektowania od nowa przy wprowadzanych zmianach, samodzielność jednostek i całych zespołów oraz skupienie się na potrzebach klienta, co może skutkować dobrymi relacjami.

Wady metodyki to miedzy innymi ograniczona kontrola nad kolejnymi etapami prac, czasami mylne założenie o wysokich kompetencjach członków zespołów, pomijanie wielu ważnych elementów w trakcie skupianiu się na wymaganiach klienta.

Etapy prac:

• Planowanie, czyli dokładne zebranie wszystkich wymagań, analiza i zaplanowanie kolejnych kroków. Etap wymaga dokładnego omówienia z osobami zamawiającymi realizację projektu i wymaga wysokich umiejętności komunikacyjnych.
• Projektowanie, to etap który jest następstwem zebranych informacji w części planowania.
• Programowanie – praca nad projektem na podstawie przygotowanego planu.
• Testy – weryfikacja czy efekt pracy odpowiada wcześniej zaplanowanemu projektowi.
• Wdrożenie – implementacja zadania po zakończeniu pomyślnie testów,
• Informacja o efektach, czyli podsumowanie testów i wdrożenia gotowego projektu.

Każdy z etapów może być w każdej chwili zmieniony i poprawiony w zależności od wymagań klienta, czy też osoby decydującej.

Metodyki zwinne świetnie sprawdzają się przy projektach SEO i IT, gdzie samodzielne zespoły bez usystematyzowanej hierarchii pracują nad konkretnym zadaniem.

Przykłady metodyk zwinnych:

• Scrum – Popularna metodyka oparta o agile.

Projekt podzielony jest na iteracje trwające maksymalnie miesiąc, które nazywane są sprintami. Każdy sprint musi zakończyć się działającą wersją produktu. Bardzo popularna metoda pracy w zespołach IT, ponieważ w oparciu o ogólne zasady metodyk zwinnych pozwala na rozwiązywanie problemów i dopasowywanie się do stawianych wymagań. W Scrum stosuje się podejście iteracyjne czyli przyrostowe, co ma na celu zachowanie kontroli nad ewentualnymi problemami.

Scrum opiera się o trzy filary:

Filar przejrzystości, który zakłada, że wszystkie najważniejsze składowe projektu muszą być zrozumiałe i dokładnie określone wspólnym standardem oceny. Dzięki takiemu podejściu każdy ma taką samą ocenę postępów prac i kontroli nad postępami.

Filar adaptacji, dzięki któremu w razie jakichkolwiek problemów zaburzających proces powstawania projektu zespól adoptuje się do nowych warunków i wprowadza zmienne niezbędne do prawidłowego działania procesu.

Filar inspekcji wprowadza zasadę częstych kontroli stanu prac nad projektem. Ważne, żeby potencjalne sprawdzanie postępów nie zaburzało pracy zespołu i nie opóźniało samego projektu.

Funkcjonowanie zespołów Scrum.

Zespoły powinny być samowystarczalne i w pełni autonomiczne. Celem takiego podejścia jest maksymalnie umożliwienie dopasowywanie się członków zespołu do zmiennej sytuacji i elastyczne działanie.

Każdy zespół powinien składać się z Właściciela projektu, Zespołu odpowiedzialnego za projekt (Development Team) oraz Scrum Master, czyli osoby odpowiedzialnej za kontrolę całego procesu i dopasowania zasad do metodyk Scrum.

W metodyce Scrum proces działania podzielony został na przedziały czasowe (Time Boxes):

Planowanie sprintu (sprint planning) – określenie rejestru produktowego i zadaniowego. W tym etapie właściciel projektu na podstawie zebranych informacji określa i wypisuje funkcje produktu, który ma być realizowany.

Sprint – realizacja zadania wg zasad wcześniej ustalonych. W trakcie Sprintu nie można zmieniać założeń. Zespół pracuje wspólnie, dzieląc się informacjami i doświadczeniem. Czas trwania sprintu nie może przekraczać 30 dni.

Codzienny Scrum – krótkie spotkanie każdego dnia gdy realizowany jest Sprint w trakcje, którego Scrum Master weryfikuje i aktualizuje stan prac pytając się każdego z uczestników:

Co zrobił do tej pory? Co zrobi w najbliższym czasie? Jakie napotkał problemy?

Spotkanie jest krótkie i zawsze przeprowadzane na tych samych zasadach, żeby wprowadzić codzienną rutynę.

• Kanban
• Extreme programming (XP)
• Lean Software Development
• Agile modeling
• Agile unified process (AUP)
• Disciplined agile delivery

Przegląd Sprintu – po każdym spotkaniu mające na celu omówienie części prac.

Restrospektywa Sprintu – wszyscy członkowie zespołu spotykają się i omawiają wszystkie kwestie organizacyjne związane z pracami. Celem jest ulepszenie dotychczasowych metod pracy.

W jakich projektach te metodyki się sprawdzają? Np. przy tworzeniu stron internetowych, projektowaniu aplikacji mobilnych, rozbudowanych serwisów online itd.