Softwareprozesse: Timeboxing & Continuous Delivery

BENJAMIN PROJDAKOV The Timeboxing Process Model •Voller Titel: The Timeboxing Process Model for Iterative Software Development •Verfasser: • Professor Pankaj Jalote Department of Computer Science and Engineering Indian Institute of Technology Kanpur • Aveejeet Palit, Priya Kurien Infosys Technologies Limited Bangalore Einführung: Wasserfallmodell •Linear •Nicht iterativ •Lange Entwicklungsdauer typisch •Anforderungen: • Müssen vollständig bekannt sein • Änderungen schwierig •Entwicklung in Phasen •Ergebnis: Vollständige Software •Komplexität der Software eher gering

Einführung: Iterative Modelle •Linear •Entwicklung: • In Zyklen • Zyklus unterteilt sich in Phasen •Kurze Entwicklungsdauer pro Zyklus •Anforderungen: • Müssen pro Iteration bekannt sein • Änderungen in nächster Iteration möglich •Ergebnis: Funktionierende Software nach jedem Zyklus

Timeboxing Modell •Entwicklung: • In Zyklen • Zyklus unterteilt sich in Phasen • Ausführung mit Versatz parallel •Feste Entwicklungsdauer pro Zyklus • Wochen bis Monate •Anforderungen: • Müssen pro Iteration bekannt sein • Änderungen in nächster Iteration •Ergebnis: • Häufige Releases • Funktionierende Software nach jedem Zyklus

Timeboxing Modell: Phasen & Teams •Phasen: •Teams: • Anzahl Variabel • Eine Aufgabe pro Team • Gleiche Dauer ideal • Größe abgestimmt auf Dauer

Timeboxing Modell: Phasen & Teams •Ungleiche Boxen führen zu ineffizienter Teamauslastung •Lösungen: • “Right-scaling” von Teams • Ressourcenumverteilung

•Kann auch durch Verzögerungen in einer Box verursacht werden Timeboxing Modell: Reales Beispiel

Oct 19 - 23 Oct 26 - Oct 30 Nov 2 - Nov 4 - Nov 24 Holiday Dec 3 - Dec 22 19 20 21 22 23 26 27 28 29 30 2 3 4 5 6 9 10 11 12 13 16 17 18 19 20 23 24 25 26 27 30 1 2 3 4 7 8 9 10 11 14 # 16 17 18 21 22 23 24 28 Cycle Commit Cycle ACCEPTANCE ACCEPTANCE Eng Cycle Kickoff & development Eng Commit Cycle Cycle Kickoff & development Eng Engineering Discussion & Est Esti Est Estimation Discussion & Discussion & Estimation Estimation

Stack rank Stack Rank Stack Rank Backlog Product Backlog Backlog

Release Engineering Stake Prod Release Engineering Sta Deploy Dep RelEng

Cycle 1: Oct 19 - Nov 25 Cycle 2: Nov 11 - Dec 23 Cycle 3: Dec 9 - January...

Detailed Tasking New Cycle Begins

Week 1 Week 2 Week 3 Week 6 Week 7

October 20 October 26 Nov 2 Nov 23 Nov 30 October 23 October 30

Discussion and •Product Stack ranks Issues in Acceptance PACM Estimates •Product and engineering agree on •Engineering takes PACM Tickets •Product Reviews issues with what is in the cycle (Tech debt, •Factors in Technical Debt Features, bugs) Engineering, collects feedback, •Engineering takes PACM Tickets •Engineering demonstrates what •Includes Bug Fixes •Development Proceeds incorporates into Tickets for •Factors in Technical Debt has been completed (Test reports, •Estimates level of effort to support further estimation •NO CHANGES TO Prioritization •Includes Bug Fixes features, etc) in the upcoming cycle •Product Revisits their Backlog for allowed during the next three •Product determines if a release is •Includes lower level tasking prioritization every two weeks. •Estimates level of effort to support weeks in the upcoming cycle warranted with releng •Assignments •Includes lower level tasking •Assumes release is stable AND there are no regressions Product •Assignments Cycle Kickoff & Discussion and Planning Development • Product Stack ranks Issues in Estimates PACM • Product Reviews issues with Engineering, collects feedback, incorporates into Tickets for further estimation • Product Revisits their Backlog for prioritization everyProduct two “Baked Data” Stack weeks Planning Ranked in Backlog “Baked Data” Stack Ranked in Backlog Continuous Delivery • Voller Titel: Release Management with Continuous Delivery: A Case Study •Verfasser: • A. Maruf Aytekin, Release Management Team atCentral Securities • Depository Institution (MKK), • Istanbul, TurkeyDepartment of Computer Science and Engineering •Veröffentlicht: • World Academy of Science, Engineering and Technology • International Journal of Social, Education, Economics and Management Engineering Vol:8, No:9, 2014 Einführung: Continuous Integration •Entwicklungsprozess •Voraussetzungen: • Häufige Integration • Automatisierung von “Builds”, Testläufen, Reporting, QA, … • Kurze Testzyklen • Schnelle Laufzeiten • Gespiegelte Produktionsumgebung für Testing •Vorteile • Schnelles Feedback • Weniger Aufwand für Defektkorrekturen • Höhere Software Qualität Continuous Delivery •Iterativ •Weiterentwicklung von Continuous Integration •Automatisierte Test und Release Prozedur •Defektkorrekturen schnell realisierbar •Anforderungen: • Auf Commit-Ebene •Entwicklung: • Erste Lieferung nicht möglich • Chaotisch •Ergebnis: • Häufige Releases • Funktionierende Software nach jedem erfolgreichem Commit Continuous Delivery: System •Vollautomatisch •Komplex •Teuer •Lange Entwicklungsdauer des Systems •Team für Wartung nötig • Single Point of Failure

Vergleich

TIMEBOXING CONTINUOUS DELIVERY

•Iterationen •Iterationen • Wochen bis Monate • Sehr kurz •Planung: •Planung • Pro Iteration • Typisch keine • Horizont: nächste Iteration • Aufgabenverteilung durch Backlog •Anforderungsänderungen •Anforderungsänderungen • In einer Iteration schwer • Jederzeit möglich • Durch Planung in nächster Iteration möglich • Priorisierung des Backlog

Vergleich TIMEBOXING CONTINUOUS DELIVERY

•Voraussetzungen: •Voraussetzungen: • Ein Team pro “Box” • Software Teams getrennt von CD Team • Software ist iterativ entwickelbar • Software ist automatisch testbar • Auslieferung Iterativ möglich • Auslieferung und Entwicklung kontinuierlich möglich • Mittelgroßes bis großes Projekt • Großes Projekt – “Gigantisches” Projekt

•Probleme: •Probleme: • Schwer zu koordinieren bei sehr großen Projekten • Minimale Software muss vorhanden sein • Nicht möglich bei kleinen Projekten • Teuer & Komplex • Nicht rechtfertigbar bei kleinen Projekten

•Anwendungsbeispiele: •Anwendungsbeispiele: • Online Anwendungen • Software im Finanzsektor • Mobile Apps • Online Anwendungen

Fragen? Vielen Dank Benjamin Projdakov Vergleich: A: The Timeboxing Process Model for Iterative Software Development

B: Release Management with Continuous Delivery: A Case Study