Implementering af TFS på Landscentret

2. Implementering af TFS på Landscentret Ibrugtagning af TFS som led i procesarbejde Thomas Vedel thv@landscentret.dk

3. Organisationsstruktur • Videntung, Landbrugsfaglig virksomhed • Ca. 550 ansatte • Over 50% akademikere(Stor idérigdom!) • Mange ”virksomheder i virksomheden” • Mange fagspecifikke systemer • Kun delvis egenudvikling • Store opgaver laves ofte helt eller delvis ”i byen” • IT udviklingsafdeling på 12 m/k • Ingen it-faglig viden uden for it-afdelingen – sådan da! s:\inet\osv.ppt

4. Typisk udviklingsforløb (hidtil) (1) • Faglige ønsker ad libitum • Somme tider vage tanker om funktionsmåde • Andre gange meget omfattende faglige beskrivelser • Ofte ingen prioriteret rækkefølge af ønsker • ”Det skal bare kunne det hele” • Ikke sjældent: Det skal virke som det vi har – bare ”bedre” s:\inet\osv.ppt

5. Typisk udviklingsforløb (hidtil) (2) • Først når der er noget ”der virker” er det til at forholde sig til • Ofte med det resultat, at der er ønske om ændringer, som ikke passer ind i oprindelig beskrivelse • Svært at få afsat nødvendige ressourcer til faglig test (så stor ”fejlpukkel” sidst i forløbet) • Svært at få gjort ting ”færdige” • Forventningsafstemning med opgavestiller • ”Driftsopgaver” kræver ”udviklerbistand” s:\inet\osv.ppt

6. ”Selverkendelsesfase” 2006 • Vi vil gerne købe 25 kg procesforbedring(!) • Ønske der bobler op fra udviklerside – ikke fra ledelse eller kunder • Kontakt til AAU, datalogisk institut • Overvejer CMM(I) • ”Kanoner til gråspurve” (mange små projekter) • Kører fast og hyrer ekstern konsulent (Ole Henningsen, Alterate) • Barsler med ”DLBR TeamDriven” s:\inet\osv.ppt

7. DLBR TeamDriven

8. Struktur • Planlægning • Scrum • Konceptualisering • Domain Driven • Automatisering • Issue Tracking • Test Driven • Continuous Integration

10. Filosofi • Udvikling som en social aktivitet! • Kommunikation, feedback og transparens • Det selvstyrende og bemyndigede team • Uddelegering af ansvar • Automatiseret og eksplicit kontrol • Pragmatisk • Værktøjsbaseret • Ikke kun en projektledermodel

12. Domænemodel Teknik Forretning Konceptualisering: Domain Driven • Traditionelt: Et projekt – to sprog • Domain Driven Design: En domænemodel • I diagrammer, tekst, tale, kode og test • Fordele: • Kommunikation • Risiko minimering • Design

13. Automatisering: Issue Tracking • Filosofi: ”Automatisér hvad automatiseres kan” • Ikke koncept men konkret værktøj • Automatiseret scrum • Dvs. automatiserede styringsredskaber • Fordele: • Ansvar • Overblik • Transparens

15. Automatisering: Test Driven • Test Driven Mantra: Rød-Grøn-Refaktorér • Fordele: • Indlejret test • Proaktiv frem for reaktiv adfærd • Design • Yderligere fordele ved automatiseret test: • Transparens • Godt udgangspunkt for release • Kan også bruges som oplærende model

16. Automatisering: CI • Enkelt koncept • Service lytter på kildestyring og automatiserer build og test ved hvert commit • Fordele • Integrationstest flyttes op i værdikæden • Hurtigt feedback (max10 minutter) • Fejlsøgning lettere (Hvad blev chekket ind?) • Rapportering

17. Versionsstyringssystemer, historisk-(og hvorfor skiftede vi)? • 1996 – 2000: Visual Sourcesafe • Nemt at bruge • Risiko for korrupte data (filbaseret system) • 2000 – 2004: JEDI VCS • God sikkerhed imod datatab (database backend) • Ingen integration med Visual Studio • .NET valgt som strategisk platform i 2003 • 2004 – 2007: SourceGear Vault • Integrerer godt med udviklingsværktøjer • IssueTracking, men ingen metodeunderstøttelse s:\inet\osv.ppt

18. Valg: TFS / Scrum for TeamSystem • VSTS licens til ”alle udviklere” igennem MSDN • TFS pilot- / test-installation forår / sommer 2007 • Installation ”bøvlet” (selv om single server install) • Et enkelt testprojekt slippes løs på VMware server • Drift på fysisk server november 2007 • Vælger Scrum template udviklet af Conchango(http://www.scrumforteamsystem.com) • Scrum template fra MS releases først på senere tidspunkt • Basal template ok, men mange fejl, især i rapporter s:\inet\osv.ppt

19. Sprints – oversigt

20. Product Backlog – oversigt

21. Tilføj Sprint Backlog item

22. Sprint Backlog items – oversigt

23. Overblik til hver en tid… • Masser af udskrifter • Alle kan til enhver tid se hvordan projektet har det

24. Sprint Burndown Chart

25. Projektportal

26. Praktiske erfaringer (1) • Nemt at sælge ideen • Demo gør underværker! • Vanskeligere at gennemføre i praksis • Kræver (megen) ”uddannelse” • Især produktejere kan have svært ved at finde sin nye rolle • ”Dobbelt bogholderi” for udviklerne • Tid skal registreres dagligt for at eks. Sprint Backlog giver sandt billede af fremdrift • Deployment kan i praksis være vanskeligere end i teorien

27. Praktiske erfaringer (2) • Glade udviklere • Deltager aktivt i sprintplanlægningen • Effektivt arbejdsredskab • Sprint backlog definerer entydigt sprintets opgaver • Glade produktejere • Får noget som er ”færdigt” efter hvert sprint • Kan til enhver tid se om fremdrift er som estimeret • Frit valg til omprioritering efter hvert sprint • Projektportalen bliver samlingspunktet for hele projektet • Ingen ”løse” dokumenter