Agile - co robimy źle?

Jestem programistą w zwinnym zespole i staramy się używać Scruma.

Przedstawię tutaj hipotetyczny problem, aby zilustrować sytuację.

Mamy bardzo starą aplikację, używającą nieporządnego i niepoprawnego kodu JQuery. Mamy również części aplikacji korzystające z React, a te części są znacznie łatwiejsze do aktualizacji / konserwacji. Poza tym celem firmy jest stworzenie aplikacji React dla klienta z pojedynczą stroną, więc korzystanie z JQuery pozwoli Ci odejść od tego.

Kiedy planujemy, zawsze wybieramy proste rozwiązanie w zakresie czasu programowania, więc na przykład, jeśli tworzymy nowe okno dialogowe lub coś takiego, korzystamy ze starego JQuery, ponieważ jest szybszy i mówimy, że wracamy później, aby posprzątać i przekształcić w React, ale to rzadko się zdarza.

Wymagania dotyczące tego, co musimy zrobić, otrzymujemy od historii użytkowników (które są dobrze wykonane przez IMO, są smukłe, ale wyjaśniają, co robimy i dlaczego to robimy).

Czasami wymagania dotyczące nowych funkcji są bardzo wąskie, więc na przykład jeśli wymaganie mówi „zrób okno dialogowe, które ładuje mnóstwo treści”, ale nie mówi o wdrożeniu funkcji ładowania, w większości przypadków nie wdrożyliśmy jej , chociaż wszyscy wiemy, że byłoby lepiej dla klientów, z tego powodu, że może to zagrozić naszemu celowi sprintu (chociaż osobiście uważam, że tak nie byłoby).

W rezultacie nasza baza kodów jest wielkim bałaganem o bardzo złej konserwacji, a czasami nowe funkcje są bardzo małe i wymagają pełnego sprintu (coś, co można osiągnąć w ciągu jednego dnia w dobrej bazie kodu) głównie z powodu tego rozwoju strategii, po prostu idź szybko, zrób minimum.

W takim przypadku co robimy źle? Czy powinniśmy zająć się rozwiązaniami w bardziej kompletny sposób, aby nie zabrakło nam pisania złego kodu i przepisywania kodu, który właśnie napisaliśmy w zeszłym tygodniu? A może powinniśmy to robić, upewniając się, że cały kod jest przepisywany? Jakie byłoby dobre zwinne podejście do tego problemu?

Nie ma to nic wspólnego z Agile ani Scrumem.

Problem z „taśmą klejącą teraz, a my to naprawimy później” polega na tym, że później nigdy nie nadejdzie, aw międzyczasie narastasz dużo długu technicznego .

Pierwszym krokiem do odzyskania jest rozpoznanie problemu i przestanie go pogarszać.

W przypadku każdej nowej historii użytkownika zespół powinien rozważyć „jaki jest właściwy sposób na zakodowanie tego?”, A nie „jaki jest najszybszy sposób włamania się do tego?” i odpowiednio zaplanuj sprinty.

Aby rozwiązać istniejący problem, zobacz doskonałe odpowiedzi na to, że odziedziczyłem 200 000 wierszy kodu spaghetti - co teraz?

To, co tam masz, to, co Martin Fowler nazywa „flacid scrum”.

Jeśli poprawnie przeczytasz wszystkie 12 zasad Manifestu Zwinności , przekonasz się, że w większości nie zdajesz egzaminu.

Dostarczaj działające oprogramowanie często, od kilku tygodni do kilku miesięcy, z preferencją do krótszych terminów.

Czy możesz powiedzieć, że dostarczasz naprawdę działające oprogramowanie? A może po prostu oprogramowanie, które ledwo działa?

Zwinne procesy promują zrównoważony rozwój. Sponsorzy, programiści i użytkownicy powinni mieć możliwość utrzymywania stałego tempa w nieskończoność.

Czy możesz powiedzieć, że twój proces jest zrównoważony? Czy podejmujesz decyzje z myślą o zrównoważonym rozwoju? A może wybierasz rozwiązania, które rozwiązują bieżący problem bez uwzględnienia efektów długoterminowych?

Ciągła dbałość o doskonałość techniczną i dobry design zwiększają zwinność.

Naprawdę główna zasada. Uważam, że należy to umieścić na OGROMNYM CZERWONYM LITERZE na stronie. To tam najbardziej zawodzi.

W regularnych odstępach czasu zespół zastanawia się, jak zwiększyć skuteczność, a następnie odpowiednio dostosowuje i dostosowuje swoje zachowanie.

I najbardziej oczywiste. Jeśli odkryjesz, że twoje zachowanie nie prowadzi do pożądanych rezultatów, powinieneś je zmienić. Jeśli twój zespół nie widzi, że ma problemy, nie może zacząć ich naprawiać.

Z twojego komentarza

Jak temu zapobiec w zwinny?

Po pierwsze, ucząc się, czym jest zwinny. Scrum nie jest zwinny. Niektórzy twierdzą, że Scrum jest najgorszy ze zwinnych frameworków, ponieważ zbyt łatwo jest osiągnąć dokładną sytuację. Powinieneś dowiedzieć się o innych zwinnych ramach. Polecam programowanie ekstremalne. Co wyraźnie rozwiązuje twoje problemy. Rozwiązania nie są proste (koncentrują się na doskonałości technicznej poprzez solidne zautomatyzowane testowanie, programowanie par i ciągłe dostarczanie), ale są wysoce skuteczne. Jak podano w raporcie State of DevOps .

To, co opisujesz, to - przynajmniej z mojego doświadczenia - dość powszechny wzór zespołów próbujących „być zwinnym”. Jest to otwarte do debaty, jeśli jest to rzeczywiście część samego Agile lub jego powszechne niewłaściwe wdrożenie, jest sprzeczne ze zwinnym manifestem / zasadami lub jego nieodłączną konsekwencją i tak dalej. Tylko z empirycznego punktu widzenia i po prostu na podstawie mojego małego, próbnego zestawu doświadczeń (i ludzi, z którymi rozmawiam), jeśli zespół jest zwinny, wydaje się, że ma ponadprzeciętną szansę na napotkanie tego wzoru. Po prostu zostawmy to i skupmy się na konkretnym przykładzie.

Istnieją dwa oddzielne aspekty tego, co opisujesz:

• Brakuje wspólnego zrozumienia / wizji i dlatego nie jest skuteczny
• Jak mierzyć sukces / postęp i całkowity koszt

Zejście niewłaściwą ścieżką lub bieganie w kółko

Z mojego doświadczenia wynika, że ​​głównym powodem takiego stanu rzeczy jest to, że w celu szybkiego opracowania kodu zespoły aktywnie odsuwają na bok przypadki użycia lub wymagania, które już znają lub o których łatwo mogą się dowiedzieć. Pomyśl o tym w ten sposób: 10-20 lat temu ludzie próbowali pisać gigantyczne specyfikacje i myśleli o wszystkim z wyprzedzeniem i często zawiedli. Albo trwało zbyt długo, albo coś przeoczyło. Jednym z wniosków z przeszłości jest to, że w rozwoju oprogramowania są rzeczy, których nie możesz wiedzieć i wiele się zmieniają, stąd pomysł szybkiego iterowania i szybkiego generowania sensownego wyniku. Co jest bardzo dobrą zasadą. Ale dzisiaj znajdujemy się na drugim biegunie: „Nie dbam o to, ponieważ jest to część następnego sprintu” lub „Nie zgłaszam tego błędu, radzę sobie z nim, gdy pojawi się ponownie”.

1. Zbierz wszystkie przypadki użycia , wymagania, zależności i ograniczenia wysokiego poziomu . Umieść go na wiki, aby wszyscy interesariusze i deweloperzy mogli je zobaczyć. Dodaj je, gdy pojawi się coś nowego. Porozmawiaj z akcjonariuszami i użytkownikami. Użyj go jako listy kontrolnej podczas opracowywania, aby zapobiec wdrażaniu rzeczy, które nie przyczyniają się do produktu końcowego lub są obejściem / włamaniami, które rozwiązują jeden problem, ale powodują trzy nowe.
2. Sformułuj koncepcję wysokiego poziomu . Nie mówię o projektowaniu interfejsów lub klas, ale z grubsza szkicuję problematyczną dziedzinę. Jakie są główne elementy, mechanizm i interakcje w ostatecznym rozwiązaniu? W twoim przypadku powinno to stać się oczywiste, gdy użycie obejścia obejścia pomaga jako krok pośredni i gdy powoduje tylko dodatkową pracę.
3. Sprawdź poprawność swojej koncepcji, korzystając ze zgromadzonej listy. Czy są w tym jakieś oczywiste problemy? Czy jest sens? Czy istnieją bardziej wydajne sposoby osiągnięcia tej samej wartości dla użytkownika bez powodowania długiego technologicznego zadłużenia?

Nie przesadzaj. Potrzebujesz czegoś, aby wszyscy w zespole (w tym nie-deweloperzy) mieli wspólne zrozumienie najlepszej ścieżki do twojego MVP. Wszyscy powinni zgodzić się, że nie ma oczywistych przeoczeń i może to faktycznie zadziałać. Zasadniczo pomaga to uniknąć ślepych zaułków lub wielokrotnego powtarzania tej samej rzeczy. Zwinne może pomóc ci lepiej poradzić sobie z nieoczekiwanym, nie ma sensu ignorować tego, co wiadomo.

Należy pamiętać o błędach kosztów utopionych : jeśli zaczniesz od jednego typu architektury lub typu bazy danych, większość ludzi waha się zmienić to w połowie projektu. Dlatego dobrym pomysłem jest zainwestowanie czasu w „najlepsze wykształcenie”, zanim zaczniesz wdrażać różne rzeczy. Deweloperzy mają tendencję do szybkiego pisania kodu. Ale często posiadanie kilku prób, prototypów na żywo, zrzutów ekranu, modelu szkieletowego itp. Pozwala na jeszcze szybszą iterację niż pisanie kodu. Pamiętaj tylko, że każda linia napisanego kodu, a nawet testy jednostkowe utrudniają zmianę ogólnej koncepcji.

Mierzenie sukcesu

Całkowicie oddzielnym aspektem jest sposób mierzenia postępu. Powiedzmy, że celem twojego projektu jest zbudowanie wieży o wysokości 1m z wykorzystaniem leżących przedmiotów. Budowanie domu z kart może być całkowicie poprawnym rozwiązaniem, jeśli na przykład czas na rynku jest ważniejszy niż stabilność. Jeśli Twoim celem jest zbudowanie czegoś, co przetrwa, użycie Lego byłoby lepsze. Chodzi o to, co jest uważane za hack i jakie eleganckie rozwiązanie zależy całkowicie od tego, jak mierzy się sukces projektu .

Twój przykład „ładowania” jest całkiem niezły. W przeszłości miałem takie rzeczy, w których wszyscy (w tym sprzedaż, PO, użytkownicy) zgodzili się, że to denerwujące. Nie miało to jednak wpływu na sukces produktu i nie spowodowało zadłużenia długoterminowego. Porzuciliśmy to, ponieważ były bardziej wartościowe rzeczy związane z zasobami deweloperów.

Moja rada tutaj to:

1. Zachowaj wszystko, nawet małe błędy, jako bilety w systemie biletowym . Podejmij aktywną decyzję, co wchodzi w zakres projektu, a co nie. Utwórz kamienie milowe lub w inny sposób odfiltruj zaległości, aby zawsze mieć „pełną” listę wszystkiego, co należy jeszcze zrobić.
2. Mają ścisłą kolejność ważności i wyraźny punkt odcięcia, w którym projekt można uznać za sukces. Jakiego poziomu stabilności / jakości kodu / dokumentacji faktycznie potrzebuje produkt końcowy? Staraj się spędzać każdy dzień pracy najlepiej, jak to możliwe, wybierając z góry. Pracując nad jednym biletem, spróbuj rozwiązać go całkowicie bez wprowadzania nowych biletów (chyba że sensowne jest odkładanie rzeczy z powodu niższego priorytetu). Każde zatwierdzenie powinno doprowadzić cię do przodu do celu końcowego, a nie na boki lub do tyłu. Ale jeszcze raz podkreślam: czasami hack, który powoduje dodatkowe prace później, może być dodatnim wynikiem netto dla projektu!
3. Użyj swojego zamówienia / użytkowników, aby obliczyć wartość użytkownika, ale także poproś programistów o określenie kosztu technicznego . Nie-deweloperzy zazwyczaj nie potrafią ocenić, jaki jest prawdziwy długoterminowy koszt (nie tylko koszt wdrożenia!), Więc pomóżcie im. Uważaj na problem gotowania żaby: wiele małych, nieistotnych problemów może z czasem doprowadzić zespół do zawieszenia. Spróbuj określić, jak efektywny może być Twój zespół.
4. Miej oko na ogólny cel / koszty. Zamiast myśleć od sprintu do sprintu, raczej miej na uwadze „czy jako zespół możemy zrobić wszystko, co potrzebne do końca projektu” . Sprinty to tylko sposób na rozbicie rzeczy i uzyskanie punktów kontrolnych.
5. Zamiast chcieć coś wcześnie pokazać, nakreśl swój kurs na najszybszej ścieżce do minimalnego opłacalnego produktu, który można podać użytkownikowi. Mimo to ogólna strategia powinna pozwalać na weryfikowalne wyniki pomiędzy.

Więc jeśli ktoś zrobi coś, co nie pasuje do twojego ostatecznego celu wdrożenia, najlepiej nie rozważ tej historii. Jeśli korzystne jest zamknięcie historii (np. Uzyskanie opinii od klientów), natychmiast otwórz nową historię / błąd w celu usunięcia niedociągnięć. Upewnij się, że stosowanie skrótów nie zmniejsza kosztów, tylko je ukrywa lub opóźnia!

Sztuczka polega na tym, aby spierać się o całkowity koszt projektu: jeśli na przykład organizacja producentów popiera skróty w celu dotrzymania terminu, należy obliczyć ilość pracy, którą należy wykonać, aby uznać projekt za wykonany!

Uważaj również na optymalizację opartą na kryteriach : jeśli twój zespół jest mierzony liczbą opowieści, które mogą pokazać podczas przeglądu sprintu, najlepszym sposobem na osiągnięcie dobrego „wyniku” jest podzielenie każdej opowieści na dziesięć małych. Jeśli jest mierzona liczbą napisanych testów jednostkowych, będzie miał tendencję do pisania wielu niepotrzebnych. Nie licz historii, raczej mierz, ile funkcjonuje potrzebna funkcjonalność użytkownika, jak duży jest koszt długu technologicznego do rozwiązania w zakresie projektu itp.

Podsumowanie

Krótko mówiąc: szybkie i minimalne podejście to dobre podejście. T on problem jest w interpretacji „szybko” i „minimalne”. Zawsze należy brać pod uwagę koszty długoterminowe (chyba że masz projekt, w którym nie ma to znaczenia). Korzystanie ze skrótu, który zajmuje tylko 1 dzień, ale powoduje powstanie długu technologicznego w ciągu 1 miesiąca od daty wysyłki, kosztuje Twoją firmę więcej niż rozwiązanie, które zajęło 1 tydzień. Natychmiastowe rozpoczęcie pisania testów wydaje się szybkie, ale nie jeśli Twoja koncepcja jest wadliwa i utrudniają podejście.

I pamiętaj, co w twoim przypadku oznacza „długoterminowe”: znam więcej niż jedną firmę, która zbankrutowała, próbując napisać świetny kod i dlatego została wysłana zbyt późno. Dobra architektura lub czysty kod - z perspektywy firmy - jest cenny tylko wtedy, gdy koszt jego osiągnięcia jest niższy niż koszt jego braku.

Mam nadzieję, że to pomaga!

Ściśle rzecz biorąc z punktu widzenia scrum, wydaje się, że to, co robisz źle, polega na tym, że nie współpracujesz z klientem. Musisz współpracować z klientem, aby zrozumieć, czego potrzebuje, a nie tylko tego, czego chce . Czy potrzebują serii szybkich poprawek, czy też potrzebują stabilnego, łatwego w utrzymaniu systemu, który będzie im służył w dłuższej perspektywie? Może to być trudne do ustalenia, ale jakość jest tak samo wymaganiem, jak kolor tła lub test wydajności. Klient musi zdawać sobie sprawę, że stabilność i łatwość konserwacji nie są bezpłatne i muszą zostać zaprojektowane w produkcie.

Jeśli powiedzą, że to ten pierwszy, nie robisz nic złego - zakładając, że wyjaśnisz im w recenzjach sprintu, że skracasz rogi inżynierii, aby osiągnąć ich cele.

Jeśli powiedzą, że to ta ostatnia, to robisz źle, ponieważ nie dajesz im tego, czego chcą.

Jednym z filarów Scruma jest przejrzystość. Jeśli robisz scrum, powinieneś robić recenzje sprintu z klientem. Czy w tych recenzjach mówisz klientowi, że skracasz granice, aby szybciej dostarczać oprogramowanie? Jeśli nie, powinieneś być. Musisz być w 100% jasny z klientem na temat konsekwencji wyboru projektu, aby dać mu szansę podjęcia świadomej decyzji, czy dostarczasz swoje oprogramowanie o odpowiedniej jakości.

Ewan ma rację. Powodem dla którego lubi scrum jest to, że mogą żądać funkcji w stylu staccato i szybko uzyskiwać wyniki. Dopóki wynikający z tego bałagan nie stanie się problemem.

Teraz, gdy mam twoją uwagę, pozwól mi wyjaśnić. To nie jest Scrum jako taki. Jest to typowa sytuacja silnego menedżera produktu i słabego zespołu programistów, który nie jest w stanie podać rozsądnych i realistycznych szacunków, ponieważ odczuwa presję. Dlatego opracowali optymistyczne prognozy i popadli głębiej w kłopoty, skracając rogi, aby dotrzymać terminu.

W scrumie (jako programista) możesz sam zaplanować. Nikt nie mówi, abyś dostarczył jakąś funkcję w ciągu X dni. Jeśli ktoś mówi ci, żebyś dostarczył za x dni, nie robisz Scruma.

Niezależnie od tego, jaki problem trzeba rozwiązać, odbierz swój czas. Czy uważasz, że potrzebujesz czasu, aby najpierw coś przerobić? Uwzględnij to w swoich szacunkach. Czy możesz sobie na to pozwolić?

Sprawdźmy, co robisz, odkładając na chwilę Agile.

Kiedy planujemy, rezygnujemy z łatwego rozwiązania w zakresie czasu programowania, więc na przykład, jeśli tworzymy nowy dialog lub coś takiego, używamy starej jquery, ponieważ jest szybsza, i mówimy, że wrócimy później do posprzątaj i przekształć w reagowanie, ale to rzadko się zdarza.

Nazywa się to „zaciąganiem długów technicznych”. Martin Fowler opisał „Kwadrant długu technicznego” w swoim blogu na dwóch osiach: „Lekkomyślny kontra rozważny” i „Rozważny kontra nieumyślny”.

Wyraźnie decydujesz się na użycie znanej starej technologii jquery, która odsuwa cię od jednego z twoich wyraźnych celów (mianowicie aplikacji jednostronicowej). Robisz to, aby dostarczyć „szybko”. To jest celowe.

To, czego nie obejmuje to „szybkie” obliczenie, to czas potrzebny na wdrożenie tej funkcji w celu późniejszego zareagowania. Wybierasz alternatywę, która ma tylko wady w porównaniu z alternatywą, o której wiesz, że jest poprawna (a mianowicie poświęcenie czasu na wdrożenie tej funkcji w reakcji) na podstawie oceny, że szybkość jest najważniejsza. To jest lekkomyślne.

Martin Fowler podsumowuje ten rodzaj długu pod hasłem „Nie mamy czasu na projektowanie”. Jest to odpowiedni wybór w środowisku, w którym nie oczekujesz utrzymania kodu, a nawet nie spodziewasz się, że będziesz go kodował dłużej niż kilka dni. Ale twój projekt to projekt długofalowy, który wyraźnie wymaga konserwacji klienta (-ów)

To, co robisz, jest złe na bardzo podstawowym poziomie. To zła inżynieria !

Wziąłeś na siebie dług techniczny, ignorując potrzebę spłaty tego długu i naliczenia odsetek. I tak robiłeś, dopóki oprocentowanie twojego długu nie zaczęło się zbliżać do dostępnej pracy podczas twojego sprintu.

To, co powinieneś zrobić, to zmniejszyć poziom długu . Porozmawiaj z szefem, porozmawiaj z klientem. Wczoraj musisz pracować nad utrzymywalnością.

Po prostu przestań używać Agile ...

A raczej przestań próbować robić coś w określony sposób, ponieważ to właśnie dyktuje (twoje rozumienie) zwinności (lub scrum itp.). Próba zastosowania jednej (błędnej) interpretacji jednego z tych terminów do projektu na niewłaściwym etapie może szybko stać się najgorszym działaniem. Zamiast tego użyj swojego powodu.

Powodem, dla którego Twój projekt i prawie każdy inny projekt na świecie jest bałagan kodu i rozbieżne podejścia, wynika z braku scentralizowanego, wszechwiedzącego projektu architektonicznego (tam, powiedziałem to).

Przyczyny, których może brakować, to:

• Architekt nie ma specjalistycznej wiedzy (jak twoje pierwsze dziesięć projektów hobbystycznych)
• Architekt nie ma czasu
• Architekt nie ma władzy (kierownik mówi „nie” lub „tak”, ale tylko w przypadku niektórych części)
• Zespół wierzy w metodologię voodoo, która je uratuje (wszystko to się wyprasuje, ponieważ używamy Agile)

Prostym rozwiązaniem jest porzucenie wszystkich tych magicznych słów i przyjrzenie się rzeczywistości, którą można podsumować jako:

1. Stan kodu utrudnia zespołowi dostarczanie na czas i bez błędów.
2. Im więcej funkcji dodamy, tym gorzej będzie.
3. Dlatego naprawdę sensowne jest pauzowanie, ponowna ocena i (być może drastycznie) przeprojektowanie części.

Naturalnie przede wszystkim zapytasz, dlaczego doszło do tego stanu, a palec winy kręci się w kółko. Odpowiedź jest taka, że ​​jest to nieuniknione: gdy twój projekt dojrzewa, zdajesz sobie sprawę, że powinieneś to zrobić inaczej, ale nie mogłeś tego przewidzieć. Co więcej, nie jest to realizacja jednorazowa na projekt, będzie się ona odbywać kilka razy i trzeba to zaplanować.

Powiedziawszy to, istnieje wiele rzeczy, które menedżerowie mogą zrobić, aby zaostrzyć:

1. Deathmarching waszych deweloperów do terminów.
2. Stwierdzenie, że deweloperzy mogą rejestrować czas tylko w stosunku do biletów, bez biletów na „myślenie, konsolidację i refaktoryzację jakości” oraz hojny limit czasu na te.
3. Nie dajemy nikomu prawa własności do architektury przez wystarczająco długi czas, aby sobie z tym poradzić
4. Nie zezwalanie tej osobie na wprowadzanie zmian, które ich zdaniem są potrzebne

Patrząc na to w ten sposób, łatwo jest zobaczyć, jak niektóre interpretacje agile i scrum faktycznie pomaszerują na tę trasę jeszcze szybciej!

Jednym z podejść jest tworzenie biletów dla każdego kawałka refaktoryzacji. Problem polega na tym, że często nie zdajesz sobie sprawy, że potrzebujesz dużego refaktora, dopóki nie zaczniesz pracować nad mniejszym biletem, który przesuwa terminy z powrotem, a bilet przechodzi przez pętle zatwierdzania, po prostu wszystko spowalnia.

Innym podejściem jest zaplanowanie sprintu, aby wykorzystać tylko 25-50% zdolności twojego zespołu. Następnie deweloperzy rejestrują swój czas na prawdziwych biletach (rejestrują czas, który powinien zająć bez refaktoryzacji) i czas refaktoryzacji (jeden duży bilet na tydzień, brak pętli zatwierdzania, tylko dyskusja między programistami). Jeśli nie ma refaktoryzacji, możesz pobrać bilety ze sprintu w przyszłym tygodniu. Dostosowujesz suwak procentowy na nadchodzące tygodnie, gdy poprawia się podstawowy kod projektu.

Tak więc, aby odpowiedzieć „co robimy źle”, powiedziałbym, że pokładasz zaufanie w metodologii zamiast zdrowego rozsądku. Pytasz nawet o „zwinne podejście do tego problemu” . Powiedziałbym, żeby rzucić słowa i pomyśleć o rzeczywistym problemie. Jeśli więc naprawdę chcesz rozdzielić różne manifesty, próbując rozszyfrować, czy twoje ostateczne podejście oparte na zdrowym rozsądku rzeczywiście mieści się w przebraniu „zwinnego” lub „scrum”, to zdecydowanie skorzystaj z niego :-)

Nie robisz nic złego. Ten rodzaj metodologii ma na celu dostarczenie funkcji zgodnie ze specyfikacją i tak szybko, jak to możliwe.

Jeśli masz drugorzędne cele, nad którymi pracujesz, najlepiej jest je wyrazić jako „niefunkcjonalne wymagania” lub „definicję zrealizowanego”.

na przykład możesz mieć wymóg niefunkcjonalny:

„Wszystkie nowe funkcje muszą być napisane w React”

i

„Wszystkie wywołania asynchroniczne muszą implementować mechanizm ładujący i obsługę błędów”

Musisz tylko poprosić właściciela produktu (lub odpowiednika), aby zgodził się, że są to rzeczy, które warto robić, a nie wkraść się do nich, ponieważ podobają się deweloperom.