Chcę wyjaśnić, dlaczego specyfikacja nie może zostać zmieniona w okresie programowania

Chcę wyjaśnić, dlaczego specyfikacja nie może zostać zmieniona w okresie programowania dla nowego pracownika działu planowania.

Specyfikacja prawie zawsze zmienia się podczas opracowywania dla każdego, ale najprostszego projektu.

Powody są następujące:

• Opracowanie lub bardziej prawdopodobne testy integracyjne projektu ujawniają rzeczy, które nie zostały zauważone po opracowaniu oryginalnej specyfikacji - od przypadków skrajnych po główne aspekty. Np. Deweloper zauważa, że ​​mogą pojawić się potwierdzenia wiadomości o braku zamówienia.

• Warunki rzeczywiste określające specyfikację nie są zamrożone. Np. Tworzony jest nowy produkt finansowy, który należy dodać do specyfikacji przetwarzania bezpośredniego.

• Presje związane z terminem powodują przycinanie funkcji.

• Odkryto dodatkowych interesariuszy projektu (np. W połowie projektu podobny projekt został odkryty w innym obszarze, a wspólne podsystemy muszą być scentralizowane / współdzielone - zdarzyło mi się to w połowie 2-letniego projektu, co spowodowało poważne architektura).

• Dodatkowi sponsorzy projektu mają nowe wymagania dotyczące specyfikacji (jednym z najbardziej znanych przykładów jest historia rozwoju pojazdu bojowego Bradley).

Co do tego, dlaczego zmiany specyfikacji mają niekorzystny wpływ (nie można powiedzieć, że „nie może się zdarzyć”, ponieważ, jak widać, istnieje wiele powodów, które robią, prawie wszystkie poza twoją kontrolą i wiele z dobrych powodów) -

• Zmiany specyfikacji powodują zmiany w kodzie, odwracając uwagę od ukończenia części projektu, które nie zostały jeszcze napisane (jak wszyscy wiemy i ewangelizowani przez Joela Spolsky'ego, zmiany ogniskowania są bardzo złe dla programistów)

• Niektóre zmiany specyfikacji (czasem pozornie BARDZO niewielkie) mogą spowodować konieczność całkowitej przebudowy / przebudowy systemu, ponieważ wybór między 2 architekturami został dokonany na podstawie założenia wziętego ze specyfikacji .

• W przypadku TDD duża część pracy poddana testom może zostać unieważniona.

• Jeśli zmiany specyfikacji pochodzą od dodatkowych interesariuszy, jak wspomniano powyżej, mogą one być sprzeczne z istniejącą specyfikacją, powodując znaczny spadek jakości produktu (patrz Fighting Vehicle, Bradley).

• Zmiana specyfikacji może naruszać niektóre istniejące wymagania biznesowe, których osoba zmieniająca / żądająca mogła nie wiedzieć lub się o nią nie troszczyć (tak naprawdę jest to ten sam punkt, co ostatni punkt).

Wszystko to sprowadza się oczywiście do przedłużenia (czasem znacznie) terminu realizacji projektu i potencjalnie zwiększonego prawdopodobieństwa wystąpienia wad.

Oto najlepszy przykład, jak niewielka zmiana specyfikacji może powodować ekstremalne problemy, mam dla Ciebie 3 litery:

Y2K .

Wszystko, co zrobili, to zmiana specyfikacji na „ musi działać po 2000 roku ”.

Ponadto w niektórych sytuacjach rzeczywiście MUSI się nie zmieniać (w przeciwieństwie do „nie powinno się zmieniać bez uzasadnionego powodu”):

• Część specyfikacji jest (lub zależy od) specyfikacją systemu zewnętrznego, z którym muszą być interfejsy.

• Częścią specyfikacji jest (lub zależy od) sprzęt, na którym system jest implementowany.

• Wymagania dotyczące umowy z klientem (choć ograniczenie dotyczy wyłącznie zmiany specyfikacji bez uprzedniej analizy zmian z klientem i zmiany umowy, a nie tylko samej zmiany)

• System może wymagać spełnienia określonych wymagań prawnych lub regulacyjnych, niezależnie od preferencji klienta. Przykłady: szyfrowanie karty kredytowej, ochrona danych podatkowych.

Zakaz wprowadzania zmian w specyfikacji podczas programowania jest idealny dla programisty, ale nie jest realistyczny w warunkach rzeczywistych. Ludzie zawsze będą chcieli wprowadzać zmiany, nawet gdy rzecz jest wysyłana za drzwi. To nigdy się nie kończy. A niektóre z tych osób mogą podpisywać wypłatę. Im bardziej im zależy, tym bardziej o tym myślą i dlatego częściej chcą zmieniać projekt. Musisz być w stanie tolerować zmianę projektu przed ukończeniem, nawet jeśli oznacza to rozpoczęcie od nowa.

Ważne jest, aby jasno przekazać konsekwencje zmian, aby każdy miał realistyczne oczekiwania dotyczące procesu projektowania.

Zmiany muszą być odpowiednio omówione, a osoba odpowiedzialna za daną rzecz musi mieć jasne zrozumienie wpływu zmian na datę dostawy. Aby to uzyskać, musi porozmawiać z deweloperem. Ponieważ jednak trwająca dyskusja na temat zmian zalewa programistę i powstrzymuje rzeczywistą pracę, zmiany muszą być kolejkowane i omawiane w zaplanowanych, rzadkich odstępach czasu. Oczywiście, masz taką nadzieję.

Idealnie, instruujesz ludzi, aby zanotowali zmiany, których chcą dokonać, i poproś ich o przedstawienie ich na cotygodniowym / dwutygodniowym / miesięcznym / jakimkolwiek spotkaniu koordynacyjnym. Podczas spotkania omawiane jest każde żądanie zmiany, w tym omówienie podstawowych modyfikacji, które należy wprowadzić, aby wdrożyć żądaną funkcję, a zatem wpływ na datę zakończenia. Po ustaleniu „kosztu” zmiany mogą następnie ustalić, czy ją uwzględnić.

Ważną rzeczą, którą wprowadza ten proces, jest przekonanie, że każda zmiana ma związany z nią koszt, a koszt jest ogólnie wyższy wraz z postępem projektu, ponieważ należy powtórzyć więcej pracy. Ludzie, którzy nie pracują w dziedzinie rozwoju, zwykle nie mają pojęcia, ile będzie to kosztować zmiana; jedyny sposób, by powiedzieli, to zaproponować i ocenić twoją reakcję. Stworzenie dobrze zdefiniowanego procesu przeglądu zmian pomoże zarówno im, jak i tobie.

Zauważ, że programiści są albo bardzo optymistyczni co do tego, jak łatwa jest zmiana, albo bardzo pesymistyczni co do tego, jak niemożliwe będzie to zrobić. Spróbuj dowiedzieć się, kim jesteś, porównując swoje oryginalne szacunki z wynikami i odpowiednio je dostosuj.

Być może lepiej byłoby powiedzieć, że specyfikacja nie może ulec zmianie bez ważnego żądania zmiany i procesu. Żądanie zmiany specyfikacji ma wpływ na harmonogram i koszty, dlatego należy je uwzględnić w zatwierdzeniu.

Biorąc pod uwagę, że istnieje odpowiedni proces zarządzania zmianami, nie ma nic „złego” w zmianie specyfikacji, ale może to być bardzo kosztowne, więc Twoi klienci mogą nie być zbyt zadowoleni. Możesz uchronić je przed sobą, starając się uzyskać pewne dobre wymagania i specyfikacje, dzięki czemu potrzeba mniej zmian.

Najlepszą analogią, jaką mam, jest porównanie jej do budowy domu. Architekt sporządza plany, a następnie przedstawia szacunek, a następnie klient zgadza się (lub nie) na plan. Jeśli klient chce wstawić dodatkową łazienkę, wówczas praca się kończy, plany muszą się zmienić, dokonywany jest nowy kosztorys i klient się zgadza (lub nie).

Pisanie oprogramowania nie różni się. po zawarciu umowy (po zaprojektowaniu i wycenie), jeśli jakieś zmiany muszą nastąpić, wówczas praca musi zostać przerwana, aby móc sporządzić nowy plan, nowy kosztorys, a następnie zatwierdzony (lub nie), a następnie praca zostanie wznowiona.

gdziekolwiek powiedziałem, czy nie, oznacza to, że projekt trwa bez nowych zmian. Oczywiście zawsze jest czas i materiały na opracowanie nowych planów i oszacowań.