Skąd my to znamy? Miesiącami ciągnące się wdrożenia, rozjazdy między wymaganiami początkowymi, a funkcjonalnościami wdrożonymi, terminy w lesie... a wszystko, by klient był zadowolony.
Trzeba powiedzieć sobie KONIEC. Terminy muszą się zgadzać, kasa też, a klient musi być zawsze zadowolony. Możliwe? Tak, możliwe, ale wszyscy członkowie zespołu muszą w to uwierzyć i trzymać się prostych zasad. Zasad zwinnego prowadzenia projektów, na przykład SCRUMa!
Pierwsza przeszkoda dla SCRUMa w małej firmie: w metodach zwinnych zespół zajmie się jednym projektem przez cały czas, od jego inicjacji, aż po zakończenie. W małej firmie - bieżących projektów jest kilka, a są też usługi serwisowe, które w losowym momencie odrywają członka zespołu od pracy nad projektem. Jest na to jakieś rozwiązanie? Nie ma - po prostu musicie zaadaptować SCRUMa do realiów w waszym biznesie; poranne mitingi muszą dotyczyć wszystkich projektów na raz :). Wiem, zaraz odezwą się głosy SCRUM Masterów, że to wbrew zasadom, że tak się nie da prowadzić skutecznie zwinnych projektów. To prawda, ale tak się da prowadzić zwinną firmę. Staramy się przestrzegać scrumowych reguł, przy czym traktujemy małą firmę jako scrumowy projekt, a w zasadzie kilka projektów jako jeden duży projekt. Przy projektach dużych staramy się wydzielić grupę projektową tak, by jego członkom nie zawracać głowy innymi sprawami i projektami i tu pilnować scrumowego porządku. Mniejsze projekty nie dadzą się tak zrealizować.
Scrumowe formalności to następna rzecz, której często nie przestrzegamy, a to już nie jest dobre. Choć w Srumie formalności jest minimalna ilość, to jednak trzeba pilnować karteczek przyklejonych na tablicy, rozliczać się przed samym sobą i członkami zespołu z postępów prac. Bez tych karteczek - zapomnijcie o dotrzymywaniu terminów! To ważne, by każdy wiedział, co ma zrobić, ile ma na to czasu i zawczasu reagował, jeśli coś się przedłuży. Ratuje to projekty i terminy.
Szacowanie czasu - odwieczny problem w małych firmach. Każdy szacuje według siebie i własnych, zwykle optymistycznych założeń. Trzeba brać poprawkę na innych. Jeżeli znasz siebie, jesteś w stanie oszacować, ile czasu Tobie zajmie dana "historyjka", to nie znaczy, że inni myślą tak samo i mają identyczny plan. Trzeba wyjąć karty do planning pokera i "zagrać" w planowanie, a wyniki planowania zaokrąglić w górę. Najwyżej zostanie troszkę czasu na "couldy". Co zrobić z członkiem zespołu, który zawsze wyciąga "jeden dzień" w planning pokerze, a potem cały sprint poświęca na wykonanie tak oszacowanej funkcjonalności? Trzeba dopytać dokładnie, jak widzi rozwiązanie funkcjonalności, i każdy etap przeanalizować, nawet kosztem przedłużenia scrumowego spotkania. Po takiej analizie wychodzi zwykle, że jeden dzień to za mało...
Scrum zwykle bywa problematyczny, jeśli chodzi o zupełnie nowe dla zespołu technologie. Nie jesteśmy w stanie przewidzieć, jakie niespodzianki czekają nas przy wdrożeniu, jeśli pierwszy raz uruchamiamy portal o milionie odsłon na dobę, pierwszy raz siadamy nad nowym frameworkiem i nie wiemy, że on nie ma takich fajnych funkcjonalności, jak nasz stary. W przypadku użycia nieznanych zespołowi technologii trzeba planować ostrożnie.
Klient jest kluczową postacią w projekcie SCRUMowym. W terminologii zwinnej przyjmuje on stanowisko właściciela produktu, ale tylko pod warunkiem, że czynnie uczestniczy w projekcie i ma świadomość, co to jest SCRUM i jakie zasady tu panują. Jeżeli klient ma tylko zarys wizji projektu, i kilka sztywnych wymogów, co do projektu, ale nie chce czynnie uczestniczyć w projekcie, stanowisko właściciela projektu musi przejąć inny członek zespołu - ten, który najlepiej rozumie potrzeby klienta i zbuduje realną wizję, pod którą klient się podpisze.
Klienci często nie rozumieją metody MoSCoW, i myślą, że wszystko, co wpisze się w tabelkę MoSCoW, musi być wykonane. Jeżeli czegoś brakuje, mają żal i czują niedosyt. Powstaje więc dylemat, czy angażować klienta, który nie zna realiów Scruma do projektu, i przedstawiać mu dokumentację. Moja odpowiedź jest taka: trzeba klientów edukować i pokazać im, że dzięki tej metodologii prowadzenia projektów mogą mieć więcej funkcjonalności, niż zakładali. A jeżeli czegoś z listy MoSCoW nie udało się zrealizować, to nie znaczy, że projekt jest niekompletny.
Ok, więc po co ten SCRUM? Ano po to, żeby przyzwyczaić zespół do trzymania porządku i tempa projektów. Po pewnym czasie zespół zacznie planować realnie, a projekty będą zamykały się w terminach. ...
Marcin Pawelec
2018-02-15
Znajdź nas w social mediach: