mityczny człowiek-miesiąc

omawia kilka przyczyn niepowodzeń w planowaniu. Najbardziej trwałe jest jego omówienie prawa Brooksa: dodanie siły roboczej do późnego projektu oprogramowania sprawia, że później. Człowiek-miesiąc jest hipotetyczną jednostką pracy reprezentującą pracę wykonaną przez jedną osobę w ciągu jednego miesiąca; prawo Brooksa mówi, że możliwość mierzenia użytecznej pracy w człowieku-miesiącach jest mitem i dlatego jest centralnym punktem książki.

złożone projekty programistyczne nie mogą być idealnie podzielone na oddzielne zadania, nad którymi można pracować bez komunikacji między pracownikami i bez ustanowienia zestawu złożonych powiązań między zadaniami a pracownikami je wykonującymi.

dlatego przypisanie większej liczby programistów do projektu działającego z opóźnieniem sprawi, że będzie to jeszcze później. Dzieje się tak dlatego, że czas potrzebny nowym programistom na poznanie projektu i zwiększenie kosztów komunikacji pochłonie coraz większą ilość dostępnego czasu kalendarza. Kiedy N ludzie muszą komunikować się między sobą, w miarę wzrostu n, ich wydajność maleje, a gdy staje się ujemna, projekt jest opóźniany dalej z każdą dodaną osobą.

• Grupa interkomunikacyjna wzór: n(n − 1)/2
• przykład: 50 programistów daje 50 · (50 – 1) / 2 = 1225 kanały komunikacji.

brak srebrnejedytuj

Brooks dodał „No Silver Bullet — esencja i wypadki inżynierii oprogramowania”—i dalsze refleksje na ten temat, „No Silver Bullet”—do jubileuszowej edycji mitycznego miesiąca człowieka.

Brooks twierdzi, że nie ma jednej srebrnej kuli — „nie ma jednego rozwoju, ani w technologii, ani w technice zarządzania, która sama w sobie obiecuje nawet jeden rząd wielkości poprawy w ciągu dekady w produktywności, niezawodności, prostocie.”

argument opiera się na rozróżnieniu między złożonością przypadkową a złożonością zasadniczą, podobnie jak prawo Amdahla opiera się na rozróżnieniu między” ściśle szeregowym „a”równoległym”.

efekt drugiego systemu edytuj

efekt drugiego systemu sugeruje, że gdy architekt projektuje drugi system, jest to najbardziej niebezpieczny system, jaki kiedykolwiek zaprojektuje, ponieważ będzie miał tendencję do włączania wszystkich dodatków, których pierwotnie nie dodali do pierwszego systemu z powodu nieodłącznych ograniczeń czasowych. Tak więc, wchodząc na drugi system, inżynier powinien pamiętać, że jest podatny na nadmierną inżynierię.

tendencja do nieredukowalnej liczby błędówedit

autor zwraca uwagę, że w odpowiednio złożonym systemie istnieje pewna nieredukowalna liczba błędów. Każda próba naprawienia zaobserwowanych błędów prowadzi do wprowadzenia innych błędów.

śledzenie postępów

Brooks napisał (A): pytanie: jak duży projekt oprogramowania może się spóźnić o rok? Odpowiedź: dzień po dniu!”Narastające poślizgi na wielu frontach w końcu kumulują się, powodując duże ogólne opóźnienie. Na każdym szczeblu zarządzania wymagana jest ciągła dbałość o spełnianie małych indywidualnych etapów.

integracjaedit

aby system był przyjazny dla użytkownika, system musi mieć integralność koncepcyjną, którą można osiągnąć tylko poprzez oddzielenie architektury od implementacji. Jeden główny architekt (lub niewielka liczba architektów), działający w imieniu użytkownika, decyduje, co wchodzi do systemu, a co pozostaje poza nim. Architekt lub zespół architektów powinien opracować pomysł na to, co powinien zrobić system i upewnić się, że ta wizja jest zrozumiała dla reszty zespołu. Nowatorski pomysł kogoś może nie zostać uwzględniony, jeśli nie pasuje bezproblemowo do ogólnego projektu systemu. W rzeczywistości, aby zapewnić system przyjazny dla użytkownika, system może świadomie oferować mniej funkcji niż jest w stanie. Chodzi o to, że jeśli system jest zbyt skomplikowany w użyciu, wiele funkcji zostanie niewykorzystanych, ponieważ nikt nie ma czasu, aby się ich nauczyć.

instrukcjaedit

główny architekt tworzy podręcznik specyfikacji systemu. Powinien szczegółowo opisywać zewnętrzne Specyfikacje systemu, tj. wszystko, co widzi użytkownik. Podręcznik powinien zostać zmieniony w miarę otrzymywania informacji zwrotnych od zespołów wdrożeniowych i użytkowników.

system pilotażowyedit

projektując nowy rodzaj systemu, zespół zaprojektuje system wyrzucania (czy zamierza, czy nie). System ten działa jako” plan pilotażowy”, który ujawnia techniki, które następnie spowodują całkowitą przeprojektowanie systemu. Ten drugi, inteligentniejszy system powinien być dostarczony do klienta, ponieważ dostarczenie systemu pilotażowego spowodowałoby jedynie agonię dla klienta i prawdopodobnie zrujnowałoby reputację systemu, a może nawet firmę.

dokumenty Formalnedytuj

każdy kierownik projektu powinien stworzyć mały podstawowy zestaw dokumentów formalnych określających cele projektu, sposób ich osiągnięcia, kto je osiągnie, kiedy zostaną osiągnięte i ile będą kosztować. Dokumenty te mogą również ujawniać niespójności, które w przeciwnym razie są trudne do zauważenia.

estymacja Projektuedytuj

szacując czas realizacji projektu, należy pamiętać, że produkty programistyczne (które mogą być sprzedawane płatnym klientom) i systemy programistyczne są trzy razy trudniejsze do napisania niż proste, niezależne programy wewnętrzne. Należy pamiętać o tym, ile czasu w tygodniu pracy będzie rzeczywiście przeznaczane na kwestie techniczne, w przeciwieństwie do zadań administracyjnych lub innych nietechnicznych, takich jak spotkania, a zwłaszcza spotkania „stand-up” lub „all-hands”.

Komunikacjaedit

aby uniknąć katastrofy, wszystkie zespoły pracujące nad projektem powinny pozostawać w kontakcie ze sobą na jak najwięcej sposobów—e-mail, telefon, spotkania, notatki itp. Zamiast zakładać coś, implementatorzy powinni poprosić architekta(architektów) o wyjaśnienie ich intencji w odniesieniu do funkcji, którą wdrażają, zanim przejdą do założenia, które może być całkowicie błędne. Architekci są odpowiedzialni za formułowanie grupowego obrazu projektu i przekazywanie go innym.

zespół chirurgicznyedit

tak jak zespół chirurgiczny podczas operacji jest prowadzony przez jednego chirurga wykonującego najbardziej krytyczną pracę, jednocześnie kierując zespół do pomocy przy mniej krytycznych częściach, wydaje się rozsądne, aby „dobry” programista rozwijał krytyczne komponenty systemu, podczas gdy reszta zespołu zapewnia to, co jest potrzebne we właściwym czasie. Dodatkowo Brooks twierdzi, że” dobrzy ” programiści są na ogół od pięciu do dziesięciu razy bardziej produktywni niż przeciętni.

zamrożenie kodu i wersja systemowaedytuj

oprogramowanie jest niewidoczne. Dlatego wiele rzeczy staje się oczywistych dopiero po wykonaniu pewnej ilości pracy na nowym systemie, co pozwala użytkownikowi doświadczyć tego. To doświadczenie przyniesie wgląd, który zmieni potrzeby użytkownika lub postrzeganie potrzeb użytkownika. System powinien zatem zostać zmieniony w celu spełnienia zmienionych wymagań użytkownika. Może to nastąpić tylko do pewnego momentu, w przeciwnym razie system może nigdy nie zostać ukończony. W określonym terminie nie należy dopuszczać żadnych zmian w systemie, a kod powinien zostać zamrożony. Wszystkie żądania zmian powinny być opóźnione do następnej wersji systemu.

wyspecjalizowane narzędziaedit

zamiast każdego programisty posiadającego własny specjalny zestaw narzędzi, każdy zespół powinien mieć wyznaczonego kreatora narzędzi, który może tworzyć narzędzia, które są wysoce dostosowane do pracy wykonywanej przez zespół, np. narzędzie do generowania kodu, które tworzy kod na podstawie specyfikacji. Ponadto Narzędzia systemowe powinny być budowane przez wspólny zespół narzędzi, nadzorowany przez kierownika projektu.

obniżenie kosztów tworzenia oprogramowaniaedit

istnieją dwie techniki obniżania kosztów tworzenia oprogramowania, o których pisze Brooks:

• Implementatorzy mogą zostać zatrudnieni dopiero po ukończeniu architektury systemu (krok, który może potrwać kilka miesięcy, podczas których przedwcześnie zatrudnieni implementatorzy mogą nie mieć nic do roboty).
• inną techniką, o której wspomina Brooks, jest nie rozwijanie oprogramowania w ogóle, ale po prostu kupowanie go „z półki”, jeśli to możliwe.