Darbības joma, dizains, veidošana, pārbaude, piegāde, atvainošanās. Šie ir tradicionālās inženierijas metodikas bieži iestaigātie soļi, ja tos pielieto dzīvsudraba programmatūras projektu pasaulē. Kā programmatūras izstrādātājs jūs, iespējams, labi pārzināt šo "galīgo" sistēmas prasību, kas, šķiet, ir pīle un aust kā balvu cīnītājs. Varbūt jūs esat strādājis pie attīstības projekta tikai tāpēc, lai parādītos mēnešus (vai gadus) vēlāk, lai sastaptos ar klientu, kurš, šķiet, ir pamatīgi vīlies, ka tā patiesās vajadzības nav apmierinātas. Varbūt jūsu vienaudži ir tajā brīdī, kad rūpīgs tālsatiksmes attīstības plāns, kas viņiem iesniegts, ieaudzina tuvojošās liktenes sajūtu. Apakšējā līnija - jūsu komanda ir gatava attīstīties, taču jūsu tradicionālais komandas vadības rīks ir ticis izmantots tradicionālajai komandas vadībai?
Veiklās metodikas var būt vieglas, taču tās ir ļoti disciplinētas. Jebkurš rīks, kas atbalsta jūs ātru piegāžu plānošanā un izsekošanā, izmantojot intīmu klientu sadarbību, var būt vērtīgs papildinājums jūsu arsenālam. Labā ziņa ir tā, ka veiklai komandai tagad ir pieejami vairāki šādi rīki. Šajā rakstā ir sīki aprakstīta reālās pasaules pieredze, kā vadīt veiklu izstrādes komandu, izmantojot vienu no šīs jaunās rīku šķirnes - atvērtā koda XPlanner.
XPlanner ir Java tīmekļa lietojumprogramma, kas izstrādāta, lai atbalstītu komandas vadību atbilstoši galējai programmēšanas metodoloģijai (XP). Tomēr mēs esam atklājuši, ka šis rīks ir pietiekami elastīgs, lai sniegtu vērtīgu atbalstu citām galvenajām veiklajām pieejām (piemēram, Scrum) projekta īstenošanas karstumā. Lai gan tas nav sarežģīts, XPlanner piedāvā ērtu rīku, lai atbalstītu jūsu komandu neatkarīgi no tā, vai esat pieredzējis vai vienkārši sākat darboties ar atjautīgu programmatūras izstrādes pasauli.
Tradicionālie un veiklie komandas vadības rīki
Tradicionālie komandas vadības rīki (piemēram, Microsoft projekts) ir balstīti uz darba sadalījuma struktūrām, kas tālu ieskatās projekta nākotnē. Lai pārvaldītu "kritisko ceļu" līdz galīgajai piegādei, tiek izmantots plānots resursu sadalījums un uzmanīga uzmanība pret dispersiju ar sākotnējo līmeni. Šādu rīku izmantošana nozīmē ievērojamus iepriekšējas plānošanas pasākumus, stingras atkarības no uzdevumiem un stabilu prasību bāzi. Nozīmīgas darbības jomas vai prasību izmaiņas, iespējams, prasīs būtiskas modeļa izmaiņas. Tādējādi šie tradicionālie rīki ir vispiemērotākie, plānojot ceļojumu no A uz B, pieņemot nelielas kursa variācijas. Turpretī veiklie projekti ir orientēti uz izmaiņu sagaidīšanu, nepieņemot, ka B pat būtu galamērķis.
Izprotot veiklā projekta kultūru, ir lietderīgi ņemt vērā veiklās attīstības principus, kurus atbalsta Agile manifesta autori:
- "Indivīdi un mijiedarbība procesos un rīkos
- Darba programmatūra, izmantojot visaptverošu dokumentāciju
- Klientu sadarbība līguma sarunu laikā
Atbildot uz izmaiņām, ievērojot plānu "
(Kents Beks et al., 2001)
Tādējādi veiklie projekti nepārprotami atsakās no ilgtermiņa plānošanas, atbalstot intīmo ieinteresēto personu iesaistīšanos, skaidru koncentrēšanos uz augstas vērtības funkcijām un izmantojamas programmatūras izlaišanu agri un bieži. Pamatmērķis ir vienkārši un efektīvi nodrošināt vērtību pastāvīgu pārmaiņu apstākļos. Lai plānošanas un izsekošanas rīks būtu vērtīgs šajā kontekstā, tam jābūt saskaņotam ar šīm vērtībām.
Projekta plānošana un izsekošana ar XPlanner
XPlanner ir veikls projektu vadības programmatūras rīks, kas pieejams saskaņā ar GNU Mazākās vispārējās publiskās licences licenci (padarot to "bezmaksas, tāpat kā alus, atvērtā koda lingo). Pakete tiek izmantota kā tīmekļa lietojumprogramma, kas ļauj jūsu komandas locekļiem un projekta dalībniekiem iekāpt, izmantojot savas iecienītās tīmekļa pārlūkprogrammas. Pēc konfigurēšanas jūs varēsit plānot un izsekot dažādus sava veiklā projekta piegādes aspektus, izmantojot vienkāršu tīmekļa saskarni.
Būtiski, ka no veiklās perspektīvas projekta dalībnieki var tieši sadarboties, ieguldot savu informāciju kopējā projekta repozitorijā. Šajā sadarbībā klienti var aprakstīt projekta prasības lietotāju stāstu veidā, kurus izstrādātāji izmanto, lai detalizēti aprakstītu un izsekotu uzdevumus, kas nepieciešami, lai šie stāsti kļūtu par realitāti.
Papildus šī līmeņa klientu sadarbības atbalstīšanai XPlanner piedāvā arī citas ērtas funkcijas, kas atbalsta veiklu pieeju. Tie ietver tādas funkcijas kā vienkāršs mehānisms projektu atkārtojumu noteikšanai; intuitīvs interfeiss personām, kas novērtē un izseko centienus; un diagrammas komandas metrikas publicēšanai. XPlanner tiek apspriests šeit, jo tas tika izvietots, lai atbalstītu elektroniskās komercijas un darbplūsmas sistēmas piegādi, kas sastāv no vairākām ieinteresēto personu grupām un septiņu izstrādātāju komandas.
Lejupielāde un instalēšana
XPlanner ir tīra Java lietojumprogramma, kuru var izvietot jebkurā J2SE 1.4 izstrādes vidē, kas aprīkota ar Apache Ant un piemērotu servleta dzinēju. Mēs izvēlējāmies Apache Tomcat kā servleta dzinēju; tomēr tas jādara jebkuram motoram, kas ir saderīgs ar Servlet 2.3 (vai jaunāku versiju). XPlanner tiek piegādāts kā failu arhīvs (zip vai tar.gz), kas pirms rīka izvietošanas un izmantošanas jums ir jāizsaiņo un jāveido.
Ir nepieciešams obligāts konfigurācijas solis, jo jums ir jāiestata iecienītā datu bāze, kas tiks izmantota kā projekta informācijas krātuve. Tā kā XPlanner datu bāzes mijiedarbībai izmanto hibernācijas objekta / relāciju noturības slāni, projekta krātuvē ir iespēja izmantot jebkuru hibernācijas režīmā atbalstītu datu bāzi. Komplektā ir vieglā Java datu bāze Hypersonic (tagad saukta par HSQLDB); tomēr kā krātuves datu bāzi mēs izmantojām Oracle 9i. Lai konfigurētu šo datu bāzi, mums bija jārediģē fails xplanner.properties komentējot jau definētās Oracle īpašības. Mums arī vajadzēja modificēt build.xml failu, lai iekļautu Oracle plānās datu bāzes draiveri. Pēc konfigurēšanas jūs varat izveidot savu XPlanner izvietojumu. Tas ietver Ant izpildīšanu, lai izveidotu izvietojamu tīmekļa arhīvu (WAR) šādi:
skudru instalēšana Izvietojiet iegūto tīmekļa arhīva failu (xplanner.war) uz izvēlēto servletīklu un pēc tam pārlūkojiet vietni URL // your-server: your-port / xplanner / (izmantojot noklusējuma lietotāja "sysadmin" un paroli "admin"), lai pārbaudītu rezultātus!
Integrācija ar savu ekosistēmu
Lielākajā daļā izstrādes vides jau ir kļūdu izsekošanas sistēma, sadarbības forumi, drošības sistēmas, standartu krātuves utt. Lai gan XPlanner vērtība ir noderīga kā atsevišķs rīks, tās vērtību var uzlabot, izmantojot tās vienkāršās un jaudīgās integrācijas funkcijas. XPlanner ietver, piemēram, iespēju atbalstīt izstrādātāja runas atveidošanu apraksta laukā, piemēram, kļūda: 1001 kā saiti uz //mybugzilla/show_bug.cgi?uid=1001. To var izdarīt, vienkārši pievienojot twiki.scheme.bug = // mybugzilla / show_bug.cgi? id = uz xplanner.properties failu. Šo pašu paņēmienu var izmantot citiem tīmekļa rīkiem, piemēram, viewcvs (xplanner.properties rāda dažus citus piemērus). XPlanner ir arī uzlabots wiki formatētājs (netiek izmantots mūsu projektā), kas ļauj automātiski saistīt ar wiki ierakstiem. Plašāku informāciju par XPlanner paplašinājumiem varat atrast vietnē Resursi.
Lielākajā daļā organizāciju vienmēr ar LDAP (viegls direktoriju piekļuves protokols) savietojams direktoriju serveris nodrošina centralizētu lietotāju drošības kontu krātuvi. Piemēram, mūsu projektu sponsorējošajā organizācijā šim nolūkam kalpoja vecmodīgs, bet funkcionāls LDAP serveris (arī Microsoft Active Directory lielā mērā atbalsta LDAP protokolu). Bija atsvaidzinoši atrast XPlanner vienkāršo XPlannerLoginModule viegli integrēt ar LDAP. Tas ietvēra atjaunināšanu xplanner.properties sekojoši:
-> Komentējiet noklusējuma drošību # xplanner.security.login.module = com.technoetic.xplanner.security.XPlannerLoginModule
-> Noņemiet komentārus un rediģējiet LDAP ierakstus no ... xplanner.security.login.module = com.technoetic.xplanner.security.jndi.JNDILoginModule
-> ... uz: xplanner.security.login.option.roleSearch = (unikālsMember = {0})
-> Pievienojiet lietotāju meklēšanas ierakstus xplanner.security.login.option.userBase = ou = cilvēki, o = persona
-> Un izdzēsiet xplanner.security.login.option.userPattern = xplanner.security.login.option.userPassword = vērtības
Ar ātru atjaunošanu un izvietošanu XPlanner autentifikācijas drošība tika pilnībā integrēta. Vienīgais trūkums bija tāds, ka lietotājvārdi joprojām bija nepārprotami jāpievieno XPlanner, taču vismaz paroles un grupas dalības problēmas kļuva par korporatīvās palīdzības dienesta problēmu.
Komanda, iepazīstieties ar XPlanner
XPlanner skata projektu atbilstoši atkārtojumiem, lietotāju stāstiem un uzdevumiem. Kā nosaka Agile paradigma, jebkurš XPlanner pārvaldītais projekts tiek plānots un izsekots atbilstoši secīgām atkārtojumu sērijām. Katrs atkārtojums sastāv no sākuma datuma, beigu datuma un lietotāju stāstu kolekcijas, kas šajā laika posmā tiek veidoti no stāsta līdz realitātei.
Lietotāju stāsts ir galvenais konceptuālais rīks, ko izmanto veiklā izstrādē, lai klienta vajadzības paziņotu programmatūras izstrādātājiem. Kad lietotāja stāsts ir piešķirts pašreizējai iterācijai (kā daļu no laidiena plānošanas, izmantojot XPlanner), izstrādātājs meklē sīkāku informāciju par katru stāstu, sadarbojoties ar lietotāju (cerams, ka klātienē). Šī posma rezultāts ir detalizēta izstrādes uzdevumu virkne, no kuriem katrs izstrādātājs reģistrējas XPlanner, salīdzinot ar attiecīgo lietotāja stāstu.
Mēs izvēlējāmies mūsu e-komercijas darbplūsmas projektu, lai palaistu ar ikmēneša atkārtojumiem, katrs sastāv no apmēram 10 stāstiem, katram stāstam piešķirot 10 līdz 15 uzdevumus.
Lietotāju stāstu ievākšana
Katram projekta atkārtojuma lietotāja stāstam ir jābūt īsam un uz rezultātu orientētam lietotāja pieredzes aprakstam, kā teikts pirmajā personā (piemēram, “Es pēc tam meklēju, pamatojoties uz krāsu ...”). Šo pieredzi ir izveidojis lietotājs, kurš darbībā iedomājas ideālo nākotnes produktu, tāpēc jūs varētu domāt par lietotāja stāstu kā pozitīvu programmatūras vizualizāciju! Katras vizualizācijas mērķis ir nodrošināt pietiekami daudz informācijas programmatūras izstrādātājam, lai novērtētu pūles, kas nepieciešamas, lai šis stāsts kļūtu par realitāti.
XPlanner katalogizē jūsu projekta lietotāju stāstu kolekciju, vienlaikus reģistrējot katra klienta, izsekotāja, prioritātes un piepūles novērtējumu. Galvenās grūtības, kuras mēs bieži atrodam, ir augstas kvalitātes lietotāju stāstu ievākšana no sistēmas lietotāju prāta. Tas noteikti attiecās uz mūsu projektu, jo tā bija ievērojama paradigmas maiņa no stingrās sadaļas / apakšsadaļas prasībām, pie kurām lietotāji bija pieraduši. Tomēr noteikti palīdzēja spēja izmantot XPlanner, lai pārvaldītu stāstus tā, lai ieinteresētās personas tos varētu viegli redzēt un atjaunināt, kā arī lai tos ātri varētu tirgot attiecīgajā atkārtojumā. Viena jauka, ja ne funkcionāla XPlanner iezīme ir autentiska izjūta, kas sniedz lietotāja stāstu, katru no tām ekrānā parādot kā līdzīgu 3 līdz 5 indeksu karti, kā parādīts 1. attēlā.
Novērtējiet un reģistrējiet piepūli
Veiklā attīstība nosaka, ka izstrādātāji paši nosaka mērķus, kas ietver lietotāja stāsta analīzi un šī stāsta realizēšanai nepieciešamo tehnisko uzdevumu noteikšanu. Izstrādātājam vajadzētu būt brīvam pievienot papildu uzdevumus vai modificēt esošos uzdevumus, kad kļūst pieejama sīkāka stāsta informācija. XPlanner atbalsta šo elastību, nodrošinot izstrādātājiem pilnīgu piekļuvi uzdevuma definēšanai un rediģēšanai. Katram uzdevumam var piešķirt tipu, piemēram, parāds, pazīme vai defekts, lai raksturotu veicamā darba veidu (piemēram, parāds ir uzdevums, lai attīrītu tehnisko "kropli", kas sistēmā palicis no iepriekšējās iterācijas). Uzdevumi tiek norādīti arī ar izkārtojumu (plānotu vai neplānotu), pieņemošo izstrādātāju, darba aprakstu un aptuveno ideālo stundu skaitu, kas nepieciešami šī uzdevuma uzvarēšanai.
XPlanner ļauj izstrādātājam viegli reģistrēt, cik daudz darba ir ieguldīts dotajā uzdevumā, vai atjaunināt sākotnējo piepūles tāmi (oriģināls joprojām tiek saglabāts). Ņemiet vērā, ka piepūles novērtējums, kā minēts, būtu jānorāda ideāls stundas. Ideāla stunda ir stunda, kurā izstrādātājs neizjūt absolūtus pārtraukumus.
Izstrādātājiem arī jāreģistrē to ideālo stundu skaits, ko viņi iegulda konkrētā uzdevuma izpildē. Ja jūs mudināsiet savus izstrādātājus godīgi ierakstīt ideālas stundas (neprasot zināt, kurp iet laiks), jūs varēsiet iegūt dažus noderīgus rādītājus no XPlanner (aplūkots turpmāk). Mēs, piemēram, konstatējām, ka mūsu projekta ideālas stundas sasniegšana prasīja apmēram 1,4 stundas. Pēc tam šo informāciju var izmantot, lai sniegtu precīzu novērtējumu nākamajām atkārtojumiem - kas palīdz izpildīt komandas solījumus un klienta cerības vienā un tajā pašā bumbas laukumā.
Metrika un nākamās atkārtošanas plānošana
Jūs esat iterācijas vidū un boss vēlas zināt, "kā mēs meklējam". Labi nodilusi atbilde uz šo jautājumu ir "Mēs esam apmēram 80 procenti no tā." Protams, šķiet, ka pēdējie 20 procenti vienmēr prasa daudz vairāk laika, nekā vajadzētu - pēdējie 20 procenti ir programmatūras ekvivalents blāvajiem dārzeņiem vakariņās, kurus jūs atstājāt līdz pēdējam.
