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

61

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?

David
źródło
9
ustanowić kamień milowy Feature Freeze w fazie rozwoju i układać / negocjować rzeczy w taki sposób, aby wszystkie żądania funkcji przesłane po tym kamieniu milowym były przekazywane do następnej wersji, a nie do bieżącej. Kluczową kwestią tutaj jest oczywiście zaplanowanie więcej niż jednego wydania z wyprzedzeniem i podzielenie się tym z klientami
gnat
4
@gnat Zakładasz, że PO działa w organizacji, w której wprowadzenie kamienia milowego Feature Freeze byłoby akceptowalne dla interesariuszy. Na podstawie osobistego doświadczenia pracującego w wewnętrznych zespołach programistycznych, gdybym zaproponował coś takiego, interesariusze wpatrywaliby się we mnie i powiedzieliby coś w stylu: „Jak myślisz, do cholery, jak mi mówisz, kiedy mogę i nie mogę się zmienić moje propozycje funkcji pod wpływem kaprysu? Jak myślisz, za co płacę? Poznaj swoje miejsce ”.
wałek klonowy
29
Czy próbowałeś zapisać specyfikację w pliku tylko do odczytu?
orlp
14
Oczywiście, że je pobierasz: każda zmiana specyfikacji opóźnia wydanie, więc twoja odpowiedź na żądanie zmiany powinna być oszacowaniem nowej daty wydania, jeśli zmiana zostanie dodana do specyfikacji. Ktokolwiek prosi o zmianę, jest odpowiedzialny za opóźnienie i musi to wyjaśnić dokładnie w taki sam sposób, jak wyjaśniłby wydatki.
Simon Richter
7
Czy nie dlatego Agile istnieje? Nie można zamrozić specyfikacji, dlatego proces powinien obsługiwać zmieniającą się specyfikację.
Craig,

Odpowiedzi:

89

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.
StasM
źródło
3
Możesz także „zamrozić” je etapami i wprowadzać zmiany do „następnej wersji” .
Grant Thomas
3
Sformalizowanie procesu zmiany i jasne określenie zakresu jest świetną radą - jeśli wykonujesz pracę na podstawie umowy o ustalonym zakresie / cenie. W innych ustawieniach takie podejście jest mielące, ponieważ daje pierwszeństwo harmonogramowi i cenie nad zakresem i jakością. Może właśnie tego potrzebujesz w danej sytuacji. Ale z drugiej strony, może to nie jest ...
opóźnij
3
+1 za numer 6. Miałem doskonałe doświadczenie z samym premierem, który sam wdrożył ten wymóg.
Joshua Drake
3
Kluczowe są krótkie cykle. Ludzie są znacznie mniej zdenerwowani tym, że coś zostanie zepchnięte na następny dwutygodniowy sprint niż na „następne wydanie” za sześć miesięcy.
Adam Jaskiewicz
1
„zainwestuj w konfigurowalność, enkapsulacja” jest bardzo zróżnicowana i niebezpieczna. Zbyt łatwo może prowadzić do efektu wewnętrznej platformy i pustych warstw abstrakcji, które w rzeczywistości znacznie utrudniają zmianę systemu. Najłatwiejszym do zmiany systemem jest ten, który jest najprostszy.
Michael Borgwardt
40

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.

ChrisF
źródło
22

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

Michael Kohne
źródło
2
NASA robi to z niektórymi programami, a przynajmniej na tyle dobrze, by wysyłać promy w kosmos. Chodzi o to, że faktycznie podążają za modelem wodospadu. Specyfikacja jest faktycznie zamrożona. Przynajmniej takie jest moje zrozumienie spoza organizacji.
Joshua Drake
5
Pracowałem nad kilkoma projektami, w których byliśmy w stanie całkowicie sprecyzować dość znaczące systemy (pomocnicze przełączniki telefoniczne). Kluczem do wszystkich tych przypadków jest to, że celowaliśmy w sprzęt, który został już opracowany i rozwijaliśmy się zgodnie ze specyfikacjami opublikowanymi (ITU), więc żadne z nich nie mogło się zmienić. Twój argument nie dotyczy wszystkich projektów - tylko 99% z nich! ;)
TMN
@TMN: Nie zgodziłbym się również z 99%. Myślę, że rozwój podobny do wodospadu jest o wiele bardziej udany, niż zasługują agileści. W przeciwnym razie nie byłby już używany. Większość projektów, nad którymi pracowałem, była podobna do wodospadu. Kluczem jest ustalenie linii bazowej, a następnie wszelkie nadchodzące zmiany są szacowane na dodatkowy czas i pieniądze. Następnie klient decyduje, czy uwzględnić zmianę, czy nie, a harmonogram i dolary odpowiednio się zmieniają.
Dunk
1
@Dunk: Wiem, że dużą część naszego sukcesu polegało na przestrzeganiu metodologii opracowanej w Bell Labs. To była prawdziwa inżynieria, z pełną identyfikowalnością, od wymagań, przez specyfikacje, projekty, testy planów, kodowanie, testowanie wyników i wyników. Gdy test się nie powiedzie, możesz dokładnie zobaczyć , które wymagania nie są spełnione, i dokładnie wiesz, gdzie szukać wadliwego kodu (lub nieudanego projektu). Aby wodospad działał, trzeba wiele dyscypliny i nadzoru, ale masz rację, może działać dobrze.
TMN
1
@TMN Zastanawiam się więc, co jest kluczem do sukcesu. Użycie modelu wodospadu czy zdyscyplinowane podejście? Myślę, że późniejsze z nich jest ważniejsze.
Ross Goddard
19

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.

Bryan Oakley
źródło
Nie wiem, dlaczego nie przyszło mi to do głowy wcześniej, ale pomysł, że posiadanie kodu pozwala łatwiej zaakceptować zmiany, nie może być poprawny. Czy zmiana niektórych diagramów lub zmiana kodu jest łatwiejsza i mniej czasochłonna? Zwłaszcza, gdy zmiana jest duża. Zgadzam się, że nie próbujesz zapobiegać zmianom, wystarczy wskazać skutki i zastosować je zgodnie z harmonogramem. Zwinne objęcia zmieniają nie więcej niż metody podobne do wodospadu. Myślę nawet, że radzi sobie ze zmianami gorzej niż z wodospadem, ponieważ wprowadzanie zmian może być nieco droższe (w zależności od momentu zmiany).
Dunk
6
@Dunk Masz rację, ponieważ tańsza jest zmiana diagramu niż kodu, ale jak odkryć, że zmiana musi nastąpić? Często zdarza się to dopiero po tym, jak dasz użytkownikowi coś do użycia i zda sobie sprawę, że albo przekazał niewłaściwy pomysł, nie tego chciał, albo są też inne rzeczy, których chciał. Sztuką jest jak najszybsze wykrycie tych zmian.
Ross Goddard
@Ross: To jeden z powodów prototypów. Wyśmiewasz rodzaj działającego systemu i otrzymujesz informacje zwrotne. Jest mitem, że w wodospadzie klient nie wie, co dostaje, dopóki nie zostanie to zrobione. Byłem przy projektach, które były wystarczająco duże, w których osoba / ludzie z interfejsu użytkownika spędzają pierwsze kilka miesięcy, próbując stworzyć reprezentatywny prototyp, aby upewnić się, że klient otrzymuje to, czego chce. Można by twierdzić, że użycie rzeczywistego systemu jest lepsze, ale jeśli kończy się to znacznie dłużej, ponieważ kod musi być często przeprojektowywany, nie jest to dobry kompromis.
Dunk
12

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.

MarcE
źródło
Tak. Przeformułowanie pierwotnego pytania: „Jak możemy zagwarantować, że dostarczymy to, czego klient chciał na początku projektu, niż to, co chciał na końcu?”
Steve Bennett
5

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

opóźnienie
źródło
+1 „Zmiana jest naturą tego, co robimy” - Lubię zmianę. Zmiana może być dobra. Daje mi to możliwość sprawdzenia, czy moje umiejętności projektowe były na poziomie tabaki, czy nie. Jeśli zmiana powoduje wiele przeróbek, to zrobiłem zły projekt. Daje to również możliwość uczynienia projektu bardziej ogólnym. Jest to wymówka, aby naprawić to, co przebiegłeś, aby dotrzymać harmonogramu. Pozwala mi wrócić i naprawić śmieci innych ludzi. Po prostu śledź żądania zmian i włącz je do harmonogramu, aby dostarczyć później niż pierwotny harmonogram, masz dowody wskazujące powód.
Dunk
4

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.

CodeCracker
źródło
4

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.

JeffO
źródło
4

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.

SkeetJon
źródło
3

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”

Farmor
źródło
1

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.

BЈовић
źródło
1

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?)

Daniel R. Hicks
źródło
:) Jeśli klienci chcą zwariowanego dostosowania, zapłacą za to pieniądze i czas. Jeśli sprzedawcy absolutnie MUSZĄ złożyć obietnicę dostarczenia funkcji, których nie ma jeszcze przez większość czasu, kiedy sprzedają, wówczas firma ma ogólnie większy problem: ma wielu konkurentów i nie jest na szczycie swojej gry, np. Dostawca bazy danych SyBase. Albo stanie się nieistotna jako firma, albo będzie potrzebować rewolucyjnego dyrektora generalnego i zastępców.
Job
1

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.

Hans-Peter Störr
źródło
1

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.

Giorgio
źródło
0

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.

Job
źródło
0

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ą ”.

medivh
źródło