Anvendelsesområde, design, opbyg, test, lever, undskyld. Dette er de ofte trampede trin i en traditionel ingeniørmetode, når de anvendes til den mercurial verden af softwareprojekter. Som softwareudvikler er du sandsynligvis godt bekendt med det "endelige" systemkrav, der ser ud til at dukke og væve som en præmiekæmper. Måske har du arbejdet på et udviklingsprojekt kun for at dukke op måneder (eller år) senere for at møde en kunde, der synes dybt skuffet over, at dens reelle behov ikke er opfyldt. Måske er dine jævnaldrende på det punkt, hvor en omhyggelig langtidsudviklingsplan, der er placeret foran dem, indgyder en følelse af forestående undergang. Bundlinjen — dit team er klar til at gå med agil udvikling, men er dit traditionelle teamledelsesværktøj blevet fastgjort til traditionel teamledelse?
De smidige metoder kan være lette, men de er meget disciplinerede. Ethvert værktøj, der understøtter dig i planlægning og sporing af hurtige leverancer med intimt kundesamarbejde, kan udgøre en værdifuld tilføjelse til dit arsenal. Den gode nyhed er, at adskillige sådanne værktøjer nu er tilgængelige for det agile team. Denne artikel beskriver en oplevelse fra den virkelige verden med at styre et agilt udviklingsteam ved hjælp af en af denne nye race af værktøjer, open source XPlanner.
XPlanner er en Java-webapplikation designet til at understøtte teamadministration i henhold til den ekstreme programmeringsmetode (XP). Vi har imidlertid fundet dette værktøj til at være fleksibelt nok til at yde værdifuld støtte til andre mainstream agile tilgange (fx Scrum) i varmen fra projektlevering. Selvom det ikke er sofistikeret, giver XPlanner et praktisk værktøj til at støtte dit team, uanset om du har erfaring med eller bare starter i den givende verden inden for agil softwareudvikling.
Traditionelle vs agile teamledelsesværktøjer
Traditionelle værktøjer til teamadministration (såsom Microsofts projekt) er baseret på arbejdsopdelingsstrukturer, der ser langt ind i et projekts fremtid. Planlagt allokering af ressourcer og et nøje øje med variansen til baseline bruges til at styre den "kritiske vej" til den endelige levering. Anvendelsen af sådanne værktøjer indebærer en betydelig planlægningsindsats på forhånd, stive opgaveafhængigheder og en stabil base af krav. Væsentlige ændringer i anvendelsesområdet eller kravene vil sandsynligvis kræve betydelige ændringer af modellen. Disse traditionelle værktøjer er således mest hensigtsmæssige, når man planlægger en rejse fra A til B, forudsat at der kun er lidt variation i kurset. I modsætning hertil er agile projekter gearet til at forvente forandring og antager ikke, at B engang skal være den endelige destination.
For at forstå kulturen i det agile projekt er det nyttigt at overveje principperne om agil udvikling, som de foreslog af forfatterne af Agile Manifesto:
- "Individer og interaktioner over processer og værktøjer
- Arbejder software over omfattende dokumentation
- Kundesamarbejde over kontraktforhandling
Svar på at skifte efter en plan "
(Kent Beck et al., 2001)
Agile projekter opgiver således eksplicit langvarig planlægning til fordel for intimt engagement fra interessenter, klart fokus på funktioner af høj værdi og frigivelse af brugbar software tidligt og ofte. Det bagvedliggende mål er at levere enkelt og effektivt værdi i lyset af konstant forandring. For at et planlægnings- og sporingsværktøj kan være værdifuldt i denne sammenhæng, skal det være i overensstemmelse med disse værdier.
Projektplanlægning og sporing med XPlanner
XPlanner er et agilt projektstyringssoftwareværktøj, der er tilgængeligt under GNU Lesser General Public License (gør det "gratis som i øl" i open source lingo). Pakken implementeres som en webapplikation, som giver dine teammedlemmer og projektinteressenter mulighed for at komme ombord ved hjælp af deres yndlingswebbrowsere. Når du er konfigureret, vil du være i stand til at planlægge og spore forskellige aspekter af dit smidige projekts levering via en simpel webgrænseflade.
Afgørende for det agile perspektiv er projektdeltagere i stand til direkte at samarbejde ved at bidrage med deres information til det fælles projektlager. Dette samarbejde kan involvere kunder, der beskriver projektkrav i form af brugerhistorier, som udviklere derefter bruger til at specificere og spore de opgaver, der kræves for at gøre disse historier til virkelighed.
Ud over at understøtte dette niveau af kundesamarbejde tilbyder XPlanner andre praktiske funktioner, der understøtter den agile tilgang. Disse inkluderer funktioner såsom en simpel mekanisme til at definere projekt iterationer; en intuitiv grænseflade til enkeltpersoner, der estimerer og sporer indsats; og diagrammer til publicering af team-metrics. XPlanner diskuteres her, da den blev implementeret til at understøtte leveringen af et elektronisk handels- og workflow-system bestående af flere interessentgrupper og et team på syv udviklere.
Download og installation
XPlanner er et rent Java-program, der kan implementeres i ethvert J2SE 1.4-udviklingsmiljø udstyret med Apache Ant og en passende servletmotor. Vi valgte Apache Tomcat som servletmotor; dog skal enhver motor, der er kompatibel med Servlet 2.3 (eller en nyere version) gøre. XPlanner sendes som et filarkiv (zip eller tar.gz), som du skal pakke ud og bygge, inden du implementerer og bruger værktøjet.
Et obligatorisk konfigurationstrin er involveret, da du skal konfigurere din yndlingsdatabase, der skal bruges som lager for projektinformation. Da XPlanner bruger Hibernate-objektet / relationelt persistenslag til databaseinteraktion, har du mulighed for at bruge en hvilken som helst Hibernate-understøttet database til dit projektlager. Den medfølgende mulighed er den lette Java-database Hypersonic (nu kaldet HSQLDB); dog brugte vi Oracle 9i som vores database. For at konfigurere denne database måtte vi redigere filen xplanner.egenskaber ved at kommentere de allerede definerede Oracle-egenskaber. Vi havde også brug for at ændre build.xml fil til at inkorporere Oracle tynd databasedriver. Når du er konfigureret, kan du opbygge din XPlanner-implementering. Dette involverer udførelse af Ant for at producere et implementerbart webarkiv (WAR) som følger:
ant install.db.schema ant build.war Implementér den resulterende webarkivfil (xplanner.war) til din valgte servletmotor, og søg derefter til URL // din-server: din-port / xplanner / (ved hjælp af standardbruger "sysadmin" og adgangskode "admin") for at inspicere resultaterne!
Integrering med dit økosystem
De fleste udviklingsmiljøer indeholder allerede et bugsporingssystem, samarbejdsfora, sikkerhedssystemer, standardopbevaringssteder osv. Selvom det er nyttigt som et enkeltstående værktøj, kan XPlanners værdi forbedres via dets enkle og kraftfulde integrationsfunktioner. XPlanner inkluderer for eksempel muligheden for at understøtte gengivelse af udvikler tale i et beskrivelsesfelt, såsom fejl: 1001 som et link til //mybugzilla/show_bug.cgi?uid=1001. Dette kan gøres ved blot at tilføje twiki.scheme.bug = // mybugzilla / show_bug.cgi? id = til xplanner.egenskaber fil. Den samme teknik kan bruges til andre webbaserede værktøjer som f.eks viewcvs (xplanner.egenskaber viser nogle andre eksempler). XPlanner har også en avanceret wiki-formatering (bruges ikke i vores projekt), der muliggør automatisk linkning til wiki-poster. Flere oplysninger om XPlanner-udvidelser kan findes i Ressourcer.
I de fleste organisationer leverer altid en form for LDAP (letvægts biblioteksadgangsprotokol) -kompatibel biblioteksserver et centraliseret lager med brugersikkerhedskonti. For eksempel inden for den organisation, der sponsorerer vores projekt, tjente en gammeldags, men funktionel LDAP-server dette formål (Microsofts Active Directory understøtter også stort set LDAP-protokollen). Det var forfriskende at finde XPlanners enkle XPlannerLoginModule let at integrere med LDAP. Dette involverede opdatering xplanner.egenskaber som følger:
-> Kommenter standardsikkerhed # xplanner.security.login.module = com.technoetic.xplanner.security.XPlannerLoginModule
-> Fjern kommentar og rediger LDAP-poster fra ... xplanner.security.login.module = com.technoetic.xplanner.security.jndi.JNDILoginModule
-> ... til: xplanner.security.login.option.roleSearch = (unikMember = {0})
-> Tilføj brugersøgeposter xplanner.security.login.option.userBase = ou = personer, o = person
-> Og blanke værdier for xplanner.security.login.option.userPattern = xplanner.security.login.option.userPassword =
Med en hurtig genopbygning og implementering var XPlanner-godkendelsessikkerhed fuldt integreret. Den eneste ulempe var, at brugernavne stadig skulle tilføjes eksplicit til XPlanner, men i det mindste blev besvær med adgangskoder og gruppemedlemskaber problematikken med virksomhedens helpdesk.
Hold, mød XPlanner
XPlanner ser et projekt i henhold til iterationer, brugerhistorier og opgaver. Som foreskrevet af Agile-paradigmet planlægges og spores ethvert XPlanner-styret projekt i henhold til en række række iterationer. Hver iteration består af en startdato, en slutdato og en samling brugerhistorier, der skal konstrueres fra historie til virkelighed inden for denne tidsramme.
En brugerhistorie er det vigtigste konceptuelle værktøj, der bruges i agil udvikling til at kommunikere kundebehov til softwareudviklere. Når en brugerhistorie er tildelt en aktuel iteration (som en del af frigivelsesplanlægning via XPlanner), søger udvikleren yderligere detaljer for hver historie ved at samarbejde med brugeren (forhåbentlig ansigt til ansigt). Dette trins resultat er en detaljeret serie af udviklingsopgaver, som hver udvikler registrerer i XPlanner mod den relevante brugerhistorie.
Vi valgte vores e-handels-workflow-projekt til at køre med månedlige iterationer, der hver består af omkring 10 historier med 10 til 15 opgaver, der er tildelt hver historie.
Høstning af brugerhistorier
Hver brugerhistorie til en projekt iteration skal være en kort og resultatorienteret beskrivelse af en brugeroplevelse som fortalt i den første person (f.eks. "Jeg søger derefter ud fra farve ..."). Denne oplevelse er skrevet af en bruger, der forestiller sig det ideelle fremtidige produkt i aktion, så du kan tænke på en brugerhistorie som positiv visualisering til software! Målet med hver visualisering er at give tilstrækkelig information til en softwareudvikler til at estimere den krævede indsats for at gøre historien til virkelighed.
XPlanner katalogiserer dit projekts samling af brugerhistorier, mens du registrerer et kunde-, tracker-, prioritets- og indsatsestimat i forhold til hver enkelt. Det største problem, vi ofte finder, er høsten af brugerhistorier af høj kvalitet fra systembrugernes sind. Dette var bestemt tilfældet for vores projekt, da det var et betydeligt paradigmeskift fra de stive sektion / underafdelingskrav, som brugerne var vant til. Evnen til at bruge XPlanner til at styre historier, så de let kunne ses og opdateres af interessenter og hurtigt kunne handles ind og ud af en given iteration, hjalp dog bestemt. En god, hvis ikke funktionel, funktion i XPlanner er den autentiske fornemmelse, det giver en brugerhistorie, der viser hver på skærmen som et 3-til-5-indekskort, der ligner hinanden, som vist i figur 1.
Anslå og registrer indsats
Agil udvikling foreskriver, at udviklere foretager deres egne målindstillinger, hvilket indebærer at analysere en brugerhistorie og definere de tekniske opgaver, der kræves for at realisere historien. En udvikler skal være fri til at tilføje yderligere opgaver eller ændre eksisterende opgaver, når yderligere historieoplysninger bliver tilgængelige. XPlanner understøtter denne fleksibilitet ved at give udviklere fuld adgang til at definere og redigere en opgave. Hver opgave kan tildeles en type, såsom gæld, funktion eller mangel, for at karakterisere den type arbejde, der udføres (gæld er for eksempel en opgave til rengøring af teknisk "cruft", der er tilbage i systemet fra en tidligere iteration). Opgaver specificeres også med en disposition (planlagt eller ikke planlagt), den accepterende udvikler, en arbejdsbeskrivelse og et skøn over antallet af ideelle timer, der kræves for at erobre den opgave.
XPlanner gør det let for en udvikler at registrere, hvor meget arbejde der er investeret i en given opgave eller at opdatere det oprindelige indsatsestimat (originalen er stadig gemt). Bemærk, at anslåede anstrengelser, som nævnt, skal specificeres i ideel timer. En ideel time er en time, hvor udvikleren absolut ikke oplever afbrydelser.
Udviklere skal også registrere antallet af ideelle timer, de investerer i forhold til en given opgave. Hvis du opfordrer dine udviklere til ærligt at registrere ideelle timer (ved ikke at kræve at vide, hvor tiden går), vil du være i stand til at udtrække nogle nyttige målinger fra XPlanner (diskuteret nedenfor). Vi fandt for eksempel, at det på vores projekt tog cirka 1,4 forløbne timer at nå en ideel time. Disse oplysninger kan derefter bruges til at give et raffineret estimat for efterfølgende iterationer - hvilket hjælper med at holde holdets løfter og kundens forventninger i samme ballpark.
Metrics og planlægning for den næste iteration
Du er midtvejs i en iteration, og chefen vil vide "hvordan vi ser ud." Et godt slidt svar på dette spørgsmål er "Vi er omkring 80 procent af vejen derhen." Selvfølgelig ser den sidste 20 procent altid ud til at tage meget længere tid, end den burde - de sidste 20 procent er softwareækvivalenten til de kedelige grøntsager til middag, som du forlod indtil sidst.
