1 / 28

Implementering af TFS på Landscentret

Implementering af TFS på Landscentret. Ibrugtagning af TFS som led i procesarbejde Thomas Vedel thv@landscentret.dk. Organisationsstruktur. Videntung , Landbrugsfaglig virksomhed Ca. 550 ansatte Over 50% akademikere (Stor idérigdom!) Mange ”virksomheder i virksomheden”

maja
Download Presentation

Implementering af TFS på Landscentret

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


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

  2. 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

  3. 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

  4. 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

  5. ”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

  6. DLBR TeamDriven

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

  8. 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

  9. 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

  10. 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

  11. 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

  12. 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

  13. 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

  14. 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

  15. Sprints – oversigt

  16. Product Backlog – oversigt

  17. Tilføj Sprint Backlog item

  18. Sprint Backlog items – oversigt

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

  20. Sprint Burndown Chart

  21. Projektportal

  22. 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

  23. 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

More Related