EVM IT un programmatūras projektiem
Earned Value Management (EVM) piemērošana IT un programmatūras projektiem ir sarežģītāka nekā būvniecībā. Programmatūras darbs ir abstrakts, prasības var mainīties projekta vidū, un funkcijas „pabeigtības procenta” mērīšana pēc būtības ir subjektīva. Tomēr, veicot pareizos pielāgojumus, EVM sniedz milzīgu vērtību IT programmu pārvaldībai un budžeta, kā arī grafika stāvokļa paziņošanai netehniskām iesaistītajām pusēm.
Galvenais izaicinājums: EV (Earned Value) mērīšana programmatūrā
Būvniecībā jūs varat mērīt fizisko progresu (ielieti kubikmetri, ielikti metri). Programmatūrā jūs mērāt neredzamu darbu. Trīs izplatītākās pieejas:
1. Stāstu punkti (Agile EVM)
Scrum vai Kanban vidēs komandas novērtē darbu stāstu punktos (story points). Jūs varat veidot EVM, pamatojoties uz tiem:
- BAC = Kopējie stāstu punkti × vidējā viena stāstu punkta cena
- PV = Stāstu punkti, kurus plānots pabeigt līdz šim sprintam
- EV = Faktiski pabeigtie stāstu punkti × vidējā viena stāstu punkta cena
- AC = Faktiskās komandas izmaksas (algas, infrastruktūra, licences) attiecīgajam periodam
Šī pieeja piešķir vērtību stāstiem tikai tad, kad tie atbilst komandas „Pabeigtības definīcijai” (Definition of Done) — novēršot slazdu „90% pabeigts”.
2. Uz posmiem balstīts EVM (Waterfall)
„Ūdenskrituma” (waterfall) projektiem piešķiriet budžeta svaru posmiem (piemēram, Prasības = 15%, Dizains = 20%, Izstrāde = 40%, Testēšana = 20%, Ieviešana = 5%). Iegūtā vērtība (EV) tiek piešķirta tikai tad, kad katrs posms ir pilnībā pabeigts un pieņemts.
3. Svērtās darba pakotnes
Sadaliet programmatūru funkcionālos moduļos (autentifikācija, atskaites, API, lietotāja saskarne). Novērtējiet katra moduļa izmaksas un ilgumu. Sekojiet pabeigtībai moduļu līmenī. Tā ir vistradicionālākā EVM metode, kas piemērota fiksētas cenas IT līgumiem.
Praktisks piemērs: Programmatūras izstrādes projekts
Pielāgotas CRM sistēmas izstrādes projekts: BAC = $400,000, 8 sprinti (16 nedēļas). Statuss 4. sprintā (8. nedēļa):
- Kopējie stāstu punkti: 800. Vidējā cena par punktu: $500.
- Plānotie stāstu punkti līdz 4. sprintam: 400. PV = 400 × $500 = $200,000
- Faktiski pabeigtie stāstu punkti: 320. EV = 320 × $500 = $160,000
- Faktiskās izmaksas (komandas algas + infrastruktūra): AC = $195,000
SPI = EV ÷ PV = 160,000 ÷ 200,000 = 0.800 (20% atpaliek no plāna)
EAC = BAC ÷ CPI = 400,000 ÷ 0.821 = $487,211
VAC = 400,000 − 487,211 = −$87,211
EVM un Agile: Bieži iebildumi
| Iebildums | Atbilde |
|---|---|
| „Agile nav fiksēta apjoma” | EVM darbojas ar prioritizētu uzdevumu sarakstu (backlog) — BAC atspoguļo saskaņoto izlaiduma (release) apjomu, nevis visu produkta sarakstu. |
| „Prasības mainās katrā sprintā” | Izmantojiet izmaiņu kontroles procesu. Apstiprinātas apjoma izmaiņas atjaunina BAC. Neplānotas izmaiņas ir novirzes, kas jāizmeklē. |
| „Stāstu punktu ātrums (velocity) ir noderīgāks” | Ātrums ir lielisks komandai; EVM sniedz finansiālo redzējumu, kas nepieciešams sponsoriem un vadītājiem. |
| „Mēs neveicam novērtējumu iepriekš” | EVM ir nepieciešams bāzes plāns (baseline). Pat relatīvi novērtēti stāsti var veidot pamatu, ja tos vērtē konsekventi. |
Praktiski padomi IT projektu vadītājiem
- Nosakiet savu BAC pirms sprinta, nevis pēc tā: Bāzes plānam jābūt stabilam, lai EVM būtu nozīmīgs.
- Izmantojiet tikai 0% vai 100% noteikumu nepabeigtiem stāstiem: Izvairieties no daļējas vērtēšanas; tas mākslīgi palielina EV un maskē grafika risku.
- Sekojiet CPI tendencēm katru nedēļu: Programmatūras projekti virzās ātri. Ikmēneša EVM atskaites var pamanīt problēmas pārāk vēlu.
- Atdaliet infrastruktūras/operāciju BAC no izstrādes BAC: Infrastruktūras izmaksām ir citi virzītājspēki, un tās jāseko atsevišķi.
- Izmantojiet EVM programmu līmenī: Ja jums ir vairākas Agile komandas, apvienojiet to EV/AC datus programmas līmenī, lai sniegtu atskaites vadībai.