Omfang, design, bygge, teste, levere, beklager. Dette er de ofte tråkkede trinnene i en tradisjonell ingeniørmetodikk når den brukes på den mercurial verdenen av programvareprosjekter. Som programvareutvikler er du sannsynligvis godt kjent med det "endelige" systemkravet som ser ut til å dukke og veve som en premiekjemper. Kanskje du har slitt på et utviklingsprosjekt bare for å dukke opp måneder (eller år) senere for å møte en kunde som virker dypt skuffet over at de reelle behovene ikke har blitt oppfylt. Kanskje er jevnaldrende på det punktet hvor en grundig langtrekkende utviklingsplan som er plassert foran dem, gir en følelse av forestående undergang. Ergo - teamet ditt er klar til å gå med smidig utvikling, men har det tradisjonelle teamledelsesverktøyet blitt hardt koblet til tradisjonell teamledelse?
De smidige metodene kan være lette, men de er svært disiplinerte. Ethvert verktøy som støtter deg i planlegging og sporing av raske leveranser med intimt kundesamarbeid, kan gjøre et verdifullt tillegg til arsenalet ditt. Den gode nyheten er at flere slike verktøy nå er tilgjengelig for det smidige teamet. Denne artikkelen beskriver en opplevelse fra den virkelige verden med å administrere et smidig utviklingsteam ved hjelp av en av denne nye typen verktøy, åpen kildekode XPlanner.
XPlanner er et Java-webapplikasjon designet for å støtte teamadministrasjon i henhold til ekstrem programmeringsmetodikk (XP). Vi har imidlertid funnet at dette verktøyet er fleksibelt nok til å gi verdifull støtte til andre vanlige smidige tilnærminger (f.eks. Scrum) i varmen fra prosjektlevering. Selv om det ikke er sofistikert, gir XPlanner et praktisk verktøy for å støtte teamet ditt, enten du er erfaren med eller bare starter i den givende verdenen av smidig programvareutvikling.
Tradisjonelle mot smidige teamledelsesverktøy
Tradisjonelle verktøy for teamadministrasjon (for eksempel Microsofts Project) er basert på arbeidsnedbrytningsstrukturer som ser langt inn i prosjektets fremtid. Planlagt tildeling av ressurser og et nøye øye med avvik til baseline brukes til å styre den "kritiske banen" til endelig levering. Anvendelsen av slike verktøy innebærer betydelige planleggingsinnsatser, stive avhengighetsoppgaver og en stabil base av krav. Betydelige endringer i omfang eller krav vil sannsynligvis kreve betydelige endringer i modellen. Dermed er disse tradisjonelle verktøyene mest hensiktsmessige når du planlegger en reise fra A til B, forutsatt liten variasjon i kurset. I motsetning til dette er smidige prosjekter rettet mot å forvente endring, og antar ikke at B engang skal være den endelige destinasjonen.
For å forstå kulturen i det smidige prosjektet er det nyttig å vurdere prinsippene for smidig utvikling som foreslo av forfatterne av Agile Manifesto:
- "Individer og interaksjoner over prosesser og verktøy
- Arbeidsprogramvare over omfattende dokumentasjon
- Kundesamarbeid over kontraktsforhandlinger
Svar på endring etter en plan "
(Kent Beck et al., 2001)
Dermed forlater smidige prosjekter eksplisitt langsiktig planlegging til fordel for intimt interessentengasjement, tydelig fokus på funksjoner med høy verdi og utgivelse av brukbar programvare tidlig og ofte. Det underliggende målet er å enkelt og effektivt levere verdi i møte med konstant forandring. For at et planleggings- og sporingsverktøy skal være verdifullt i denne sammenhengen, må det være i samsvar med disse verdiene.
Prosjektplanlegging og sporing med XPlanner
XPlanner er et smidig programvareverktøy for prosjektledelse tilgjengelig under GNU Lesser General Public License (gjør det "gratis, som i øl", i åpen kildekode-lingo). Pakken distribueres som et webapplikasjon, som lar teammedlemmene og prosjektinteressentene komme ombord ved å bruke favorittnettleserne. Når du er konfigurert, vil du kunne planlegge og spore forskjellige aspekter av det smidige prosjektets levering via et enkelt webgrensesnitt.
Avgjørende, fra det smidige perspektivet, er prosjektdeltakere i stand til å samarbeide direkte ved å bidra med informasjonen sin i det felles prosjektregisteret. Dette samarbeidet kan involvere kunder som beskriver prosjektkrav i form av brukerhistorier, som utviklere deretter bruker til å detaljere og spore oppgavene som kreves for å gjøre disse historiene til virkelighet.
I tillegg til å støtte dette nivået av kundesamarbeid, gir XPlanner andre nyttige funksjoner som støtter den smidige tilnærmingen. Disse inkluderer funksjoner som en enkel mekanisme for å definere prosjektgjentakelser; et intuitivt grensesnitt for enkeltpersoner som estimerer og sporer innsats; og diagrammer for publisering av teamberegninger. XPlanner blir diskutert her da den ble distribuert for å støtte levering av et elektronisk handels- og arbeidsflytsystem bestående av flere interessentgrupper og et team på syv utviklere.
Laste ned og installere
XPlanner er et rent Java-program som kan distribueres i ethvert J2SE 1.4-utviklingsmiljø utstyrt med Apache Ant og en passende servletmotor. Vi valgte Apache Tomcat som servletmotor; Imidlertid bør enhver motor som er kompatibel med Servlet 2.3 (eller en nyere versjon) gjøre det. XPlanner sendes som et filarkiv (zip eller tar.gz) som du må pakke ut og bygge før du distribuerer og bruker verktøyet.
Et obligatorisk konfigurasjonstrinn er involvert, ettersom du trenger å konfigurere favorittdatabasen din som skal brukes som lager for prosjektinformasjon. Da XPlanner bruker Hibernate-objektet / relasjonelt vedvarende lag for databaseinteraksjon, har du muligheten til å bruke en hvilken som helst Hibernate-støttet database for prosjektdatabasen. Det medfølgende alternativet er den lette Java-databasen Hypersonic (nå kalt HSQLDB); Imidlertid brukte vi Oracle 9i som vår database. For å konfigurere denne databasen måtte vi redigere filen xplanner.properties ved å kommentere de allerede definerte Oracle-egenskapene. Vi trengte også å endre build.xml fil for å innlemme Oracle tynn databasedriver. Når du er konfigurert, kan du bygge XPlanner-distribusjonen din. Dette innebærer å utføre Ant for å produsere et distribuerbart webarkiv (WAR) som følger:
maurinstallasjon.db.skjema maurbygg.krig Distribuer den resulterende nettarkivfilen (xplanner.war) til servletmotoren du velger, og bla deretter til URL // din server: din-port / xplanner / (ved hjelp av standardbruker "sysadmin" og passord "admin") for å inspisere resultatene!
Integrering med økosystemet ditt
De fleste utviklingsmiljøer inneholder allerede et bugsporingssystem, samarbeidsfora, sikkerhetssystemer, standardregister osv. Selv om det er nyttig som et frittstående verktøy, kan XPlanners verdi forbedres via enkle og kraftige integrasjonsfunksjoner. XPlanner inkluderer for eksempel muligheten til å støtte gjengivelse av utviklerens tale i et beskrivelsesfelt, for eksempel feil: 1001 som en lenke til //mybugzilla/show_bug.cgi?uid=1001. Dette kan gjøres ved å bare legge til twiki.scheme.bug = // mybugzilla / show_bug.cgi? id = til xplanner.properties fil. Den samme teknikken kan brukes til andre nettbaserte verktøy som viewcvs (xplanner.properties viser noen andre eksempler). XPlanner har også en avansert wiki-formatering (brukes ikke på prosjektet vårt) som tillater automatisk lenking til wiki-oppføringer. Mer informasjon om XPlanner-utvidelser finner du i Resources.
I de fleste organisasjoner gir alltid en eller annen form for LDAP (lettvekt katalogadgangsprotokoll) -kompatibel katalogserver et sentralisert lager med brukernes sikkerhetskontoer. For eksempel, i organisasjonen som sponser prosjektet vårt, tjente en gammeldags, men funksjonell LDAP-server dette formålet (Microsofts Active Directory støtter også i stor grad LDAP-protokollen). Det var forfriskende å finne XPlanners enkle XPlannerLoginModule enkel å integrere med LDAP. Dette innebar oppdatering xplanner.properties som følger:
-> Kommenter standard sikkerhet # xplanner.security.login.module = com.technoetic.xplanner.security.XPlannerLoginModule
-> Fjern kommentar og rediger LDAP-oppføringene fra ... xplanner.security.login.module = com.technoetic.xplanner.security.jndi.JNDILoginModule
-> ... til: xplanner.security.login.option.roleSearch = (unikMember = {0})
-> Legg til brukeroppføringer xplanner.security.login.option.userBase = ou = personer, o = person
-> Og blanke verdier for xplanner.security.login.option.userPattern = xplanner.security.login.option.userPassword =
Med en rask ombygging og distribusjon var XPlanner-autentiseringssikkerhet fullt integrert. Den eneste ulempen var at brukernavn fremdeles måtte legges eksplisitt til XPlanner, men i det minste ble problemer med passord og gruppemedlemskap problem for bedriftens kundeservice.
Team, møt XPlanner
XPlanner viser et prosjekt i henhold til iterasjoner, brukerhistorier og oppgaver. Som foreskrevet av Agile-paradigmet, planlegges og spores ethvert XPlanner-administrert prosjekt i henhold til en påfølgende serie iterasjoner. Hver iterasjon består av en startdato, en sluttdato og en samling brukerhistorier som skal konstrueres fra historie til virkelighet innen den tidsrammen.
En brukerhistorie er det viktigste konseptuelle verktøyet som brukes i smidig utvikling for å kommunisere kundebehov til programvareutviklere. Når en brukerhistorie er tilordnet en gjeldende iterasjon (som en del av utgivelsesplanlegging via XPlanner), søker utvikleren ytterligere detaljer for hver historie ved å samarbeide med brukeren (forhåpentligvis ansikt til ansikt). Dette trinnets utfall er en detaljert serie med utviklingsoppgaver, som hver utvikler registrerer i XPlanner mot den aktuelle brukerhistorien.
Vi valgte vårt arbeidsflytprosjekt for e-handel for å kjøre med månedlige iterasjoner, hver bestående av rundt 10 historier, med 10 til 15 oppgaver tildelt hver historie.
Høsting av brukerhistorier
Hver brukerhistorie for en prosjekt-iterasjon bør være en kort og resultatfokusert beskrivelse av en brukeropplevelse som fortalt i første person (f.eks. "Jeg søker deretter basert på farge ..."). Denne opplevelsen er skrevet av en bruker som ser for seg det ideelle fremtidige produktet i aksjon, så du kan tenke på en brukerhistorie som positiv visualisering for programvare! Målet med hver visualisering er å gi nok informasjon til at en programvareutvikler kan estimere den innsatsen som kreves for å gjøre historien til virkelighet.
XPlanner katalogiserer prosjektets samling av brukerhistorier, mens du registrerer en kunde, tracker, prioritet og anstrengelsesestimat mot hver enkelt. Den største vanskeligheten vi ofte finner er høsting av brukerhistorier av høy kvalitet fra hodet til systembrukere. Dette var absolutt tilfelle for prosjektet vårt, da det var et betydelig paradigmeskifte fra de stive delen / underavsnittene brukerne var vant til. Muligheten til å bruke XPlanner til å administrere historier slik at de lett kunne sees og oppdateres av interessenter, og for å bli raskt handlet inn og ut av en gitt iterasjon, hjalp imidlertid absolutt. En fin, om ikke funksjonell funksjon av XPlanner, er den autentiske følelsen det gir en brukerhistorie, og viser hver på skjermen som et 3-for-5-indekskort, som vist i figur 1.
Anslå og registrer innsatsen
Agil utvikling foreskriver at utviklere foretar sin egen målinnstilling, som innebærer å analysere en brukerhistorie og definere de tekniske oppgavene som kreves for å realisere den historien. En utvikler bør være fri til å legge til flere oppgaver eller endre eksisterende oppgaver når ytterligere historiedetaljer blir tilgjengelige. XPlanner støtter denne fleksibiliteten ved å gi utviklere full tilgang for å definere og redigere en oppgave. Hver oppgave kan tildeles en type, for eksempel gjeld, funksjon eller mangel, for å karakterisere hva slags arbeid som utføres (gjeld er for eksempel en oppgave for rengjøring av teknisk "cruft" som er igjen i systemet fra en tidligere iterasjon). Oppgaver er også spesifisert med en disposisjon (planlagt eller ikke planlagt), den aksepterende utvikleren, en arbeidsbeskrivelse og et estimat på antall ideelle timer som kreves for å erobre den oppgaven.
XPlanner gjør det enkelt for en utvikler å registrere hvor mye arbeid som er investert i en gitt oppgave eller å oppdatere det opprinnelige anslagsoverslaget (originalen er fortsatt lagret). Vær oppmerksom på at anstrengelsesestimater, som nevnt, bør spesifiseres i ideell timer. En ideell time er en time der utvikleren opplever absolutt ingen forstyrrelser.
Utviklere bør også registrere antall ideelle timer de investerer mot en gitt oppgave. Hvis du oppmuntrer utviklerne dine til å ærlig registrere ideelle timer (ved ikke å kreve å vite hvor tiden går), vil du kunne hente ut noen nyttige beregninger fra XPlanner (omtalt nedenfor). Vi fant for eksempel at det på vårt prosjekt tok en ideell time omtrent 1,4 timer å oppnå. Denne informasjonen kan deretter brukes til å gi raffinert estimering for etterfølgende iterasjoner - som hjelper til å holde lagets løfter og kundens forventninger i samme ballpark.
Målinger og planlegging for neste iterasjon
Du er midt i en iterasjon og sjefen vil vite "hvordan vi ser ut." Et godt slitt svar på dette spørsmålet er "Vi er omtrent 80 prosent av veien dit." Selvfølgelig ser det ut til at de siste 20 prosent alltid tar mye lengre tid enn det burde - de siste 20 prosentene er programvareekvivalenten til de kjedelige grønnsakene til middagen du forlot til sist.
