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

23

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ć ->.

punkouter
źródło
20
Fałszywa zwinność znów podnosi brzydką głowę ... Wiele firm twierdzi, że są „zwinne” i używają „scrum”, podczas gdy w rzeczywistości nie robią tego ani jednego.
Oded
4
Nie wykonujesz Scruma
20
rozważ wydrukowanie dużego plakatu na ten temat i umieszczenie go na ścianie w miejscu, w którym osoby nietechniczne mogą go wyraźnie zobaczyć: Manifest dotyczący rozwoju oprogramowania zwinnego w połowie ... Podczas gdy elementy po lewej brzmią ładnie w teorii, jesteśmy firma korporacyjna i nie ma mowy, żebyśmy puścili przedmioty po prawej
komara
12
obowiązkowy link do bloga Joela: joelonsoftware.com/articles/fog0000000069.html
marco-fiset
8
„<-wstawać o ludziach nietechnicznych, którzy mówią ludziom, co mają tutaj robić->” , kierownictwo powinno w 100% mówić ludziom technicznym, co mają robić, dlatego to oni są zarządcami i odpowiedzialni za biznes , to jest to, co oni robić najlepiej. Co oni 100% powinno nie robić jest mówienie im , jak to zrobić, tech ludzie powinni zdecydować, na jaki się technicznie osiągnąć to, co oni zostali poproszeni zrobić. Wszystko inne jest całkowicie naiwne !

Odpowiedzi:

7

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.

Erik Reppen
źródło
Jeśli chodzi o refaktoryzację, wydaje mi się dziwne, że ludzie nie są w stanie „zinternalizować” tego, że refaktoryzacja jest stałą częścią całego rozwoju, a nie czymś, czego się boli, gdy problem jest tak poważny, że niewiele można zrobić.
nicodemus13
1
Lub nie masz testów jednostkowych. :) Jedną z głównych zalet testowania jednostkowego jest to, że pozwala on na pewną refaktoryzację. Największy problem z dobrą praktyką jest taki sam jak wszystko - wymaga dyscypliny i ogólnie ludzie wolą być leniwi.
nicodemus13
2
To lub jeszcze jeden prezent od tłumu kodującego, który równie łatwo można przekształcić w narzędzie, które umożliwia złe zachowanie w niewłaściwych rękach. Zautomatyzowane testy są przydatne w kluczowych punktach, ale wolę architekturę dźwięku i pisanie od interfejsu zamiast testu.
Erik Reppen
1
Powiedziałbym, że tak samo jest dla wszystkiego, osobiście piszę testy, aby pomóc zdefiniować interfejs.
nicodemus13
1
Potem pojawia się ból wszystkich kłębków, które należy przywrócić, ponieważ istnieją małe wyjątki, które nie mogą być łatwo wychwycone przez wstępną analizę.
JB King
33

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.

EricSchaefer
źródło
8
Jeśli masz tyle doświadczenia i mądrości, ile twierdzisz, zrób krok i bądź facetem, który odkryje ten wadliwy moduł, zostań ekspertem od niego i napraw go, a następnie przygotuj uzasadnienie biznesowe, aby go ponownie napisać, ponieważ wtedy będzie ekspertem w tym module.
3
Niektóre bałagany wymagają oczyszczenia. Cytując artykuły Joela i stwierdzając, że przepisywanie rzadko się sprawdza, bez statystyk, które i tak byłyby wątpliwe (bo kto chwali się udanymi przepisywaniami?) Tego nie zmienia.
Erik Reppen,
3
@ErikReppen Więc kiedy twój salon jest brudny, burzysz dom i budujesz nowy?
EricSchaefer
4
Jeśli czytasz jego komentarze, on nie mówi o salonie. Prawdopodobnie trudno powiedzieć, gdzie zaczyna się jeden pokój, a drugi kończy. I cały dom płonie.
Erik Reppen
5
Zaraz, kowboju. Zanim wydamy ogólną wypowiedź na temat „przepisywania nie jest dobrym pomysłem”, myślę, że musimy to zakwalifikować prawdą, że przejście na nowe technologie i dostosowanie się do czasów jest niezbędne dla przetrwania IT twojej firmy. Jeśli nie zastosujesz nowszych (miejmy nadzieję lepszych) technologii i korzyści, jakie dają, konkurenci to zrobią. Dotyczy to ogólnie techniki. Model T był doskonale dobrym pojazdem, ale dzięki konkurencji i wprowadzeniu nowej technologii samochody były wielokrotnie „przepisywane” na znacznie lepsze pojazdy, którymi dziś jeździmy.
blesh
18

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,

S.Robins
źródło
Nie. Nie odpowiadam. Jestem programistą, który kodował 12 lat profesjonalnie i 7 lat .NET. Byłem na wielu kontraktach i po pewnym czasie możesz szybko poczuć jakość kodu. Ile „stawek”? Nie jestem pewien, co przez to rozumiesz. Możemy nadal podłączać i naprawiać starą klasyczną ASP, która jest teraz wyjątkowo delikatna i zajmuje 10 razy dłużej, niż gdyby zmiany te były częścią dobrej nowoczesnej architektury. Uzasadnieniem biznesowym jest to, że witryna ulega awarii w produkcji z powodu modułu, którego nikt nie rozumie ze względu na wysokie obroty
punkouter
Nie sądzę, że rozumiesz, jak zła jest ta baza kodu. Ponadto nie jest to nauka rakietowa. To jest CRUD 101. Wyświetla formularz, umożliwiając użytkownikowi wypełnienie go, sprawdzenie poprawności, a następnie utworzenie niektórych raportów i plików PDF na podstawie danych. To w gruncie rzeczy .. Ale przez 10 lat kod został podzielony na tak wiele kawałków, że jest to okropne. W ciągu ostatnich 12 lat brałem udział w około 20 projektach i to musi być najgorszy zbiór kodu, jaki widziałem, który jest faktycznie wykorzystywany w produkcji ... Chciałbym pokazać wam wszystko
punkouter
To, co robię na początek, polega na znalezieniu ludzi w zespole, którzy mają trochę pasji do kodowania i są zainteresowani udziałem w ostatecznym zrozumieniu tego. Nie jest łatwo znaleźć tych ludzi z powodu ... brucefwebster.com/2008/04/11/…
punkouter
16
@punkouter: Myślę, że nie rozumiesz, o co tu chodzi; Baza kodu, która jest „zła”, nie jest uzasadnieniem biznesowym do przepisania. Pasja do kodowania i chęć poprawnego działania nie jest uzasadnieniem biznesowym do przepisania. Kosztowne błędy produkcyjne i przerwy w dostawie, a także wdrożenie miesięcy w trywialne, ale ważne nowe funkcje - THOSE stanowi uzasadnienie biznesowe do przepisania.
Michael Borgwardt,
1
@punkouter Twój link do opisu zjawiska „Dead Sea” jest również szczególnie trafny. Nie ma sensu tracić wiedzy przez biznes na skutek ścierania się, a odzyskanie tego, co może, ma wielką wartość. Inwestycja czasu w uniknięcie potencjalnie kosztownego i niepotrzebnego przepisywania ma większą wartość biznesową niż utrata wiedzy i doświadczenia. Zachęcanie do lepszych praktyk zatrudniania i stawienie czoła wyzwaniu, jakim jest usunięcie problemu i udoskonalenie systemu, to okazja, aby zarobić trochę uznania i stać się cennym atutem dla pracodawcy.
S.Robins
13

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.


źródło
8
Zespół jest odpowiedzialny za własny bałagan, ale nie może wybrać priorytetu długu technicznego a nowych funkcji. Decyduje o tym właściciel produktu. Po prostu, gdy organizacja producentów zdecyduje o priorytecie zaległości, zespół może zdecydować, jak ją dostarczyć. Mogą powiedzieć „nie możemy dostarczyć funkcji X bez uprzedniego refaktoryzacji Y”, ale nie mogą powiedzieć „nie, przepraszamy, nie dodamy żadnych nowych funkcji, dopóki nie przepisujemy jej od zera”.
Bryan Oakley,
6
@BryanOakley: Przepisywanie od zera nie jest tym, co sugeruję. Sugeruję stopniowe zmniejszanie zadłużenia technicznego, ponieważ zespół programistów pracuje nad danymi obszarami. Sugeruję również, aby odpowiednio oszacowali.
1
To dobrze, ale co, jeśli potrzebujemy nowych serwerów, nowych baz danych, nowego oprogramowania, aby nasi deweloperzy mieli wszystkie narzędzia potrzebne do przepisania? A jak zaczyna się przepisywanie, gdy jedyne „Historie” dotyczą naprawiania bieżących problemów, a nigdy koncepcji „przepisywania”?
punkouter
1
@punkouter: jeśli musisz przepisać, rozwiąż problem w retrospekcji scrum. Następnie właściciel produktu przejmie odpowiedzialność za anulowanie bieżącego projektu i rozpoczęcie nowego.
5
Nie zakładaj, że decyzja o przepisaniu jest „właściwa” tylko dlatego, że najbardziej podoba się twórcom. Czasami istnieje dobry powód biznesowy, aby udostępnić funkcje już teraz, nawet jeśli zwiększy to zadłużenie techniczne.
DJClayworth
8

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ę.

Peter Mortensen
źródło
1
to nie znaczy, że nie jest odpowiedzialny za deweloperzy użyć jakiś system kontroli wersji wewnętrznie niezależnie, chciałbym powiedzieć, że jest nadal w gestii programistów, aby dbać o siebie i swoich najlepszych interesów niezależnie. W twoim słomkowym człowieku tych 200 deweloperów nie zrobiło tego, co musieli zrobić, kierownictwo nie przyłożyło pistoletu do głowy i zabroniło im samodzielnego konfigurowania systemu kontroli wersji.
3
Podstawy Messy Code nigdy nie są bezpośrednim wynikiem zarządzania, ponieważ zarządzanie nigdy nie jest bezpośrednio odpowiedzialne za pisanie kodu. To takie proste. Zarządzanie jest odpowiedzialne za tworzenie i rozwijanie mniej niż idealnego środowiska pracy dla programistów, ale odpowiedzialność za rozwiązywanie problemów, takich jak brak kontroli wersji, zawsze spoczywa na tych, którzy wykonują rzeczywistą pracę.
Peter Lange,
1
Outsourcing devs to problem z zarządzaniem. Ludzie w środku wiedzieli lepiej. Zarząd lubił udawać, że oszczędza mnóstwo pieniędzy, zatrudniając 200 deweloperów, podczas gdy w rzeczywistości mogliby zrobić to dobrze z 20 kompetentnymi. Podobnie jak wiele wdrożeń Scrum, które widziałem, przyjęta strategia była wynikiem niekompetencji i nic, nad czym twórcy, którzy byli pracownikami firmy, nie mieli żadnej kontroli.
Erik Reppen,
2
@Erik, nie mówiąc, że menedżerowie nie muszą ponosić odpowiedzialności za złą bazę kodu (lub wszelkie inne złe decyzje podjęte w ich dziale) i że menedżerowie nie są bezpośrednio odpowiedzialni za zapewnienie środowiska, w którym pracuje programista, takiego jak opisany scenariusz. Ale jedyną osobą, która może być bezpośrednio odpowiedzialna za bazę kodu, jest osoba, która sama pisze kod.
Peter Lange,
3
Chciałbym również dodać, że głupotą jest nie dopuścić do tego, aby twoi deweloperzy byli wtajemniczeni w cele biznesowe. Nigdy nie zrozumiałem, dlaczego ludzie tak bardzo chcą ukrywać te rzeczy przed ludźmi, którzy faktycznie decydują o zachowaniu ich produktu. Znajomość długoterminowych celów firmy może w rzeczywistości informować o sposobie tworzenia aplikacji. Również deweloperzy, przynajmniej ci dobrzy, rozwiązują problemy. Ciągle rozwiązują problemy. Niektórzy z nas przewidują i rozwiązują je z wyprzedzeniem w naszych głowach lub przynajmniej pozostawiają otwarte drzwi otwarte w naszym kodzie.
Erik Reppen
7

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.

Michael Brown
źródło
Może to być trudne, jeśli istniejąca baza jest dość bałaganu. Mówi o wielu starszych systemach asp.net autorstwa zupełnie różnych autorów ściśle powiązanych dla tej samej cholernej strony. Same formularze sieciowe są potworem i jestem pewien, że jest to mieszanka.
Erik Reppen
Och, nigdy nie powiedziałem, że będzie to najłatwiejsza droga ... ale jest bardziej smaczna dla interesariuszy. Mam nadzieję, że raz to przejrzysz, więc upewnisz się, że kiedy dzisiejsze najnowsze i największe wydarzenia staną się przestarzałe, łatwiej będzie je wycofać.
Michael Brown
Zgadzam się. Ale tak jak powiedziałem Ive (i nie jestem pewien, że wszyscy tu są). To, co istnieje, to zbiór około 9 oddzielnych aplikacji internetowych, z których połowa to Klasyczna ASP, a druga połowa to różne formy ASP.NEt. Wszystkie używają zupełnie różnych sposobów obsługi dostępu do danych itp. Więc jedynym sposobem na zrobienie tego, o czym się mówi, jest sfałszowanie interfejsu użytkownika, aby wyglądał, jakby nowy kod był częścią starego kodu ... więc tak, może ... ale wtedy jest baza danych .. Jedna tabela ma 400 pól!
punkouter
Jestem ciekawy. Co przedstawia ta tabela? To najgorsza rzecz, o której słyszałem od czasu, gdy zobaczyłem i ++; doSomething (i); powtórzone kilkanaście razy w kodzie, który wylał się z uszkodzonego tagu JSP.
Erik Reppen,
5

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.

BennyB
źródło
Czyli deweloperzy mogą pisać „historie” i przesyłać je? Problem polega na tym, że przyczyny ponownego pisania są dla nich zbyt techniczne, aby sobie z nimi poradzić ... Wszystko, co mogę powiedzieć, to ... „Obecny kod jest trudny do zarządzania i łamie się” ..
punkouter
6
@punkouter: jeśli powody, dla których chcesz przepisać, są czysto techniczne (tj. nie kosztują pieniędzy biznesowych), NIE MAJ wystarczającego powodu do przepisania.
Michael Borgwardt
@MichaelBorgwardt: Czy twierdzisz, że jakiekolwiek względy techniczne nigdy nie są wystarczające do przepisania czegoś? To fundamentalnie złamane podejście, jeśli dobrze cię rozumiem. Jedną z rzeczy, które ciągle mi się denerwują, jest normalne podejście master / slave, że „biznes” określa wszystko, co robi „IT” lub jakikolwiek dział. Dotyczy to tylko do pewnego stopnia. IT ma własne wymagania, które są wewnętrzne i nie są determinowane przez biznes - to jedna z rzeczy, której zwykle brakuje, i która prowadzi do niezaprojektowanego, nieodpowiedniego oprogramowania.
nicodemus13
1
@ user12355 Jak widziałem, Michaels twierdzi, że jeśli nie traci pieniędzy, nie zarobi ich, to nigdy nie ma sprawy. Jeśli nie tracą pieniędzy, przepisywanie kosztuje je. Pieniądze, których nie można odzyskać. Deweloper może przedstawić przypadek „ten kod jest do kitu”, ale jeśli nie uda mu się udowodnić korzyści finansowej pracodawcy, nigdy nie dostanie zielonego światła do przepisania, chyba że zrobi to samodzielnie.
rig
1
@ user12355: Przyczyny techniczne są zdecydowanie wystarczające dla historii użytkownika. Niekoniecznie wystarczą, aby ta historia została awansowana na szczyt listy i umieszczona w sprincie.
Adam V
4

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.

Buhb
źródło
1
Właśnie, a jeśli masz 10-letnią historię ciągłych obrotów i działań jednorazowych deweloperów, którzy najwyraźniej nie potrafili dobrze kodować ani zrozumieć współczesnej architektury, masz to, co mam teraz ... Jestem bardziej zaniepokojony niż ktokolwiek inny, odkąd Jestem nowy w pracy i nie przyzwyczajam się do wyświetlania tak niskiej jakości kodu. Chcę przepisać nie tylko ze względu na moje samolubne pragnienie czerpania przyjemności z pisania nowego dobrego kodu ... ale także ze względu na wszystkich innych ... nawet jeśli nie rozumieją sytuacji tak jak ja.
punkouter
1
Mogę tylko powtórzyć to, co już powiedziano; Formalnie nie możesz zdecydować, że teraz jest czas na duże przepisanie. Sądzę, że możesz spróbować pokazać interesariuszom, ile wysiłku wymaga stopniowe przekształcenie bazy kodu w nieco mniej bolesny stan, i porównać to z wysiłkiem, jaki trzeba wykonać, aby całkowicie przepisać.
Buhb
3

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ę.

guillaume31
źródło
Jak wspomniałem .. Nie ma możliwości rozwoju z kolekcją 6 klasycznych stron ASP + 4 witryn .net 1.1, które są połączone w jedną stronę. Wszystkie kodowane przez różnych ludzi na różne sposoby.
punkouter
Jestem prawie pewien, że baza kodów będzie się rozwijała w nadchodzących latach, parafrazując doktora Iana Malcoma z Jurrasic Park „Po prostu mówię, że zarządzanie… hmm… znajdzie sposób” .
Może to potrwać w najbliższych latach, ale różnorodne smaki starszych witryn .net ściśle ze sobą powiązanych prawdopodobnie nie posuną się bardzo daleko w tych latach.
Erik Reppen,
Jasne, ale jeśli wszystkie te witryny .net nadal działają, a ich funkcjonowanie nadal generuje przychody bezpośrednio lub pośrednio dla firmy, dlaczego dynamika rozwoju jest tak ważna? Gdy na jakość kodu bezpośrednio wpływają przychody, możesz uwierzyć, że menedżerowie nie będą marnować czasu na przeprojektowanie, ponieważ wszyscy mają hipoteki, tak jak robią to deweloperzy.
Peter Lange,
Bezustanny pęd do przodu jest zasadniczo źródłem problemu w pierwszej kolejności z mojego doświadczenia. Ból zaczyna się, gdy oczekiwania na zmianę nie maleją, podczas gdy wciąż słuchają problemów w architekturze i myślą, że Scrum będzie magicznie opracowywał nowe zestawy kompletnych funkcji co dwa tygodnie bez dalszego zaostrzania problemu. Nie twierdzę, że nie powinniśmy obawiać się chęci wyrywania rzeczy, jeśli nie możemy wymyślić alternatyw, które rozwiązałyby napotkane ograniczenia czasowe, ale widziałem co najmniej dwa bardzo dobre przypadki dla głównych remonty w mojej karierze.
Erik Reppen
2

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.

Peter Lange
źródło
1
Jeśli poprawnie czytam między wierszami, brzmi to tak, jakbyś był nieco zgorzkniały z powodu niezdolności do trzymania się nowych pracowników. Jeśli się nie mylę, czy pomyślałeś, że nowi pracownicy, których umiejętności są w rzeczywistości wystarczająco duże, aby chodzili, gdy nie lubią pracować w Twojej firmie, są jedynymi stałymi w równaniu?
Erik Reppen
1
Nawet nie blisko. W rzeczywistości pracownicy mojego działu są ze mną od kilku lat. Nie mam praktycznie żadnego obrotu. Chodzi mi o to, że ostatecznie w każdej firmie, w każdej branży, praca wykonywana przez pracownika zależy wyłącznie od osoby podpisującej wypłatę, a nie od pracownika. Jedyną decyzją, którą musi podjąć pracownik, w tym ja, gdy mój szef składa prośbę, jest utrzymanie się lub nie utrzymywanie relacji z pracownikiem. Oryginalny plakat zapytał, kiedy on, jako pracownik, może dyktować rozwój. Odpowiedź nigdy nie jest taka.
Peter Lange
Więc co było z charakterystyką „obawiam się mojego szalonego skilza”? Ten facet jest doświadczonym twórcą. Mogę ci powiedzieć z mojego doświadczenia z podobnymi sytuacjami, że problem, o którym mówi, to nie tylko kwestia chęci zrobienia rzeczy po swojemu, ale w rzeczywistości ciągła katastrofa, która zarówno powoduje, że wszyscy są nieszczęśliwi, jak i kosztuje pracodawcę znacznie więcej w zmarnowanym urządzeniu zatrzymanie czasu i talentów, niż się wydaje.
Erik Reppen
1
Ponieważ ilustrowałem błąd w podstawowej argumentacji, która była zakorzeniona w ego (w sensie psychologicznym). Nie chodzi o to, jak on jest wykwalifikowany. To nie jest pytanie, jak popsuty jest kod. To nie jest pytanie, co metodologia rozwoju może dla niego zrobić. To pytanie o władzę. Uprawnienia do podejmowania decyzji w relacjach pracowniczych spoczywają na pracodawcy. Jedyną siłą decydującą, jaką ma pracownik, jest anulowanie relacji, gdy staje się ono zbyt trudne do zniesienia.
Peter Lange
1
Zgadzam się, scrum jest kiepski w radzeniu sobie z długami technologicznymi. Ale nie zgadzam się co do podstawy pierwotnego pytania. W rzeczywistości zadawał pytanie dotyczące relacji pracodawca / pracownik, ale właśnie wspomniał o scrum w pytaniu. To tak, jak gdybym zapytał: „Jako chrześcijanin, jaki jest najlepszy sposób na stworzenie Enchillady?”. To nie jest tak naprawdę pytanie teologiczne; to pytanie o gotowanie, nawet jeśli popełniłem błąd, uważając, że moje preferencje religijne są istotne.
Peter Lange
1

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.

Nemanja Trifunovic
źródło
Proces rozwoju, który obiecuje, że wszystko zostanie ukończone co dwa tygodnie, może wiele zrobić, aby stanąć na drodze do niezbędnego refaktoryzacji na dużą skalę, który był ignorowany przez lata. Pierwszą rzeczą, jaką zauważyłem w szkoleniu scrumowym, jest sposób, w jaki podchodzą do tematu długu technologicznego. Nie jest ekscytujące deklarowanie, że Twoja aplikacja jest teraz bardziej szczupła i wredna i możesz robić rzeczy szybciej. Typy firm chcą widocznych wartości dodanych, które mogą pokazać znajomym i inwestorom.
Erik Reppen
1

Czekaj, co?

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

Sokół
źródło