agile planning with microsoft team foundation server
Denne opplæringen forklarer hvordan du gjør smidig planlegging ved hjelp av Microsoft TFS, som vil hjelpe prosjektledere med å planlegge og spore arbeid på tvers av teamene sine:
Blant de forskjellige artiklene som ble publisert i SoftwareTestingHelp.com på DevOps, har vi sett noen gode artikler om DevOps fra synspunktet om kontinuerlig integrering og kontinuerlig levering ved bruk av Microsoft TFS, AWS og absolutt open source-verktøy som Ansible.
En av forutsetningene for DevOps er en viss sterk prosess som AGILE, som bringer smidighet til hele SDLC-prosessen, hvor fokusområdet er å frigjøre programvare på en veldig tidsriktig måte med kortere utgivelsessykluser og rask tilbakemelding. Så å si den smidige prosessen fokuserer hovedsakelig på hastighet.
Hva du vil lære:
Agil planlegging ved bruk av Microsoft TFS 2017
Før du går gjennom forskjellige seksjoner i denne artikkelen, vil det være greit å bli oppmerksom på noe av det viktige terminologier brukt i Agile. Disse terminologiene vil bli brukt i denne artikkelen.
Forutsetninger: Microsoft TFS 2017
Opprett TFS-teamprosjekt ved hjelp av SCRUM-prosessmal
Vi begynner først med å lage et TFS-teamprosjekt ved hjelp av SCRUM-malen ved å følge trinnene nevnt nedenfor.
Logg deg på Microsoft TFS 2017 og klikk på Nytt prosjekt.
Skriv inn et prosjektnavn og velg Scrum som malen. Klikk på Skape.
Når prosjektet er opprettet, legg til medlemmer i prosjektet ved å klikke på + ikon.
Opprett etterslep
Som du er klar over at Microsoft TFS er et integrert ALM-verktøy som hjelper til med å lage arbeidsartikler, gjør prosjektplanlegging, lager Build-definisjoner og Release Definitions med funksjonen for å utføre manuell testing.
Før noen Agile planlegging, må vi begynne med å definere Sprint som er en forhåndsdefinert tidsramme for arbeidet som skal utføres. Klikk på Innstillinger -> Arbeid og definer deretter sprintene med start- og sluttdatoer.
Velg Sprint og angi start- og sluttdatoer.
Her vil vi fokusere på å lage arbeidselementer som vil utgjøre en integrert del av Agile planlegging. Så la oss begynne med å opprette et produktetterslep som inneholder en prioritert liste over alle funksjoner som skal være en del av applikasjonen eller produktet ditt.
Produkteieren opprettholder dette etterslepet og ved hjelp av scrumteamet bestemmer han muligheten for å jobbe i en bestemt sprint.
For å opprette et produktetterslep fra Arbeidsdel-menyen velg Forsinkelser.
Klikk på Ny, skriv inn en tittel for forsinkelseselementet og klikk på Legg til .
Produktet etterslagt vare legges til etterslaget. I teoretisk forstand kan du vurdere Product Backlog Item som en brukerhistorie eller en endringsforespørsel. De vil normalt bli spaltet i flere utvikleroppgaver og testtilfeller.
hvordan finne nettverkssikkerhetsnøkkel på datamaskinen min
Du kan også bestille på nytt basert på prioritet. Bare dra og slipp arbeidselementene over eller under.
Åpne arbeidselementet og legg til innsatsen. Her kan innsatsen være i henhold til prosjektets behov for historiepoeng eller dager eller timer. Innsatsanslaget vil bli lagt til når varen er spaltet i oppgaver. Tilordne en Eieren i delen 'Assigned To' og sett 'State' til Godkjent for utvikling. Klikk på Lagre og lukk.
Deretter tilordner du elementet til Sprint 1 ved å dra og slippe til Sprint 1.
Iterasjonsstien endrer elementet til Sprint1 som vist i bildet nedenfor.
Når vi flytter varen til Ferdig Stat, hastigheten som definerer det totale antallet historiepoeng som scrum-teamet oppnår i en sprint, vises ved å klikke på det øverste høyre hastighetsdiagrammet.
Så oppsummert kan vi si at teamet har fullført 8 historiepoeng i Sprint 1 som vist i hastighetsdiagrammet ovenfor.
Kapasitetsplanlegging
For hver sprint kan vi definere antall timer hvert medlem skal jobbe for prosjektet som er tildelt. Kapasitetsvisningen for hver sprint definerer dette. Denne visningen fanger også aktiviteten hvert medlem jobber med som design eller utvikling eller rapportering etc.
Klikk på riktig Sprint. I dette tilfellet, åpne Sprint 1 og gå til Kapasitetsvisning . Oppdater som vist nedenfor.
I skjermbildet ovenfor, siden Dev1-bruker bare jobber 4 timer om dagen i løpet av en sprintperiode på 2 uker, som er 10 virkedager. De Arbeid tilordnet viser at han er tilordnet en oppgave som trenger 8 timer å fullføre ut av 40 timer i sprintperioden på 2 uker. Dette beregnes som 4 (timer per dag) * 10 (2 uker) = 40 timer.
En lignende beregning gjøres for Dev2-brukeren.
Opprette oppgaver
Ettersom vi nå har definert Product Backlog Item eller User Story og også kapasitet planlagt for hver bruker i prosjektet, kan vi nå dele den opp i utvikleroppgaver. Klikk på på arbeidsskjermen Sprint 1 og klikk deretter på Legg til oppgaveskilt + for produktets etterslagsvare.
Tilordne den til utvikleren og skriv inn en verdi i timer for det gjenværende arbeidsfeltet. Klikk på Lagre og lukk.
Oppgaven som er opprettet, er koblet til varen på etterslaget.
Her er gjenværende arbeidsfelt antall timer igjen for å fullføre en oppgave. Siden vi i det ovennevnte eksemplet har satt feltet til 8 timer, og la oss si at utvikleren på slutten av en dag bare har fullført 2 timers arbeid med oppgaven, vil den gjenværende timens felt bli oppdatert til 6. Du kan gjøre det 0 når det ikke er mer arbeid, eller hvis det er 1 time eller mindre arbeid igjen eller et sted mellom 0 og 1 time.
Fra denne verdien kan TFS lage et nedbrytningsdiagram for sprinten, som er en av de veldig nyttige beregningene i Agile. Ovennevnte prosess er for SCRUM-malen og har ikke feltet Originalestimat i oppgavens arbeidselement.
Hvis TFS-teamprosjektet er konfigurert ved hjelp av Agile- eller CMMI-prosessmalen, er det et alternativ å gå inn i Original Estimate-feltet.
For å legge til feltet Original estimat ( Microsoft.VSTS.Scheduling.OriginalEstimate ) i oppgaveartypetypen ved hjelp av SCRUM-prosessmal, må den legges til som et egendefinert felt. Du kan bruke witadmin exportwitd , som er et kommandolinjealternativ. Legg til feltet i XML-filen som eksporteres, og importer det tilbake til teamprosjektet.
Fremtidige sprints
Produktet Backlog Element eller User Story kan også planlegges for fremtiden ved å dra og slippe varen til en hvilken som helst annen fremtidig sprint.
Bruke Taskboard
Siden Sprint-planen er på plass, kan vi nå se fremdriften for hver oppgave fra oppgavelinjevisningen. Så Taskboard gir en visuell flyt av oppgavene og statusen. Så under hvert scrummøte kan du se på statusen til hver oppgave som er tildelt medlemmene.
Du kan også se oppsummeringen av det totale gjenværende arbeidet som skal fullføres.
Det er veldig viktig å overvåke status og fremgang, og kan gjøres gjennom oppgavelinjen. Klikk på Styret syn for Sprint.
Dette styret er et veldig nyttig syn og kan brukes til rapporteringsformål under det daglige standupmøtet.
til) Hvis utviklerne med tildelte oppgaver har begynt å jobbe med oppgavene, kan du flytte oppgavene fra Å gjøre stat til I prosess tilstand ved å bare dra og slippe-funksjonen.
b) Endre gjenværende arbeidstid for oppgaven for en Dev2-bruker fra 8 til 5 timer igjen. Oppgavens åpningstider oppdateres deretter.
c) Nedbruddskartet oppdateres automatisk ved å klikke på øverst til høyre.
d) Lukk nå oppgaven som er tildelt Dev2 ved å dra og slippe oppgaven til Ferdig stat. De gjenværende arbeidstidene for denne oppgaven reduseres automatisk til 0, og nedbrekkdiagrammet oppdateres også.
Sprint gjennomgang og retrospektiv
Vel, arbeidet er gjort nå og sprintens tidsramme er over. Tror teamet at det nå er på tide å slappe av eller ta en pause? Absolutt et stort NEI. Tiden er nå å diskutere den svært viktige delen av SCRUM-livssyklusen, som er gjennomgang og tilbakeblikk.
Sprint-gjennomgang fokuserer på leveransen, går gjennom DONE-produktets etterslagsartikler og gir en demo til kundene. Det er også veldig viktig å diskutere hvilke produktforsinkelser som ikke ble gjort, og hvorfor og viktigst av alt samle inn tilbakemeldinger fra kundene og planlegge dem for fremtidige sprints. Sprintgjennomgangen gjøres vanligvis mellom produkteier, utviklingsteam og kunder.
Sprint retrospektiv fokuserer på aspektene av prosessen, som hva som gikk bra og hva ikke? Så du må også fange tilbakemeldinger om prosessen og mennesker også. Siden dette er et veldig viktig aspekt av den smidige livssyklusen, kan du lære mer om det tilbakeblikk.
Så det er veldig mulig at det kan være uferdig arbeid i hver sprint. I dette scenariet flytter du PBI's / Tasks til enten Product Backlog eller til neste Sprint som Product Owner bestemmer.
Men for nå, hvor lagrer vi anmeldelsene og tilbakeblikkene? Du kan lagre dem som en del av arbeidsdiskusjonen eller opprette et nytt arbeidselement for å holde tilbakevendende handlingspunkter og tilbakemeldinger.
kvalitetsanalytiker intervju spørsmål og svar pdf
Konklusjon
Vi har sett i denne artikkelen hvordan Microsoft Team Foundation Server som et ALM-verktøy gir en rask og fin måte å begynne å jobbe med applikasjonen din etter Agile Scrum-prosessen.
Vi må sørge for at alle teamene som følger Agile SCRUM-prosessen, må definere og lage følgende aspekter for å planlegge og styre teamets arbeid riktig.
- Bruk riktig SCRUM-prosessmal i Microsoft TFS
- Lag etterslep i produktet
- Spesifisering av sprintplan og lagkapasitet
- Velge elementer for sprintforsinkelse
- Nedbryter PBI- eller brukerhistorier til oppgaver
- Bruk Burndown-diagrammer for å spore fremgang
- Veldig viktig å bruke Taskboard for å overvåke fremdriften
- Til slutt, gjennomfør en effektiv sprintanmeldelse og retrospektiv
Anbefalt lesing
- Hvordan være et godt team mentor, coach og en ekte team-forsvarer i en smidig testverden? - Inspirasjonen
- Agile And Scrum Terminology: A Glossary For Agile / Scrum Concepts
- Hvordan gjøre smidig estimeringsprosess enkel med planlegging av poker
- Moderne testprinsipper for smidig metodikk i testing
- Selvforsynte Scrum-lag: Hvordan lage et selvforsynt team?
- Agile retrospektive møter - hvorfor det er nødvendig og noen morsomme måter å gjennomføre det på
- 4 trinn mot utvikling av Agile Testing Mindset for vellykket overgang til smidig prosess
- ISTQB Foundation Exam Format & Guidelines To Solve Papers