Światowy dzień pocałunku (ang. kiss) przypada na 6 lipca. Wiem, bo sprawdziłem. Autorem pomysłu jest prawdopodobnie firma stomatologiczna. Logiczne. Nielogiczne wydaje się połączenie pocałunków i Scrum. Po serii tekstów o Kanban, dziś zajmiemy się czymś bardziej metafizycznym – porozmawiamy o KISS w Scrum.
Pocałunki w Scrum
Pocałunków w Scrum jako takich nie ma, chyba że podczas celebracji kolejnego udanego Sprintu czy wdrożenia. KISS (ang. Keep It Simple, Stupid) to nic innego jak koncept, który tłumaczony na język ojczysty brzmi „Zrób to prosto, idioto”. Ostatnie słowo z tłumaczenia nie koniecznie pasuje do tego bloga, ale nie będziemy przecież poprawiać twórców. Zrób to prosto, co w jasny sposób przywołuje nam skojarzenia z… pragmatyzmem.
Lubię smaczki w postaci takich akronimów. Pasują one idealnie do naszego życia. Jeszcze bardziej lubię doszukiwać się ich pochodzenia. Źródłem KISS jest wojsko amerykańskie, a czas powstania to okolice lat 60 ubiegłego wieku. Idea KISS wdrażana była po to, aby uzmysłowić konieczność prostoty w projektowanych samolotach. Założeniem było to, aby każdy, nawet średnio doświadczony mechanik był w stanie serwisować maszynę która do niego trafi. Istniała przecież duża szansa, że będzie obsługiwał ją w warunkach polowych i przy niedostępności specjalistycznych narzędzi.
KISS, czyli prostota
To mógłby być kolejny z tekstów o prostocie, ale nie pójdę w tę stronę. Opisywaliśmy już czym jest pragmatyzm i kim jest pragmatyk, pisaliśmy o tym, że „Worse is better„. Temat wydaje się być wyczerpany. Dlatego swoje myśli skieruję na wybór rozwiązania z pośród dostępnych alternatyw. A może jeszcze wcześniej, na określenie produktu i jego zakresu. Czy nie będzie z nim dokładnie tak samo jak z budowanym samolotem?
Patrząc na produkt, mimo, że nie lubię tego stwierdzenia widzimy jego dwie warstwy: biznesową i techniczną. Pełna zgoda co do tego, że powinniśmy widzieć jedno spójne wymaganie. Ale nikt mi nie powie, że patrząc na zadanie do wykonania nigdy nie będziemy rozważać tych dwóch aspektów.
Zresztą biznesowa część produktu została w większości przypadków już opisana, najczęściej w postaci User Story. Przecież powinno być ono napisane „językiem zrozumiałym dla zgłaszającego”, a więc najczęściej biznesu. Załóżmy więc, że jednak mamy dwie warstwy i zastanówmy się jak one wzajemnie na siebie wpływają. Przede wszystkim – jak przekłada się skomplikowanie jednej z nich na drugą.
Zależności
Mówiąc o zależnościach mamy najczęściej na myśli zależności między wymaganiem A i wymaganiem B. Na etapie realizacji te będą występowały najczęściej. Ale mówiąc o zależnościach nie możemy zapominać o wpływie pomysłu na jego realizację (i odwrotnie). Im bardziej skomplikowany pomysł, tym realizacja również będzie bardziej skomplikowana. A to już kłóci mi się z ideą KISS.
Powinniśmy dążyć więc do tego, aby przygotowywane rozwiązanie było proste, zrozumiałe dla wszystkich i co najważniejsze możliwe do utrzymania przez kogokolwiek. Na powyższe składają się znów co najmniej dwie czynności. Nie oszukujmy się – domena w której przyszło nam pracować nie zawsze jest zrozumiała. Do najlepszych przykładów należą tu np. zespoły wytwarzające rozwiązania na potrzeby departamentów księgowości. Nie zawsze wymagania są jasne. Jak więc mamy „keep them simple”?
Tutaj dochodzimy do sedna. Skoro nie są jasne, potrzebujemy Refinementu. To na nim powinniśmy przecież wyjaśnić „co jest do zrobienia”. Im prościej tym lepiej – simple. A gdy już wiemy „co” mamy zrobić i udało nam się te nasze „co” doprowadzić do prostego i zrozumiałego stanu, to „jak” obarczone będzie mniejszym ryzykiem. Po pierwsze znam założenia biznesowe, po drugie nie tworze rozwiązania pod coś, czego nie rozumiem. Nie komplikuję go i robię dokładnie to, co jest jego przedmiotem. Prosto jak tylko się da.
Bo trudno jest skomplikować proste wymaganie. To te niezrozumiałe i skomplikowane są przyczyną dla których budujemy koszmarne i nieutrzymywalne rozwiązania (patrz: dług technologiczny).
KISS w Scrum
Idea KISS, choć początkowo dotyczyła tylko samolotów, szybko się rozprzestrzeniła. Nauka, inżynieria, życie społeczne, a idąc dalej – tworzenie oprogramowania czy definiowanie zakresu projektu czy produktu. Przedmiotem prac w tych wszystkich i wielu innych obszarach powinny być rzeczy proste. Po co komplikować sobie życie, po co komplikować życie innym?
Pierwszą rzeczą, o której pomyślałem w kontekście KISS była wymiana żarówki w samochodzie (tej w reflektorze). Są pojazdy, w których wymiana żarówki wymaga wizyty w warsztacie samochodowym, a są również takie, w których wymiana jest czynnością polegającą na wykonaniu kilku prostych czynności. W przypadku tych pierwszych i koniecznej wizycie w warsztacie musimy dodatkowo zapłacić. Którą markę wybierzecie?
KISS to idea, która powoduje, że rozwiązanie, które przygotowujemy jest tańsze. Brak implementacji tych wszystkich skomplikowanych elementów powoduje, że mniej się napracujemy, więcej zrobimy, a klient będzie bardziej zadowolony. I o to nam przecież chodzi!
Ale aby móc dojść do tego stanu rzeczy, musimy doskonale wiedzieć, co mamy zrobić. Do tego posłuży nam proces Scrum, od momentu pojawienia się wymagania w Backlogu Produktu, poprzez Refinement, aż do zaplanowania w Sprincie. Keep It Simple, od początku do końca. Pamiętajcie o tym!
