Po ponad dwóch latach pracy w wysoce wyciszonej strukturze działu rozwoju „samotnego wilka”, wdrażamy Agile SCRUM. Świetny. Lubię Agile; jako deweloper utrzymuje koncentrację, zajęcie i produktywność, nie zmuszając niezliczonych interesariuszy do popchnięcia projektu za projektem do gardła, oczekując, że wszystkie zostaną wykonane wczoraj.
Jest jednak jeden aspekt przejścia na SCRUM w porównaniu z naszym obecnym „modelem”, który moim zdaniem nie spodobałby się osobom spoza rozwoju w najmniejszym stopniu. To jest ich obecna zdolność do namawiania małych zmian „podczas oczekiwania”. Duża część naszego rozwoju przeznaczona jest wyłącznie do użytku wewnętrznego, a większość z nas jest w tym samym budynku. Tak więc od wielu lat kierownik działu lub menedżer w innym miejscu przychodzi do „właściciela bazy kodów” określonej aplikacji i prosi o małe rzeczy (czasem nie tak małe, ale całkiem nieźle przyjmujemy trzy- tygodniowe projekty oparte na tych „przejazdach”). Nawet nasz szef czasami przekazuje rzeczy, które mu przywołano w ten sposób. Bardzo często, jeśli pracujemy w danej bazie kodu, możemy po prostu wyskoczyć plik źródłowy,
Dzięki podstawowej metodologii Agile SCRUM te poprawki byłyby rejestrowane jako wady (nie spełniliśmy wymagań określonych w poprzednio skonsumowanej historii) lub nowe małe historie (spełnialiśmy wszystkie określone wymagania, ale wymagania te były niepełne, niejasne lub niepoprawne lub zmieniły się po dostarczeniu, gdy użytkownicy zobaczyli nowe funkcje). Tak czy inaczej, zdecydowana większość byłaby co najwyżej jednopunktowa, jeśli nie zerowa, i miałaby stosunkowo niski priorytet (system nadaje się do użytku w obecnym stanie, ale byłby o wiele fajniejszy, gdyby ...), co sprawia, że jest mało prawdopodobne, aby były wprowadzony do sprintu podczas pracy zaległości z góry na dół.
Możliwość ta została podniesiona na spotkaniu deweloperów jako źródło aktywnego sprzeciwu wobec naszego procesu Agile przez inne działy, które postrzegałyby to jako mniej „zwinne” niż nasza obecna zdolność do wprowadzania drobnych poprawek na żądanie. Jest to ważna sprawa IMO; interesariusze stojący za PO nie zawsze zgadzają się co do tego, co jest najważniejsze, ponieważ nie wszyscy mają ten sam punkt widzenia, jednak zazwyczaj tylko menedżerowie podejmują ostateczną decyzję, a zatem ich stronniczość jest tą, która pokazuje się w rejestrze produktu.
Następnie zaproponowano rozwiązanie, które wstępnie nazwano „słoikiem z cukierkami” (innym wyrzuconym terminem była „łódź sos”). Małe poprawki wymagane przez „małych facetów” w różnych działach, które nie są wadami w istniejącej historii, które są szacowane na podstawie konsensusu lub aklamacji w zespole, aby zabrać mniej niż połowę dnia programisty, i to by było natychmiastowy, znaczący, pozytywny wpływ na wrażenia użytkownika w opinii użytkownika końcowego, są umieszczane na liście równolegle do głównego zaległości. Zostałyby zidentyfikowane jako „historie”, ale byłyby oddzielone od głównego portfela „dużych” historii podlegających priorytetowi. Jeśli w dowolnym momencie podczas normalnego przebiegu sprintu zdarzy się, że będziemy pracować w obszarze systemu, w którym można wprowadzić jedną z tych poprawek, czyniąc usprawnienie trywialnym, możemy wprowadzić ulepszenie do sprintu i zakodować go wraz z większą historią. Robiąc tonie może zagrażać ukończeniu większej historii lub innej zaangażowanej pracy. OP miałby również dostęp do tej listy, a jeśli pracowaliby nad nadchodzącą historią użytkownika dotykającą podstawowej funkcji związanej z poprawką, mogliby ją złożyć jako wymaganie, a następnie spełnilibyśmy to wymaganie, tak jak my inny. Pomyślano, że sprawi to, że poprawki będą bardziej prawdopodobne niż wcześniej.
Wywołało to reakcję wśród nas na szkolenie ScrumMaster „uh-uh”. Istnieje jeden zaległość. Dwa zaległości wprowadzają pytanie, który element nr 1 jest naprawdę najważniejszy, które elementy listy określają rzeczywistą prędkość, i które z dwóch zaległości, do których należy historia (przy każdym wyznaczeniu wielkości / złożoności wystąpią przypadki, które spadną względnie dowolnie po jednej lub drugiej stronie). „Niech proces zadziała”, powiedzieliśmy; jeśli zmiana jest naprawdę znacząca dla użytkowników końcowych, zrobią wystarczająco dużo hałasu, aby zmusić kierowników działów do podjęcia decyzji dotyczących czasu / pieniędzy na pokładzie, i zostanie to podniesione do świadomości zespołu deweloperów na szczycie zaległości.
Pomyślałem, że zadam to pytanie: Czy Pana zdaniem równoległa lista opowieści o „kęsach” miałaby wartość, gdyby szybsze były małe, przydatne, ale ostatecznie o niskim priorytecie zmiany, czy też ogólnie jest to lepsza decyzja złożyć je w głównym zaległości i pozwolić, aby podstawowy proces rządził ich włączeniem do sprintu?