Chciałbym zaapelować do wszystkich klientów oraz właścicieli produktów (Product Ownerów), aby przeczytali ten artykuł.
SCRUM to metodologia zwinna, która witaje zmiany. Mimo jej dużej otwartości, dlaczego nie jest możliwe zmienianie specyfikacji istniejącego sprintu? Aby projekt nie stał się całkowicie zdezorganizowanym chaosem, który może prowadzić do jego anulowania. Jak to miało miejsce w Iraku po ostatnim „importowaniu demokracji”.
Co jest zmianą, a co nią nie jest? Dla właścicieli produktów mam złą wiadomość: tylko SCRUM Master lub członkowie zespołu SCRUM mogą to ocenić. Z perspektywy nie-programisty to tak, jakby Twoja mała córka uśmiechała się do Ciebie, a Ty miałbyś ocenić, czy ma próchnicę. Nie masz pojęcia. Zasadniczo, pod pojęciem „zmiana” nie traktujemy drobnych zmian, takich jak zmiana tekstu, zmiana kolorów, zmiana treści przycisków czy drobne przesunięcia komponentów. W przypadku wszystkiego, gdzie zmieniają się dane wejściowe i wyjściowe, należy podejrzewać, że to nie jest drobna zmiana.
Na potrzeby tego artykułu załóżmy, że tworzymy portal internetowy. W sprincie, który obecnie realizujemy, mamy ściśle określone User Stories (historie użytkowników), które będziemy implementować. Mamy określony czasowy szacunek (w roboczogodzinach), ile czasu zajmą poszczególne User Stories.
Jeśli klient (lub Product Owner, albo niedoświadczony SCRUM Master) spróbuje dodać jedną User Story do istniejącego sprintu, wywoła to następujące działania z perspektywy SCRUM Mastera:
Jakie czynności i których ludzi wpłynie jedna User Story w obecnym sprincie?
Jeśli SCRUM Master nie będzie aktywnie pracował nad integracją zespołu, zespół może się łatwo demotywować i zacząć się kłócić. W końcu, aby pokłócić dwóch ludzi, nie trzeba mieć wykształcenia wyższego.
Teraz załóżmy idealny przypadek, w którym ludzie chcą pracować, lubią się i mają stworzone odpowiednie warunki do pracy. Wyobraź sobie, że początkowo zdefiniowałeś User Story, którą członek zespołu opracował dokładnie tak, jak chciałeś. Został dłużej w pracy, odwołał nawet swój ulubiony squash, aby praca była wykonana jakościowo i na czas. Następnie zmieniasz specyfikację tej User Story. Myślisz, że to tylko drobna zmiana, ale tak naprawdę zmienia to przepływ danych, co wymaga zmiany modelu bazy danych, a więc i kodu. Będziesz twierdzić, że to tylko drobiazg. Jak myślisz, jakie to wywoła reakcje w członku zespołu? Nie mówię, abyś nie zmieniał specyfikacji istniejących User Stories, tylko abyś brał pod uwagę takie uczucia.
Słyszałeś o efekcie kaskadowym? Jeśli w jakimś miejscu nastąpi zmiana, może ona rozprzestrzenić się do obszaru, gdzie nie ma bezpośredniego powodu do tej zmiany. Jak to przełożyć na praktykę w rozwoju oprogramowania? Załóżmy, że tabele na portalu filtrujemy za pomocą uniwersalnego modułu filtracji, który jest używany przez wszystkie tabele przez standardowe API. Jeśli zmienimy uniwersalne filtrowanie tabel (np. strukturę klas, które obsługują filtrowanie), może to wpłynąć (lub wywołać nieoczekiwany stan) na tabele, które również używają tego modułu. Z perspektywy programisty, jedyną obroną przed tym problemem jest ciągłe testowanie, co stanowi podstawę zapobiegania.
Ale jak zapobiec sytuacji, że najpierw zaprojektujesz User Story, a potem ją zmienisz po implementacji? Możesz spróbować zwizualizować ją przynajmniej za pomocą Wireframe (prostym modelem 2D, ekranem logicznym, gdzie nie uwzględniamy grafiki, wystarczy na czystą kartkę A4 z długopisem), nawet jeśli to będzie drobna zmiana. Już samo to, że pomyślisz o tym, jak ma wyglądać wizualnie, pomoże Ci uświadomić sobie cechy tej historii na początku jej tworzenia. Może uda Ci się pomyśleć o historii, gdy będzie już zaimplementowana i może doprecyzujesz jej wymagania. Może, gdy spróbujesz wyobrazić sobie samą historię w finalnej implementacji, zapiszesz na papierze poszczególne punkty, które pomogą Ci dostrzec inne kwestie.
Jeszcze raz powtarzam, SCRUM to metodologia zwinna, która witaje zmiany. Jej głównym celem jest jakościowe oprogramowanie. Aby uniknąć dezorganizacji i chaosu sprintu, najlepszym rozwiązaniem jest przestrzeganie poniższego procesu: