Tartalomjegyzék:
szoftver projekt becslés
Pixabay
Bevezetés
A becslés csak nehéz. Sajnos ez is nagyon szükséges. A vállalatok becslések alapján tervezik a kiadási ütemterveket, vállalják az ügyfeleket, eldöntik, hogy érdemes-e megvalósítani a javasolt funkciót, nyomon követik a csapatok sebességét, és hatékonyan rangsorolják a munkát. A vezetők gyakran szeretnék tudni, hogy egy szolgáltatás vagy termék mikor lesz kész a gyártásra. Végül is a szoftverfejlesztés nem jelentéktelen befektetés. Becslések nélkül hogyan végezne értékelést a projektmenedzser? Ha az emberek pontosan meg tudnák jósolni a jövőt, akkor az emberek az esetek 2% -ában nem nyernek a lóversenyeken. A becslés a nagy talány. A vállalatok számára elengedhetetlen és szükséges, hogy a lehetetlenné tegyék az embereiket: megjósolják a jövõt.
Először tekintsünk át néhány népszerű becslési módszert (arra az esetre, ha elmulasztanátok az izgalmat). Aztán megnézhetjük, hogy ez mit jelent számunkra és a projektjeinkben.
A jósnő modellje
Ez a modell szinte nem igényel erőfeszítést a becslés elkészítéséhez. Az becslők egy kicsit elgondolkodnak azon, hogy mit kell tenni egy funkció megvalósítása és tesztelése érdekében, majd kidobnak egy számot. Nagyon úgy hangzik, hogy „… (hosszú szünet)… Ummmmm… 6 hét.” Aztán mindenki bólint, és továbbállunk. Elég sokáig tölthetnének a kezelőfelületen, és átbeszélhetik, mit tudnak a követelményekről (ami valószínűleg nem teljes kép). Ez a körültekintő elemzés megbecsülésüket megbízhatóbbnak érzi. A projekt végén mindig elfogadott indoklás van arra, hogy a becslés miért volt annyira távol a valóságtól. Mindig vannak olyan előre nem látható körülmények, amelyek bűnbakként szolgálhatnak. Gyakran senkinek sem tűnik fel, hogy a modell súlyosan hibás.
Tehát hogyan lehetne ezt a folyamatot jobbá tenni? Tudom! Használhatjuk a Bomlási technikát (azaz megosztani és meghódítani). Ez a megközelítés feltételezi, hogy ismeri a szolgáltatás vagy a projekt teljes körét a kezelőfelületen. Minden funkciót harapás méretű darabokra bontunk. Minden darab becsült (jövendőmondó stílus), majd összeadjuk őket, hogy átfogó tulajdonságot / projekt becslést kapjunk. Ez minden bizonnyal bonyolultabb megközelítés, de két okból jobbnak tűnik:
- A kisebb munkadarabokat általában könnyebb megbízhatóan megbecsülni.
- Bár továbbra is fennáll a lehetőség a hibára (+/- valamilyen összeg), feltételezzük, hogy a hibák törlik egymást, amikor összeadjuk az összeget, és megbízhatóbb összbecslést kapunk.
Ennek a megközelítésnek az alapvető hibája, hogy az egyes közreműködők (a munkát ténylegesen végző emberek) általánosan alábecsülik. Még mindig lényegesen jobbak, mint a felettük és körülöttük élők, de ez nem egy magas léc. Úgy tűnik, ez nem így van, mert mindannyian láttunk olyan eseteket, amikor a fejlesztők meglepték magukat azzal, hogy valamit előre teljesítettek. De ez egyetlen adatpont, nem pedig trend. Az emberek néha valóban nyernek a kaszinóban; költsön pénzt egy kaszinóban egy éven keresztül minden nap, és kevesebb pénze lesz, mint amivel kezdte. Ha követi a becsléseket a tényekhez képest egy-két évig, rájön, hogy a becslések valóban elmaradnak a valóságtól. Míg sok üzletember teljesen biztos abban, hogy a fejlesztők lustán töltik ki becsléseiket, és a többletidőt arra használják, hogy "aranylemezre" tegyék vagy ellenőrizzék készleteiket,az adatok mást mutatnak. A „törlés” stratégia nem működik.
Akkor most mi legyen? Távolítsuk el a jósnő modelljét, és váltsunk méretalapú megközelítésre. Kiderült, hogy bár az emberek elég borzasztóan becsülik meg a befejezési időt, mi valójában nagyon jól mondhatjuk, hogy mekkora valami. Különösen jól értünk az összehasonlító méretezéshez („ennél nagyobb, de ennél kisebb ott”). Ha méretben vagy összetettségben gondolkodunk, nem pedig időben, agyunk megbízhatóbban dolgozza fel. Ezután felvehetjük a méretértékeket, és egy remek mágikus képlet alapján kiszámíthatjuk a projekt tényleges óraszámát! És ekkor lép be a színre a népszerű funkciópont-modell (bal oldali szakasz).
Funkciópont-elemzés (FPA)
A funkciópont-elemzéshez ötféle dolgot kell meghatároznunk alkalmazásunkban: külső bemenetek, külső kimenetek, külső lekérdezések, külső interfészfájlok és belső logikai fájlok (ne aggódj túl sokat a definíciók miatt; ezeket később is kutathatja). Mindegyik példának (egy függvénynek) összetettsége van (alacsony, átlagos vagy magas). Az alábbi táblázat alapján kitaláljuk, hogy az egyes függvények hány ponttal rendelkeznek.
Ha összeadjuk az összes függvény pontját, akkor a projektünkhöz 457 funkciópontot kaphatunk. Akkor csak képletre van szükségünk az órák számának kiszámításához… Legutóbbi projektünk alapján a „szállítási arányunk” havonta 15 funkciópont volt fejenként. Ez nagyjából 30 emberhónapos munka, amelynek valamivel több mint két és fél hónapot kell igénybe vennie a 12 fős csapatomnak. Ta-da!
Ez minden bizonnyal összetettebb, mint az előző modellünk. Valójában a komplexitás négy kulcsfontosságú területét kell felismerni.
- Az öt komponenstípus nem feltétlenül intuitív, és könnyen el lehet felejteni valamit felvenni a listába vagy rossz sávba rendelni.
- A függvénypontok tényleges előállításához használt táblázat olyan mágikus számokat tartalmaz, amelyek validálása sok erőfeszítést igényel. Megfelelően kalibrálják ezeket a számokat, hogy megbízható becsléseket hozzanak létre csapataim számára?
- A kézbesítési arány (a rejtvény kritikus része) a csapat termelékenysége alapján kerül kiszámításra. Milyen gyakran kell új számot kiszámítanunk? Valójában nagyon kevés útmutatás van erről.
- Mi az alacsony, átlagos vagy magas komplexitás? Hogyan definiálhatjuk ezt, hogy mindenki megértse? Nem kritikus a számítások pontossága szempontjából ez a helyes?
Ebben a nagyon egyszerű példában több mozgó rész is található, és még nem is tárgyaltunk bonyolultabb bonyolultsági modellekről és az egyéb adatokról, amelyek szóba jöhetnek (pl. Költségarány, támogatási ráta, hibasűrűség stb.). A több mozgó alkatrész több hibalehetőséget jelent. Túl bonyolulttá tesszük a becslést? Nem azért fizetünk a fejlesztőknek, hogy sok időt fordítsanak a becslésre. Becslést nem tudok eladni vevőimnek. Szükségem van működő szoftverre. Van még valami odakinn?
Fürges
Most nézzük meg röviden az agilis súrlódást (csak ahhoz, hogy összehasonlítást végezzünk). Amint azt korábban elmondtuk, az emberek szörnyen becsülik az idõt, és nagyon jók az összehasonlító méretezésben. Íme néhány megértendő kifejezés:
- Sprint - időzített időtartam (általában két hét).
- Felhasználói történet - diszkrét munka, lehetőleg elég kicsi ahhoz, hogy egy ember végezhesse el sprintben. Ezt becsüljük.
A legnépszerűbb stratégia a fibonacci szekvencia (0, 1, 2, 3, 5, 8, 13) használata a becslésekhez. Ez nem lineáris - ahogy felfelé halad, a rések nagysága megnő. A legfontosabb az, hogy a hézagoknak elég szélesnek kell lenniük, így nincs ok vitatkozni a jelentéktelen különbségeken. Ha 3 fölé kerül, akkor a 4 és 5, illetve a 7 és a 8 közötti különbség annyira elhanyagolható, hogy értelmetlen időt tölteni azzal, hogy melyik az. Egy bázis-2 szekvencia is működne (0, 1, 2, 4, 8, 16 stb.).
- De várjon, ez csak egy szám. Mit jelent? Hány óra a lényeg? A pontok nem célja, hogy közvetlenül korreláljanak az órákkal, mert ha mégis megtennék, akkor a csapatok kedvet kapnának arra, hogy visszatérjenek az órákra vonatkozó becsléshez, majd ezt valahogy pontokká alakítsák át. Mint korábban tárgyaltuk, becsléseink pontossága összehasonlító méretezésből származik, és nem becsüljük meg az órák számát. Ha lehetőséget ad a csapatnak arra, hogy órákban gondolkodjon, akkor veszélybe sodorja a pontos becslés képességét.
Tegyük fel, hogy egy kalibrációs gyakorlattal kezdte. Húzza a csapatát egy szobába, és végigvezeti őket egy 10-12 felhasználói történet listáján. Válasszon egyet, amelyik kicsi, de nem a legkisebb, és először tegye meg. Tekintse át, és jelentse be, hogy ez a történet „3”. Nem kérdezed. Azt mondod. Ezután folytassa a következő történettel. - Ha ez 3 volt, mi ez? Most a csapat történeteket oszt meg a többi történethez képest. Végül elég jó ötletük lesz arról, hogy mi minősül „1” -nek, „2” -nek stb. Az idő nem számít. Történeteket méreteznek, összehasonlítva más, már számmal rendelkező történetekkel. Ezután a szekvencia minden egyes számához példa-történeteket tehet egy vonalzónak nevezett dokumentumban. Ezt használhatják referenciaként, ha nem tudják biztosan, mi az „5”.
Most itt van a kulcs. A varázsszósz, amely ezt a munkát eredményezi, a „sebesség” (a csapatok által megszerzett pontok száma 3-4 sprint átlagában átlagolva). Tegyük fel, hogy a sprinted két hét, a 8 fős csapatod átlagos sebessége 35 pont. 35 pontot ér el 640 munkaidő alatt (8 x 80 óra). Ha kitaláljuk, hogy egy funkció körülbelül 100 pont értékű munkát igényel, akkor tudom, hogy ez körülbelül 6 hét munka és ~ 1900 óra. A csapat nagyon jól megismeri a történetek következetes méretezését, és ezt felhasználja a projekt tervezéséhez. Ez a számítás azért működik, mert az időtartam sprintről sprintre következetes.
Hosszú távú, magas szintű tervezéshez megkérheti az ügyfeleket, hogy bontsák le a magas szintű szolgáltatásokat átmeneti egyvonalas történetekre, és tegyenek rá pontértékeket. Bizonyos pontosság elvész, de kihasználja azt a modellt, amelyet ők már értenek. A pontosabb út a relatív méretezés lenne a jellemző szintjén. "Ez a funkció nagyobb, mint a 40 pontos szolgáltatás, kisebb, mint az ott található 120 pontos és kissé nagyobb, mint az imént használt 65 pontos szolgáltatás." A történetek „epikákba” vannak csoportosítva. Ha minden funkció epikus, a végén tudni fogja, hány pont kellett ahhoz, hogy teljesítse ezt a funkciót. Tartsa ennek előzményeit, és felhasználhatja a kiadás tervezéséhez.
Következtetés
Rengeteg módszert használnak manapság. Mindegyiknek vannak előnyei és hátrányai. Valahogy ki kell találnunk, hogyan lehet maximalizálni becsléseink pontosságát, hogy jó döntéseket hozzunk. Ez nem azt jelenti, hogy becsléseinknek pontosnak kell lenniük. Csak elég pontosaknak kell lenniük ahhoz, hogy hasznosak legyenek. Ha nem érti a becslést, akkor feltételezheti, hogy a becslések nem voltak pontosak, mert a csapat nem végzett jó munkát. Nem becsülték meg helyesen, vagy nem megfelelően hajtották végre a projektet. A verés a becslések javulásáig folytatódik. De a becsléseket soha nem szabad elkötelezettségként használni. Ez a legjobb tipp a ma rendelkezésre álló korlátozott információk alapján. Amikor új információ jelenik meg, lehetővé kell tennünk a becslések felülvizsgálatát. Minden más a lehetetlent várja, ami a vezetéssel (nem a csapattal) kapcsolatos probléma.
A Scrum megközelítése sokkal egyszerűbb, mint amit a függvénypont-elemzés során látunk. És azt mondanám, hogy sokkal megbízhatóbb, mint a mágikus számokkal ellátott mágikus táblák. A legtöbb durranást a bakért kapja (minimális erőfeszítés, meglehetősen nagy pontossággal). Erőfeszítés szempontjából nem hoz létre nehéz folyamatot a csapatok számára, hogy megértsék és felhasználják. Az agilis becslési darab valójában nagyon gyorsan megtörténhet, ha mindenki megérti a becsült munka részleteit. Ez minden bizonnyal jobb, mint a számok kihúzása a levegőből. A sebesség kihasználása nagyon fontos dolgot tesz: történelmi adatokat visz be a számításba. Minden sprintben újraszámolja a sebességét. Ez kritikus, mert az idő múlásával az áteresztőképesség megváltozik. Az FPA-t használó csapatok szállítási arányukat korábbi projektjükből származtathatják,ami egyes esetekben több hónappal ezelőtt volt. Azóta valószínűleg sok minden változott. Javaslatom az Ön számára, hogy fedezze fel az Agile-t, és fektessen igazán erőfeszítéseket a sztoripontok és a sebesség megértése érdekében. Ne essen vissza az órákig tartó becsléshez, csak azért, mert ezt érti. Azt hiszem, később megköszöni magának.