Tytuł oryginału: The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Tłumaczenie: Wojciech Moch

ISBN: 978-83-283-5079-3

Authorized translation from the English language edition, entitled: THE MYTHICAL MAN-MONTHS, ANNIVERSARY EDITION, 2nd Edition; ISBN 0201835959; by Frederick Phillips Brooks; published by Pearson Education, Inc, publishing as Addison Wesley. Copyright © 1995 Addison Wesley Longman, Inc.

All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc.Polish language edition published by HELION S.A. Copyright © 2019.

The essay entitled, No Silver Bullet, is from Information Processing 1986, the Proceedings of the IFIP Tenth World Computing Conference, edited by H.-J. Kugler, 1986, pages 1069-1076. Reprinted with the kind permission of IFIP and Elsevier Science B.V., Amsterdam, The Netherlands.

Wszelkie prawa zastrzeżone. Nieautoryzowane rozpowszechnianie całości lub fragmentu niniejszej publikacji w jakiejkolwiek postaci jest zabronione. Wykonywanie kopii metodą kserograficzną, fotograficzną, a także kopiowanie książki na nośniku filmowym, magnetycznym lub innym powoduje naruszenie praw autorskich niniejszej publikacji.

Wszystkie znaki występujące w tekście są zastrzeżonymi znakami firmowymi bądź towarowymi ich właścicieli.

Autor oraz Helion SA dołożyli wszelkich starań, by zawarte w tej książce informacje były kompletne i rzetelne. Nie biorą jednak żadnej odpowiedzialności ani za ich wykorzystanie, ani za związane z tym ewentualne naruszenie praw patentowych lub autorskich. Autor orazHelion SA nie ponoszą również żadnej odpowiedzialności za ewentualne szkody wynikłez wykorzystania informacji zawartych w książce.

Materiały graficzne na okładce zostały wykorzystane za zgodą Shutterstock Images LLC.

Helion SAul. Kościuszki 1c, 44-100 Gliwicetel. 32 231 22 19, 32 230 98 63e-mail: helion@helion.plWWW: http://helion.pl (księgarnia internetowa, katalog książek)

Drogi Czytelniku!Jeżeli chcesz ocenić tę książkę, zajrzyj pod adres http://helion.pl/user/opinie/legosoMożesz tam wpisać swoje uwagi, spostrzeżenia, recenzję.

Printed in Poland.

• Kup książkę• Poleć książkę • Oceń książkę

• Księgarnia internetowa• Lubię to! » Nasza społeczność

Spis tre ci 7

Spis tre ci

Wst p do wydania rocznicowego 11

Wst p do pierwszego wydania 15

1. Smolisty dó 21

2. Legendarny osobomiesi c 31

3. Zespó chirurgiczny 47

4. Arystokracja, demokracja i projekt systemu 59

5. Efekt drugiego systemu 71

6. Przekazywanie wie ci 79

7. Dlaczego upad a wie a Babel? 91

8. Podejmowanie decyzji 105

9. Dziesi kilo w pi ciokilowym worku 115

10. Hipoteza dokumentacji 125

11. Plan odrzucania 133

12. Ostre narz dzia 145

Poleć książkęKup książkę

8 Legendarny osobomiesi c

13. Ca o i cz ci 159

14. Wysiadywanie katastrofy 173

15. Druga twarz 183

16. Nie ma srebrnej kuli — esencja i przypadekw in ynierii oprogramowania 199

17. Nie ma srebrnej kuli, raz jeszcze 227

18. Propozycje z „Legendarnego osobomiesi ca”:prawda czy fa sz? 251

19. Legendarny osobomiesi c — 20 lat pó niej 277

Epilog. Pi dziesi t lat cudów, zachwytów i rado ci 315

Przypisy ko cowe 317

Skorowidz 333

Poleć książkęKup książkę

Legendarny osobomiesi c 31

2.Legendarnyosobomiesi c

Dobra kuchnia wymaga czasu. Je eli zechcesz poczeka ,pozwoli to lepiej Ci obs u y i zadowoli .

MENU RESTAURACJI ANTOINE W NOWYM ORLEANIE

Poleć książkęKup książkę

32 Legendarny osobomiesi c

Wi cej projektów upad o z powodu braku czasu w kalendarzu ni z wszyst-kich innych powodów razem wzi tych. Dlaczego w a nie ten powód jesttak cz sty?

Po pierwsze, nasze techniki szacowania s wyj tkowo s abej jako ci.Przede wszystkim, wyra aj one ciche (i niczym nieuzasadnione) za o e-nie, e wszystko uda si zrealizowa bez problemów.

Po drugie, nasze techniki szacowania ch tnie mieszaj poj cia pracyi post pu, ukrywaj c w ten sposób nies uszne za o enie, e pracownik i mie-si c s poj ciami wymiennymi.

Po trzecie, poniewa nie jeste my pewni poprawno ci naszych sza-cunków, kadrze zarz dzaj cej cz sto brakuje tego wspania ego uporu szefarestauracji Antoine.

Po czwarte, post py projektu s zazwyczaj s abo monitorowane. Tech-niki, które dobrze si sprawdzi y w innych dziedzinach in ynierskich i dla-tego s w nich stosowane rutynowo, w przypadku in ynierii oprogramo-wania uznawane s za radykalne innowacje.

Po pi te, w przypadku zauwa enia opó nie w harmonogramie ca -kowicie naturaln (i tradycyjn ) reakcj jest dodanie do zespo u nowychprogramistów. Powoduje to tylko ci g e pogarszanie si sytuacji i przy-pomina próby gaszenia ognia benzyn . Wi kszy ogie wymaga u ycia wi k-szej ilo ci benzyny, a powtarzaj cy si w ten sposób cykl prowadzi prostodo katastrofy.

Monitorowanie post pów b dzie tematem jednego z rozdzia ów, terazprzyjrzyjmy si innym aspektom tego problemu.

OPTYMIZMWszyscy programi ci s optymistami. By mo e nowoczesna forma magiiprzyci ga do siebie osoby, które wierz w szcz liwe zako czenia i Wró kiZ buszki. By mo e setki powodów do frustracji odstrasza wszystkich tych,którzy ca kowicie koncentruj si na osi gni ciu celu. By mo e wynikato z tego, e komputery s jeszcze ca kiem m ode, programi ci s jeszczem odsi, a m odzie zawsze promienieje optymizmem. Niezale nie od tego,jak dzia a ten mechanizm selekcji, w jego wyniku pojawiaj si takie stwier-dzenia jak: „Tym razem na pewno zadzia a” albo „W a nie znalaz emostatni b d”.

Poleć książkęKup książkę

Legendarny osobomiesi c 33

A zatem pierwsze fa szywe za o enie stanowi ce podstaw harmono-gramów tworzonych systemów programistycznych brzmi: Wszystko pójdziejak nale y, czyli ka de zadanie zajmie tylko tyle czasu ile „powinno” zaj .

Taka powszechno optymizmu w ród programistów zas uguje na cowi cej ni tylko pobie n analiz . Dorothy Sayers w swojej doskona ejksi ce The Mind of the Maker dzieli dzia ania kreatywne na trzy etapy:pomys u, implementacji i interakcji. Oznacza to, e ksi ka, komputerlub program powstaje najpierw jako konstrukcja idealna, stworzona po-za czasem i przestrzeni , ale w umy le jej autora kompletna i doskona a.Nast pnie jest realizowana w czasie i przestrzeni za pomoc pióra, atra-mentu i papieru albo przewodów, krzemu i elaza. Taka kreacja zostajeuko czona, gdy kto przeczyta ksi k , skorzysta z komputera albo uru-chomi program, wchodz c tym samym w interakcj z umys em twórcy.

Taki opis, którego Sayers u ywa nie tylko do obja nienia ludzkiejkreatywno ci, ale te chrze cija skiej doktryny Trójcy wi tej, przyda siw naszym aktualnym zadaniu. W przypadku ludzkich twórców ró nychrzeczy niedoskona o ci i niespójno ci naszych idei staj si widoczne pod-czas ich implementowania. Oznacza to, e pisanie, eksperymentowanie,„ wiczenie” s bardzo wa nymi elementami dla teoretyka.

W wielu dzia aniach kreatywnych medium ich realizacji jest trudnedo opanowania. Drewno si amie, farby brudz , a uk ady elektryczne siprzepalaj . Takie fizyczne ograniczenia stosowanego medium sprawiaj ,

e nie wszystkie idee mo na za ich pomoc wyrazi , a na dodatek tworznieoczekiwane problemy podczas implementowania.

Sama implementacja te wymaga czasu i pracy, co wynika zarównoz wykorzystania fizycznego medium, jak i z niedopasowania samych idei.Zazwyczaj win za wi kszo problemów z implementacj zrzucamy nafizyczne medium. Po prostu medium nie jest „nasze” w ten sposób, w jaki„nasze” s idee, a duma zawsze wp ywa na nasze oceny.

Programowanie komputerów to jednak praca z niezwykle plastycznymmedium. Programi ci tworz wy cznie za pomoc w asnych my li, stosuj csame idee oraz ich niezwykle elastyczne reprezentacje. Z powodu takwielkiej plastyczno ci u ywanego medium oczekujemy niemal e ca kowi-tego braku k opotów przy implementowaniu. To w a nie z tego wynikanasz nieod czny optymizm. Niestety nasze idee nie s idealne, a zatempowstaj b dy podczas implementowania. To z kolei oznacza, e naszoptymizm jest nieuzasadniony.

Poleć książkęKup książkę

34 Legendarny osobomiesi c

W przypadku pojedynczego zadania za o enie, e uda si je zrealizo-wa bez problemów, ma probabilistyczny wp yw na ca y harmonogram.Rzeczywi cie wszystko mo e pój zgodnie z planem, poniewa prawdo-podobie stwo opó nienia w danym zadaniu ma pewien rozk ad, w którymmo na wyznaczy prawdopodobie stwo wyst pienia „braku opó nie-nia”. Niestety du e projekty programistyczne sk adaj si z wielkiej licz-by zada , z których cz musi by wykonywana sekwencyjnie. W takichwarunkach prawdopodobie stwo, e adne z nich nie b dzie mia o opó -nie , jest bardzo niskie.

OSOBOMIESI CKolejnym gro nym sposobem my lenia jest stosowanie samej jednostkiwykonywanej pracy podczas szacowania oraz przygotowywania harmo-nogramu: osobomiesi ca. Rzeczywi cie koszt tworzenia oprogramowaniamo na wyrazi jako iloczyn liczby pracowników i liczby przepracowanychmiesi cy. Nie dotyczy to jednak post pów. Oznacza to, e osobomiesi c sto-sowany jako jednostka miary wielko ci poszczególnych zada jest bardzo niebez-piecznym i podst pnym mitem. Sugeruje, e pracownicy i miesi ce s warto-ciami wymiennymi.

Pracownicy i miesi ce staj si warto ciami wymiennymi jedynie, gdydane zadanie mo na podzieli pomi dzy wielu pracowników, nie wyma-gaj c od nich adnej komunikacji (rysunek 2.1). Takie podej cie sprawdzasi przy m óceniu pszenicy lub zbieraniu bawe ny, ale w przypadku pro-gramowania systemów zupe nie nie ma zastosowania.

Rysunek 2.1. Czas a liczba pracowników — zadanie doskonale podzielne

Poleć książkęKup książkę

Legendarny osobomiesi c 35

Je eli zadania nie da si podzieli , na przyk ad z powodu ograniczewynikaj cych z sekwencji prac, to przypisanie do niego dodatkowych pra-cowników nie b dzie mia o wp ywu na harmonogram (rysunek 2.2). Uro-dzenie dziecka zajmuje zawsze dziewi miesi cy, niezale nie od tego, ilekobiet zostanie przydzielonych do tego zadania. Wiele zada programi-stycznych ma taki w a nie charakter, co wynika z sekwencyjnej naturydebugowania.

Rysunek 2.2. Czas a liczba pracowników — zadanie niepodzielne

W przypadku zada , które mo na podzieli , ale wymagaj one komu-nikacji pomi dzy poszczególnymi zadaniami cz stkowymi, do ilo ci pracykoniecznej do wykonania trzeba doliczy jeszcze prac zwi zan z samkomunikacj . Oznacza to, e najlepszy efekt, jaki mo na uzyska , b dziezawsze gorszy od prostej zamiany pracowników na miesi ce (rysunek 2.3).

Dodatkowe obci enia zwi zane z komunikacj mo na podzieli nadwie kategorie: nauk oraz wymian informacji. Ka dy z pracownikówmusi nauczy si korzysta ze stosowanej technologii, pozna cele ca egoprzedsi wzi cia, ogóln strategi oraz plan pracy. Takiej nauki nie da sipodzieli na mniejsze cz ci, a zatem ta kategoria obci enia powodujewzrost nak adu pracy rosn cy liniowo wraz ze wzrostem liczby pracow-nikówI.

Poleć książkęKup książkę

36 Legendarny osobomiesi c

Rysunek 2.3. Czas a liczba pracowników— podzielne zadanie wymagaj ce komunikacji

Druga kategoria, czyli wymiana informacji, jest znacznie gorsza. Je elika da cz zadania musi by koordynowana z pozosta ymi cz ciami,to wymagany nak ad pracy ro nie zgodnie ze wzorem: n(n –1)/2. Trzechpracowników wymaga trzykrotnie intensywniejszej komunikacji dwu-stronnej ni dwóch. Czterech wymaga ju sze ciokrotnie wi cej komu-nikacji dwustronnej. Co wi cej, je eli konieczne s konferencje mi dzytrzema, czterema lub wi ksz liczb pracowników w celu wspólnego roz-wi zywania problemów, to sprawy komplikuj si jeszcze bardziej. Do-datkowe nak ady zwi zane z komunikacj mog ca kowicie zanegowazyski wynikaj ce z podzia u zadania, przez co znajdziemy si w sytuacjiprzedstawionej na rysunku 2.4.

Tworzenie systemów programowych to jednoznacznie zadanie sys-temowe i jako takie wymaga obs u enia wielu powi za . Oznacza to, enak ady na komunikacj s bardzo wysokie i potrafi szybko zdominowaczas wykonania poszczególnych zada , nawet po ich podzieleniu. W takiejsytuacji dodanie nowych pracowników zamiast skraca , b dzie wyd u aharmonogram prac.

Poleć książkęKup książkę

Legendarny osobomiesi c 37

Rysunek 2.4. Czas a liczba pracowników— zadanie ze z o onymi zale no ciami wzajemnymi

TESTY SYSTEMOWEDebugowanie komponentów i testy systemowe to cz ci harmonogramu,które s najbardziej ograniczane przez konieczno utrzymania sekwencjiprac. Co wi cej, czas wymagany do ich wykonania uzale niony jest odliczby i skomplikowania wykrytych b dów. Teoretycznie takich b dównie powinno by wcale. Z powodu naszego optymizmu zazwyczaj ocze-kujemy, e ogólnie b dów b dzie mniej, ni jest ich w rzeczywisto ci.W zwi zku z tym testowanie jest najgorzej zaplanowanym etapem tworze-nia oprogramowania.

Przez wiele lat, z sukcesem, stosowa em poni sz ogóln regu plano-wania harmonogramu prac dla zadania programowego:

1/3 to planowanie1/6 to tworzenie kodu1/4 to testy komponentów i wczesne testy systemowe1/4 to testy systemowe, gdy gotowe s ju wszystkie komponenty

W kilku punktach ró ni si to od konwencjonalnego przygotowywaniaharmonogramu:

Cz przeznaczona na planowanie jest wi ksza ni normalniestosowana. Mimo to i tak czasu z ledwo ci wystarczana przygotowanie szczegó owej i porz dnej specyfikacji.

Poleć książkęKup książkę

38 Legendarny osobomiesi c

Jest te ca kowicie niewystarczaj ca, je eli chcieliby myprzeprowadzi badania i wiczenia w nowych technikach.

Po owa harmonogramu jest zwi zana z debugowaniem gotowegokodu i jest to warto zdecydowanie wi ksza ni normalniestosowana.

Cz , która jest naj atwiejsza do oszacowania, czyli tworzeniekodu, otrzyma a zaledwie jedn szóst ca o ci czasu.

Kontroluj c konwencjonalnie planowane projekty, zauwa y em, ezaledwie kilka z nich przeznacza o po ow harmonogramu na testowanie,ale niemal we wszystkich, w rzeczywisto ci, po ow czasu zajmowa o te-stowanie. W wielu z tych projektów prace post powa y zgodnie z harmo-nogramem do momentu rozpocz cia testów systemowychII.

B d polegaj cy na nieprzydzieleniu odpowiedniej ilo ci czasu na testy,w szczególno ci na testy systemowe, ma katastrofalne skutki. Poniewatakie opó nienie pojawia si pod koniec ca ego harmonogramu, niemaldo samego ko ca nikt nie ma poj cia, e projekt ma jakiekolwiek k opoty.Z e wie ci przekazywane tak pó no i bez ostrze enia s niezwykle depry-muj ce zarówno dla klientów, jak i dla kadry zarz dzaj cej.

Co wi cej, opó nienia pojawiaj ce si na tym etapie zazwyczaj majpowa ne reperkusje zarówno finansowe, jak i psychologiczne. Projekt mape n obsad , a zatem koszt ka dego dnia prac jest maksymalny. Co wa -niejsze, tworzone oprogramowanie powinno stanowi wsparcie dla in-nych dzia ów firmy (dostawy komputerów, prace w nowych oddzia achi inne) i takie pochodne koszty opó nienia mog by bardzo wysokie, po-niewa inni spodziewaj si teraz otrzyma gotowe oprogramowanie.

I rzeczywi cie, takie pochodne koszty opó nienia mog szybko prze-wy szy wszystkie pozosta e. Z tego powodu bardzo wa ne jest, ebyw pierwotnym harmonogramie przeznaczy odpowiednio du o czasu natesty systemowe.

SZACOWANIE TCHÓRZLIWEZauwa , e w przypadku programisty, jak w przypadku kucharza, naciskize strony prze o onego mog wp ywa na planowany czas wykonania za-dania, ale nie b d mia y wp ywu na czas faktycznego uko czenia. Przygo-towywanie omletu, który zgodnie z planem ma by gotowy w dwie minuty,

Poleć książkęKup książkę

Legendarny osobomiesi c 39

mo e post powa zgodnie z harmonogramem. Je eli jednak po dwóchminutach nie b dzie gotowy, to klient ma dwie mo liwo ci: albo pocze-ka , albo zje surowe jajka. Klienci czekaj cy na swoje oprogramowaniemaj podobny wybór.

Kucharz mo e jeszcze podnie temperatur . W efekcie zazwyczaj po-wstaje omlet ca kowicie niejadalny — przypalony z do u, a surowy z góry.

Nie s dz , by mened erowie oprogramowania mieli mniej odwagii niez omno ci od kucharzy, podobnie jak inni mened erowie prowa-dz cy projekty in ynierskie. Niestety le przygotowane harmonogramy,które dopasowywane s do daty wyznaczonej przez zleceniodawc , w na-szej bran y pojawiaj si znacznie cz ciej ni w innych dzia ach in ynier-skich. Niezwykle trudno jest przygotowa powa n obron swojego planu,ryzykuj c przy tym utrat pracy, szczególnie gdy taki plan nie zosta zbu-dowany z wykorzystaniem adnej solidnej metody, do dyspozycji mieli-my tylko niewiele danych, a poparty jest jedynie ogólnymi odczuciami

mened erów.Oczywi cie potrzeba nam tutaj dwóch rozwi za . Musimy przygo-

towa i opublikowa wska niki produktywno ci, wska niki wykrywalno cib dów, regu y szacowania i tym podobne. Ca a nasza bran a mo e tylkozyska , je eli takie informacje stan si publicznie dost pne.

Do czasu, a szacowanie b dzie mog o by realizowane na tak solid-nej podstawie, mened erowie musz usztywni swoje karki i broni przy-gotowanych przez siebie szacunków, maj c pewno , e ich niepoparteniczym odczucia i tak s znacznie lepsze od szacowania yczeniowego.

POWTARZALNE KATASTROFYHARMONOGRAMÓWCo nale y zrobi , je eli w wa nym projekcie programistycznym nie dasi dotrzyma harmonogramu? Oczywi cie zatrudni wi cej ludzi! Jakwida na rysunkach od 2.1 do 2.4, takie podst powanie nie zawsze jestprawdziw pomoc .

Przyjrzyjmy si pewnemu przyk adowiIII. Za ó my, e do zadania sza-cowanego na dwana cie osobomiesi cy przydzielono trzech pracownikówna cztery miesi ce. Zdefiniowano te cztery mierzalne kamienie miloweoznaczone A, B, C i D, które zosta y zaplanowane na koniec ka degomiesi ca (rysunek 2.5).

Poleć książkęKup książkę

40 Legendarny osobomiesi c

Rysunek 2.5.

Za ó my teraz, e pierwszy z kamieni milowych uda o si osi gndopiero po up ywie dwóch miesi cy (rysunek 2.6). Jakie decyzje mo epodj w takiej sytuacji mened er?

1. Za o y , e zadanie musi zosta wykonane w zaplanowanym czasie.Zak ada si zatem, e tylko pierwsza cz ca ego zadania zosta a

le oszacowana, czyli rysunek 2.6 ca kiem dobrze przedstawia ak-tualn sytuacj . Wówczas pozostaje jeszcze dziewi osobomiesi cyprac i tylko dwa miesi ce na ich wykonanie, czyli po cztery i póosoby na ka dy z miesi cy. Oznacza to, e do trzyosobowego ze-spo u trzeba doda jeszcze dwóch pracowników.

Rysunek 2.6.

Poleć książkęKup książkę

Legendarny osobomiesi c 41

2. Za o y , e zadanie musi zosta wykonane w zaplanowanym czasie.Zak ada si te , e ca o planu zosta a oszacowana za nisko, a zatemaktualn sytuacj lepiej opisuje rysunek 2.7. W tej sytuacji pozo-staje do wykonania jeszcze osiemna cie osobomiesi cy prac, czylipotrzeba nam dziewi ciu pracowników. Oznacza to, e do trzy-osobowego zespo u trzeba doda jeszcze sze ciu pracowników.

Rysunek 2.7.

3. Zmieni ca y harmonogram. Bardzo podoba mi si rada P. Fagga— do wiadczonego in yniera, który mówi : „Nie akceptuj ma ychpo lizgów”. Oznacza to, e w nowym harmonogramie trzeba za-planowa do czasu, aby mie pewno , e prace zostan przepro-wadzone rzetelnie i dok adnie, tak eby nie trzeba by o dokonywakolejnych korekt.

4. Zmniejszy wielko zadania. W praktyce zadania i tak s reduko-wane, gdy tylko zauwa one zostan opó nienia. Je eli pochodnekoszty opó nie s bardzo wysokie, to jest to jedyne akceptowalnerozwi zanie. Mened er ma zatem do wyboru formalne zmniejszeniezadania, korekt harmonogramu albo ciche obserwowanie, jak za-danie zostaje ograniczone przez pospieszne projektowanie i niepe -ne testy.

W pierwszych dwóch przypadkach upieranie si , e niezmienione za-danie mo e zosta zrealizowane w cztery miesi ce, to prosta droga do kata-strofy. Przyjrzyjmy si efektom regeneracyjnym, na przyk ad dla pierwszego

Poleć książkęKup książkę

42 Legendarny osobomiesi c

rozwi zania (rysunek 2.8). Dwóch nowych pracowników, niezale nie odtego, jak b d kompetentni i jak szybko zostan pozyskani dla projektu,b dzie wymaga o wdro enia w tematyk zadania przez jednego z do wiad-czonych programistów. Je eli zajmie to jeden miesi c, to znaczy, e trzyosobomiesi ce zostan zu yte na prace niezwi zane z pierwotnym harmono-gramem. Co wi cej, zadanie, które pocz tkowo podzielono na trzy cz ci,teraz musi zosta podzielone na pi . A to oznacza, e cz wykonanychju prac zostanie stracona, natomiast wyd u ona musi zosta faza testówsystemowych. A zatem pod koniec trzeciego miesi ca do przepracowa-nia zostanie jeszcze siedem osobomiesi cy, podczas gdy dost pnych b -dziemy mieli jeden miesi c i pi ciu przeszkolonych pracowników. Z ry-sunku 2.8 wynika, e projekt b dzie mia takie samo opó nienie, jakie mia bybez dodawania do zespo u dodatkowych pracowników (rysunek 2.6).

Rysunek 2.8.

Aby mie nadziej na zako czenie prac w cztery miesi ce, bior c poduwag sam czas szkolenia i nie uwzgl dniaj c konieczno ci ponownegopodzia u zada oraz dodatkowych testów systemowych, pod koniec dru-giego miesi ca powinni my doda do zespo u czterech, a nie dwóch pra-cowników. Chc c te pokry nak ady zwi zane z ponownym podzia emi dodatkowymi testami, nale a oby rozwa y dodanie do zespo u kolejnychosób. W takiej sytuacji powstanie jednak zespó sk adaj cy si przynajm-niej z siedmiu osób, a nie tylko z trzech. W zwi zku z tym organizacjazespo u oraz podzia zada stanowi zupe nie inny rodzaj problemu.

Poleć książkęKup książkę

Legendarny osobomiesi c 43

Prosz zauwa y , e pod koniec trzeciego miesi ca sprawy wygl dajbardzo le. Pierwszy etap prac nie zosta uko czony mimo wzmo onychwysi ków mened erskich. Bardzo mocna jest pokusa powtórzenia ca egocyklu przez dodanie do zespo u kolejnych pracowników. To czyste sza-le stwo.

To wszystko jest prawd przy za o eniu, e tylko pierwszy etap praczosta le zaplanowany. Je eli po jego uko czeniu przyjmiemy rozs dneza o enie, e ca o harmonogramu by a zbyt optymistyczna, tak jak narysunku 2.7, to potrzebnych b dzie sze ciu dodatkowych pracownikówtylko po to, aby zrealizowa pierwotne zadanie. Obliczenie czasu po-trzebnego na szkolenie, ponowny podzia prac i testy systemowe pozo-stawiam jako wiczenie dla czytelnika. Bez w tpienia taka samonap dzaj -ca si katastrofa nie pozostanie bez wp ywu na jako produktu, któryzostanie dostarczony pó niej, ni to by nast pi o w przypadku korektyharmonogramu i pozostaniu przy pierwotnym, trzyosobowym zespole.

Nadmiernie upraszczaj c, mo emy tu zdefiniowa prawo Brooka:

Dodawanie pracowników do opó nionego projektu tylko zwi ksza opó nienie.

W ten sposób chc zdemitologizowa osobomiesi c. Liczba miesi cytrwania projektu zale y od wielu ogranicze sekwencyjnych. Maksymal-na liczba pracowników uzale niona jest od liczby niezale nych od siebiezada podrz dnych. Na podstawie tych dwóch wska ników mo na przy-gotowa harmonogram wymagaj cy mniejszej liczby pracowników, alewi kszej liczby miesi cy. (Jedynym ryzykiem jest przedawnienie si pro-duktu). Nie da si jednak uzyska realizowalnego harmonogramu wyma-gaj cego wi kszej liczby osób, a mniejszej liczby miesi cy. Wi cej projek-tów programistycznych leg o w gruzach z powodu braku czasu ni z powoduwszystkich innych przyczyn razem wzi tych.

Poleć książkęKup książkę

44 Legendarny osobomiesi c

I V.A. Vyssotsky z laboratoriów Bell Telephone ocenia, e wielki projekt mo e przetrwa wzrost zatrudnienia do wielko ci 30 procent rocznie. Szybsze przyrosty utrudniaj , a nawet uniemo liwiaj ewolucj najwa niejszych nieformalnych struktur oraz istniej cych cie ek komunikacji, o których b dzie mowa w rozdziale 7. F.J. Corbat z MIT wskazuje, e wielki projekt musi liczy si z wymian kadr na poziomie 20 procent rocznie, a nowi pracownicy musz zosta przeszkoleni i w czeni w formalne struktury organizacji.II C. Portman z firmy International Computers Limited mówi: „Gdy wszystko ju dzia a jak nale y i zosta o odpowiednio zintegrowane, to masz przed sob jeszcze cztery miesi ce pracy”. Kilka innych sposobów podzia u harmonogramu podawanych jest w: R.W. Wolverton, The Cost of Developing Large-Scale Software, „IEEE Trans, on Computers”, C-23, 6 (czerwiec 1974), str. 615 – 636.III Rysunki od 2.5 do 2.8 s dzie em Jerry’ego Ogdina, który cytuj c moje przyk ady z jednej z wcze niejszych publikacji tego rozdzia u, znacznie poprawi wcze niejsze ilustracje. J.L. Ogdin, The Mongolian Hordes versus Superprogrammer, „Infosystems” (grudzie 1972), str. 20 – 23.

Poleć książkęKup książkę

Skorowidz 333

SkorowidzA

administrator, 51aktualizacje, 168architekt, 72, 256, 280Aron Joel, 108audyt projektu, 92

B

bezpo rednie do czenie, 84biblioteka, 262

g ówna, 267programowa, 150

b dy, 160szacowania, 108

bud et, 126

C

cele, 126ceny, 127chirurg, 50ci g a zmiana, 135

organizacji, 136systemu, 135

Corbató, 111cotygodniowe konferencje, 85cz sto , 283

D

debugowanie, 37, 38interaktywne, 164komponentów, 162systemowe, 165systemu, 267, 270

decyzje, 259diagram

organizacji, 127przep ywu, 187, 191struktury programu, 188

dodawanie komponentów, 168dokumentacja, 125, 152, 185, 262, 268,

273dokumenty, 126

dla wydzia u uniwersytetu, 128formalne, 129w projekcie oprogramowania, 128

dostarczanie, 264, 273drabinka awansów, 137drugi pilot, 50dyrektor, 99

techniczny, 98

Poleć książkęKup książkę

334 Legendarny osobomiesi c

E

efekt drugiego systemu, 73, 284eksperyment

Golda, 269my lowy, 235

elastyczno , 264entropia, 141ewolucja produktu, 23

F

formalne definicje, 81

G

generowanie formalnej definicji, 82

H

Harel David, 232harmonogram, 37, 43, 147, 126, 175,

271Harr John, 108hipoteza dokumentacji, 125, 262

I

implementacje, 86interfejs

metaprogramowania, MPI, 311WIMP, 284, 288

in ynieria oprogramowania, 199, 312

J

jako , 237j zyk Ada, 208j zyk wysokiego poziomu, 153, 206,

208, 268

K

kamienie milowe, 174, 271katastrofa, 173, 270klasa, 209

kompilator, 109komponenty zast pcze, 166komputer

dla asemblera, 150dla kompilatora, 150do debugowania, 267docelowy, 147roboczy, 149

komunikacja, 92, 256, 257konflikt, 177konserwacja programu, 109, 138kontrola

wielko ci systemu, 117zmian, 167

koszty, 242, 260konserwacji, 266u ytkowania, 116

ksi ka prac projektu, 93, 258kwantyfikacja

aktualizacji, 168zmian, 136

L

LIFO, 96Lukasik Steve, 231

M

mened er, 40, 48architektury, 65implementacji, 65projektu, 85, 267

metaprogram, 311metaprogramista, 310metaprogramowanie, 309metoda top-down, 161migawki, 163minidecyzje, 256model wodospadu, 289MPI, metaprogramming interface,

311

Poleć książkęKup książkę

Skorowidz 335

N

narz dzia, 145, 216, 239, 267programowe, 151

niewidoczno , 205, 236, 264

O

obs uga bibliotek, 150odrzucanie, 264ograniczenia wielko ci, 261opis programu, 185opó nienia, 270oprogramowanie zafoliowane, 307optymizm, 32, 232organizacja, 92, 97, 259

drzewiasta, 259gotowa na zmiany, 265

osobomiesi c, 31, 34, 253

P

pakiety jako komponenty, 309Parnas David, 292peopleware, 300pesymizm, 232planowanie, 37plik

miniaturowy, 167zast pczy, 167

podatno na zmiany, 204podbiblioteki aktualnej wersji, 151podejmowanie decyzji, 105, 259podr cznik, 80podzia

czasu, 207zada , 35

polecenia, 286ponowne wykorzystanie kodu, 242,

244poprawki, 266Portman Charles, 107prawo Brooksa, 299producent, 98

produkt programowaniasystemowego, 22–24

produktywno , 111, 237programowanie

automatyczne, 213graficzne, 214interaktywne, 154, 268samodokumentuj ce, 274strukturalne, 162, 269wysokiego poziomu, 273zorientowane obiektowo, 209, 240

programysamodokumentuj ce, 189uzupe niaj ce, 167

projektpilota owy, 263systemu, 255

projektanci, 222projektowanie metod top-down, 161projekty w druj ce, 301propozycja

Millsa, 50protokó telefoniczny, 87prototyp systemu, 220przemys oprogramowania, 307przewidywania, 127przydzia przestrzeni, 127przypadek, 229przypadki testowe, 165

R

realizm, 232redaktor, 51regulowanie wielko ci programu, 119rekurencja architektów, 281reprezentacja, 121rewolucja mikrokomputerów, 306rozrost funkcji, 282rozwi zania pilota owe, 134rozwój inkrementalny, 221

Poleć książkęKup książkę

336 Legendarny osobomiesi c

S

samodokumentuj cy si program, 192sekretarz, 51separacja architektury od

implementacji, 280skalowanie, 55, 134s owniki, 245specjalista j zykowy, 53specyfikacja, 80, 126spotkania, 84, 93spójno koncepcji, 60, 279, 284stacje robocze, 216struktura komunikacji, 259symulator, 149

wydajno ci, 152system

dokumentacji, 152edycji tekstu, 268ekspercki, 211operacyjny, 308programowy, 274szkieletowy, 291

szacowanie tchórzliwe, 38szacunki, 127sztuczna inteligencja, 210szybkie prototypowanie, 294szybko

debugowania, 110programowania, 110

rodowiska programistyczne, 216

T

technikiregulowania wielko ci, 119szacowania, 32

tester, 52testowanie

produktu, 87specyfikacji, 160

testy systemowe, 37translator, 109tworzenie

dokumentacji, 189kodu, 38oprogramowania

model wodospadu, 289model inkrementalno –

progresywnych ulepsze , 291przyrostowe, 294

prototypów, 219systemu szkieletowego, 291

U

uproduktowienie programu, 252urz dnik, 51us ugi danych, 149uszczegó awianie wymaga , 219utrzymywanie programu, 265u ytkownik, 282, 310u ywanie zdebugowanych

komponentów, 165

W

weryfikacja programu, 215wielko oprogramowania, 116wska niki produktywno ci, 238wymagania, 219

dokumentacyjne, 273wymiana informacji, 36

Z

zabezpieczanie definicji, 160zespó , 53, 254, 267zgodno , 204zintegrowane rodowiska

programistyczne, 207z o ono , 202, 231zmniejszanie skali konfliktu, 177zrzuty pami ci, 163zyski, 242

Poleć książkęKup książkę

http://program-partnerski.helion.pl