Wskazówki dotyczące unikania drugiego syndromu systemu

Question

Ostatnio widziałem, jak nasz zespół programistów niebezpiecznie zbliża się do pomysłów typu "second system syndrome", podczas gdy planujemy kolejną wersję naszego produktu. Chociaż jestem za wprowadzaniem ulepszeń i usuwaniem błędów z przeszłości, nie chciałbym, abyśmy utknęli w nieskończonej pętli przepisywania i nigdy nie uruchamiali niczego.

Czy istnieje dobra metoda projektowania/rozwoju, która pozwala na stworzenie lepszej wersji 2.0 przy jednoczesnym uniknięciu scenariuszy drugiego systemu?

Answer 1

„Nie chciałbym, aby zobaczyć nas tkwi w niekończąca się pętla przepisywania i nigdy nie uruchamiająca niczego. "

Dlatego ludzie używają Scrum.

1. Zdefiniuj zaległości dotyczące rzeczy do skompilowania.

2. Priorytet, aby rzeczy, które doprowadziły do ​​wydania, są pierwsze. Rzeczy, które należy naprawić, są na drugim miejscu.

3. Wykonaj sprinty, aby dostać się do wydania. Wykonaj sprint zwalniający.

Answer 2

Skoncentrowanie się na architekturze systemu powinno pomóc np.

• uwzględniając udokumentowane interfejsy, które obsługują „luźne sprzężenie” pomiędzy podsystemami
• Po udokumentowanych decyzji projektowych (uniknąć ponownego mieszaja wcześniej ubite ścieżki)

Stąd, bez przechodzenia na all out swapu , obecny system można "zaktualizować" o bardziej odpowiednie interfejsy, aby pomóc w przyszłym rozwoju.

---

Innym dobrym sposobem, aby skupić: przypisać postać $$$ do każdej funkcji i priorytety odpowiednio ;-)

Tak czy inaczej, tylko moje 2cents

Answer 3

Staraj się skupić na krótkich cyklach dostaw, tj. Zmuszaj się do dostarczenia użytkownikom czegoś materialnego i przydatnego co kilka tygodni lub miesięcy. Ustal priorytety zadań w oparciu o ich wartość dla klienta. W ten sposób zawsze masz użyteczną, funkcjonalną aplikację z zadowolonymi użytkownikami, podczas gdy pod maską możesz, jeśli chcesz, refaktoryzować architekturę małymi krokami (i jeśli możesz to uzasadnić - to znaczy w kierunku zarządzania/klientów, nie tylko koledzy z drużyny!).

Bardzo pomaga, jeśli masz stabilny proces budowy z dobrym zestawem testów automatycznych (unit/integration).

Zręczne metody programowania, takie jak Scrum, robią to i są gorąco polecane. Ale oczywiście nie zawsze jest łatwo, a nawet możliwe, przystosować taką metodę w swoim zespole. Nawet jeśli nie możesz, możesz nadal brać elementy z tego i stosować je do korzyści swojego projektu (może nawet nie wymieniając publicznie słów "zwinny" lub "Scrum" ;-)

Answer 4

Zdobądź kogoś, kto napisał co najmniej trzy systemy do kierowania projektem.

Answer 5

Upewnij się, że dokumentujesz wymagania tak dobrze, jak to możliwe.Oczywiście musisz również zarządzać tym, co spełnia wymagania, aby uniknąć nadmiernego projektowania, mając ustalony zakres, który uniemożliwia deweloperom uruchamianie pomysłów lub pozłacanie, co należy zrobić, i pomaga utrzymać zarządzanie lub klientów przed wprowadzaniem pełzania zakresu . Określ wszystkie wymagania i jak będą rozwiązywane zmiany zakresu.

Jestem za krótkimi cyklami rozwoju (upewnij się, że piszesz testy) i zwinną metodologią, ale żadna z nich nie jest tarczą przeciwko drugiemu syndromowi. W pewnym sensie łatwiej jest dodawać funkcję po funkcji, jeśli pracujesz w krótkim sprincie, nie zatrzymując się, by spojrzeć na ogólny obraz. Użyj zwinnych praktyk, aby zbudować najprostszą rzecz, która działa, a następnie dodaj pozostałe swoje wymagania tak prosto, jak to tylko możliwe. Zapamiętaj YAGNI, ponieważ kiedy zbudujesz system po raz drugi, wtedy najprawdopodobniej zbudujesz coś, czego na pewno będziesz potrzebował w pewnym momencie, coś, co sprawi, że system będzie "rozszerzalny", więc nigdy nie będzie musiał trzecia kompilacja. To najlepsze intencje, ale droga do piekła i tak dalej.

Answer 6

ja up-głosowało odpowiedź S. Lott i chciałbym dodać jeszcze kilka sugestii:

1. dostarczyć produkt pracy do klienta tak często, jak to możliwe. Iteracje trwające od kilku tygodni do 2 miesięcy są idealne. Zwinne metodologie, takie jak Scrum, dobrze się do tego nadają.

2. Użyj funkcji FogBugz do śledzenia funkcji i błędów. Jego funkcje są bardzo praktyczne w przypadku zwinnych projektów. FogBugz umożliwia łatwe ustalanie priorytetów zgodnie z wydaniami i priorytetami. Jeśli Twój zespół osiągnie swój szacunkowy poziom wysiłku dla każdego zadania, możesz również użyć go do obliczenia rozsądnych dat statku.

3. Określ priorytety, które będą rozwijane zgodnie z 80/20 rule (20 procent funkcji będzie używanych przez 80 procent czasu) i najwięcej będzie za dużo. Pomaga to w utrzymaniu systemu tak prostego, jak to tylko możliwe, pomaga zapobiec feature bloat i oszczędza czas opracowywania i testowania.

4. Podobna myśl zarówno do nowych funkcji, jak i błędów, gdy określasz priorytet problemu. Jeden punkt the Joel Test brzmi "Czy naprawiasz błędy przed napisaniem nowego kodu?". W większości sklepów tak się nie dzieje, ale nie należy debugować systemu po namyśle. Ponadto zachowaj kopię roboczą starego systemu, aby porównać ją, gdy wykryte zostaną błędy w nowym systemie.

5. Należy również uwzględnić poziom nakładu pracy wymagany do zachowania, a jeśli to konieczne, przepisania istniejącego kodu. Jeśli jeszcze tego nie zrobiłeś, daj zespołowi trochę czasu na sprawdzenie wszystkich plików, które sprawiają kłopot. Jeśli kod systemu był trudny do utrzymania po raz pierwszy, będzie go tylko pogorszyć i sprawi, że zespół poświęci więcej czasu na nowe funkcje.

Answer 7

Mam doświadczenie drugiego syndromu systemu z obu stron jako klient/sponsor i część zespołu programistów.

Główną przyczyną problemów jest moment, w którym zespół przejmuje utopijną wizję wersji 2, na przykład pragnienie uczynienia nowego oprogramowania "elastycznym". W tym scenariuszu wszystko jest abstrahowane do n-tego stopnia. Na przykład, zamiast obiektów danych, które reprezentują rzeczywiste elementy, tworzony jest ogólny obiekt "przedmiot", który może reprezentować dowolne obiekty. Jednym z wadliwych pomysłów jest to, że możemy wbudować tak wiele elastyczności w oprogramowanie, aby przewidzieć przyszłe potrzeby, aby nie-programiści mogli po prostu skonfigurować nowe możliwości. Często jeden cel, taki jak "elastyczność", przesłania wysiłek do punktu, w którym powstałe oprogramowanie nie działa.

Zrównoważone, praktyczne rozważenie użyteczności, wydajności, skalowalności, funkcji, łatwości konserwacji i celów elastyczności może przywrócić zespół na ziemię. "Byłoby wspaniale, gdyby ..." powinno się zabronić słownictwa zespołu. Backlog Scruma jest dobrym narzędziem, a zespół powinien często słyszeć ... "Zaniechajmy, że ... nie potrzebujemy tego dla wersji 2."

Answer 8

Nigdy nie można tego uniknąć w całości. Ale bycie ostrożnym może złagodzić problem. Powinieneś sformułować pewną regułę kciuka opartą na najważniejszych parametrach (najgorszy zasób), które definiują sukces systemu. Na przykład ograniczenie potencjalnej liczby błędów może bezpośrednio zmniejszyć koszty operacyjne (potencjalne wywołania serwisowe do centrum wsparcia). Ale nie może tak być w przypadku każdego innego systemu. Inny przykład, rzadkie wykorzystanie procesora, pamięci i innych zasobów może być w niektórych przypadkach korzystne, ale mogą istnieć środowiska, w których mogą być dostępne w dużej ilości.

Więc po prostu w celu uniknięcia "pokus", zidentyfikować najbardziej brakuje zasobów (czasu, wysiłku, pieniędzy $ etc) i rozważyć zastosowanie tylko te, które przekraczają wartość progową [f (s1, s2, ...)> Próg].

Pomimo iteracyjnego rozwoju, chciałbym podkreślić, jak obsługiwane są długi techniczne.
Linki, które są związane z tym:
Tech Debts: Effort Vs Time
Tech Debt Quadrant

Answer 9

nie można zbliżyć się do syndromu drugiego systemu. Albo jesteś w tym, albo jesteś z dala od tego. Będziesz wiedział, kiedy będziesz w tym uczestniczył, ale tylko po zmarnowaniu wielu zasobów.

Porady są: wiem o tym (więc w zasadzie mamy już pokryte). To nieoceniona informacja, aby wiedzieć, czym jest "drugi system", a jeszcze więcej, aby mieć z tym pewne doświadczenie. Myślę, że wszyscy mamy z tym pewne doświadczenia, miejmy nadzieję, łagodne.

Ta wiedza często sprawi, że będziesz dwa razy myślał, a znajdziesz rozwiązanie bez wchodzenia w stan drugiego systemu.

PS: Wiesz również, jak korzystać z obecnego systemu, który obejmuje, być może udokumentowane, rozwiązania i inną dokumentację.