Jak powstrzymać zmiany specyfikacji rozwoju w połowie rozwoju?

Problem : Wydaje się, że przy prawie każdym wysiłku programistycznym, w który jestem zaangażowany, bez względu na to, ile czasu spędzam na planowaniu przed rozpoczęciem rozwoju, zawsze wymagana jest duża ilość zmian w połowie lub pod koniec projektu. Są to czasem duże zmiany, które wymagają wielu zmian.

Nie pracuję dla klientów, którzy płacą pieniądze, to wewnętrzny zespół programistów na wewnętrznych stronach programistycznych. Więc to nie tak, że mogę za to pobierać opłaty lub cokolwiek innego. I na koniec dnia musimy spróbować dotrzymać terminów.

Pytania : Jakie są najlepsze sposoby zminimalizowania i zapobiegania pojawianiu się zmian specyfikacji w połowie lub po opracowaniu?

Jest słynne powiedzenie wojskowe przypisywane Helmutowi von Moltke: „Żaden plan bitwy nie przetrwa kontaktu z wrogiem”. W tym samym duchu nie sądzę, aby można było stworzyć specyfikację, której nie trzeba będzie zmieniać - chyba że można przewidzieć przyszłość i odczytać zdanie interesariuszy (nawet wtedy nie mogliby jeszcze podjąć decyzji, nawet jeśli twierdzą, że tak). Sugerowałbym zamiast tego podejść do tego na kilka sposobów:

1. Wyraźnie rozróżnij, co można zmienić, a co nie. Przekazuj to wyraźnie interesariuszom, spraw, by jak najszybciej podpisali się na niezmiennych rzeczach.
2. Przygotuj się na zmianę z góry. Używaj metodologii kodu, które pozwalają łatwiej wymieniać wymienne części, inwestuj w konfigurowalność, enkapsulację i jasne protokoły, które umożliwiłyby niezależną wymianę i wymianę części.
3. Często rozmawiaj z interesariuszami, zdobywaj opinie i aprobatę. Pozwoliłoby to zachować synchronizację i uniknąć sytuacji, w której twierdzilibyśmy „och, nie tego chcieliśmy”, gdy jest już za późno. Jak zauważono w innych odpowiedziach, pomocne byłyby zwinne metodyki i częste mini-wydania.
4. Ustaw w harmonogramie czas na dostosowanie się do nieuniknionych zmian. Nie obawiaj się powiedzieć „będziemy potrzebować więcej czasu” wcześniej, jeśli uważasz, że tak - jeśli podany harmonogram jest nierealny, lepiej go poznać (i powiedzieć, że tak się dzieje) na początku niż na początku koniec.
5. Jeśli zmiany są zbyt rozległe i zagrażają terminowi - odsuń się i powiedz coś w stylu „ta zmiana jest możliwa, ale przesunie termin do X, dokonaj wyboru”.
6. Dokonaj formalnego procesu wnioskowania o zmiany, ustalania priorytetów zmian i przypisywania zmian do wersji lub wydań. Jeśli możesz powiedzieć ludziom: „Nie mogę tego zrobić w tym wydaniu, ale chętnie ustawię to zgodnie z harmonogramem na następny”, to znacznie lepiej niż powiedzieć im „spóźniłeś się, twoja zmiana nie może wejść , do widzenia ”i uczyniłoby ich Twoimi przyjaciółmi - byliby szczęśliwi, gdybyś wypuścił je na czas, abyś mógł być wolniejszy, aby przejść do następnego wydania, które będzie miało ich zmianę - a nie twojego wroga.

Dostarcz coś (waham się, aby użyć słowa cokolwiek) wcześnie i często dostarczaj. To znaczy - użyj jakiejś metodologii iteracyjnego rozwoju.

Jest to podstawa rozwoju Agile, ale można go używać z (prawie) dowolną metodologią.

Dzieląc projekt na serię mini projektów, zyskujesz większą kontrolę, ponieważ możesz wcześnie postawić coś przed klientem, nie jesteś uwikłany w długi harmonogram rozwoju, który staje się nieaktualny, gdy klient zmienia zdanie (ponieważ oni będą).

Gdy zobaczą, że system ewoluuje, niektóre wymagania zmienią się, niektóre staną się zbędne, a inne będą miały wyższy priorytet. Jednak dzięki krótkiemu cyklowi życia projektu będziesz w stanie poradzić sobie z tymi zmianami.

Teoria, że ​​można całkowicie sprecyzować projekt oprogramowania o dowolnej wielkości, jest całkowitą fantazją. Stwierdzono, że teoria ta nie działa w organizacjach od dużych do małych przez prawie całą historię tworzenia oprogramowania.

MUSISZ znaleźć sposób na dostosowanie się do zmian! Tak się stanie, ponieważ większość interesariuszy, nawet jeśli powie „tak, właśnie tego chcę”, tak naprawdę nie ma pojęcia, czego chcą, dopóki nie stanie przed nimi. Dlatego tak wielu ludzi stosuje metody iteracyjne.

Niezależnie od tego, czy wykonujesz iterację produktu, czy coś, MUSISZ znaleźć sposób na uwzględnienie tych zmian, ponieważ próba znalezienia sposobu na brak zmian wymaga jedynie grawitacji, aby wyłączyła się na kilka minut, abyś mógł latać.

Nie próbuj zapobiegać zmianom, zaakceptuj je. Im więcej planujesz z wyprzedzeniem, tym bardziej prawdopodobne jest, że Twój plan się zmieni. Więc planuj mniej , nie więcej. Zastosuj zwinną metodologię programowania, w której często dostarczasz małe fragmenty działającego kodu, dając klientowi szansę na zmianę specyfikacji co kilka tygodni.

Zadajesz złe pytanie. Zmiany specyfikacji zawsze będą miały miejsce w projektach programistycznych dowolnej wielkości.

Często dzieje się tak, ponieważ zmieniają się wymagania biznesowe, ale widziałem też, że tak się dzieje, ponieważ klienci (wewnętrzni lub zewnętrzni) mogą mieć trudności z wizualizacją tego, co jest możliwe, bez konieczności zobaczenia iteracji, więc mają wizję, która powoli zmienia się, gdy angażują się w opracowanie rozwiązania.

Pytanie, które powinieneś zadać, nie brzmi: „jak mogę zablokować specyfikację”, ale „w jaki sposób mogę ustrukturyzować swój kod i procesy, aby reagowały na zmieniające się środowisko bez wyrzucania wszystkiego, co już napisałem?”

To następnie prowadzi do modnej bingo: zwinne metodyki, iteracyjny rozwój i rozwiązania techniczne, takie jak kodowanie modułowe / modułowe, ciągła integracja ... lista jest długa.

Nie twierdzę, że to srebrna kula dla wszystkich twoich problemów, ale wszystkie powstały z powodu chęci poradzenia sobie z sytuacją, którą opisujesz, więc przynajmniej warto je zbadać.

Przepraszam, jeśli to nie oferuje konkretnych rozwiązań, ale myślę, że zmiana sposobu myślenia w kierunku akceptacji i zarządzania zmianami przyniesie większe dywidendy niż próba jej uniknięcia.

Zmiana to tylko niespodzianka ... jeśli to niespodzianka!

Proponuję pomyśleć o:

• skąd się biorą te zmiany?
• dlaczego nie zdajesz sobie z tego sprawy wcześniej?
• dlaczego nie przyczyniasz się do tych zmian (i potencjalnie czynisz ich jeszcze więcej)?

Zmiana jest naturą tego, co robimy. Od kiedy kodujesz algorytm dokładnie taki, jak przewidziany pierwszego dnia?

Ale jeśli chcesz uniknąć ciągłego bycia sfrustrowanym programistą „zaskoczonym” zmianami, myślę, że musisz znaleźć się bliżej akcji, w której podejmowane są decyzje. W końcu jestem pewien, że masz mnóstwo pomysłów na ulepszenie produktu. Usiądź przy stole lub na zawsze zaakceptuj, że będziesz musiał poradzić sobie z tymi „niespodziewanymi zmianami”.

Cóż, to połączenie, klienci zawsze chcą więcej, ale oto kilka kwestii, które powinieneś rozważyć:

Makiety HTML: zawsze twórz makiety HTML, aby zdefiniować część interfejsu użytkownika aplikacji, pokazać im, jak to będzie wyglądać i zapytać ich o opinie. Jeśli znajdziesz coś rozsądnego do zmiany, zrób to w prototypie HTML. Za pomocą tego uporządkujesz wiele rzeczy, takich jak problemy z interfejsem użytkownika, podstawowy przepływ i niektóre dodatki (takie jak sortowanie, paginacja, liczba rekordów do wyświetlenia itp.)

Aktywny udział z drugiej strony: jest to bardzo ważne, jeśli rozwijasz się dla organizacji biznesowej, wejdź do jej firmy, poproś ją o wyjaśnienie swoich wątpliwości i bez wątpienia zapytaj ich, jakie zmiany chcą w swoim przepływie (w razie potrzeby).

Wydanie modułowe: uwolnij swój kod w sposób modułowy, zwolnij, przetestuj, prześlij opinię i ponownie zwolnij.

Dlatego prawie niemożliwe jest planowanie z dużym wyprzedzeniem, ale nie jest to wymówka, aby w ogóle nie planować. Nie zakochuj się zbytnio w swoich planach i nie będziesz musiał się martwić, że złamią ci serce.

W Twojej firmie korzystanie z zasobów IT wiąże się z pewnym kosztem, niezależnie od tego, czy ktoś się do tego przyznaje, śledzi go, czy też musi na niego budżetować. W rzeczywistości Twój zespół może stworzyć tyle kodu w określonym czasie. Wszystkie działy i projekty korzystają z tego budżetu.

Nie możesz powstrzymać nikogo przed zmianą wymagań, ale nie może uniknąć konsekwencji. Zmiany mogą znacznie wydłużyć czas rozwoju. To fakt, z którym muszą sobie poradzić lub zdecydować się nie wprowadzać zmian. Czy wniosek z jednego działu wpływa na inny? Być może konieczne będzie całkowite przeniesienie projektu za inne działy, ponieważ żądanie zmiany będzie naruszać harmonogram innej grupy.

Aktywne zaangażowanie użytkowników w całym cyklu programowania i stosowanie możliwie jak największej liczby metodologii Agile naprawdę pomaga nam z naszymi produktami.

Zmiany specyfikacji są nieuniknione, ale ponieważ są przejrzyste dla użytkowników, a przede wszystkim częste ich konsultowanie oznacza, że ​​większość zmian jest rejestrowana jak najwcześniej.

Dla mnie to całkiem proste.
Powiedz temu, „właścicielowi produktu” , który zamówił funkcje, że jest to w porządku, ale musi wybrać kilka zaplanowanych funkcji, w których może być bez tego terminu.
Pomyśl o tym jako o spotkaniu w połowie sprintu z PO, gdzie powiesz mu, że sprint nie spali się do zera.

Ps. Jeśli to nie jest „PO” , powiedziałbym, nie rozmawiaj ze mną, przejdź przez „PO”

Jakie są najlepsze sposoby zminimalizowania i zapobiegania pojawianiu się zmian specyfikacji w połowie lub po opracowaniu?

Nie ma najlepszych sposobów. Do kierownictwa należy ograniczenie zmian do specyfikacji w określonej fazie rozwoju.

Należy jednak zaprojektować oprogramowanie w taki sposób, aby oczekiwać zmian. Wtedy wpływ zmian byłby znacznie mniejszy. Iteracyjny i przyrostowy rozwój to dobry początek.

Przekonałem się, że bezpośrednio lub pośrednio klienci są przyczyną większości zmian (a także najbardziej krytycznych błędów, BTW). Oczywistym rozwiązaniem jest wyeliminowanie klientów. (Co to w ogóle są za dobre?)

Ponieważ nie możesz zapobiec zmianie, musisz ją zaakceptować. Myślę, że najważniejszą rzeczą, jaką możesz zrobić, jest: musisz spróbować uzyskać wnioski o zmianę od klienta tak wcześnie, jak to możliwe , ponieważ zmiana rzeczy jest tańsza, gdy jest mało kodu. Musisz więc jak najwcześniej przedstawić klientowi swój projekt, używając prototypów (być może nawet papierowego), stosować zwinne metody i tak dalej.

Możesz rozważyć wprowadzenie dyscypliny w procesie rozwoju przy użyciu metodologii takiej jak SCRUM. W SCRUM zespół tworzy wstępny plan, dzieląc implementację funkcji na historie i przypisując każdej historii szacunkową nakład pracy (liczbę godzin pracy lub dni potrzebnych na wdrożenie tej historii).

Jeśli wymagana jest późna zmiana (w przypadku już zaimplementowanej historii), musisz utworzyć nową historię i oszacować nakłady na jej wdrożenie. Następnie możesz udać się do swojego menedżera ( właściciela produktu ) i po prostu wyjaśnić, że nowa funkcja będzie kosztować ten dodatkowy czas. Kierownik projektu jest następnie odpowiedzialny za przyjęcie dodatkowego wysiłku i dostosowanie harmonogramu (ewentualnie anulowanie innych jeszcze nie zaimplementowanych artykułów).

Nawet jeśli Twój zespół nie zamierza w pełni wdrożyć SCRUM lub innego procesu programistycznego, możesz przynajmniej wprowadzić planowanie oparte na historiach , oszacować wysiłek rozwojowy dla każdej historii i dostosować harmonogram, gdy wymagane są nowe historie.

http://teddziuba.com/2010/05/why-engineers-hop-jobs.html

Spędziłem zbyt wiele wieczorów po pracy zestresowanych i nieszczęśliwych, ponieważ kolejny facet nie rozumie ani nie obchodzi, jak działa biznes związany z oprogramowaniem. Nie mam problemu z konfrontacją z kimś wyżej, ale nie mam wsparcia moich nerdów. Posiadanie dzieci to dziwka, co? Prawdopodobnie wkrótce zrezygnuję.

Szczerze mówiąc, chciałbym, żeby programiści w ogóle mieli więcej piłek. Spójrzmy na to:

„” „Nie pracuję dla klientów, którzy płacą pieniądze, to wewnętrzny zespół programistów zajmujący się wewnętrznymi witrynami programistycznymi. Nie mogę więc pobierać opłat za to ani nic. Na koniec dnia, musimy spróbować dotrzymać terminów. ”„ ”

Jeśli miałeś do czynienia z klientem płacącym za $ i obejmowałeś swoją dupę kontraktem (http://vimeo.com/22053820?utm_source=swissmiss), to zmiany specyfikacji kosztowałyby tego klienta więcej czasu ORAZ więcej pieniędzy ( lub potencjalnie ten sam lub mniej czasu, ale wykładniczo więcej pieniędzy). Twoja firma próbuje uciec od zmiany specyfikacji bez ponoszenia kosztów więcej czasu i pieniędzy.

Tymczasem próba dotrzymania terminów powoduje, że Ty i Twoi współpracownicy NIEPOTRZEBNY stres; nie możesz spędzić weekendu z rodziną / przyjaciółmi. To naprawdę nie jest konieczne, ponieważ ktokolwiek rzuca w ciebie pracą, prawdopodobnie nawet o tym nie wie, co jest smutne.

Moje proponowane rozwiązanie: wspólnie przygotuj kulki, aby się z nimi skonfrontować i wyjaśnić, że nie ma bezpłatnego lunchu, a wszystko kosztuje, że automechanika potrwa dłużej i pobierze więcej, jeśli specyfikacje zostaną zmienione w połowie pracy, że agencja zamawiająca potrwa dłużej i pobierać więcej, jeśli specyfikacje zostały zmienione w trakcie pracy, i jest ku temu dobry powód. Jeśli nie będą chcieli współpracować z tobą w rozsądny sposób, wtedy jako grupa wstaniesz i odejdziesz, a oni będą musieli zatrudnić programistów, którzy będą mogli odebrać projekt tam, gdzie został przerwany i dostarczyć go na czas.

Jest też obietnica zwinnego rozwoju, który nie oznacza sztywnych terminów.

Mam jeszcze do zobaczenia, jak programiści strajkują, ale to by było coś. Niekompetentni menedżerowie są zbyt liczni w firmach programistycznych. Zbyt wiele osób chce dostać coś za darmo, na Craigslist lub w prawdziwej firmie. http://teddziuba.com/2011/07/the-craigslist-reverse-programmer-troll.html

Programiści muszą mieć więcej piłek.

Podejście, które według mnie działa w porządku (oczywiście nie u wszystkich menedżerów), brzmi: „Myślę, że mogę to zrobić, tak. To zależy - ile dodatkowego czasu przeznaczasz na ten projekt? To dość poważna zmiana, którą jesteś z prośbą ”.