agile planning with microsoft team foundation server
Denne vejledning forklarer, hvordan man laver Agile Planning ved hjælp af Microsoft TFS, som vil hjælpe projektledere med at planlægge og spore arbejde på tværs af deres teams:
Blandt de forskellige artikler, der er offentliggjort i SoftwareTestingHelp.com på DevOps, har vi set nogle gode artikler om DevOps med henblik på kontinuerlig integration og kontinuerlig levering ved hjælp af Microsoft TFS, AWS og bestemt open source-værktøjer som Ansible.
En af forudsætningerne for DevOps er en bestemt stærk proces som AGILE, der bringer smidighed til hele SDLC-processen, hvor fokusområdet er at frigive software på en meget rettidig måde med kortere frigivelsescyklusser og hurtig feedback. Så at sige den agile proces fokuserer hovedsageligt på hastighed.
Hvad du vil lære:
Agil planlægning ved hjælp af Microsoft TFS 2017
Før du gennemgår forskellige sektioner i denne artikel, ville det være godt at blive opmærksom på nogle af de vigtige terminologier, der bruges i Agile. Disse terminologier vil blive brugt overalt i denne artikel.
Forudsætninger: Microsoft TFS 2017
Opret TFS-teamprojekt ved hjælp af SCRUM-processkabelon
Vi starter først med at oprette et TFS-teamprojekt ved hjælp af SCRUM-skabelonen ved at følge nedenstående trin.
Log ind på Microsoft TFS 2017, og klik på Nyt projekt.
Indtast et projektnavn, og vælg Scrum som skabelon. Klik på Skab.
Når projektet er oprettet, skal du tilføje medlemmer til projektet ved at klikke på + ikon.
Opret produktbacklog
Som du er klar over, at Microsoft TFS er et integreret ALM-værktøj, der hjælper med at oprette arbejdsgenstande, skal du lave projektplanlægning, oprette builddefinitioner og frigive definitioner med funktionen til at udføre manuel test.
Før enhver agil planlægning skal vi starte med at definere Sprints hvilket er en foruddefineret tidsramme for det arbejde, der skal udføres. Klik på Indstillinger -> Arbejde og definer derefter sprints med start- og slutdatoer.
Vælg Sprint, og indstil start- og slutdatoer.
Her vil vi fokusere på at skabe arbejdsemner, der vil udgøre en integreret del af Agile planlægning. Så lad os starte med at oprette et produktbakke, der indeholder en prioriteret liste over alle funktioner, der skal være en del af din applikation eller dit produkt.
Produktejeren fastholder dette efterslæb og med hjælp fra scrumteamet beslutter han muligheden for at arbejde i en bestemt sprint.
For at oprette et produktforsinkelse fra Arbejdssektionsmenuen vælger Backlogs.
Klik på Ny, indtast en titel til backlog-elementet, og klik på Tilføje .
Produktet Backlog Item føjes til backloget. I teoretisk forstand kan du overveje Product Backlog Item som en brugerhistorie eller en ændringsanmodning. De nedbrydes normalt i flere udvikleropgaver og testsager.
softwareudvikler i spørgsmål til testinterview
Du kan også genbestille baseret på prioritet. Træk og slip bare arbejdspunkterne over eller under.
Åbn arbejdsemnet, og tilføj indsatsen. Her kan indsatsen være som i projektets behov for enten historiepunkter eller dage eller timer. Indsatsoverslaget tilføjes, når varen nedbrydes i opgaver. Tildel en ejer i afsnittet 'Tildelt til' og indstil 'Staten' til godkendt til udvikling. Klik på Gem og luk.
Dernæst tildel elementet til Sprint 1 ved at trække og slippe til Sprint 1.
Iterationsstien ændrer elementet til Sprint1 som vist i nedenstående billede.
Når vi flytter varen til Færdig Tilstand, hastigheden, der definerer det samlede antal historiepunkter, som scrum-holdet opnår i en sprint, vises ved at klikke på det øverste højre hastighedsdiagram.
hvordan man åbner apk-filer på windows
Så alt sammen kan vi sige, at holdet har afsluttet 8 historiepoint i Sprint 1 som vist i hastighedsdiagrammet ovenfor.
Kapacitetsplanlægning
For hver sprint kan vi definere antallet af timer, hvert medlem skal arbejde for det projekt, der er tildelt. Kapacitetsvisningen for hver sprint definerer dette. Denne opfattelse fanger også den aktivitet, hvert medlem arbejder på som design eller udvikling eller rapportering osv.
Klik på den relevante Sprint. I dette tilfælde skal du åbne Sprint 1 og gå til Visning af kapacitet . Opdater som vist nedenfor.
I ovenstående skærmbillede, da Dev1-bruger kun arbejder 4 timer om dagen i sprintperioden på 2 uger, hvilket er 10 arbejdsdage. Det Arbejde tildelt viser, at han er tildelt en opgave, der har brug for 8 timer at udføre ud af 40 timer i sprintperioden på 2 uger. Dette beregnes som 4 (timer pr. Dag) * 10 (2 uger) = 40 timer.
En lignende beregning udføres for Dev2-brugeren.
Oprettelse af opgaver
Da vi nu har defineret Product Backlog Item eller User Story og også planlagt kapacitet for hver bruger i projektet, kan vi nu opdele det i udvikleropgaver. Klik på arbejdsskærmen Sprint 1 og klik derefter på Tilføj opgaveskilt + for produktets efterslæbspost.
Tildel det til udvikleren, og indtast en værdi i timer for det resterende arbejdsområde. Klik på Gem og luk.
Opgave, der er oprettet, er knyttet til Product Backlog Item.
Her er det resterende arbejdsfelt antallet af timer tilbage til at fuldføre en opgave. Da vi i ovenstående eksempel har sat feltet til 8 timer, og lad os sige, at udvikleren i slutningen af en dag kun har afsluttet 2 timers arbejde med opgaven, så vil den resterende times felt blive opdateret til 6. Du kan gøre det 0 når der ikke er mere arbejde, eller hvis der er 1 time eller mindre arbejde tilbage eller et sted mellem 0 og 1 time.
Fra denne værdi kan TFS oprette et nedbrydningsdiagram for sprinten, som er en af de meget nyttige metrics i Agile. Ovenstående proces gælder for SCRUM-skabelonen og har ikke feltet Originalestimat i opgavearbejdsemnet.
Hvis TFS-teamprojektet er konfigureret ved hjælp af Agile- eller CMMI-processkabelonen, er der mulighed for at indtaste feltet Originalestimat.
For at tilføje feltet Originalestimat ( Microsoft.VSTS.Scheduling.OriginalEstimate ) i opgavetypeartypen ved hjælp af SCRUM-processkabelon skal den tilføjes som et brugerdefineret felt. Du kan bruge witadmin eksportwitd , som er en kommandolinjemulighed. Tilføj feltet i den eksporterede XML-fil, og importer det tilbage til teamprojektet.
Fremtidige sprints
Produktbackloggen eller brugerhistorien kan også planlægges i fremtiden ved at trække og slippe varen til enhver anden fremtidig sprint.
Brug af Taskboard
Da Sprint-planen er på plads, kan vi nu se fremskridtene for hver opgave fra Taskboard-visningen. Så Taskboard giver en visuel strøm af opgaverne og dens status. Så under hvert scrummøde kan du se på status for hver opgave, der er tildelt medlemmerne.
Du kan også se opsummeringen af det samlede resterende arbejde, der skal udføres.
Det er meget vigtigt at overvåge status og fremskridt og kan gøres via procesbordet. Klik på Board view til Sprint.
Dette tavle er en meget nyttig visning og kan bruges til rapporteringsformål under det daglige standupmøde.
til) Hvis udviklerne med tildelte opgaver er begyndt at arbejde på opgaverne, kan du flytte opgaverne fra At gøre stat til I gang tilstand ved bare at trække og slippe funktionen.
b) Skift de resterende arbejdstid for opgaven for en Dev2-bruger fra 8 til 5 timer tilbage. Arbejdstimerne i gang opdateres derefter i overensstemmelse hermed.
c) Nedbrydningsdiagrammet opdateres automatisk ved at klikke på øverste højre hjørne.
d) Luk nu den opgave, der er tildelt Dev2, ved at trække og slippe opgaven til Færdig stat. De resterende arbejdstimer for denne opgave reduceres automatisk til 0, og nedbrydningstabellen opdateres også.
Sprint anmeldelse og retrospektiv
Nå, arbejdet er udført nu, og tidsrammen for sprint er forbi. Tror holdet, at det nu er tid til at slappe af eller tage en pause? Absolut et stort NEJ. Tiden er nu til at diskutere den meget vigtige del af SCRUM-livscyklussen, som er gennemgangen og tilbagevirkende kraft.
Sprint-gennemgang fokuserer på leverancerne, gennemgår produkterne i FÆLLES efterslæbsposter og giver en demo til kunderne. Det er også meget vigtigt at diskutere, hvilke produktforsinkelser der ikke blev udført, og hvorfor og vigtigst af alt indsamle feedback fra kunder og planlægge dem til fremtidige sprints. Sprint-gennemgangen udføres normalt mellem produktejer, udviklingsteam og kunder.
Sprint retrospektiv fokuserer på aspekterne af processen som hvad der gik godt og hvad ikke? Så du bliver også nødt til at fange feedback om processen og mennesker også. Da dette er et meget vigtigt aspekt af den agile livscyklus, kan du lære mere om retrospektiver.
Så det er meget muligt, at der kan være ufærdigt arbejde i hver sprint. I dette scenarie flytter PBI'er / opgaver til enten Product Backlog eller til den næste Sprint, som Product Owner beslutter.
Men indtil videre, hvor gemmer vi anmeldelser og retrospektiver? Du kan gemme dem som en del af diskussionsarbejdsemnet eller oprette et nyt emne til at holde retrospektive handlingspunkter og feedback.
Konklusion
Vi har set i denne artikel, hvordan Microsoft Team Foundation Server som et ALM-værktøj giver en hurtig og pæn måde at begynde at arbejde på din applikation efter Agile Scrum-processen.
Vi er nødt til at sikre, at alle holdene, der følger Agile SCRUM-processen, skal definere og oprette følgende aspekter for korrekt at planlægge og styre deres teams arbejde.
- Brug den relevante SCRUM-processkabelon i Microsoft TFS
- Opret produktbacklogs
- Angivelse af Sprint-tidsplan og holdkapacitet
- Valg af emner til sprintforsinkelse
- Nedbrydning af PBI'er eller brugerhistorier til opgaver
- Brug Burndown-diagrammer til at spore fremskridt
- Meget vigtigt at bruge Taskboard til at overvåge fremskridt
- Endelig udfør en effektiv sprintanmeldelse og retrospektiv
Anbefalet læsning
- Hvordan man kan være et godt teammentor, coach og en ægte holdforsvarer i en agil testverden? - Inspirationen
- Agile And Scrum Terminology: En ordliste til Agile / Scrum-koncepter
- Sådan gør du en smidig estimeringsproces let med planlægning af poker
- Moderne testprincipper for agil metode i testning
- Selvforsynende Scrum-hold: Hvordan oprettes et selvforsynende team?
- Agile retrospektive møder - hvorfor det er nødvendigt og nogle sjove måder at gennemføre det på
- 4 trin mod udvikling af Agile Testing Mindset for vellykket overgang til agil proces
- ISTQB Foundation Exam Format & Retningslinjer til løsning af papirer