Scrum językiem Developerów 

Kontynuujemy cykl o Scrumie dla Developerów. Dziś Artur Komendatskyi wyjaśni, co można zrobić, żeby przedstawić Scrum tak, aby był on zarówno zrozumiały, jak i atrakcyjny dla wspominanych już Developerów. Zapraszamy do kolejnego gościnnego posta.

Framework Scrum

W poprzednim artykule znaleźliśmy odpowiedź na pytanie: „Dlaczego Developerzy nie rozumieją Scruma?„. Dziś chcemy wytłumaczyć: jak przedstawić programistom Scrum w języku, który oni rozumieją oraz po co ten Scrum jest im potrzebny. Musimy pamiętać o ludzkiej naturze, która sprawia, iż jesteśmy zmotywowani tylko, jeśli widzimy w tym jakieś zyski dla siebie.

Zacznijmy od najbardziej prostego: Scrum jest frameworkiem. A przecież my, Developerzy, korzystamy z frameworków na co dzień. Nawet jak nie umiemy sformułować ładnej definicji o tym, czym konkretnie jest framework, to intuicyjnie doskonale wiemy, czym one są. Gdy siadamy do tworzenia nowej aplikacji lub modułu, nigdy nie realizujemy własnej implementacji HashMap czy LinkedList. Nie stwarzamy od zera narzędzia do zarządzania połączeniami do bazy danych lub do parsowania plików Excel. Dlaczego? Bo możemy skorzystać z gotowych już rozwiązań, którym możemy ufać. Innymi słowy, możemy użyć frameworków. A więc framework to stworzone przez kogoś innego rozwiązanie naszego problemu. Co więcej, jest ono rzetelnie przetestowane i ulepszone do najwyższych standardów jakości, a do tego przeszło próbę czasu.

Dlaczego nie stwarzamy od zera własnych kolekcji takich jak HashMap? Bo spędzimy czas na implementację, pisanie testów, ewentualne debugowanie i naprawianie błędów, a po miesiącu okaże się, że nasze rozwiązanie jest wolne i zjada dużo pamięci. W najlepszym razie będzie działało równie dobrze, co rozwiązanie „rynkowe”. O wiele lepiej wykorzystać odpowiedni framework, żeby oszczędzić sobie czasu i uniknąć bólu głowy.

Analogicznie, Scrum jest dobrym, sprawdzonym przez czas rozwiązaniem pewnych problemów. Za chwilę przyjrzymy się im bliżej. Na razie spójrzmy na jeszcze jeden aspekt. Wyobraźmy sobie, że znamy dobry framework do parsowania, nazwijmy go GoodParser. Jest najszybszy i ma najlepszy mechanizm procesowania wyjątków. Importujemy go do naszej aplikacji i patrzymy, jakie ma klasy. Potem stwarzamy własne klasy o takich samych nazwach, a te oryginalne – ignorujemy. Czy możemy powiedzieć, że korzystamy z GoodParsera? Czy będziemy słusznie oczekiwać, że uzyskamy jego korzyści? Czy też po prostu dodaliśmy nieużywaną zależność do naszego projektu?

Właśnie do takiej sytuacji trafiamy, kiedy chcemy działać w ScrumButach. Musimy wiedzieć, do czego framework służy i jaki problem rozwiązuje. Jeśli mówimy, że „u nas to nie zadziała”, ale wdrażamy część scrumowych aspektów, to robimy to samo, co w sytuacji z GoodParserem. Skoro nie zadziała, to może mamy nie te problemy, które rozwiązuje Scrum i powinniśmy poszukać innego narzędzia. Tak samo jak nie będziemy stosować frameworku do parsowania, żeby zarządzać bazą danych.

Frameworki agile’owe

Scrum jest agile’owym frameworkiem. Agile jest filozofią, a nie konkretną implementacją, czyli – innymi słowy – jest abstrakcją. Można powiedzieć, że jest jak klasa abstrakcyjna lub interfejs. Zwinne frameworki są realizacją tej filozofii w praktyce. Możemy spojrzeć na to w następujący sposób:

Public interface Agile {

}

Public class Scrum implements Agile {

}

Public class Kanban implements Agile {

}

Spójrzmy też na to, jak pojawiła się filozofia Agile. W 2001 roku osoby z najbardziej wydajnych firm z tworzenia oprogramowania spotkali się razem, żeby ustalić, co odróżnia ich od reszty firm. Cóż takiego oni robią inaczej, że mają o tyle lepsze wyniki? W wyniku tych dyskusji zostały zdefiniowane zasady oraz wartości filozofii zwinnej, które znamy z Agile Manifesto. Czyli, to nie jest tylko przypuszczenie, że „byłoby fajnie, gdybyśmy stawiali więcej na współpracę z klientem niż na negocjowanie umów”. Zasady te powstały z  praktyki, z rzeczywistych wyników najlepszych zespołów w branży. Zestawienie sukcesów projektów agile’owych i waterfallowych pokazuje, że tylko 26% projektów tradycyjnych osiąga swoje cele w porównaniu do 42% projektów zwinnych. Co więcej, w przypadku dużych projektów ten wynik wynosi 18% kontra 9% na korzyść Agile.

Frameworki agile’owe są implementacjami filozofii Agile, dostosowaną pod bardziej konkretne problemy lub zadania. Zespoły do wsparcia technicznego, zazwyczaj nie pracują w Scrumie, lecz w Kanbanie – innym frameworku zwinnym, który bardziej pasuje do ich trybu pracy. Scrum natomiast jest dostosowany pod tworzenie produktów.

Jakie problemy rozwiązuje Scrum? Jeśli GoodParser jest gotowym i skutecznym narzędziem do parsowania plików, to Scrum jest gotowym i skutecznym narzędziem do:

1. organizacji pracy nad produktem i podziału jej na dobrze zdefiniowane zadania,
2. ustalania zasad współpracy Developerów pomiędzy sobą oraz z innymi stronami uczestniczącymi w przedsięwzięciu (Product Owner, klient),
3. minimalizacji ryzyka, maksymalizacji jakości i usuwania wszystkich możliwych przeszkód.

A przede wszystkim Scrum jest frameworkiem do osiągnięcia Celu Produktu w najlepszy (najszybszy, najtańszy, itp.) realnie możliwy sposób. Tylko to wszystko zadzieje się pod warunkiem, że stosujemy Scruma tak, jak należy. A to już o wiele szerszy temat, na który jest mnóstwo postów na tym blogu. Fajnie by było, gdyby było ich więcej właśnie z Developerskiej perspektywy. Dlatego też dobrze, że następne posty z tego cyklu opowiedzą więcej o tym, jak Scrum służy Developerom.