2. fejezete ez a mitikus "ember-hónap" - A mitikus Man-Month: Essays on Software

Hogy előkészítse a finom ételek, ez időt vesz igénybe. Ha kellett várni, csak azért, mert azt akarjuk, hogy jobban kiszolgálja Önt, és örömet.

Éttermi menü "Antoine" In New Orleans

Szoftver projektek gyakran nem hiánya miatt naptári időt, mint minden más okból kombinált. Miért van ez, mint egy gyakori oka a hiba?

Először is, gyengén fejlett az értékelési módszereket. Tény, hogy azok tükrözzék a csendes és teljesen téves feltételezés, hogy minden jól fog menni.

Másodszor, a becslésére szolgáló módszereket tévesen összekeverik előrelépés az erőfeszítéseket kiürül, hallgatólagosan feltételezve, hogy a sebességet a projekt arányos a foglalkoztatottak száma az alkalmazottai.

Harmadszor, mivel a szoftver projekt menedzserek nem bízik a megítélés, gyakran nem udvarias makacsság, mint egy szakács „Antoine„étteremben.

Negyedszer, a végrehajtás a munkarend rosszul kontrollált. Tesztelt modell más mérnöki tudományok, technika tekinthető radikális újítások szoftverfejlesztés.

Ötödször, észlelésekor természetes lag a grafikonon, és a közös reakció számának növelése a fejlesztők. Ez olyan, mint hogy eloltotta a lángokat benzinnel. Ennek eredményeként, a dolgok sokkal rosszabb. Minél erősebb a láng, annál van szüksége a benzin, és ennek eredményeként ez út vezet a katasztrófa.

Végrehajtásának nyomon követése a menetrend tárgya lesz egy külön vitát. Nézzük meg részletesebben a másik szempontból a probléma.

Minden programozó - optimisták. Talán ez a modern fajta varázslás különösen vonzó azok számára, akik hisznek a boldog befejezés, és tündér keresztanyja. Talán száz balesetek taszítja minden, de azok, akik arra használják, hogy összpontosítson a végső cél. És talán éppen ez a számítógépek és a programozók fiatal, és a fiatalok jellemző optimizmus. Bármi is volt, ennek eredményeként egy dolog: „Ebben az időben, akkor megy, az biztos!” Or. „Épp most kiderült, az utolsó hiba!”

Tehát, a középpontjában a szoftverfejlesztés tervezés egy téves feltételezés, hogy minden rendben van, hogy a Minden feladat lesz annyi idő, mint „kellene” venni.

Mély optimizmus programozók többet érdemel komoly figyelmet. Dorothy Sayers (Dorothy Cayers) írt kiváló könyvében: „A Mind a Teremtő» ( "The Mind a Maker") kiemeli a kreatív tevékenységekben a három szakaszból áll: tervezés, a megvalósítás, az interakció. Ennek megfelelően, egy könyv vagy egy számítógépes program először jelennek meg, mint a tökéletes alkat, nem létezik térben és időben, de csak a szem előtt az alkotó. Végrehajtási azonos időben és térben ez történik egy toll, tinta, papír, vagy - vezetékek, szilícium és ferrit. Creation fejeződik be, amikor valaki olvas egy könyvet, hogy kihasználják a számítógép vagy elindítja a programot, így érintkezésbe lép az elme alkotójuk.

Ezt a leírást használják világítás Sayers nemcsak az emberi kreativitást, hanem a keresztény dogma a Szentháromság, segít nekünk a jelenlegi feladat. Egy olyan személy, aki teremt valamit, hiányos és ellentmondásos gondolatok kiderült, csak ha azok megvalósítását. Ezért elméleti kifejtése papíron, a kísérletezés, a gyártás szerves része a kreatív folyamat.

Sok fajta kreatív tevékenység az anyag nem könnyű kezelni. Wood megszúrta, piszkos festék, elektromos áramkör „gyűrűt.” Ezek a fizikai korlátok szűk tartományban ötleteket, hogy lehet kifejezni, valamint hozzon létre váratlan végrehajtás nehézségei.

Végrehajtás így idő- és munkaigényes mind a fizikai anyag, és mivel a nem megfelelő alap ötleteket. A legtöbb nehézséget a végrehajtás során, hajlamosak vagyunk, hogy ismertesse a mozgásszegény anyag, mert „idegen” nekünk - ellentétben az elképzelést, hogy büszkék vagyunk.

Amikor létrehozza a program, mi foglalkozunk rendkívül rugalmas anyaggal. A programozó végzi építési alapján tiszta gondolat - fogalmak és a reprezentációk nagyon rugalmas. Mivel az anyag annyira hajlékony, nem várunk semmilyen nehézséget a végrehajtás, ezért mély optimizmus. Mivel a gyarlóság eszméink vannak hibák a programokat. Következésképpen, a optimizmus nem indokolt.

Az egyéni feladat, hogy azt valamennyi bude jó, hogy van, hogy a menetrend valószínűségi hatást. A dolgok igazán megy a terv szerint, mivel van egy valószínűségi eloszlás az esetleges késések, és van egy véges valószínűsége, hogy késedelem nem. Azonban egy nagy szoftver projekt egy sor feladat, amelyek közül néhány csak akkor kezdeményezhető, a másik után. Annak a valószínűsége, hogy az összes feladat befejezése időben, végtelenül.

A második hiba az érvelés rejlik nagyon mértékegységben becsléséhez használt és tervezés: Man-Month. Az ára valóban mérve a termék a foglalkoztatottak száma a hónapok számát töltött. De nem az elért eredmény. Ezért az ember-hónap, mint az egység munkateher egy veszélyes tévhit.

Ábra. 2,1-szer függően a foglalkoztatottak száma - a teljes elkülöníthető feladatot

A foglalkoztatottak száma és a hónapok számát felcserélhető értékek csak akkor, ha a feladat lehet osztani a munkavállalók száma, akiknek nincs kapcsolata egymással (ábra. 2.1). Igaz, amikor aratnak búzát vagy szedés pamut, de a rendszer programozási ez nem így van.

Ábra. 2,2-szer függően a foglalkoztatottak száma - oszthatatlan feladat

Ha a feladat nem bontható részekre, mert vannak korlátozások a lépések sorozata, a költségek emelkedésével nem érinti a grafikon (ábra. 2.2). Ahhoz, hogy egy gyerek van szükség kilenc hónap nem számít, hány nők vonzódnak a megoldást erre a problémára. Sok programozási feladat az ilyen típusú, mert a hibakeresés eredendően szekvenciális.

Ábra. 2,3-szer függően a foglalkoztatottak száma - elkülöníthető igénylő feladat adatcsere

Milyen feladatokat lehet részekre bontjuk, de ehhez az adatcsere az egyes feladatok között, a kommunikáció költségét hozzá kell adni az összes szükséges munka mennyiségének. Ezért a legjobb elérhető eredmény valamivel rosszabb, mint puszta megfelelés a foglalkoztatottak száma, és a hónapok számát (ábra. 2.3).

További terhelést két részből áll - a tanulás és az adatcserét. Minden alkalmazottnak ki kell képezni a technológia, a projekt célkitűzéseit, általános stratégia, munkaterv. Ez a képzés nem lehet részekre osztani, így ez a része a költség lineárisan változik a foglalkoztatottak száma.

Ábra. 2,4-szer függően a foglalkoztatottak száma - a probléma komplex összefüggéseket

Mivel a helyzet rosszabb, mint az adatcsere. Ha az összes feladatot külön kell hangolni egymással, a költségnövekedés n (n-2) / 2. A három munkásokat háromszor annyi páros kommunikáció, mint két-4-6 alkalommal. Ha ezen felül szükség van az üléseken a három, négy, stb munkavállalók közösen a kérdések, a helyzet még rosszabb lesz. További költségek cseréjére vonatkozó adatok teljes egészében ellentéte A zúzás a kezdeti probléma, és az ólom, hogy a helyzet által leírt 2.4 ábra.

Létrehozása óta a szoftver lényegében egy szisztémás projekt - a gyakorlatban a komplex kapcsolatok, a költségek adatcserét nagy és gyorsan kezd uralkodóvá csökkentése szempontjából, eredményeként elért felosztása feladatok kisebb részfeladatok. Ebben az esetben a részvétel további személyzet nem vágja, és kiterjeszti menetrend.

Az összes elem munkarend által leginkább érintett korlátozások a műveletsornak alá hibakeresés komponensek és a rendszer tesztelése. Ezen túlmenően, a szükséges idő függ a talált hibák száma, valamint azok a „rejtett”. Elméletileg, a hiba nem lehet. Mivel a optimizmus, mi általában alábecsülik a tényleges hibák száma. Ezért a programozás, hogy tartsák be menetrendek általában a legnehezebb a hibakeresés.

Egy több éve a tervezés, a fejlesztés a program azt használja a következő ökölszabály:

1/6 - írásban programok

1/4 - tesztelés alkatrészek és fejlett rendszer tesztelése,

1/4 - rendszer tesztelése jelenlétében valamennyi komponens.

Ez a szabály van néhány fontos különbség a hagyományos tervezés:

1. Tervezés kap több időt, mint máskor. Mégis, ebben az időben éppen elég fejlesztésének részletes és megbízható technikai feltételek és az elégtelen kutatási vagy találjon új technológiákat.

2. Fél a menetrend kiosztott teljes hibakeresés kódot, sokkal magasabb, mint a normális.

3. Az a rész, könnyű felmérni, azaz Kód írása mindössze egyhatoda a teljes idő.

Tanulás a projektek ütemezése tették ki a szokásos módon, rájöttem, hogy néhány közülük kinyert fél időbeosztás hibakeresés, de a gyakorlatban a legtöbb időt töltötte rajta a fele az aktuális időt. Számos projekt az ütemterv szerint minden szakaszában, kivéve a rendszer tesztelése. [2]

Különösen katasztrofális következményei lehetnek az idő hiányát rendszer tesztelése. Mivel a késés lép fel az utolsó része a grafikon, senki sem sejtette, hogy a menetrend veszélyben, amíg a szülés napján a terméket. Rossz hír érkezett, későn, mindenféle figyelmeztetés nélkül elriasztja az ügyfelek és a vezetők.

Sőt, ebben a szakaszban, a késedelem különösen súlyos fizikai és pszichológiai következményei. A projekt a teljes

személyzeti alkalmazottak és a maximális pénzügyi költségeket. Ennél is fontosabb, a szoftver támogatást kell nyújtania a többi tevékenység (szállítás a számítógépek, a dob az új termelési kapacitások, stb), és a hozzá tartozó késleltetett másodlagos költségek nagyon magasak. A gyakorlatban ezek a másodlagos költségek magasabbak lehetnek, mint a többiek. Ezért nagyon fontos a kezdeti munkarend veszi elég idő a rendszer tesztelése.

A félénkség a becslések

A programozó, szeretek főzni, a mester által nyomás határozza meg a tervezett befejezésének időpontját a problémát, de nem tudja meghatározni az időt a tényleges befejezését. Omlett, az ígért két percig is sikeresen sült, de ha két percen belül nem áll készen, akkor az ügyfél két lehetőség van: várni, vagy akár enni nyersen. Az ugyanabban a tartományban a standok előtt és a kliens szoftver.

Főzünk van egy másik lehetőség: add hőt. Ennek eredményeként az omlettet gyakran reménytelenül elrontott: megégett az egyik végén és a nyers - egy másik.

Nem hiszem, hogy a menedzsment szoftver termékek kevesebb bátorság vagy a keménysége, mint a szakácsok és más vezetők mérnöki területeken. De hamis grafika, amelynek célja a kívánt dátumot a tulajdonos is van, sokkal gyakoribb, mint bármely más műszaki területeken. Nagyon kemény, a veszélye, hogy elveszítik a munkájukat, az energia és a kedvesség, hogy megvédje az élet, amely a meghatározás nélkül kvantitatív módszerek adatok hiányában, és támogatja, főleg intuíció vezetője.

Míg értékelési módszerek nem fog szilárd alapot, a vezetők csak akkor szív és megvédeni az előrejelzések, azzal érvelve, hogy a szegény támaszkodnak az intuíció is jobb, mint egy alapul vágyak.

Hozzászólások megbontása a menetrend

Mit kell tenni, amikor a fontos szoftver projekt kezd esni késésben? Természetesen az emberek hozzá. Mivel a számok 2,1-2,4, ez nem mindig segít.

Vegyünk egy példát. [3] Tegyük fel, hogy a probléma összetettsége becsült 12 ember hónap, három ember fuss ez 4 hónap, és a végén minden hónap, négy ellenőrző pont A, B, C & D, ahol ez lehetséges, hogy a méréseket (ábra. 2.5).

Tegyük fel, hogy az első referencia pont eléréséig csak két hónap után. Milyen alternatívák állnak rendelkezésre a menedzser?

1. Tegyük fel, hogy szükséges betartani a határidőt a feladat, és csak az első része a problémának tévesen értékelte, hogy van, 2.6 ábra tükrözi a valódi helyzet. Marad 9 személy hónapos munkaerő-költségek és a két hónap, így szükség lesz 4Ѕ ember, és a három meglévő igény, hogy két újabb.

2. Tegyük fel, hogy meg kell, hogy megfeleljen a határidők a feladat, és ugyanolyan alábecsülte volt az egész pontszámot. azaz helyzet megfelel a 2.7 ábra. Tehát, van 18 ember hónapokig tartó erőfeszítést és két hónap, így szükség lesz 9 fő. Ahhoz, hogy a három meglévő igény, hogy újabb hat.

3. Állítsa be a menetrend. Szeretem a észrevételét P. faggen (P. Fagg), egy tapasztalt mérnök számítástechnika: „Small késedelem nem történt meg.” Ez azt jelenti, hogy az új menetrend legyen elég idő, hogy végeztünk alaposan és teljesen és nem kell megváltoztatni a menetrend újra.

4. Hogy csökkentsék a problémát. A gyakorlatban ez mindig véget ér, amikor a csapat felfedezi, hogy nem fér bele a menetrend. Ha nagyon magas a másodlagos költségek az egyetlen dolog, amit tehetünk. A menedzser egy lehetőséget, hogy hivatalosan és óvatosan csökkentheti a problémát, módosítsa a menetrend, vagy nézni, ahogy a feladat csendben levágja sietett változás a projekt és a hiányos tesztelés.

Az első két esetben, ragaszkodnak ahhoz, hogy a feladatot végezték változatlanul négy hónapig, tele van a katasztrófa. Vegyük például, a redukáló hatása az első alternatíva (ábra. 2.8). Két új alkalmazottak, nem számít, milyen jól vannak, és milyen gyorsan nem találtam őket, tanulmányozni kell a problémát az egyik tapasztalt fejlesztők. Ha egy hónapig tart, a 3 hónapos költenek majd a munkát, amely nem szerepel az eredeti becslést. Ezen túlmenően, a feladat először tört be három patak, kell most rajzolni öt részre. Ezért része a már elvégzett munka elvész, és a rendszer tesztelése kell majd hosszabbítani. Ennek eredményeként, a végén a harmadik hónapban a működés továbbra is lényegesen nagyobb, mint 7 hónap, és az ártalmatlanítás lesz 5 képzett embereket, és egy hónap. Ábra szerint 2.8 termék késni fog ugyanúgy, mintha egyetlen személy adtak (lásd. Ábra. 2.6).

Ha azt várod, hogy kezelni négy hónap, figyelembe véve csak a képzési időhöz, de nem az újraelosztás feladatok és további vizsgálata a rendszer, a végén a második hónap, kell hozzá 4 helyett 2 fő részére. Hatásának ellensúlyozására az újraelosztás feladatok és a rendszer tesztelése lesz szükség több új embert. Most azonban a csapat nem készült fel 3, és legalább 7 fő, és olyan kérdések, mint a szervezet a csapat és a feladatmegosztás, hogy egy új minőségi szintre.

Rendkívül egyszerűsítése megfogalmazni törvény Brooks:

Ha a projekt nem fér bele a feltételeket, kiegészítve a munkaerő késleltetni fogja még tovább.

Ez leleplezi a mítosz az ember-hónap. A projekt időtartama függ a megszorításoknak a munka szekvencia. A legnagyobb fejlesztők száma függ a független részfeladatokra. Ez a két érték lehetővé teszi, hogy egy ütemtervet, amely kevésbé lesz elfoglalva a fejlesztők és a több hónapon keresztül. (Az egyetlen veszély az esetleges elavulás a terméket.) Lehetetlen azonban, hogy a munkarend, ami foglalkoztat több embert, és kevesebb időt vesz igénybe. Szoftver projektek gyakran nem hiánya miatt naptári időt, mint minden más okból kombinált.