Iterate

Wdrażanie Scrum – wstęp

W ostatnim czasie specjaliści Iterate uczestniczyli jako konsultanci w realizowanym przez zewnętrzną firmę projekcie IT. Naszym zadaniem było przedstawienie wszystkim stronom koncepcji, zasad i praktyk Agile Software Development, wprowadzenie ich w życie, oraz uczestnictwo w realizacji projektu jako część zespołu projektowego.

Chcielibyśmy podzielić się naszymi doświadczeniami i ciekawi jesteśmy opinii na temat przyjętych rozwiązań, dlatego też stwierdziliśmy, że dobrym pomysłem będzie opisanie naszego podejścia. W pełni wyczerpujący tekst miałby jednak zapewne znaczną objętość i mógłby być mało przejrzysty. Z tego względu opiszemy tylko wybrane aspekty takiego zadania. Jeśli którykolwiek z tematów zainteresuje czytających to liczymy na wywiązanie się dyskusji, która pozwoli na bardziej szczegółowe jego omówienie.

Wdrażanie Scrum – przygotowania

Większość osób związanych z realizacją projektu posiadała mglistą lub jedynie podstawową wiedzę na temat prowadzenia projektów za pomocą metodyk zwinnych. Z tego powodu najpierw postanowiliśmy przedstawić samą ideę Agile Software Development. W tym celu umówiliśmy się na spotkanie podczas którego osoby reprezentujące klienta, zespół, oraz zarząd firmy mogli obejrzeć prezentację dotyczącą tej koncepcji. Omawiała ona ogólne zasady Agile Software Development i zawierała między innymi:

• Popularny w branży IT komiks „od specyfikacji wymagań do wdrożenia”. Przedstawia on formę projektu IT pod postacią huśtawki. W skutek wykorzystania metody opartej o waterfall projekt ten ulega mutacji w kolejnych fazach jego realizacji. Przedstawione zostały problemy wynikające z niejednoznaczności komunikacji opartej jedynie o dokumentację, konieczność wyspecyfikowania wymagań na samym początku projektu, utrudnione wprowadzanie zmian, oraz możliwość uzyskania produktu będącego sukcesem technicznym ale nie spełniającego swojej funkcji.
• Omówienie zjawiska „Cone of Uncertainity”, czyli zmiany stopnia dokładności estymacji i specyfikacji projektu w różnych fazach jego realizacji. Wskazuje ono na to, że największy stopień niepewności związanej z projektem występuje właśnie na początku projektu, po czym zmniejsza się w trakcie jego trwania. Wydaje się że wniosek ten, sugerujący iteracyjne planowanie i rozwój projektu, jest oczywisty. W rzeczywistości jednak wiedza ta często nie jest brana pod uwagę.
• Badania przedstawiające stopień wykorzystania funkcjonalności systemów IT, potwierdzające koncepcję 20-80 którą można zinterpretować w taki sposób, iż 20% nakładu pracy daje z reguły 80% oczekiwanego efektu. W przypadku systemów IT około 20% funkcjonalności wykorzystywanej jest często, 16% umiarkowanie często, 19% rzadko a 45% nie jest wykorzystywane nigdy lub prawie nigdy.
• Przedstawienie i omówienie Agile Manifesto
• Informacje o praktykach Agile Software Developement, a w szczególności Scrum, takich jak praca w sposób iteracyjny, priorytetyzacja zadań w oparciu o ich wartość biznesową, bezpośrednia komunikacja, udostępnianie informacji o stanie projektu, ciągła analiza i optymalizacji sposobu pracy, doprecyzowywanie wymagań projektu, oraz ich wpływ na zmniejszenie skali występowania przedstawionych wcześniej problemów.

Po prezentacji przedyskutowaliśmy wspólnie omawiane tematy, tak aby rozwiać ewentualne wątpliwości i uzyskać od wszystkich stron potwierdzenie zainteresowania realizacją projektu za pomocą metodyki zwinnej. Uzyskanie takiego potwierdzenia od wszystkich stron jest istotne i ma na celu wspieranie nowych zasad, co przekłada się na możliwość poprawnej ich implementacji. Dotyczy to między innymi zmiany sposobu zarządzania zespołem, co często może stanowić problem w organizacjach zakładających bezpośrednie, odgórne nim kierowanie.

Na kolejnym spotkaniu zaproponowaliśmy realizację projektu w oparciu o „Vanilla Scrum”, czyli metodykę Scrum nie zmodyfikowaną względem zaleceń Scrum Alliance. Propozycja ta wynikała z braku wcześniejszego doświadczenia większości zaangażowanych w realizacji projektów za pomocą metod zwinnych, oraz łatwego dostępu do literatury traktującej o tym podejściu. Propozycję tą poprzedziliśmy kolejną prezentacją omawiającą bardziej szczegółowo role, aktywności, artefakty i obowiązki członków zespołu Scrum. Nie były to jednak wielogodzinne wykłady, jako że uważamy iż umiejętności najszybciej zdobywa się poprzez praktykę. Często już po pierwszej lub drugiej iteracji zrealizowanej z pomocą osób bardziej doświadczonych zespół uzyskuje wiedzę o podstawach procesu wystarczającą do w miarę skutecznego korzystania z niego.

Po kolejnej sesji dyskusyjnej dotyczącej szczegółów Scrum, dysponowaliśmy już wiedzą, pozwalającą wyłonić osoby które przypisane zostaną do roli Product Ownera, oraz Scrum Mastera. Jeden z reprezentantów klienta potwierdził iż dysponuje on czasem, który pozwoli mu uczestniczyć we wszystkich aktywnościach, aktualizować i rozwijać Backlog projektu, odpowiadać na pytania deweloperów, oraz w razie konieczności być obecnym na uzgadnianych ad-hoc spotkaniach. Chciał on jednak aby pomagała mu jeszcze jedna zaufana osoba, która funkcjonowałaby jako ktoś w rodzaju doradcy technicznego, czy też Tech Product Ownera. Będąc świadomymi potencjalnych problemów jakie taka sytuacja może powodować, przyjęliśmy tę propozycję. Uzgodniliśmy także iż funkcję osoby pełniącej rolę Scrum Mastera, której obowiązkiem jest między innymi pełnienie roli strażnika procesu, przyjmie jeden z naszych konsultantów. Co istotne, zaznaczaliśmy wielokrotnie, iż zdanie Scrum Mastera, który w tym przypadku pełnił także rolę dewelopera, w kwestiach technicznych ma taką samą wagę jak każdego innego członka zespołu i że jego rolą jest pomagać zespołowi uczyć się samoorganizacji oraz efektywnego wykorzystywania zalet metody Scrum. Nie powinien być on traktowany jak ktoś w rodzaju Project Managera w klasycznym tego słowa znaczeniu. Zachęcaliśmy także aby w każdym momencie, w którym jakieś działanie, lub jego cel wydawać się będzie niejasne kierować pytania do tej właśnie osoby. Wszystkie wspomniane osoby, łącznie z deweloperami, zostały przedstawione jako członkowie jednego zespołu odpowiedzialnego za projekt. Sformułowanie tego w odpowiedni sposób pozwala zmniejszyć ryzyko wystąpienia konfliktu na linii my – oni, jakkolwiek by się te grupy określały.

Na środowisko pracy zespołu wybrany został jeden duży pokój, w którym pracować mogli wszyscy jego członkowie. Zlokalizowanie wszystkich w jednym pomieszczeniu jest naszym zdaniem jednym z istotniejszych aspektów wpływających na poczucie współodpowiedzialności i ducha kooperacji. Wiemy oczywiście iż nie zawsze jest to możliwe do zrealizowania, ale w przypadkach gdy jest to możliwe, to szczególnie zalecamy takie podejście. Co więcej w pokoju tym nie przebywały osoby nie związane z realizacją projektu. Ostatecznie zaproponowaliśmy jeszcze zwiększenie powierzchni tablic, tak aby cały zespół mógł przy nich swobodnie omawiać kwestie architektury, procesu, itp.

Poprosiliśmy także Product Ownera i Tech Product Ownera, aby podczas jednego z naszych spotkań przedstawili zespołowi aktualną wizję projektu. Na spotkaniu tym wywiązała się dyskusja dzięki której Product Owner mógł wziąć pod uwagę niektóre aspekty techniczne, których prawdopodobnie wcześniej nie rozważał, a z drugiej strony zespół zyskał całościową wiedzę na temat produktu który miał stworzyć. Posiadanie takiej wiedzy pozwala na lepsze podejmowanie decyzji przez zespół podczas rozwoju systemu oraz wpływa na zwiększenie motywacji. Posiadanie wiedzy jedynie o tych elementach systemu które będą implementowane w najbliższej przyszłości często jest dla zespołu demotywujące i sugeruje między innymi brak zaufania, co powodować może zmniejszenie stopnia poczucia odpowiedzialności.

Prace które bezpośrednio poprzedzały rozpoczęcie pierwszej iteracji obejmowały zapoznanie się członków zespołu, poznanie przez konsultantów kultury i specyfiki firmy, oraz analizę technologii które miały być wykorzystane podczas realizacji projektu. Zespół mógł poświęcić na te prace mniej więcej tydzień. W tym czasie rozpoznane zostały możliwości technologii służącej do tworzenia warstwy prezentacji, która nie była wcześniej wykorzystywania przez zespół, a którą zaproponował Tech Product Owner, oraz stworzony został wstępny szkielet projektu. Przygotowane zostało także środowisko projektowe, ustalony został sposób budowania projektu i poczynione zostały ustalenia dotyczące formatowania kodu.

W kolejnej części postaram się opisać aktywności związane z planowaniem pierwszego Sprintu.