Zaległości w zadaniach „wielkości kęsa” równolegle do zaległości funkcji „głównej”?

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?

Opowiem o kilku punktach, które, mam nadzieję, pomogą ci znaleźć drogę:

1. „ SCRUM ” polega na zwinności. Wymagany jest zdrowy rozsądek. Jeśli zmiana jest zmianą kilku minut, nie sądzę, że potrzebujesz do tego zaległości. Jeśli to więcej niż 2 godziny, myślę, że powinieneś przemyśleć to jeszcze raz. Nie należy robić wszystkiego, co jest „łatwe do wygrania”. W SCRUM pracujesz według priorytetów. Myślę, że organizacja producentów musi uzyskać informacje o tym, co zyskasz na dodaniu i ile wysiłku wymaga. Tylko wtedy organizacja producentów może zdecydować, czy jest to ważne, czy nie. Przechodząc do SCRUM, czasami pojawia się wiele pytań, a programiści często mówią „ale to zajmie tylko ד kilka godzin”. Więc co? Kilka godzin to czas, nie wszystko, co jest krótkie, musi zostać uwzględnione.
2. Kiedyś pracowałem nad projektem, w którym mieliśmy „zaległości inżynieryjne” . Ten zaległości zawierał elementy sugerowane przez programistów w celu ulepszenia produktu. Te elementy nie miały wyraźnej wartości użytkownika (ale miały domyślną wartość użytkownika). Na przykład: refaktoryzacja komponentu w kodzie. Opisaliśmy zmianę, wysiłek i zysk (w tym przypadku nie możesz nic przedstawić użytkownikowi. Ale jeśli takie refaktoryzowanie powoduje szybsze rozwijanie nowych możliwości, to z pewnością jest to zysk dla użytkownika). Nasza PO zdecydowała, że ​​podczas wersji powinniśmy inwestować 10% każdego sprintu (średnio) na takie przedmioty. Przed każdym sprintem, kiedy PO decydował o zaległościach w nadchodzącym sprincie, upewniał się, że mamy 10% pozycji do zalegania. Zatem 2 zaległości wersji -> 1 zaległość sprintu.
3. Bufory - Rozpoczynając pracę w SCRUM, ludzie często zapominają, że jako inżynierowie oprogramowania wychodzimy w świat niepewności. W porządku jest zaliczenie 1 dnia pracy jako 6 godzin zamiast 8. Załóżmy, że masz 15-dniowy sprint, co oznacza, że ​​masz dodatkowe 30 godzin na spotkania, na rzeczy, które zajęły zbyt długo, i tak - również dla tych małych rzeczy, które są zbyt drobne, aby je zapamiętać, ale są częścią naszej codziennej pracy.
4. Pozostań skupiony - Wreszcie, w SCRUM ważne jest, aby pozostać skupionym. Zdecyduj, ile wysiłku i jaki priorytet chcesz zainwestować w takie zadania, i pamiętaj, aby zainwestować ten czas i wysiłek. Nie dryfuj do pracy nad „małymi rzeczami” tylko dlatego, że są małe. Masz PO, które pomogą Ci podjąć decyzję i masz zdrowy rozsądek.
5. Bądź zwinny - na koniec nie zapomnij wypróbować różnych metod podejścia do problemu, zadaj sobie pytanie, czy to rzeczywiście najlepszy sposób. Ulepsz po drodze.

Powodzenia :)

Ramy programowania, takie jak Agile i SCRUM, mają na celu zastosowanie dyscypliny i struktury do rozwoju. Jednak dyscyplina i struktura wydają się być antonimami zabawy i kreatywności. Zazwyczaj musisz ciężko pracować, aby ustanowić i utrzymać dyscyplinę. Bardzo trudno jest znaleźć równowagę między tymi przeciwnymi koncepcjami. Dlatego też ramy zwykle unikają tematu.

W moim ostatnim projekcie zauważyliśmy, że programiści potrzebowali każdego dnia trochę czasu, aby odświeżyć lub oczyścić swoje głowy itp. Dano im budżetowy czas (0,5 godziny / dzień lub 2,5 godziny / tydzień), w którym mogli zrobić wszystko, w ciągu powód (z możliwością zastosowania do czegoś w pracy). Aby zachować dyscyplinę, poproszono ich o udokumentowanie swoich działań, aby mogli uzyskać uznanie za wszelkie osiągnięcia itp. Posiadanie określonego budżetu na „słoik z cukierkami” mieściło się w naszych ramach czasowych i zapobiegało wymykaniu się spod kontroli.

Przy okazji nazywaliśmy nasz „chłodzeniem projektu”, który okazał się źródłem wielu dobrych pomysłów i ulepszeń w tej firmie.

Powinieneś zachować małe historie w głównym zaległości.

Mam podobne problemy do tego, co opisujesz, chociaż nie używam scrum. Widzę, że napotykasz wyzwania związane z ustalaniem priorytetów i wydajnością .

Wygląda na to, że na swój „stary sposób” każdy był domyślnie upoważniony do tego, aby jego zadanie stało się „najwyższym priorytetem”, jeśli odwiedzi biuro dewelopera. Ma to pewne zalety. Pytający czuje się, jakby odpowiedział na nie, a zarówno zleceniodawca, jak i programista otrzymują „szybką wygraną”.

Minusem jest to, że częste wstawianie tych zadań powoduje spowolnienie lub wykolejenie zadań o najwyższym priorytecie, które zostały uzgodnione z właścicielem produktu. (Uwaga: często wszyscy nie doceniają czasu potrzebnego na te „szybkie” poprawki).

Z mojego doświadczenia wynika, że ​​próba wyciśnięcia zadania o niskim priorytecie podważa zalety ustalania priorytetów. Jako programista ustalanie priorytetów potwierdza mi, że pracuję nad tym, nad czym właściciel produktu chce, abym pracował. Właściciel produktu powinien zdecydować, czy chce wziąć na siebie dodatkową pracę i ryzyko (choć niewielkie) złożenia w prośbie „miło mieć”.

Często, gdy proszę interesariuszy o ustalenie priorytetów, pytają mnie: „Czy możesz to wcisnąć?”. Implikowane życzenie polega na tym, abym magicznie wykonał nowe zadanie bez wpływu na obecny najwyższy priorytet.

Często zdarza mi się, że interesariusze żądają LargeImportantProject i SmallLessImportantTask. Dylemat brzmi: czy SmallLessImportantTask powinien czekać na zakończenie LargeImportantProject (czy mieć blokadę drogi)? Są kompromisy, a moje doświadczenie było takie, że właściciel produktu musi zdecydować. (Jeśli właściciel produktu nie zdecyduje, zespół programistów musi zgadywać).

Jednym z celów scrum (i ogólnie zarządzania projektami) jest unikanie przeszkód w zadaniach o najwyższym priorytecie. Gdy stajesz się bardziej wydajny, jest mniej miejsca na wyciskanie dodatkowej pracy „miło mieć”.

Wydajność może być przerażająca, ale widziałem korzyści przewyższające koszty na dwa ważne sposoby.

1. Gdy stajesz się bardziej wydajny, zwiększasz zdolność swojego zespołu do wykonania cennej pracy, w tym do wniosków „miło mieć”.
2. Jeśli żądanie jest naprawdę „miłe w odbiorze”, prawdopodobnie jest całkowicie uzasadnione, aby żądanie czekało na zajęcie się ważniejszymi priorytetami biznesowymi.

W mojej opinii; Twoim problemem jest sposób, w jaki zadania są traktowane priorytetowo w zaległościach. Na przykład „priorytet” może uwzględniać zarówno znaczenie, jak i szybkość jego realizacji. Coś, co nie jest tak ważne, ale można je ukończyć w 10 minut, może mieć wyższy priorytet niż coś ważniejszego, co zajmie kilka tygodni.

Od jakiegoś czasu pracuję w zwinny. Wszystko, co mogę powiedzieć, to to - są sytuacje, w których naleganie na metodologię i wszystko, co ona zawiera, jest całkowicie błędne. Musisz być ZWINNY, a dopracowanie metodologii w konkretnych sytuacjach jest, IMO, koniecznością.

Jak powiedział wyżej Avi - „SCRUM” polega na byciu zwinnym. Wymagany jest zdrowy rozsądek. Jeśli zmiana jest zmianą kilku minut, nie sądzę, że potrzebujesz do tego zaległości.

Jeśli zmiana wymaga czasu, oznacza to, że nie jest wcale tak „nieszkodliwa” i powinna być dobrze udokumentowana.

Na podstawie twojego pierwszego pytania i późniejszych wyjaśnień, właśnie to zauważyłem, że twoje punkty bólu są

• Stale zmieniające się wymagania
• Niemożność skupienia się programistów na innych obszarach aplikacji, tj. jesteśmy bohaterami jednej części aplikacji, ale nie chcemy jej dotykać.
• Różne podejścia do architektury, rozwiązań, przyjętych ram
• Wydaje się, że proces zbierania wymagań nie działa

Scrum, jeśli początkowo przestrzegany, powinien rozwiązać wiele z tych problemów, a co ważniejsze, wysunąć na pierwszy plan inne problemy, które należy rozwiązać.

- Ciągle zmieniające się wymagania

Posiadanie pojedynczego zaległości, w którym wszystko jest odpowiednio uwzględniane i traktowane priorytetowo, powinno oznaczać, że zespół nie powinien ponosić ciężaru zmieniających się wymagań w trakcie opracowywania. Jeśli jest to środowisko bardzo dynamiczne, mniejsze sprinty trwające 1 lub 2 tygodnie powinny zapewnić możliwość zmiany priorytetów w stosunkowo krótkim czasie.

- Niemożność skupienia się programistów na innych obszarach aplikacji, tj. jesteśmy bohaterami jednej części aplikacji, ale nie chcemy jej dotykać.

Zespół scrum dobrze współpracujący ze sobą i wspierający się nawzajem, ze szczególnym dążeniem do dzielenia się wiedzą w zespole i szukający wyzwania pracy nad innymi częściami aplikacji, będzie starał się zapewnić dzielenie się wiedzą na temat aplikacji. Niektóre praktyki, takie jak programowanie w parach, mogą pomóc ludziom przezwyciężyć obawy związane z pracą nad kodem, którego nie znają, a także uczyć się i dzielić tą wiedzą. Może to potrwać kilka sprintów, zanim wiedza o aplikacji zostanie podzielona między zespoły i ludzie będą czuli się komfortowo pracując nad dowolnym obszarem aplikacji. Również zachęcanie ludzi do wykonywania zadań zarządu, tj. Dokonywania własnego wyboru tego, co chcieliby pracować, może zachęcać do tego.

- Różne podejścia do architektury, rozwiązań, przyjętych ram

Scrum ułatwia lepszą komunikację, ułatwia pracę zespołową i lepsze podejmowanie decyzji, a także zapewnia lepszy wgląd w to, co się dzieje. To z kolei powinno ułatwić podejmowanie decyzji organizacyjnych dotyczących korzystania z ram, rozwiązań architektonicznych itp., A zastosowanie mechanizmu Scrum of Scrums może pomóc w zaszczepieniu tego w całej organizacji.

- Proces gromadzenia wymagań

Ponownie, jeśli ściśle przestrzegasz zasad, jeśli wymaganie nie jest określone i nie jest gotowe, aby zespół mógł zrozumieć i oszacować, co jest wymagane do spełnienia wymagania, nie należy go wprowadzać do sprintu. Weź kolejny wymóg, który ma wysoki priorytet i został dobrze zdefiniowany ... ponieważ wtedy wiesz, że będziesz w stanie to zrealizować! Chociaż nie może natychmiast naprawić procesu zbierania wymagań, wymusi zmianę wymaganą do naprawienia tego procesu.

Aby odpowiedzieć na twoje pierwsze pytanie, nie, nie powinny istnieć dwa osobne zaległości. W danym momencie w najlepszym interesie wszystkich leży, aby programiści i organizacja pracowali w pierwszej kolejności nad elementami o najwyższym priorytecie. Priorytety powinny opierać się głównie na wartości biznesowej i jest całkiem możliwe, że wiele drobnych poprawek i próśb wnosi wartość biznesową. Niech właściciel produktu zdecyduje o tym.

Jestem Scrum Master od ponad 7 lat i pomagałem we wprowadzaniu Scruma do wielu różnych zespołów i firm. Według mojej skromnej opinii i moich obserwacji uważam, że jeśli Scrum zostanie wprowadzony do twojej organizacji po raz pierwszy, postępuj zgodnie z nim. Nie odchodź. Scrum wymaga dyscypliny, aby móc przestrzegać praktyk i procesów. Zbyt łatwo jest robić wyjątki, aby pasowały do ​​pewnych okoliczności, a jeśli zrobi się to zbyt wcześnie, doprowadzi to do erozji korzyści i wartości, które ze sobą niesie. Zrób podstawy, zrób to naprawdę dobrze. Zostań ekspertem w zrozumieniu podstaw i zrozumieniu, dlaczego one istnieją, a następnie zmień ten proces, aby lepiej pasował i prowadził ciągłe doskonalenie w organizacji.

Istnieją bardzo uzasadnione przypadki, aby powiedzieć, że jest to „zwinny”, więc musimy być gotowi na zmianę procesu, ale istnieje znacząca różnica między kierowanym przez siebie, samoorganizującym się zespołem, który rozumie ten proces, a dyskutowaniem o zmianach, które można wprowadzić w proces, w przeciwieństwie do zespołu, który dopiero zaczyna kroczyć ścieżką Agile lub Scrum. To tak, jakbyś próbował uciec, zanim zaczniesz czołgać się ...