Radzenie sobie z niekończącym się niekończącym się projektem

Mamy dużą (ponad 1200 godzin) stronę internetową, która ma duże zadłużenie techniczne. Wynika to głównie z następujących (zwykle) przyczyn.

1. Wielu programistów, którzy przychodzą i odchodzą podczas programowania.
2. Zmiana specyfikacji podczas programowania.
3. Dodano wiele dodanych funkcjonalności (w krótkim czasie).

Klient chce wielu nowych funkcjonalności, a to w zasadzie sprowadza się do pracy nad tym projektem co tydzień przez ponad 10 godzin.

Z powodu długu technicznego spędzamy DUŻO godzin na naprawianiu lub badaniu problemów, które zwykle znajdują swoje źródło w jednym z poniższych:

1. Bezwstydna, głupia robota, która powoduje, że ludzie płaczą.
2. Nowa funkcja skutkuje powyższym, ponieważ nie przewidzieliśmy wszystkich miejsc, na które nowy wpływ miałby wpływ.
3. Inne napotkane problemy (np. Migracja serwera, aktualizacje)

Mamy problemy codziennie i staraliśmy się następujące rzeczy umieścić to do zatrzymania:

1. Utworzono dokumentację techniczną dotyczącą importu, płatności i ogólnego działania strony.
2. Spotkaj się na początku tygodnia - omawiając bieżące problemy lub ulepszenia oraz sposoby ich rozwiązania.
3. Mieć plan testów. Programator A test B, B testy C i C testy A. Następnie nasz Kierownik Projektu przeprowadzi niektóre testy. Jeśli chodzi o wpływ tej funkcji, rzucamy ją na środowisko testowe i pozwalamy klientowi sprawdzić się.

Problem polega na tym, że problemy się zdarzają ... i jakoś nie możemy się z tym pogodzić. Nowe funkcje wciąż powodują błędy, a stare błędy przywitają się. W jakiś sposób - być może ze względu na wielkość projektu - nie wydaje się, abyśmy mogli go opanować.

Zakładam, że jest dużo programistów pracujących nad większymi projektami. Dlatego przechodzę do mojego pytania:

Co możemy zrobić lub co zrobić , aby uniknąć tych problemów w dużych projektach?

Drobna edycja, dodatkowe informacje:

1. Używamy kontroli wersji (SVN).
2. Mamy proces rozwoju DTAP.

Będę grał w adwokata diabła, ponieważ zbyt często widziałem, jak to się okazuje: nie możesz sobie z tym poradzić. Gwarantuję, że jesteś jedyną osobą, która widzi prawdziwy problem z obecnym systemem, w przeciwnym razie nie będziesz musiał pytać, jak sobie z tym poradzić, ponieważ kultura firmowa polega na usuwaniu błędów i naprawianiu kodu wszędzie tam, gdzie to możliwe, tzn. działając, jak działają prawdziwi profesjonaliści.

Założę się, że jest zbyt duży, aby rozpocząć pisanie testów jednostkowych, ponieważ nie miał nikogo, kto wiedziałby, jak przeprowadzić testy jednostkowe przed tobą (i przy odrobinie szczęścia innych osób w zespole) i nie można wiedzieć, od czego zacząć, a może nawet niemożliwe test, ponieważ opiera się na dokładnych implementacjach i konkretnych danych, więc usunięcie tego wszystkiego na interfejsy, symulacje, kody pośredniczące i tym podobne zajęłoby o wiele za dużo czasu, aby móc je przetestować. Założę się również, że nie możesz po prostu przefiltrować tego, co należy refaktoryzować, ponieważ jest zbyt ściśle powiązane, a ponieważ nie ma testów, kto wie, co zostanie zepsute przez naprawienie złego kodu. Krótko mówiąc, prawdopodobnie stał się zbyt rakowy, aby go poważnie naprawić, ale oczywiście nie można go po prostu wyciąć i zacząć od nowa.

Staczasz przegraną bitwę, przyjacielu. Albo wypalisz się z frustracji i ostatecznie porzucisz lub oszalejesz, albo jeśli narzekasz na to wystarczająco długo, próbując przekonać innych do zrozumienia problemów, pomyślą, że jedynym problemem jest ty i zobaczysz drzwi.

Testowanie jednostkowe jest dobrym punktem wyjścia, jeśli nic nie robisz. Przynajmniej ochronią cię przed dodawaniem nowych błędów podczas usuwania starych błędów.

Kontrola źródła również pomaga, chyba że go nie używasz. W szczególności funkcje obwiniania i rejestrowania są wspaniałe, aby ustalić, w jaki sposób / dlaczego popełniono błąd w kodzie.

Po stronie klienta stwierdziłem, że omawianie ceny i (dużych) opóźnień, gdy tylko wymagane są zmiany / dodatkowe funkcje, działa całkiem dobrze, podobnie jak pobieranie opłat za czas poświęcony na ich omówienie / zaprojektowanie. Często klienci decydują, że po drugiej myśli mogą poczekać.

(W przeciwieństwie do tego, jeśli od razu zajmiesz się specyfikacjami i pomysłami na implementację, zazwyczaj ustawią cię na „och, myślałem, że i tak zgodzimy się na to” lub (gorzej, po kilku dniach wycofania i napiszmy o szczegółach) „ale spójrz, jest już zaprojektowany, a my, o czym rozmawialiśmy, nie brzmi tak ciężko!”.)

I wreszcie, okazało się, że fakt, że czytam e-maile tylko raz dziennie (po przyjeździe do pracy) i że mam telefon do czegoś pilniejszego, prowadzi do ogromnego wzrostu wydajności.

Sugeruję dodanie testów opartych na CI, głównie na obszarach, które najczęściej się psują. Pomoże to podnieść jakość w trakcie pracy nad projektem.

Staje się również bardziej widoczne, które obszary / funkcje ulegają częstszym awariom, dzięki czemu łatwiej jest zdecydować, które części wymagają refaktoryzacji lub przynajmniej zwiększonego testowania.

Dodanie większej liczby ręcznych testów wiąże się z ryzykiem, że projekt pójdzie w niewłaściwy sposób pod względem $$$ i czasu wymaganego na dodaną funkcję.

Przegląd kodu jest dobry, ale może to część schematu testowania A-> B-> C-> A. (Może przegląd kodu w innym kierunku?)

Pozwól mi rzucić ci bajkę. Spacerowałeś z osobą wcześniej tego samego dnia ulicą i dotarłeś do celu. Osoba, z którą idziesz, szybko dowiaduje się, że zgubił gdzieś po drodze pierścień, więc oboje zdecydujcie się na powrót i poszukiwanie go. Osoba, z którą idziesz, szybko zatrzymuje się przy latarni i zaczyna gorączkowo patrzeć. Mówicie: „Dlaczego patrzysz tam na latarnię, kiedy myślę, że mogłeś ją zgubić, kiedy przecinamy ulicę?”. Odpowiada: „Wiem, ale światło tutaj jest lepsze”.

Byłem w tej sytuacji więcej niż kilka razy i zauważyłem pewne podobieństwa. Tego rodzaju koszmary związane z konserwacją są zazwyczaj prowadzone w środowisku o dużym obciążeniu procesowym, z dużym nadzorem i usprawnieniami procesu narzuconymi przez kierownictwo. Nie twierdzę, że usprawnienia procesów są złą rzeczą, ale najczęściej rodzaje ulepszeń procesów, które kierownictwo zazwyczaj chce wprowadzić, mają dwa kluczowe punkty.

1) Na ogół nie zakłócają polityki biurowej i równowagi sił. 2) Udaje im się stworzyć iluzję kontroli przez kierownictwo, zamiast uderzać w sedno problemu.

Myśl „tutaj jest lepiej”, zazwyczaj myśli kierownictwo, mówiąc: „Każda nowa funkcja musi mieć szczegółową specyfikację techniczną” lub „Pozwalamy codziennie odbywać cotygodniowe spotkania w celu omówienia problemów i sposobów ich przezwyciężenia”.

Żadna z tych rzeczy nie uderza w sedno problemów i mogą po prostu zmniejszyć wydajność, ale z pewnością potwierdzają iluzję kontroli przez kierownictwo.

Jedynymi prawdziwymi zmianami, na które możesz pomóc, są zmiany, które wstrząsają. Podejrzewam jednak, że twoja monstrualność strony internetowej prawdopodobnie nie jest w tej chwili możliwa do naprawienia i będziesz o wiele dalej, aby przeprojektować i przepisać. W przyszłości można jednak pamiętać o znaczeniu metodyki Agile, ciągłej integracji, rozwoju opartego na testach, przeglądów kodu i specyfikacji wymagań biznesowych, które są regulowane przez ścisłe procedury kontroli zmian, aby pomóc zminimalizować pełzanie zakresu bez dostosowywania harmonogramu.

Tego rodzaju zmiany naprawdę wymagają zmiany w sposobie myślenia na poziomie zarządzania i w całym moim doświadczeniu zawodowym nigdy nie spotkałem się z tym, gdyby nie doszło do jakiegoś wstrząsu na średnim poziomie zarządzania. Mam nadzieję, że nie jest to zbyt zniechęcające, ponieważ powinieneś próbować tego, co słuszne, niezależnie od tego, czy stoczysz bitwę pod górę, ponieważ prawdopodobnie spotkasz się z silnym oporem ludzi, którzy kochają status quo.

Jakiś czas temu byłem w tym samym miejscu. Nie jestem już dzięki dwóm prostym zasadom:

• Co tydzień spędza się jeden lub dwa dni na naprawianiu / przepisywaniu większości włochatych części aplikacji. Bez szukania błędów, bez opracowywania nowych funkcji.
• Wdrażając nowe funkcje, staramy się, aby działał poprawnie, nawet gdy spędziliśmy więcej czasu, niż oczekuje klient.

Jedynym problemem jest przekonanie innych ludzi, by ich szanowali. Zaskakująco łatwą częścią był klient. Naprawdę nie potrafię wyjaśnić, dlaczego, ale jakoś go przekonaliśmy, że kiedy pracujemy nad funkcją nieco dłużej, jest to lepsze dla wszystkich. Przestrzeganie pierwszej zasady okazuje się bardziej problematyczne, ale czujemy, że bardzo nam to pomaga. Gwarantuje stały postęp, ponieważ różne części aplikacji stają się coraz lepsze.

Recenzje kodu. Testy jednostkowe. Prawdziwe testy jakości. Proces zbierania specyfikacji i stopniowy rozwój - są to niektóre rzeczy, które powinny rozwiązać większość problemów.

Nie pozwól też, aby klienci bezpośrednio pingowali twoich programistów - jest to zazwyczaj najbardziej nieproduktywny sposób rozwiązywania problemów. Zatrudnij dobrego menedżera programu, który utworzy interfejs między Twoimi klientami a programistami. Jego zadaniem będzie znajomość produktu od końca do końca, aktualny status, przyszłe kierunki i tak dalej. Za każdym razem, gdy klient chce kolejnej nowej funkcji, powinien być w stanie podać aktualną listę produktów i pokazać klientom, co zostanie odrzucone, jeśli ma zostać przyjęte nowe żądanie.

Proces jest zły, gdy jest używany za mało lub za dużo. Myślę, że jesteś w byłym stanie.

Jak wspomina Deni, jeśli możesz dodać testy jednostkowe do projektu, to by ci pomogło. Przeprowadź test obejmujący część systemu, którą zamierzasz zmienić / naprawić, a więc kiedy kodujesz kod, użyj tego testu jako przewodnika, aby upewnić się, że nic nie zepsujesz.

Ponadto segreguj najbardziej uszkodzone części kodu. Staraj się umieścić tych, którzy są najbardziej dotknięci, na liście ryzyk i zarządzaj nimi niezależnie. Spróbuj dowiedzieć się, ile uszkodzonego kodu znajduje się w bazie kodu, sprawdzając, gdzie najczęściej występują błędy. Następnie możesz wymienić obszar dotknięty problemem według liczby błędów (lub zgłoszonych problemów, cokolwiek dla Ciebie działa).

Poprawianie i czyszczenie kodu zajmie trochę czasu, ale jeśli każdy deweloper w zespole może zostawić kod nieco bardziej przejrzysty, to było nim zanim go poprawiono, z czasem baza kodu ulegnie poprawie. Jeśli szukasz szybkiego, wojskowego stylu, posortuj to teraz, jestem pewien, że jest coś praktycznego (lub zalecanego), co by pomogło.

Twoje zdrowie. Jas.

Napisz jasne specyfikacje funkcjonalne; pedantycznie, więc jeśli możesz to znieść i regularnie sprawdzaj funkcjonalność pod kątem tych specyfikacji. Im mniej pomysł ma twórca na temat tego, co powinien opracować, tym mniejsza szansa, że ​​będzie to sposób, w jaki powinien się rozwijać.

Zanim zaczniesz pisać kod, zrób trochę pracy projektowej; nie musi to być ani doskonałe, ani duże, ani zawierać UML, ale powinno stanowić dość solidne rozwiązanie problemu, który należy rozwiązać. O ile wiem, im mniej oprogramowania jest planowane, tym gorzej. Omów projekt, zanim zaczniesz nad nim pracować.

Kiedy zaczniesz pracować nad obszarem kodu, który jest wyraźnie zły i naprawdę utrudnia twoje postępy; przestań go dodawać, odsuń się od problemu, wymyśl, jak możesz przeprojektować architekturę, aby nie było przeszkód i aby była bardziej elastyczna w przyszłości. Im dłużej pozostawiasz go przed uregulowaniem długu technicznego, tym trudniej będzie go rozwiązać bez pełnego przepisania. Powiedziałbym, że to wykładnicza rzecz.

Projektuj testy, które sprawdzają zachowanie i nie łączą się ściśle z Twoją architekturą. Nie jest to zbyt modne, ale powiedziałbym, żeby nie zaczynać testowania, dopóki prawdziwy cel twojego kodu nie będzie jasny. W szczególności nie zaczynaj testowania, dopóki nie dowiesz się, co naprawdę chcesz przetestować; IMO źle przemyślany test jest gorszy niż brak testu. Im więcej testów, tym trudniej jest wewnętrznie zmienić kod. Traktuj swój kod testowy jak kod produkcyjny; musi być zaplanowany i dobrze napisany.

Rób regularne / codzienne przeglądy kodu: chodzi bardziej o sprawdzanie rozsądku, aby upewnić się, że deweloper nie poszedł zbyt daleko. Skorzystaj z tych sesji, aby zaplanować pracę na kolejne dni. Mogą istnieć dni, kiedy zajmują 5 minut lub 1 godzinę; chodzi o to, aby dialog był otwarty i dać programistom szansę na omówienie swojej pracy z innymi programistami i zasięgnięcie porady. Wykonuj sesje parowania na trudnych częściach kodu lub prototypuj pomysły, ale daj ludziom czas na pracę.

Ułatw zbudowanie i wdrożenie kodu. Staraj się, aby czasy kompilacji były krótkie. Im łatwiej jest zbudować, tym więcej zostanie zbudowane, tym szybciej, tym więcej zostanie zbudowane.

Przyjęcie standardów kodowania i ścisłe ich egzekwowanie. Powinno to obejmować wszystko, od miejsca, w którym projekt powinien mieszkać w systemie plików, po obudowę prywatnego const. Może się to wydawać bezcelowe i denerwujące, ale dobre nawyki są podstawą procesu rozwoju.

Zasadniczo nie sądzę, że proces, który stosujesz, ma tak duże znaczenie, mody przychodzą i odchodzą. Najważniejsze jest to, że jesteś profesjonalistą w zakresie tworzenia oprogramowania i że jesteś zdyscyplinowany w swojej praktyce.

Zacznę od zaprojektowania i zautomatyzowania testów dymu i wrzucenia ich do środowiska CI. Te powinny być funkcjonalne. Gdy klient powie Ci, że coś powinno działać tak a tak, poproś o zanotowanie go, abyś mógł się do niego później odwołać. Gdy zobaczysz określone rozwiązanie w oprogramowaniu, zadawaj pytania, a gdy tylko otrzymasz odpowiedzi, włącz je do bazy wiedzy i spraw, aby były możliwe do prześledzenia.

Zapewnij, że działa podstawowa funkcjonalność pozytywnych przypadków. Następnie rozpocznij tworzenie przyrostowych testów nieprawidłowej obsługi danych, umieszczając defekty tam, gdzie zostanie to uznane za konieczne. Przeprowadzić długą i głęboką dyskusję na temat priorytetów i poinformować o tym kierownika testów, aby mógł odpowiednio przydzielić czas testowania. Nie próbuj automatyzować wszystkiego, ale jak tylko niektóre przypadki testowe mają sens, aby być zautomatyzowanym - nie wahaj się.

Ogólnie rzecz biorąc, testowanie służy do zwiększenia zaufania do produktu, a nie jako narzędzie, które natychmiast poprawi jakość. Bądź spokojny, a jednocześnie asertywny :). Być może spróbuj zwinności, ale tylko jeśli absolutnie, pozytywnie możesz zaangażować certyfikowanego premiera. Przedstawienie Agile osobie, która nie zna Agile, najprawdopodobniej zabije projekt.