Embed Size (px)
DESCRIPTION
Anhand von Praxisbeispielen bei namhaften Unternehmen zeigen wir, wie der TFS in Projekten und Entwicklungsabteilungen genutzt werden kann, um die agilen Entwicklungsprozesse im gesamten Application Lifecycle optimal zu unterstützen, wie verschiedene Entwicklungspartner und Standorte (auch offshore) effektiv integriert werden und wie ein reibungsloser Übergang von Entwicklung in die Wartung sichergestellt wird, während bereits an weiteren Versionen der Software gearbeitet wird. Darüber hinaus diskutieren wir das Projekt-Controlling auf Basis agiler Methoden wie dem Burn-Down Chart. Mehrwert: Zusammenspiel verschiedener Workitemtypen und deren Stati zur Erfüllung komplexer Projektmanagementaufgaben auch in verteilten Projekten. Auswirkungen der verschiedenen Phasen des Softwarelebenszklus auf die Ausprägung der Workitemtypen, Queries und Reports. Integration und Koordination von verteilten Entwicklungs-/Testteams über mehrere Versionsstände der Software hinweg. Controlling auf Basis agiler Methoden - wie dem Burn-Down Chart im Vergleich zum Earned Value Management (EVM).
Citation preview
© Zühlke 2011
Klaus Liebe und Frank Zetzsche
Agiles Management und Controlling großer verteilter Softwareprojekte während des
gesamten Application Lifecycle
Referenten: Klaus Liebe und Dr. Frank Zetzsche
23. November 2011Folie 1
© Zühlke 2011
Embedded Device
Embedded Device
Smart ClientSmart Client
ProjektvorstellungKomponententopologie
23. November 2011 Folie 2
Smart Client
Smart Controller
Backend
Node Node Node Node
WWW
WWW
...
© Zühlke 2011
ProjektvorstellungProjektorganigramm
23. November 2011 Folie 3
© Zühlke 2011
ProjektvorstellungTeamtopologie und Probleme
23. November 2011 Folie 4
© Zühlke 2011
ProjektvorstellungKollaboration
Örtliche Verteilung der Teams erfordert vielfältige Kollaborationsstrategien
• Telefon
• Instant Messaging
• Emails
• Screen Sharing
• Sharepoint
• TFS Work Items (insb. History Tracking)
• Persönliche Meetings (incl. Social Events)
• Solution Architekten reisen zu den Teams
23. November 2011 Folie 5
© Zühlke 2011
Entwicklungsprozess„RUP mit Scrum-Kern“
23. November 2011 Folie 6
Scrum
Rational Unified Process
© Zühlke 2011
EntwicklungsprozessInception
Inception
• Business Model ist erarbeitet (Business Consultants)
• Anforderungsanalyse (grobes Product Backlog in Excel)
• HW Auswahl (Embedded- und Server-Komponenten)
• TFS aufsetzen
• Grobarchitektur und Technologiewahl
• Risikobetrachtung
• Kleines Team– Softwarearchitekten (SA)– Infrastrukturexperten– Teamleads (TL)
23. November 2011 Folie 7
© Zühlke 2011
EntwicklungsprozessElaboration
Elaboration
• Technologieprototypen
• Architekturdurchstich
• Risikominimierung
• UI Wireframes / Usability
• Security Konzept
• Team Rampup– Entwickler– Tester
23. November 2011 Folie 8
}Kundendemo
© Zühlke 2011
EntwicklungsprozessConstruction
Construction (Scrum basiert)
• Iterationen à 4-5 Wochen
• Vor jeder Iteration– Backlogmeeting (Kunde mit SW Partner) – 1Tag– Konzeptmeeting aller SAs – 1Tag– High Level Sprintplanung mit Kunde und TL/SA aller Teams.
Teamübergreifende Synchronisation von Tasks und Prios. – 1Tag– Retrospektive & teaminterne feingranulare Sprintplanung – 1Tag
• Während der Iteration– Teamübergreifendes Scrum of Scrum Meetings – 30min– Parallele teaminterne Scrum Meetings – 15min
• Am Ende jeder Iteration– Teamübergreifendes Sprint Review Meeting mit dem Kunden– Produktdemo vor dem Kunden
23. November 2011 Folie 9
© Zühlke 2011
Integration
EntwicklungsprozessConstruction
Iterationsstruktur
Wochenstruktur
23. November 2011 Folie 10
Entwicklung
Entwicklung
QS
Entwicklung
Entwicklung
QS
Sprint n
Sprint n+1
Woche n
Woche n+1
Planung
© Zühlke 2011
EntwicklungsprozessConstruction
Dokumentation
23. November 2011 Folie 11
High Level Requirements
(Excel)
Product BacklogItems (PBI im TFS)
Sprint BacklogItems (SPI)
Wireframes(Powerpoint) Designentwurf
RequirementSpecification
(Word)
Solution Architecture
Document (Word)
© Zühlke 2011
EntwicklungsprozessTransition
Transition
• Stufenweise Übergabe der Verantwortungen an das Wartungsteam des Kunden
• Reduzierung der Teams– Nur noch Entwickler und Tester
• Reduzierung der Partner
23. November 2011 Folie 12
© Zühlke 2011
EntwicklungsprozessTransition
23. November 2011 Folie 13
Projektorganigramm
© Zühlke 2011
ToolunterstützungTeam Foundation Server (TFS)
TFS Unterstützung
• „Scrum for Team System“ Prozesstemplate
• Quellcodeverwaltung und Versionsverwaltung
• Build-Management
• Projektverfolgung und –Steuerung
• Bug-Tracking
• Reporting
23. November 2011 Folie 14
© Zühlke 2011
Work Item TrackingProduct Backlog Item
23. November 2011 Folie 15
© Zühlke 2011
Work Item TrackingSprint Backlog Item
23. November 2011 Folie 16
© Zühlke 2011
Work Item TrackingMengengerüst
23. November 2011
Work Item Types Nr of Instances
Product Backlog Item 1058
Sprint Backlog Item 4966
Bug 780
Stabilization Item 4438
Integration Issue 303
Maintenance Item 112
Folie 17
Späte Kunden-Einflußnahme
© Zühlke 2011
ControllingTimesheet for Team System Web Access
23. November 2011 Folie 18
© Zühlke 2011
ControllingTimesheet for Team System Web Access
• Tageweise Zuordnung von Arbeitsstunden zu Tasks
• Durch tägliche Pflege hohe Aktualität der Aufwände
• Nachteil: Zusatzaufwand für die Entwickler
• Open Source Software http://tfstimesheet.codeplex.com/
• Anpassungen für das Projekt– Entwicklerbezogenes Wochenresumee der Stunden und Tasks
zum Übertragen in das verbindliche Buchungssystem– Akkumulation der Task-bezogenen Aufwände zur Fortschritts-
und Budgetkontrolle per Reporting
23. November 2011 Folie 19
© Zühlke 2011
ReportingSprint Burndown Chart
23. November 2011 Folie 20
© Zühlke 2011
Lifecycle ManagementBranching Strategien
23. November 2011 Folie 21
Team Branches bis Beta Version
Main BranchMain Branch
UI BranchUI Branch
Backend BranchBackend Branch
Smart Controller BranchSmart Controller Branch
Label for QS
Freitag Montag
1 2 3
© Zühlke 2011
Lifecycle ManagementBranching Strategien
23. November 2011
Release Branches
Main BranchMain Branch
Folie 22
V1.0 Stabilisierung
V1.1 StabilisierungV1.1 Stabilisierung
Bug
fix
Bug
fix
Bug
fix
V1.0 RTMV1.0 RTM
V1.1 RTMV1.1 RTM
© Zühlke 2011
Lifecycle ManagementBranching Strategien
23. November 2011
Feature Branches bei Bedarf
Main BranchMain Branch
Folie 23
Feature BranchFeature Branch
© Zühlke 2011
Team Foundation ServerKennzahlen aus dem Projekt
23. November 2011
Users
Users 112
Work Items
Work Items 11.792
Attached Files 2.936
Areas & Iterations 259
Queries 1.615
Version Control
Files 2.104.336
Total File Size 13.315 MB
Workspaces 343
Checkins 19.886
Folie 24
© Zühlke 2011
Agiles Management und Controlling großer verteilter Softwareprojekte während des gesamten Application Lifecycle
Klaus Liebe und Frank Zetzsche
Projektcontrolling
Earned Value Management / Burndown Charts
23. November 2011Folie 25
© Zühlke 201123. November 2011 Folie 26
Elemente des agilen Projektmanagements(SCRUM Terminologie)
Die Entwicklung erfolgt iterativ anhand sukzessiver „Sprints“
• Product Backlog: priorisierte Liste aller Anforderungen; oft repräsentiert durch „User Stories“
• Sprint Backlog: alle Aufgaben (Tasks) zur Realisierung der einem Sprint zugeordneten Anforderungen
• Burndown Charts: Darstellung der geschätzten Restaufwände über die Zeit, evtl. mit Trendlinie
Release
Sprint
© Zühlke 201123. November 2011 Folie 27
Sprint Burndown Chart
© Zühlke 201123. November 2011 Folie 28
Product Burndown Chart
© Zühlke 201123. November 2011 Folie 29
Earned Value Management, EVM
Das EVM ist ein bekannter Standard des Projektcontrollings
• 1960 durch das „Department of Defense“ eingeführt
• Fragen zum EVM sind Teil der PMP Zertifizierung
• EVM betrachtet Arbeitsfortschritt und aktuelle Kosten gegenüber dem Plan
• Die Darstellung geleisteter Arbeit „Earned Value“ und akkumulierter Kosten führt zu „Burn-Up Charts“
• Modelle des erwarteten Verlaufs („Planned Value“) bilden die Bewertungsgrundlage des Projektstands.
• EVM kann auf Release (Requirements) oder Iterations-Level (Tasks) angewendet werden.
© Zühlke 201123. November 2011 Folie 30
Ein einfaches EVM Schema für Tasks
PV(task) → <estimated effort of the task in ideal working hours>PV(t) → <linear approximation of the total PV at time t>EV(task, t) → task(t) == done ? PV(task) else 0;EV(t) → Sum(EV(task(t)): task in project);
© Zühlke 201123. November 2011 Folie 31
EVM Charts mit dem TFS(Beispiel Task Tracking)
Die benötigten Kalkulationen basierten alleine auf MDX
© Zühlke 201123. November 2011 Folie 32
Unterschiede zum Sprint Burndown Chart
• Die Bewertung erfolgt auf Basis abgeschlossener Tasks und nicht durch Restschätzung (ähnlich dem Release Burndown)
• Explizite Darstellung des geplanten linearen Arbeitsverlaufs. Andere, nichtlineare Modelle sind möglich.
• Der Burn-Up Chart erlaubt die natürliche Darstellung der Planungshistorie anhand des Gesamtaufwands.
• Die Darstellung einer Trendkurve zum Earned Value ist natürlich auch möglich.
© Zühlke 201123. November 2011 Folie 33
Agile Planning versus EVM
• Die differenzierte Betrachtung und Verfolgung von Requirements und Tasks beim Agile Planning erweitert den Blickwinkel des EVM.
• Das EVM bietet darüber hinaus die Möglichkeit der systematischen Integration der Kostenverfolgung.
• Die Unterschiede beim Task Tracking eröffnen interessante Diskussionen und Alternativen.
• Alles in allem sehen wir viele Gemeinsamkeiten und eine sinnvolle Ergänzung er beiden Ansätze.
© Zühlke 2011
Vielen Dank
23. November 2011 Folie 34
Fragen ?
