Czy w Scrumie powinieneś podzielić zaległości na funkcjonalne i techniczne?

W naszych zespołach Scrumowych korzystamy z zaległości, które w większości zawierają tematy funkcjonalne, ale czasem także tematy techniczne. Zaletą posiadania 1 zaległości jest to, że łatwo jest wybrać tematy do następnego sprintu, ale mam kilka pytań:

• Po pierwsze, bardziej logiczne wydaje mi się posiadanie osobnego technicznego zaplecza, w którym sami programiści mogą dodawać elementy czysto techniczne, takie jak: moglibyśmy poprawić wydajność w tej metodzie, w tej klasie brakuje dokumentacji technicznej ... Dzięki jednemu zaległościowi wszystkie programiści zawsze muszą przekazywać informacje o właścicielu produktu, aby dodawać tematy do zaległości, co wydaje się dodatkowa, niepotrzebna praca dla właściciela produktu.
• Po drugie, jeśli masz właściciela produktu, który koncentruje się wyłącznie na elementach czysto funkcjonalnych, elementy czysto techniczne (takie jak brakująca dokumentacja techniczna, kod, który ulega erozji i powinien zostać ponownie opracowany, klasy, które zawsze powodują problemy podczas debugowania, ponieważ nie mają stabilna podstawa i powinna zostać zrefaktoryzowana ...) zawsze kończy się na końcu listy, ponieważ „nie służą one bezpośrednio klientowi”. Dysponując osobnym zapleczem technicznym i czasem zarezerwowanym na każdym sprincie dla tych czysto technicznych elementów, możemy ulepszyć funkcjonalnie aplikacje, ale także utrzymać je w zdrowiu.

Jakie jest najlepsze podejście? Jeden czy dwa zaległości?

Nie jestem ekspertem, ale powiedziałbym, że możesz mieć tylko jeden backlog na zespół. Zespół musi zdecydować, które kwestie są pilne, a które można odłożyć. Jeśli podzielisz problemy na osobne typy stosów, postąpisz w sprzeczności z podstawową ideą leżącą u podstaw scrum, a mianowicie, że istnieje pula problemów i każdy sprint zespół pracuje nad najpilniejszym z nich. Jeśli (pod) podzielisz zespoły, być może będziesz w stanie podzielić typy zadań, które są dla nich odpowiednie, ale zasadniczo będziesz tworzył zespoły, które pracują równolegle. Pilność / konieczność to decydujący numer jeden, jeśli chodzi o planowanie następnego sprintu. Możesz podzielić zadania na kategorie, ale nie powinno to przeszkadzać w podejmowaniu decyzji.

Chciałbym dodać mój głos do tych, którzy zalecają jeden zaległości na produkt. Utworzenie kolejnego zaległości jest racjonalną reakcją, ale tak naprawdę po prostu unika podstawowego problemu: dlaczego właściciel produktu nie priorytetowo traktuje elementów technicznych nad elementami funkcji? Powinieneś skupić się na rozwiązaniu tego problemu, a nie na obejściu go. Możesz na przykład użyć techniki 5 Whys , aby spróbować dojść do sedna sprawy.

Może istnieć wiele powodów, dla których organizacja producentów nie traktuje priorytetowo problemów technicznych. Na przykład może zespół techniczny nie wyjaśnia długoterminowego kosztu (w $$$) braku uregulowania długu technicznego. Może to coś zupełnie innego. Istnieje spora szansa, że ​​przyczyną jest problem z komunikacją, a długoterminowym rozwiązaniem jest nad tym popracować i rozwiązać - usunąć przeszkodę.

Dodatkowo mam inne pytanie do przemyślenia: dlaczego w ogóle powstał dług techniczny? Idealnie byłoby, gdyby prace takie jak refaktoryzacja itp. Odbywały się w ramach historii funkcjonalnych i były wykonywane w trakcie sprintu. Nie powinny być osobnymi dodatkowymi historiami, w przeciwnym razie nie masz potencjalnie kodu do wysyłki.

To, o czym mówisz, jest powszechnie nazywane „długiem technicznym”. Czasami może być trudno zobaczyć, w jaki sposób dług techniczny wpasowuje się w proces scrum, w taki sam sposób jak wady.

To, co proponujesz, jest podobne do sugerowania oddzielnego „zaległości w defekcie”, dzieląc zaległości na 3.

Osobiście nie opowiadałbym się za podzieleniem zaległości produktu. Ideą backlogu produktu jest reprezentowanie wyjątkowych elementów pracy . Z tej perspektywy jedyną różnicą między funkcją a długiem technicznym jest to, że wymaganie pochodziło od zespołu programistów, a nie od klienta. Jest to nadal element pracy i nadal wymaga zarządzania, w tym nadawania priorytetu innym elementom pracy. Jest to szczególnie prawdziwe, jeśli pozycja długu technicznego wymaga przetestowania, w którym to przypadku powinna przejść dokładnie ten sam proces kontroli jakości, co zwykła funkcja.

Zgadzam się z Onno, że powinien istnieć tylko jeden zaległość na projekt. W przeciwnym razie zespół zasadniczo bierze w swoje ręce decyzje, które słusznie należą do właściciela produktu.

Nawet elementy „czysto techniczne” muszą mieć pewną praktyczną wartość dla użytkowników (a zatem dla właściciela produktu), aby kwalifikować się do zaległości w sprincie. Twoim zadaniem jest wyjaśnienie korzyści z nich właścicielowi produktu i przekonanie go o wartości dodanej uzasadniającej koszt. Ten proces zmusza cię do przemyślenia tych problemów i wybrania zmian technicznych, które przynoszą największą wartość dla projektu przy najmniejszym wysiłku.

Zgadzam się ze wszystkimi powyższymi odpowiedziami. W ogniu rzeczywistości komercyjnej organizacja producentów będzie priorytetowo traktować historie funkcjonalne nad technicznymi. Często do frustracji zespołu. Zespół powinien powstrzymać się od opowiadań technicznych bez żadnej wartości dla użytkownika (kogo obchodzi optymalizacja, jeśli szybkość nie jest problemem?) I nauczyć się widzieć niektóre inne zadania techniczne sugerowane przez opowiadania funkcjonalne. Dużą rolę odgrywa także „definicja ukończenia”. Pozostałe funkcjonalne historie znajdują się w zaległościach, aby organizacja producentów miała priorytet.

Np. Dokumentacja techniczna: Dostępność dokumentacji technicznej (w stosownych przypadkach) jest typowym przedmiotem, który należy do DOD. Dlatego jej aktualizacja jest DOROZUMIANA z każdą historią funkcjonalną.

Np. Kod refaktoryzacji: należy zrobić, gdy przynosi korzyść rozwojowi produktu. Nie wcześniej (zespół nie powinien zakładać, w którym kierunku będzie ewoluować produkt) i nie później, kiedy już zamienił się w dług techniczny. Przegląd projektu może być również częścią DoD.

Zgadzam się z MelR. Jeśli jest coś „technicznego”, musimy zastanowić się, dlaczego to robimy - a nawet jaka jest krótko- i długoterminowa przyczyna i skutek (dla użytkownika) ?.

Widziałem wiele zaległości, w których tak zwane „zadania techniczne” można łatwo napisać w sposób wartościowy dla biznesu.

Zadania techniczne są często również wynikiem dużych, podzielonych historii, ponieważ może to być łatwiejszy sposób na podział rzeczy. Może to jednak powodować wolniejsze iteracje prawdziwej wartości dodanej (lub możliwości uzyskania informacji zwrotnej) lub nawet gorsze awarie sprintów.

W odniesieniu do „kodu, który ulega erozji i powinien zostać zrefaktoryzowany”, jak wspomina Patrick, uważam, że musimy zapytać - jaki obszar funkcjonalności systemu ma wpływ na ten kod? i jaki jest długoterminowy wpływ na użytkownika, jeśli nie zmienimy go teraz?

Następnie pojawia się temat „pozostawienia rzeczy nieco lepszych niż to, w jaki sposób to znaleźliśmy”, aby zmniejszyć długoterminowy dług techniczny i czy można tego dokonać w ramach krótkich opowiadań w każdym sprincie bez zbytniego wpływu na szerszy projekt?

Ostatecznie nie widzę potrzeby dwóch zaległości, co otwiera okazję do spowolnienia odpowiednio ustalonych priorytetów - ale istnieje potrzeba właściciela produktu, który jest wykształcony w kwestiach technicznych i ma silną zdolność do identyfikowania prawdziwej wartości, więc aby podzielić historie w pionie - Adobe oferuje dobre wyjaśnienie na temat pionowego krojenia .

Nie, nigdy nie powinieneś tworzyć historii technicznych. Jest to częsty błąd. Twoje historie muszą odzwierciedlać wymagania biznesowe. Rzeczy techniczne nigdy tak naprawdę nie wynikają z wymagań biznesowych. Jest to rola mistrza scrum i zespołu w ocenie wszystkich zadań technicznych, które będą musieli wykonać, aby osiągnąć cel lub historię.

Jeśli na przykład twoja historia dotyczy utworzenia ekranu logowania, musisz rozważyć utworzenie bazy danych, jeśli jeszcze nie została utworzona.

Nie widzę problemu z tworzeniem, przy zamówieniu publicznym, zadań, w których zespół IT jest użytkownikiem. Jeśli zlecenie może być zrozumiane przez organizację producentów i można je ocenić pod kątem wartości biznesowej, to tak, masz sposób na stworzenie pewnego rodzaju opowieści technicznych. Po prostu korzystasz z systemu.