Właśnie rozpocząłem pracę w Scrum i wydaje się, że czegoś brakuje. Jestem nowy w Scrumie

Kod jest kompletnym bałaganem kombinacji klasycznej ASP / ASP.NET. Scrum polega na tym, że załatujemy wielki bałagan lub wprowadzamy do niego dodatki. Jesteśmy zbyt zajęci robieniem tego, aby rozpocząć przepisywanie, więc zastanawiam się ...

Gdzie jest część Scruma, w której programiści mogą powiedzieć, że wystarczy wystarczającej ilości i zażądać, aby mieli czas na rozpoczęcie przepisywania? Wydaje się, że jesteśmy w niekończącej się pętli polegającej na łataniu starego kodu za pomocą „Stories”.

Więc rzeczy są prowadzone przez nietechnicznych ludzi, którzy wydają się nie mieć ochoty naciskać na przepisanie, ponieważ nie rozumieją, jak źle zrobiła się baza kodów.

Więc kto jest odpowiedzialny za dokonanie tej wielkiej zmiany przepisywania? Deweloperzy? Scrum Master?

Obecna strategia polega na tym, aby znaleźć czas i zrobić to sami, bez zaangażowanych w to osób z wyższego szczebla, ponieważ to one są głównie winne za obecny bałagan, w którym się znajdujemy. <-Wstawić rant na temat ludzi nietechnicznych, którzy mówią technicznym ludziom, co mają tutaj robić ->.

Nie jestem pewien, dlaczego jest to takie trudne dla ludzi. Jego uzasadnienie biznesowe znajduje się tutaj:

We seem in an endless loop of just patching old code with 'Stories'.

Czas programisty to pieniądz. Dużo pieniędzy. Opuściłem firmę, która planowała przeróbkę interfejsu użytkownika ponad rok temu i miałem nadzieję, że przyjęcie scrum pomoże im przestać kręcić kołami. Co się stało? Same ol 'same ol'. Nadal rozbudowywali nowe funkcje, a „dług techniczny” nie miał uzasadnienia biznesowego, chociaż połowa kodu, który napisaliśmy, traciła na znaczeniu z każdą iteracją, ponieważ podstawowa baza kodów była kompletnie przestarzała. Od czasu ich odejścia nic się nie zmieniło na froncie, a zostałem wciągnięty w celu całkowitego przebudowania. W ciągu dwóch miesięcy, kiedy tam byłem, nie dotknąłem ani CSS ani JavaScript. Właśnie bałaganiłem HTML i jakiś starożytny system szablonów Java z końca lat 90.

Moja odpowiedź? Rób, co możesz, ale jeśli inni programiści już się poddali i pracują do późna, aby osiągnąć cele sprintu, zamiast utrzymywać bardziej praktyczne terminy i nalegać, aby dług technologiczny w rzeczywistości był problemem blokującym, załóż najgorsze i zacznij szukać nowej pracy teraz. Twoi programiści albo nie mogą, albo nie mogą komunikować swoich obaw, lub interesy też są krótkowzroczne, aby zrozumieć, ile pieniędzy sikają.

Ignorowanie tych problemów ZAWSZE kosztuje w dłuższej perspektywie. I nie troszkę więcej, ale dużo więcej. Jest to nie tylko rana ssąca w klatce piersiowej, jeśli chodzi o czas rozwoju, ale nieuchronnie zmniejszy twój talent, ponieważ programiści, którzy wiedzą lepiej i mają inne opcje, unikną twojej firmy jak zarazy. Mój obecny szef jest deweloperem ORAZ właścicielem firmy. Są rzeczy, których nie przerabiamy na rzecz skupienia się na innych priorytetach, ale kiedy coś naprawdę potrzebuje refaktora ze względu na konsekwentny czas, dostaje odpowiedni refaktor. A wyniki są oczywiste. Modyfikowanie i dodawanie nowych rzeczy staje się łatwiejsze i szybsze z wielu powodów. To, co kiedyś mogło zająć godziny, może zająć minuty przy odpowiedniej architekturze. Biznes nie lubi tego słuchać, ale warto to odłożyć na później.

Scrum jest porażką w środowiskach, w których programiści nie mają większego wpływu, IMO, ponieważ typom firm zbyt łatwo jest zignorować konserwację i aktualizacje na korzyść punktów, które mogą umieścić na swoich listach „udanych inicjatyw”, gdy nadchodzi czas oceny. Zawsze będą faworyzować swoje skóry i potencjał awansu na dłuższą metę, nawet jeśli konsekwentnie gryzie ich w dupę, ignorując te kwestie.

Scrum to także branża motywowana do zysków, a następnie niektóre. Firmy płacą dużo pieniędzy za szkolenie scrum. Ludzie, którzy chcą adoptować, powinni uważnie patrzeć na to, kto jest sprzedawany i jak realistycznie będzie to miało miejsce w ich kulturze.

Niezależnie od tego, jeśli naprawdę dbasz o rozwój, kiepska baza kodowa, zarządzanie z woskiem w uszach i programiści bez kolców to przepis na nieszczęście i środowisko, które niewiele zrobi, aby podnieść swoje umiejętności pod jakimkolwiek użytecznym względem. Nie wahaj się, zanim zaczniesz wprowadzać kroki do GTFO, zanim faktycznie odkryjesz, czy twoje wysiłki w celu rozwiązania problemu są opłacalne.

Jeśli naprawdę robiłbyś Scrum, w co wątpię, Właściciel Produktu byłby odpowiedzialny za decyzję o przepisaniu. W większości przypadków przepisywanie nie jest dobrym pomysłem, btw, ponieważ nie daje żadnych nowych funkcji, wprowadza tylko nowe błędy.

http://blog.objectmentor.com/articles/2009/01/09/the-big-redesign-in-the-sky
http://www.joelonsoftware.com/articles/fog0000000069.html

Aby rozwinąć „przepisywanie nie jest dobrym pomysłem”:

Prawie zawsze lepiej jest wypróbowywać stopniową poprawę. Jak napisał Jarrod Robertson w komentarzu, znajdź moduł, który wymaga ulepszenia, zostań ekspertem dla tego modułu i napisz historię do następnego sprintu w celu ulepszenia tego konkretnego modułu. Wyjaśnij właścicielowi produktu, dlaczego ten moduł wymaga pracy.

Będę naprawdę szczera ...

• Czy jesteś odpowiedzialny za programistów w tej pracy?
• Czy jesteś liderem projektu?
• Ile „udziałów” mają deweloperzy w projekcie?
• Jakie jest Twoje uzasadnienie biznesowe dla przepisania?
• Co takiego jest w bazie kodu, która sprawia, że ​​jest ona całkowicie bezużyteczna i nieodwracalna?

Stwierdziłeś, że właśnie rozpocząłeś pracę, a jednak wydajesz się być panem sytuacji. Być może źle zrozumiałem cel twojego pytania, ale mam wrażenie, że podjąłeś pracę, w której widzisz wiele problemów, i doszedłeś do najłatwiejszego wniosku, w którym kod jest zepsuty, a jedynym wyjściem jest przepisać, ale czy naprawdę zastanawiałeś się nad kosztami poniesionymi przez pracodawcę?

Z każdą istniejącą bazą kodu - bez względu na to, jak zły jest stan - właściciel zwykle będzie miał znaczną inwestycję w produkt (y), które reprezentuje kod. Z bazą kodu wiążą się zarówno bezpośrednie, jak i pośrednie koszty, a przepisywanie jest często ostatnią rzeczą, którą chcesz zrobić jako programista, ponieważ ryzykujesz dewaluacją zasobów kodu, a tym samym uzyskujesz niższy zwrot z wszystkich poprzednich starania.

Weźmy na przykład system operacyjny Windows. Z każdą nową wersją powstaje duża część kodu przeniesiona z poprzedniej wersji. Czasami całe biblioteki i interfejsy API są przeciągane do przodu przez kilka generacji systemu operacyjnego. Czemu? Ponieważ programiści wiedzą, że te elementy działają, zostały przetestowane, zostały załatane i naprawione, aby zapobiec problemom z bezpieczeństwem i pamięcią, oraz ponieważ kosztują dużo pieniędzy, aby dostać się do tego stanu. Nikt nie chce wyrzucać działającego kodu, gdy zarabia na nich pieniądze, nawet jeśli koszty utrzymania są stosunkowo wysokie, koszt rozpoczęcia od zera zawsze będzie nadal wyższy, aw firmie takiej jak Microsoft, mają miliardy w banku, który pozwalają im zacząć od początku, jeśli chcą, ale nie ponieważ chcą zmaksymalizować zwrot z inwestycji. Twój pracodawca nie różni się niczym od Microsoftu, z wyjątkiem tego, że masz miliardy gotówki do wydania w projekcie.

Więc kod jest bałaganem i wygląda na to, że istnieją problemy z komunikacją i granicami między różnymi obszarami firmy. Co ty lub twoi koledzy możecie z tym zrobić?

Jedną z opcji jest po prostu kontynuowanie pracy zespołu i liczenie na cud w przyszłości. Prawdopodobnie nie jest to dobry pomysł i może tylko zwiększyć frustrację i stres.

Lepszą opcją jest po prostu rozłożenie się i wykonanie zadań, ale w ramach tego szukania możliwości dodania testów do obsługi tych obszarów kodu, które wydają się najbardziej kruche, a następnie refaktoryzuj je, aż staną się bardziej stabilne. Łatwiej będzie ci przedstawić przekonujący argument, aby ulepszyć inwestycję firmy, zamiast argumentować, że po prostu ją wyrzucisz.

Jeszcze lepszą opcją jest zorganizowanie się w zespół i upewnienie się, że masz kogoś z wystarczającym stażem pracy, aby mógł zrobić dobry przypadek, aby umożliwić zespołowi większą elastyczność w planowaniu czasu na ulepszenie bazy kodu. Nie obchodzi mnie, jak bardzo firma jest zajęta lub jak sztywny wydaje się harmonogram, zawsze zdarzają się „przerwy” w działaniu, które można wykorzystać do wprowadzenia poprawy lub dwóch ulepszeń. Jest jednak jeszcze lepiej, jeśli ulepszenia można wprowadzić podczas wykonywania innych zadań. Gdybym to był ja, przytuliłbym się do menedżera i przedstawiłbym je pojęciom w niektórych kanonicznych książkach czytanych przez programistów. Wyczyść kodjest prawdopodobnie tym, którego najbardziej potrzebuje Twój zespół. Posadź kilka nasion o tym, jak poprawić kod i podaj kilka przykładów tego, co masz na myśli. Dobry menedżer zobaczy wartość dodawania przyrostowych ulepszeń do kodu, szczególnie jeśli jesteś w stanie opisać koncepcję długu technicznego . Pomóż swojemu liderowi lub menedżerowi zespołu w uzasadnieniu biznesowym usprawnienia kodu, a on będzie miał lepszą motywację do działania.

Nie wystarczy też powiedzieć „kod jest nieporządny”. Musisz zachęcać swoich kolegów, aby cały czas ćwiczyli kodowanie w czystości, i używaj techniki czystego kodowania, aby zachęcić do trochę porządkowania podczas podróży. Mam mały plakat, który drukuję i zawieszam na ścianie w biurze za każdym razem, gdy podejmuję nową pracę. Mówi: „Zawsze staraj się pozostawiać kod trochę piękniejszy, niż go znalazłeś”. Zaraz obok dodaję kolejny, który mówi: „Lilie nie muszą być złocone”. Oba służą przypomnieniu, że zawsze powinienem starać się poprawić to, co znajduję, ale unikaj po prostu pozłacania jednego problemu innym. Ogromne przepisywania są często najgorszym rodzajem „pozłacania”, ponieważ często są wykonywane z niewłaściwych powodów. Na pewno w pewnym momencie uzasadniona może być całkowicie nowa wersja produktu,

Oto oficjalna definicja Zespołu Rozwoju Scrum z oficjalnego Przewodnika Scrum . Kładę nacisk na części, które dotyczą ciebie bezpośrednio:

Zespół programistów składa się z profesjonalistów, którzy wykonują prace nad zapewnieniem potencjalnie możliwego do wydania Przyrostu „Gotowego” produktu na końcu każdego Sprintu. Tylko członkowie Zespołu programistycznego tworzą Przyrost. Zespoły programistyczne mają strukturę i uprawnienia organizacji do organizowania i zarządzania własną pracą . Uzyskana synergia optymalizuje ogólną wydajność i skuteczność zespołu programistów. Zespoły programistyczne mają następujące cechy:

• Są samoorganizujące się. Nikt (nawet Scrum Master) nie mówi zespołowi programistycznemu, jak zamienić Backlog Produktu w Przyrosty potencjalnie możliwej do uwolnienia funkcjonalności;

• Zespoły programistów są interfunkcjonalne, ze wszystkimi umiejętnościami jako zespół niezbędny do stworzenia Przyrostu produktu;

• Scrum nie uznaje żadnych tytułów dla członków Zespołu programistycznego innego niż Deweloper, niezależnie od pracy wykonywanej przez daną osobę; Nie ma wyjątków od tej zasady;

• Członkowie indywidualnego zespołu programistów mogą mieć wyspecjalizowane umiejętności i obszary zainteresowania, ale odpowiedzialność należy do całego zespołu programistów; i,

• Zespoły programistów nie zawierają podgrup zajmujących się konkretnymi dziedzinami, takimi jak testy lub analizy biznesowe.

Zespół programistów jest zatem odpowiedzialny za swój bałagan i powinien zająć się nim sam, bez konieczności proszenia kogokolwiek spoza zespołu.

Uwzględnij techniczny termin naprawy długu w każdym z przyszłych oszacowań i upewnij się, że jakość dostarczanego oprogramowania jest na najwyższym poziomie.

Jeśli naprawdę musisz wykonać kompletne przepisywanie, musisz rozwiązać problem w Restrospektywie Scrum. Właściciel produktu może ostatecznie anulować projekt i rozpocząć nowy. Właściciel produktu jest także jedynym, który może anulować sprint.

Kiedy to opisujesz, muszę powiedzieć, że nie widzę nic, co ma coś wspólnego z SCRUM lub twoim zespołem rozwoju produktu, który jest obecnie problemem .

To normalne

Co opisujesz jest normalne entropia bazy kodu. W twoim przypadku zespół prawdopodobnie zaczął od ideału, ale wciąż każda baza kodu ostatecznie staje się Big Ball of Mud .

W całkowicie idealnym scenariuszu typu greenfield wszystko, co możesz zrobić, to zacząć od absolutnej entropii i przejść do niej wolniej.

Zgadzam się z innymi, bałagan w bazie kodu jest spowodowany przez programistów. Jestem pewien, że poprzedza on przyjęcie SCRUM o wiele lat.

To nie jest decyzja techniczna lub programista o ponownym napisaniu, to decyzja biznesowa.

Nie masz pojęcia, dlaczego właściciele produktów nie chcą pisać od nowa. Jako deweloper uważasz, że jest to potrzebne, ale czy naprawdę jest na to jakieś uzasadnienie biznesowe ?

Jeśli istnieje prawdziwy przypadek biznesowy , nie tylko machanie ręką; „kod jest starszym bałaganem, który chcę założyć od podstaw, ponieważ tego właśnie chcę” , a następnie zarząd poświęciłby koszt przepisywania, biorąc pod uwagę zwrot z tej inwestycji.

Nie dały jedno solidne uzasadnienie biznesowe dla ponownego zapisu, tylko rant o swojej opinii na temat jak każdy inny spowodował ten bałagan, a ty nie chcesz, aby sobie z tym poradzić.

Dowód - Zysk kieruje decyzjami biznesowymi, aby wyrzucić działające oprogramowanie, a nie niektóre potrzeby OCD dotyczące czystej bazy kodu

Jeśli naprawdę potrafisz pokazać dowód , nie tylko teorię, ale twardy dowód, że wydawanie Xdolarów na ponowne zapisywanie od podstaw będzie gwarantować ZROBIĆ X * N dolary dla firmy w określonym Yczasie (gdzie Njest wysoki i Ykrótki), możesz zyskać trochę troski ze strony kierownictwa . Jest to bardzo mało prawdopodobny przypadek, który możesz przedstawić i udowodnić.

W przeciwnym razie musisz sobie z tym poradzić, to jest rzeczywistość. Wbrew nieugiętym zapewnieniom, że bez tego wielkiego, nieskazitelnego przepisywania nie ma absolutnie żadnej przyszłości, postawiłbym pieniądze, że ponad 5 lat od momentu, gdy narzekasz, że nadal będziesz działał i działał gdzieś, zapewniając komuś funkcjonalność i wartość długo po tym opuściłeś firmę.

Zazwyczaj jestem sceptyczny, gdy ludzie naciskają na „duże przepisywania”. W niektórych przypadkach zdecydowanie ma to sens, ale przez większość czasu ten starszy kod ma wartość (ponieważ jest już produkowany i jest wykorzystywany do celów, które zainspirowały go do stworzenia). Wykonanie dużego przepisywania jest w wielu przypadkach przeciwieństwem zwinnego. Ile czasu zajęłoby przeniesienie nowej wersji aplikacji do punktu, w którym mogłaby ona zastąpić istniejącą aplikację?

Wolę podejście, które Martin Fowler nazywa duszącym winoroślą . Wdrażaj nową funkcjonalność (w tym zmiany w istniejącej funkcjonalności), stosując nowe podejście, ale używaj istniejącej aplikacji jako kraty, na której nowa funkcjonalność może się rozwijać. To daje ci to, co najlepsze z obu światów, nie musisz wszystko zatrzymywać, gdy wielkie przepisywanie jest wprowadzane do tabaki, ale zyskujesz możliwość napisania nowego kodu, który wykorzystuje zaktualizowane frameworki. Jest to zdecydowanie trudniejsze podejście niż rozpoczęcie czyszczenia i może nie być tak seksowne, ale zapewnia większą wartość dla firmy niż odrzucanie wszystkiego, co tam jest, ponieważ jest przestarzałe.

Tam, gdzie jestem i jak działamy, robilibyśmy to: Napisz nową historię i przekaż ją właścicielowi produktu, który następnie zdecyduje, jak nadać jej priorytet. Przykładem może być: „Jako twórca produktu X chciałbym ponownie napisać kod w tym obszarze, aby przyszły rozwój był bardziej wydajny”. Kryteria akceptacji musiałyby wówczas przebiegać następująco: Ponowne pisanie / refaktoryzacja x aby było lepiej w ten sposób.

Nie wiem o sytuacji, w której się znajdujesz, ale tutaj, jeśli chcielibyśmy zacząć od nowa, byłoby to usiąść z właścicielem produktu i przekonać go, dlaczego, a następnie napisać stos historii, aby odtworzyć istniejące funkcjonalność.

Innymi rzeczami, które zrobiliśmy, aby poradzić sobie ze złym i / lub starszym kodem, były zadania związane z przeróbką podczas przygotowywania historii użytkowników.

Decyzja o dużych przepisywaniach jest decyzją biznesową. Możesz próbować wpływać na decyzje biznesowe, sprzedając z własnego punktu widzenia osoby odpowiedzialne za część biznesową rzeczy.

Jednak; zmiana jakości kodu z jednej iteracji na drugą jest decyzją programisty. Jeśli dopuścisz do obniżenia jakości kodu, dodajesz dług techniczny, aby spełnić oczekiwania właściciela produktu. Możesz wziąć odpowiedzialność za napisany kod i upewnić się, że poprawia on bazę kodu, a nie na odwrót. Teraz oznacza to, że stracisz prędkość, ponieważ ciągle zmniejszasz kwotę długu technicznego, a właściciel produktu na pewno będzie zawiedziony. Możesz spróbować wyjaśnić, że z chęcią sprawiłeś, że jakość kodu obniżyła się, a teraz podejmujesz kroki w celu rozwiązania tego problemu.

Teraz zdaję sobie sprawę, że jest to przerażający krok i może być kuszące, aby opóźnić go o jeszcze jeden sprint, abyś mógł wydostać się z funkcji X przed ważnym terminem. Niestety, im dłużej będziesz czekać, będzie to trudniejsze.

Nawiasem mówiąc, nie jest to kwestia ściśle Scruma, ani nie sugeruję rozwiązania specyficznego dla Scruma. Chodzi o to, że programiści przejmują na własność kod.

Programiści są odpowiedzialni za ostrzeganie świata o aktualnym stanie bazy kodu. Może się to zdarzyć podczas codziennego scrum, retrospekcji lub po prostu nieformalnie. Może się to wydawać oczywiste, ale jeśli nie wyrazisz jasno, jaki to bałagan i ile czasu z tego powodu marnujesz, nikt nigdy nie zauważy. Scrum Master będzie zazwyczaj odpowiedzialny za przekazywanie informacji do PO i osób odpowiedzialnych za projekt i przekonanie ich, że należy coś zrobić, a następnie ułatwienie wdrożenia rozwiązania przez zespół.

Na marginesie, przepisywanie Big Bang przez IMO niekoniecznie jest właściwą odpowiedzią na tego rodzaju problem. Niezależnie od tego, czy macie dość deweloperów z obecną bazą kodu, zrobienie drobnych, mierzalnych kroków w kierunku czystszej architektury jest często lepszym pomysłem, ponieważ można zobaczyć postęp, uzasadnić swoją pracę, regularnie pokazując PO osiągnięcia i kontynuować wdrażanie nowego użytkownika historie równoległe, a nie gubiące się w niekończącej się, monopolizującej metamorfozę.

Zapytałeś:

Gdzie jest część Scruma, w której programiści mogą powiedzieć, że wystarczy wystarczającej ilości i zażądać, aby mieli czas na rozpoczęcie przepisywania? Wydaje się, że jesteśmy w niekończącej się pętli polegającej na łataniu starego kodu za pomocą „Stories”. Więc rzeczy są prowadzone przez nietechnicznych ludzi, którzy wydają się nie mieć ochoty naciskać na przepisanie, ponieważ nie rozumieją, jak źle zrobiła się baza kodu ...

Jako ktoś, kto jest zarówno menedżerem, jak i programistą, najprostszą odpowiedzią na twoje pytanie jest to, że nie ma udziału w Scrumie ani w żadnej innej metodologii, ani w żadnym scenariuszu biznesowym, w którym programista ma moc powiedzieć, że wystarczy i żąda przepisać. Wiele osób przedstawiło tutaj dobre, uzasadnione argumenty, aby wyjaśnić, dlaczego ponowne pisanie jest często złymi pomysłami oraz wyjaśnić, w jaki sposób można i należy wprowadzać zmiany w sposób stopniowy i zwinny. I zgadzam się z nimi wszystkimi.

Ale sedno jest jeszcze prostsze. Nigdy nie podejmiesz takiej decyzji, KIEDYKOLWIEK. Jesteś pracownikiem i jedyną decyzją, którą naprawdę możesz podjąć, jest „czy będę nadal pracował dla tych dupków, czy znajdę nową pracę, która boi się moich szalonych umiejętności”. Twoja nowa praca również nie pozwoli ci podjąć tej decyzji, ale przynajmniej poczujesz, że kontrolujesz swój los, skacząc z pracy do pracy.

Czuję twój ból, ale nie jestem pewien, co to ma wspólnego ze Scrumem. Decyzja o ponownym zapisaniu kodu nie zależy od procesu programowania.

Czekaj, co?

Jesteś łatanie ? Powinieneś refaktoryzować . Trzymaj się zwinnych wartości. Użyj TDD i odpowiednich praktyk, a sytuacja ostatecznie się poprawi.