Brooks-törvény
 |
Ez a szócikk nem tünteti fel a független forrásokat, amelyeket felhasználtak a készítése során. Emiatt nem tudjuk közvetlenül ellenőrizni, hogy a szócikkben szereplő állítások helytállóak-e. Segíts megbízható forrásokat találni az állításokhoz! Lásd még: A Wikipédia nem az első közlés helye. |
A Brooks-törvény kimondja, hogy ha egy elcsúszott projekthez további embert adsz, a projekt még tovább fog csúszni.[1][2]
1975-ben Fred Brooks, a szoftverfejlesztés egyik alapelvének mondta ki a The Mythical Man-Month című könyvében. Hasonló a csökkenő megtérülés általános tervéhez.
Fennáll a halálmenet lehetősége is, ha nem adnak új embereket a projekthez, hanem azokat túlóráztatják, akik már a projektben vannak.
Magyarázatok
[szerkesztés]Maga Brooks is leegyszerűsítésnek nevezte a rövid leírást,[1] ami azonban leírja az általános elvet. Brooks a következőkkel magyarázza a jelenséget:
- Az embereknek időbe telik, hogy egy projektben produktívan vegyenek részt. A szoftverprojektek nagyon komplexek, s a résztvevőknek oktatásra van szükségük, hogy megismerjék ezeket a mérnöki rendszereket, a konkrét rendszert és az egyedileg kialakított szokásokat. Ez az oktatás további erőforrásokat von el a fejlesztéstől. Azon kívül, hogy a tapasztalt résztvevők csökkent mértékben tudnak részt venni a munkában, az új emberek még hátráltathatják is a munkát, mivel nagyobb valószínűséggel írnak hibás kódokat az ismerethiány miatt.
- A kommunikáció több ember között, több időt és erőforrást köt le. Bonyolultabb szervezeti struktúra kell hozzá; újfajta kommunikációs csatornák és stílusok jönnek létre. Az emberek számának duplára növelése a kommunikáció mennyiségének négyszeresre növekedését okozza.[3] Mindenkinek, aki ugyan azon a feladaton dolgozik szükséges, hogy szinkronban maradjon a többiekkel. Tehát, minél több ember dolgozik ugyanazon, annál több időt kell eltölteni annak a földerítésével, hogy a többiek pontosan mit csinálnak.
- A feladatok feloszthatósága. Ha a feladat jól felosztható, akkor több személy bevonása a munkába gyorsabb munkavégzést eredményez. Jól felosztható például a hotelszobák takarítása. Ezzel szemben Brooks rámutat arra, hogy egy nő kilenc hónap alatt hord ki egy babát; ugyanerre nem képes kilenc nő egy hónap alatt.
Megoldási lehetőségek
[szerkesztés]Brooks törvénye nyitva hagy néhány kiskaput, amelyek ajtók a lehetséges megoldások számára.[4][5]
Brooks törvénye a késésben levő projektekről szól.[6] A korábban a projekthez adott emberek segíthetnek visszanyerni az ellenőrzést a projekt fölött.[7] Fontos eldönteni, hogy az ütemezés volt-e túl optimista, vagy valóban késésben van a projekt, mivel sokszor az ütemezéssel van hiba. Ekkor segít az átütemezés, ami valós időhatárokat tűz ki.[8]
Figyelembe kell venni, hogy hány munkatársat adnak a projekthez, milyen képességekkel és milyen szerepben. Számolni kell a betanulással és a kommunikáció bonyolultságának növekedésével annak eldöntésében, hogy hány taggal bővítenek. Jó programozók, illetve szakértők rövidebb idő alatt térnek át egy új projektre. A projekthez lazábban kapcsolódó feladatokat is lehet adni, például dokumentációt vagy minőségbiztosítást, ezek is segítenek a betanulásban.
Az olyan modern módszerek, mint a tesztvezérelt fejlesztés, a folyamatos integráció és az iteratív fejlesztés jelentősen csökkenti a kommunikációra fordított időt, így javítja a skálázhatóságot.[9] Az új fejlesztési és dokumentációs eszközök lerövidítik a betanulási időt, ezzel megkönnyítik az új munkaerő bevonását.
A programtervezési minták segítik felosztani a feladatokat. Különálló egységeket jelölnek ki, amelyek a minta által előírt módon kapcsolódnak, és milyen előírásoknak kell megfelelni. Segíti a kommunikációt egy szabványosított nyelvvel, konzisztenciát és skálázhatóságot biztosít. A jobb felosztás miatt a kapcsolattartás is egyszerűbb, mivel mindenki főként azokkal beszél, akinknek a munkája az ő munkájához kapcsolódik; másokhoz ritkábban fordul. A részproblémák helyi szinten kezelhetők. Ha rosszul osztanák fel a projektet, akkor akár akadályozhatják is egymást a problémák megoldásában.
A Brooks-törvény folyományaként alkalmazzák a Bermuda-tervet. Eszerint a programozók 90%-át a projekt befejezése előtt eltávolítják a projektből, és a maradék 10% fejezi be.
Jegyzetek
[szerkesztés]- ↑ a b Frederick P. Brooks, Jr. The Mythical Man-Month. 1995 [1975]. Addison-Wesley.
- ↑ Maggie Fox NBC News, October 21, 2013, Better use the phone: Why Obamacare website is such a fail. Accessed Oct 21, 2013. "And sending in too many of the "best and the brightest’ might not be the right fix, either, software experts note. They often cite Brooks’s Law, which holds that adding people to a project slows it down."
- ↑ James Taylor, "A Survival Guide for Project Managers", 2nd edition, AMACOM, 2006, ISBN 978-0814408773, p. 21.
- ↑ "In spite of Brooks' law, adding people to a late project remains commonplace" ... "I have evangelized this well-worn software engineering chestnut many times myself, but I no longer think it's true". (McConnell, 1999)
- ↑ "The trouble is that there are important exceptions that many people do not take the time to consider when using Brooks' law to justify something". (Berkun, 2006)
- ↑ "Implicit in those projects is that it applies only to the final phases of a project. The question is, How do you know whether you're in a project's final phases?" (McConnell, 1999)
- ↑ "We have found that adding people to a late project will always increase its cost, but the project may not always be late since there may be sufficient schedule to absorb them and the project may not be at maximum staffing. Only under certain degree of sequential constraints among project tasks will the project be delayed." (Hsia, Hsu, Kung, 1999)
- ↑ Late chaotic projects are likely to be much later than the project manager thinks – project completion isn't three weeks away, it's six months away. Go ahead and add staff. You'll have time for them to become productive. Your project will still be later than your plan, but that's not a result of Brooks' law. It's a result of underestimating the project in the first place." (McConnell, 1999)
- ↑ Continuous integration in agile development: How agile methods, continuous integration, and test-driven enhance design and development of complex systems. IBM developerWorks , 2012. augusztus 14. (Hozzáférés: 2015. szeptember 25.)
Fordítás
[szerkesztés]Ez a szócikk részben vagy egészben a Brooks's law című angol Wikipédia-szócikk fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.
