Visual Studio Team System Fra versionsstyring til processtyrring.

Præsentationer af emnet: "Visual Studio Team System Fra versionsstyring til processtyrring."— Præsentationens transcript:

1 Visual Studio Team System Fra versionsstyring til processtyrring

2 Pains Trinvis indførelse Hvorfor? Planlægning/Roller Versionsstyring Build Test Rapportering Agenda:

3 Commentor A/S Kontor i Herlev Konsulenthus/softwarehus 20 faste + netværk af 20 kontraktansatte Arme og ben Udvikling af produkter –Mobil, client/server (x-tier) Microsoft fokus –.NET, ASP.NET, SQL Server, SharePoint, TFS

4 Pains De menneskelige ressourcer ”Udvikleren” –Overdreven tro på egne evner Mener ikke at læring fra andre er nødvendig –Lalleglad optimist En given deadline kan altid nås –Mangler fokus Laver andre (endda egne) opgave –”Kun” teknisk dygtig Mangler drev og ønske om at nå kundens mål –Forkælet

5 Pains De menneskelige ressourcer ”Arkitekten” –Alle er arkitekt –Mangler det ”ekstra”, der skal til –”Karrieremulighed” Senior udvikler, Arkitekt… –Ikke involveret i kodningen Tegner diagrammer Separat fra udviklerne –Projektleder/Arkitekt

6 Pains De menneskelige ressourcer ”Testeren” –Ikke interesseret i at teste Det er en ikke-lide opgave for udvikleren –Udvikler tester selv –Mangler fokus –Hvad er den rette baggrund for en tester? Udvikler? Forretningsspecialist? Begge dele? Testspecialist?

7 Pains De menneskelige ressourcer ”Projektlederen” –Ingen teknisk baggrund Og hvis de har, er det fordi de var for dårlige udviklere –Eller Bedste udvikler –”Karrieremulighed” Kan man ikke blive arkitekt så kan man da… –Hvad er den rette baggrund for en projektleder? Udvikler? Forretningsspecialist? Professionel projektleder? –Tager beslutninger på smalt grundlag –Er aldrig bedre end sit team!

8 Pains Andre Dårlig krav spec, politik, presset (ikke af udviklerene committed) tidsplan, ikke de rigtige værktøjer, store usikkerheder på nye teknologier, nye metoder, usikre brugerønsker, hyppige omprioriteringer, ingen forankring i ledelsen, dårlig kemi på projektet, uklare roller, fejlfyldt platform, mission impossible, manglende forretningsviden, forskellige opfattelser af..

9 Trinvis indførelse Hvorfor? Hurtigt igang Ikke vende organisationen på hovedet ”Opdag” hvordan virksomhedens processer egentlig fungerer Gulerod/pisk for projektdeltagere (Mulighed for at bakke ud)

10 Trinvis indførelse Planlægning/Politikker

11 Trinvis indførelse Planlægning/Roller Forventningsafstemning –Hvad vil vi opnå på sigt? Adgang til projekter -> fokus –Sikkerhed/Granulering –Styring hvor (AD’et ?) Virksomhedens processer/ressourcer –Har vi mange nye/stor udskiftning?

12 Trinvis indførelse Planlægning/Politikker Versionsstyring

13 Trinvis indførelse Versionsstyring ”Fundamentet” Politikker –Ikke kunne lave Check-in uden at associere det med et work-item -> fokus, styreværktøj –Kræv code-review -> vidensdeling, læring, fokus

14 Trinvis indførelse Planlægning/Politikker Versionsstyring Automatiseret Build

15 Trinvis indførelse Automatiseret Build Buildstrategi –Daglig, ugentlig, Kontinuert –Opdag i tide hvad, der mangler –Få statistik tilbage på fremgang, status Hvad har vi overset? –Et fuldt byg viser pludselig at tingene ikke hænger sammen eller at funktionalitet mangler

16 Trinvis indførelse Planlægning/Politikker Versionsstyring Automatiseret Build Test

17 Trinvis indførelse Test Hvilke tests hvornår? –Flere buildtyper? –Automatisk/Manuelle, Konfigurationer –Hvem skal notificeres? –I hvilke miljøer? Krav (scenarie), Explorativ (monkey), Regression, Unit, Discovery, QoS

18 Trinvis indførelse Test (fortsat) Automatiser -> nedbring ikke-lide opgaver Sæt krav om test (politik) -> Skab fokus Separat Testteam -> fokus, højne kavalitet, dække fault-paths

19 Trinvis indførelse Planlægning/Politikker Versionsstyring Automatiseret Build Test Rapportering

20 Trinvis indførelse Rapportering Bygger ovenpå metrikker fra build/test Muligheder –Queries –Reports Hvem skal have hvilken information? –Team Explorer, Team Portal, Team Plain, (Project), Excel

21 Trinvis indførelse Projektledelse Flere dimensioner –Bugs, test passed/failed, Code Churn, bug rate, Code coverage, Configuration coverage, reopened rate –Rapporttyper –Gennemsigtighed i projektet

22 Trinvis indførelse Iterér processen Opsaml/evaluer systemet Tilpas projekt templaten Tilpas politikkerne Tilpas ressourcerne