Coraz więcej firm i zespołów używa metodologii lekkich do wytwarzania oprogramowania. Wśród tych metodologii bardzo popularny jest Scrum. Nie jestem specjalistą od tej Scruma i dlatego chciałbym zadać trzy pytania, na które obecnie nie znam odpowiedzi. Może ktoś bardziej doświadczony w tej metodyce dopisze do nich odpowiedzi?
Scrum a utrzymanie systemu
Teoria Scruma jest prosta: przed rozpoczęciem sprintu definiujemy, które zadania z backlog’u wchodzą do tego sprintu. W czasie sprintu wykonujemy je – i bardzo ważnym założeniem jest to, że na czas sprintu zestaw zadań pozostaje niezmienny. Nawet właściciel produktu nie ma prawa ich zmieniać.
To wszystko ma szansę bardzo ładnie działać w sytuacji, kiedy mamy dość stabilny system, do którego dodajemy kolejne funkcjonalności. Co zrobić jednak w przypadku systemu, który zawiera w sobie sporo błędów, a te błędy wymagają pilnej poprawy albo przynajmniej kosztownej analizy przyczyny błędu?
Pierwsza teoretyczna odpowiedź jest prosta: najpierw poprawić błędy w systemie i dopiero wtedy tworzyć kolejne funkcjonalności. Ale w praktyce jest to często niemożliwe – nie możemy zatrzymać rozwoju systemu na dłuższy okres i to z bardzo istotnych powodów: bo nie zaakceptuje tego klient; bo rynek ucieknie nam za bardzo do przodu; bo nie mamy na to pieniędzy… Dlatego często prace utrzymaniowe przeplatają się z pracami rozwojowymi. I często odbywa się to z niszczycielskim skutkiem dla dotrzymywania wcześniej założonych planów i terminów…
Prezentacja stworzona przez Hamida Shojaee (polecam!) mówi, że błędy związane z rozwijanymi funkcjonalnościami powinno się poprawiać od razu w sprintach, natomiast resztę błędów dobrze jest poprawiać od czasu do czasu w „kill bugs sprint”. Ale nie zawsze ta odpowiedź może być zastosowana praktyce – są błędy, które atakują nas znienacka, a ich poprawienie nie może czekać do następnego sprintu czy wydania.
A zatem: czy możliwe jest stosowane Scrum’a, kiedy bieżące i pilne prace utrzymaniowe (analiza i poprawianie błędów) przeplatają się z realizacją nowych funkcjonalności?
Scrum a architektura systemu
Jednym z założeniem Scrum’a jest to, że kod nie ma właścicieli – dowolna osoba może wykonać refaktoryzację kodu, w momencie kiedy uzna to za pożądane. A o poprawność działania systemu po refaktoryzacji powinny zadbać nam automatyczne testy jednostkowe.
Natomiast w praktyce może być tak, że posadzenie do rozwoju systemu dwudziestu programistów bez osoby pełniącej rolę „technical leader’a” skutkuje rozjazdem systemu we wszystkich możliwych aspektach: począwszy od nazewnictwa zmiennych, poprzez sposoby odwoływania się do bazy danych, sposoby komunikacji z innymi systemami, kończąc na rozjechanym interfejsie użytkownika. Podobne funkcje systemu są realizowane na różne sposoby, a sam system staje się z czasem bardzo trudno utrzymywalny.
Rozwiązaniem, które jest stosowane często w praktyce dla dużych systemów (podkreślam słowo „duży” – problem jest tym bardziej dotkliwy, im większy jest rozwijany system), jest powierzenie jakiejś osobie – z reguły doświadczonemu programiście – roli architekta systemu lub lidera technicznego. Ta osoba powinna m.in. dbać o spójność rozwiązań i mechanizmów stosowanych w systemie. Jeżeli nasze środowisko pracy składa się z wielu współpracujących systemów – osoba ta powinna decydować o rozmieszczeniu funkcji oraz konstrukcji interfejsów pomiędzy tymi systemami.
A zatem: w jaki sposób pracując w Scrum’ie można dbać o zachowanie spójności architektonicznej dużego systemu i kto powinien do robić?
Scrum a skalowalność pracy
Jeżeli pracujemy w firmie, która ma dostarczać w miarę stałą ilość pracy w czasie, sprawa jest prosta. Mamy dostępnych ileś osób, tworzymy z nich zespół bądź kilka zespołów, zaczynamy pracę.
Ale zdarzają się trudniejsze przypadki – bywają firmy IT, których budżet z roku na rok się zmienia. W jednym roku te osoby muszą zrealizować trzy projekty, w drugim dziesięć, w trzecim cztery. Można wtedy oczywiście zmieniać liczebność zespołu – ale tak jak zatrudnianie nowych osób jest zjawiskiem bardzo pozytywnym, tak operacja zmniejszenia zespołu jest bardzo trudna i destruktywna – oczywiście przede wszystkim dla osób, które tracą pracę, ale również dla całego zespołu. Alternatywnie można stosować wtedy outsourcing – pewne elementy pracy oddaje się firmom zewnętrznym zamiast realizować je wewnętrznie.
Ale jak można stosować outsourcing w Scrumie – czy zastosowanie go nie niszczy bardzo ważnej cechy, jaką jest samowystarczalność, samoorganizacja oraz doskonalenie się zespołu?
I zasadnicze pytanie: czy jest jakiś sposób, aby w Scrumie zapewnić pracę w warunkach zmiennego zapotrzebowania na pracę organizacji?
Tyle pytań na dzisiaj. Gdyby ktoś chciał się podzielić odpowiedziami wynikającymi ze swoich praktycznych doświadczeń lub dopisać jakieś nowe pytania – zapraszam!
Witam.
Pierwsze pytanie: z ilości czasu dostępnego dla zespołu ucinane jest 20-30% (w zależności od ilości błędów i problemów związanych z utrzymaniem jakie się pojawiają w sprincie – trzeba to uśrednić) i w ten sposób utrzymujemy stałą ilość wytwarzanych funkcjonalności oraz realizujemy poprawki do błędów które wymagają natychmiastowej reakcji. Pozostałe błędy wchodzą do najbliższego sprintu (ale tu decyduje product owner – czy są one ważniejsze od nowych funkcjonalności czy można żyć z nimi jeszcze klika tygodni). Pracowałem w takim trybie i jest on bardzo wygodny – jak w danym sprincie nie wpada dużo błędów zawsze jest czas żeby podgonić z refaktoringiem jakiejś części lub dopisaniem unit testów.
Co do pytania drugiego: Tak, osoba która ogarnia całość musi znajdować się niejako obok zespołów tak by mogła doglądać kierunku w jakim jest rozwijany kod. Tylko w ten sposób struktura zostanie zachowana. Byłem liderem technicznym w dosyć dużym projekcie i się to tam sprawdzało.
Co do trzeciego pytania to nie wiem – nie miałem do czynienia z taką sytuacją – zespoły tylko się rozrastały. Ale wydaje mi się, że outsourcing jest tutaj rozwiązaniem.
Scrum nic nie wspomina o technical leaderze co znaczy, że rownież nie zaprzecza istnieniu takiej osoby w projekcie. Chociaż z drugiej strony pozostaje pytanie czy taka osoba powinna być w zespole czy może poza nim (czyli niejako poza scrumem)? Mialem do czynienia z różnymi przypadkami i najlepiej (co nie znaczy, że inne podejścia nie dzialaly) sprawdzało się jednak podejście w którym nie było TL, a w zasadzie cały zespól kolektywnie podejmował decyzje architektoniczne jak TL wiec każdy z nich był TL. Ważnym jest tutaj element komunikacji i roli planowania w scrumie na poziomie sprint planningu i daily scrum które pozwalają na inicjowanie rozmów o takich właśnie decyzjach i problemach jak najczęściej. Ponadto krótkie iteracje zmniejszają ryzyko tego ze rozjazd między zespołami czy zależnymi aplikacjami będzie bardzo duży, a w najgorszym wypadku do kosza pójdzie praca z ostatniego sprintu. To oczywiście wymaga synchronizacji pracy na zakończenie każdego sprintu – uwaga: nie oznacza to, że tylko wtedy wszystko ma być dopinane tak żeby razem dzialalo, w definition of done powinno zawierać się stwierdzenie, że item jest ukończony dopiero, gdy przeprowadzone zostały testy integracyjne lub protokoły komunikacji zostały zatwierdzone przez wszystkich zainteresowanych.
Odnośnie wspólnego kodu i problemów z nim to ważne jest ustalenie pewnych prostych zasad co do standardów kodowania, które wielu problemów pozwalają uniknąć. Ponadto sprawdza się w takich przypadkach idea pisania czystego kodu – polecam absolutnie każdemu nie tylko programistom do przeczytania książkę Clean Code – Robert C. Martin, w której jest przepis jak takich problemów unikać.
Co do bugow to widzę, że jest juz tam bardzo trafny komentarz powyżej na ten temat więc nie będę się powtarzał. Nie przywiązywał bym się tylko do tych 20-30%.
Odnośnie stałości zespołu to faktycznie ciągłe fluktuacje i roszady są bardzo problematyczne i Scrum niestety albo stety wymaga własnie względnej stałości zespołu.
Zmienność projektów nie stanowi dużego problemu pod warunkiem, że to cały zespół jest migrowany z jednego projektu na drugi, z jednego backlogu na drugi. Oczywiście wymagany jest pewien narzut czasu na wdrożenie się w nowy projekt, ale cały zgrany zespół robi to znacznie szybciej niż pojedyncze jednostki.
Przypomina mi się stwierdzenie, że: „Jeśli chcesz kazać swoim pracownikom wykonywać multitasking to równie dobrze możesz kazać im pić w pracy – w obu przypadkach wydajność spada o 50%”
Wiele firm (zwłaszcza tych większych) używa zespołów scrumowych jako zespołów od zadań specjalnych, które w momencie zwiększonego ryzyka dotyczącego tego że jakiś projekt ma problemy są w taki projekt wrzucani by uratować sytuację.
Scrum został stworzony do skomplikowanych problemów, czasem mówi się nawet, że do tych z pogranicza chaosu. Scrum to takie pudełko w którym zamykamy jakiś fragment projektu wycięty ze skomplikowanej i zmiennej rzeczywistości i przenosimy to pudełko na czas iteracji do spokojnej, prostej bo określonej zasadami scruma, zamrożonej – niezmiennej rszczywistości, w której pracuje się stosunkowo prosto.
Cześć Stasiu:)
jak zawsze celne pytania. Nie będę kusił się o precyzyjną odpowiedź na wszystkie, natomiast polecam artykuł, który był dla mnie inspiracją do wdrażania elementów SCRUM w naszej organizacji. Agile w RUP