Workshop Hot Spots der Software-Entwicklung 20. Juni 2007 ...

Workshop Hot Spotsder Software-Entwicklung20. Juni 2007Technische Universität MünchenInstitut für InformatikSoftware & Systems EngineeringProf. Dr. Dr. h.c. Manfred Broy&BICCNETReport: VSEK/061/DVersion: 1.0Klassifikation: externMünchen, 6. Juli 2007Martin FritzscheFlorian Deißenböck

InhaltsverzeichnisInhaltsverzeichnis1 Einleitung 32 Teilnehmerliste 43 Programm 64 Vorträge und Diskussion 74.1 Martin Fritzsche: Einführung zum Workshop“ . . . . . . . . . . . . . . . . . . 7”4.2 Jens Coldewey: Agile Entwicklung aus Management-Sicht“ . . . . . . . . . . . 11”4.2.1 Folien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114.2.2 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234.3 Dr. Carsten Ohlemeyer und Robert Weidinger: eXtreme Programming bei der”LV1871“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.1 Folien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 244.3.2 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 334.4 Dr. Peter Braun: Experience with an Agile Process in a Telecommunication”Project“ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4.1 Folien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 344.4.2 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 424.5 Dr. Markus Pizka: Lean Software Production“ . . . . . . . . . . . . . . . . . . 43”4.5.1 Folien . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 434.5.2 Diskussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 542

1 EinleitungAm Mittwoch, den 20. Juni 2007, fand ein weiterer Workshop in der Reihe ”Hot Spots derSoftware-Entwicklung“ statt. Thema war ”Agile Methoden“. 37 Teilnehmerinnen und Teilnehmeraus Forschung und Industrie fanden sich zum Workshop ein. Der Workshop wurdeam Lehrstuhl für Software & Systems Engineering der Technischen Universität München inKooperation mit dem Bavarian Information and Communication Technology Cluster (BICC-NET) und dem Virtuellen Kompetenzzentrum für Software-Engineering (VSEK) organisiertund veranstaltet. Die Reihe ”Hot Spots der Software-Entwicklung“ wurde im Jahre 2002 imRahmen des ViSEK-Projekts (Virtuelles Software Engineering Kompetenzzentrum) gegründet.Ziel der Veranstaltungen ist es, eine Plattform zum Erfahrungsaustausch zu aktuellenThemen des Software-Engineering zu schaffen.Agile Methoden haben in den letzten Jahren zunehmend Verbreitung gefunden, allen voraneXtreme Programming und Scrum. Aber auch andere Methoden wie Crystal, Adaptive SystemsDevelopment (ASD), Dynamic Systems Development Method (DSDM), Feature DrivenDevelopment (FDD) und eine Vielzahl an Adaptierungen dieser Methoden befinden sich imEinsatz. Die vier zentralen Werte agiler Methoden wurden 2001 im Agilen Manifest festgehalten:• Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.• Funktionierende Software ist wichtiger als umfassende Dokumentation.• Die Zusammenarbeit mit dem Kunden ist wichtiger als Vertragsverhandlungen.• Sich auf unbekannte Änderungen einzustellen, ist wichtiger als einem Plan zu folgen.Vorteile bieten agile Methoden vor allem in Projekten die häufigen Änderungen und hohemZeitdruck unterliegen. Hierbei bieten sie hohe Flexibilität und die Möglichkeit schnell Ergebnissezu produzieren. Doch agile Methoden haben auch Nachteile. Der Verzicht darauf zuProjektbeginn den genauen Umfang von Releases zu definieren macht die Vertragsgestaltungschwierig. Zudem stoßen agile Organisations- und Kommunikationsformen in großen und verteiltenProjekten an ihre Grenzen. Es gibt jedoch auch Erfahrungsberichte, wie auch in einemsolchen Umfeld erfolgreich agil entwickelt werden kann.Während agile Methoden schon vielfach erfolgreich eingesetzt werden, sind ihre Grenzen nochnicht genau bekannt. Es muss noch Erfahrung darüber gesammelt werden, in welchen Situationenagile Entwicklung vorteilhaft ist, worin Problemfelder bestehen und wie man mit denProblemen umgehen kann.Die Perspektiven und Probleme, die agile Methoden mit sich bringen, wurden im Rahmen desWorkshops in einem Kreis von Experten aus Wirtschaft und Wissenschaft genau beleuchtet.Neben generellen Konzepten wurden auch Berichte über Projekterfahrungen vorgetragen unddiskutiert.3

2 Teilnehmerliste2 Teilnehmerliste• Peter Braun, Nokia Siemens Networks• Wilhelm Braunschober, Krauss-Maffei Wegmann GmbH & Co KG• Prof. Dr. Dr. h.c. Manfred Broy, Technische Universität München• Sabine Canditt, Siemens• Andrea Christ, ACTANO• Jens Coldewey, Coldewey Consulting• Jean-Paul Dichter, e.sigma Systems• Jürgen Dinsing, ACTANO• Kai Doernemann, GeNUA• Quirin Eberle, Fachhochschule Rosenheim• Harald Elsperger, xpecto• Martin Feilkas, Technische Universität München• Peter Fleischer, Munich Airport• Markus Friedl, GeNUA• Annemarie Fritzsche, Nokia Siemens Networks• Martin Fritzsche, Technische Universität München• Alexander Geltermair, Indanet• Ludwig Groten, Realtime• Tobias Hauzeneder, Dynalogic• Jonas Helming, Technische Universität München• Dr. Joachim Jordan, Sepis GmbH• Maximilian Kögel, Technische Universität München• Mike Lie, Indanet• Jürgen Lohrmann, msg systems ag• George Mesesan, MicroDoc• Thomas Mey, Münchner Rück• Carsten Ohlemeyer, LV1871• Andreas Pillip, Fachhochschule Rosenheim4

• Dr. Markus Pizka, Technische Universität München• Harald Ranner, Munich Airport• Jennifer Schiller, Siemens• Dr. Werner Schmid, Münchner Rück• Rainer Singvogel, msg systems ag• Dirk Steinkopf, WorNet• Martin Wagner, TNG• Harald Wagner, Private ptm-Akademie• Robert Weidinger, LV18715

3 Programm3 ProgrammBlock 114:00 Begrüßung am Lehrstuhl für Software & Systems EngineeringProf. Dr. Dr. h.c. Manfred Broy, Technische Universität München14:05 Einführung zum WorkshopMartin Fritzsche, Technische Universität München14:15 Agile Entwicklungs aus Management-SichtJens Coldewey, Coldewey Consulting15:00 eXtreme Programming bei der LV1871Robert Weidinger und Dr. Carsten Ohlemeyer, LV187115:45 Kaffee-PauseBlock 216:00 Experience with an Agile Process in a Telecommunication ProjectPeter Braun, Nokia Siemens Networks16:45 Lean Software ProductionDr. Markus Pizka, itestra17:30 Abschlussdiskussion18:00 Empfang6

4 Vorträge und DiskussionIn diesem Abschnitt werden die Vortragsfolien und die wichtigsten Diskussionspunkte dargestellt.Der Diskussionsverlauf wird dabei nicht chronologisch wiedergegeben, sondern orientiertsich an inhaltlichen Schwerpunkten. Dabei werden zusammenhängende Diskussionspunkte, diein mehreren Vorträgen zu Diskussionen geführt haben, oftmals zentral an einer Stelle zusammengefasst.Aufgrund des fließenden Übergangs der Diskussion zum letzten Vortrag und derAbschlussdiskussion finden sich viele Punkte aus dieser beim Vortrag von Dr. Pizka.4.1 Martin Fritzsche: ”Einführung zum Workshop“Einführung zum HotSpots-Workshop„Agile Methoden“Martin Fritzsche20.06.2007Fakultät für InformatikLehrstuhl IV: Software & Systems Engineering 17

4 Vorträge und DiskussionGastgeber• VSEK – Virtuelles Kompetenzzentrum für Software-Engineering– Transfer von Erfahrungen aus der Forschung– Portal software-kompetenz.de mit über 100.000 Besuchen imMonat und mehr als 4.000 Inhaltsseiten– Zukunft: GI-Arbeitskreis Software EngineeringTechnologietransferFakultät für InformatikLehrstuhl IV: Software & Systems Engineering 2Gastgeber• BICCNET – Bavarian Information and CommunicationTechnology Cluster– Teil der Cluster-Offensive der bayerischen Staatsregierung– Förderung des I&K Sektors– Aufbau von persönlichen Netzwerken und Kooperationen– Wissensvermittlung– VeranstaltungsorganisationFakultät für InformatikLehrstuhl IV: Software & Systems Engineering 38

4.1 Martin Fritzsche: ”Einführung zum Workshop“ProgrammEinführung und Begrüßung14:00 bis 14:0514:05 bis 14:15Begrüßung durch Prof. Dr. Dr. h.c. Manfred Broy,Lehrstuhl für Software & Systems Engineering, TU MünchenMartin Fritzsche (TU München):Einführung zum Workshop14:15 bis 15:0015:00 bis 15:45Jens Coldewey (Coldewey Consulting):Agile Entwicklung–EineEinführungRobert Weidinger (LV1871):eXtreme Programming bei der LV1871Kaffeepause16:00 bis 16:4516:45 bis 17:3017:30 bis 18:00AnschließendPeter Braun (Nokia Siemens Networks):Experience with an Agile Process in a Telecommunication ProjectMarkus Pizka (itestra GmbH, TU München):Lean Software ProductionKaffeepauseDiskussionAbschlussdiskussionEmpfangFakultät für InformatikLehrstuhl IV: Software & Systems Engineering 4Zielsetzung• Lebhafte Diskussion• Ergebnisse– Liste der Herausforderungen aus Sicht dieser Gruppe– Zusammenfassung in einem Workshop-Bericht– www4.in.tum.de/~hseFakultät für InformatikLehrstuhl IV: Software & Systems Engineering 59

4.2 Jens Coldewey: ”Agile Entwicklung aus Management-Sicht“4.2 Jens Coldewey: ”Agile Entwicklung aus Management-Sicht“4.2.1 FolienAgile Entwicklung– Eine EinführungJens Coldewey (BDU)Coldewey ConsultingToni-Schmid-Str. 10 bD-81825 MünchenGermanyTel: +49-700-COLDEWEYTel: +49-700-26533939Fax: +49-89-74995703jens.coldewey@coldewey.comhttp://www.coldewey.comTechnische Universität MünchenHot Spots der Software Entwicklung20. Juni 2007, MünchenSome Statements You Often Hear About AgileDevelopment„I prefer anengineeringapproach…“„You need anexpert team towork agile““Some academicideas that don’twork in reality”WRONG“Hacking withoutdesign and quality”„Only suitable forsmall projects“„We doXPbecause we don‘tlike to document“Slide 2; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights Reserved11

4 Vorträge und DiskussionAgile Development Optimizes the OverallBusiness Value of Development• Understand the Domain• Learn from the System• React to ChangeBuild theRightSystemBusinessBusiness … ValueValueAvoid WasteBuild theSystemRight• Changeability• Emerging Design• Refactoring• Testing• Sustainability• Focus on Value-Added Delivery• Efficient Collaboration• Adaptable ProcessSlide 3; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedTo Build the Right SystemYou Have to Understand the Domain• The development team doesn’t understandthe domain• The domain experts don’t understand howthe system changes the domain• Often the domain potential of the systememerges during the development Close collaboration between domain andsoftware experts during the whole projectinstead of “over-the-wall” requirementsSlide 4; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights Reserved12

4.2 Jens Coldewey: ”Agile Entwicklung aus Management-Sicht“Following a Plan Produces the ProductYou Intended, Not The One You NeedSource: James A. Highsmith III: Adaptive Software Development - A CollaborativeApproach to Managing Complex Systems, Page 43Slide 6; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedTo Build the Right SystemYou Have to React to Change• Learning comprises of four elements:– Try the system realistically– Perceive potentialities and problems– Understand the implications of the observations– Change accordingly (system, usage, process,…)• This is an incremental approach Responding to change is the key in agiledevelopmentSlide 7; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights Reserved13

4 Vorträge und DiskussionA Disciplined Approach to ChangePrevents ChaosPriorityPlaningDeploymentSlide 8; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedA Planning Workshop Starts Each Increment• Developers, stakeholdersand business experts plantogether• The requirements arechopped into pieces of afew days work• Developers estimate effortand risk• Business people estimatebenefit• Requirements are rankedaccording to estimations• The top is skimmed untilthe increment is completeSlide 9; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights Reserved14

4.2 Jens Coldewey: ”Agile Entwicklung aus Management-Sicht“Several Levels Balance Flexibility andPredictabilityReleaseRelease BacklogRelease BacklogBacklogPlanningIncrementBacklogPlanningIterationBacklogProductBacklogPlanningOperation3-4 Releases/yearMonthly IncrementsWeekly IterationsPlanningDevelopmentUnit Test SuiteIntegratedReleasableFull QA TestsReleasedBeta TestClientSlide 10; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedAgile Development Optimizes the OverallBusiness Value of Development• Understand the Domain• Learn from the System• React to ChangeBuild theRightSystemBusinessBusiness … ValueValueAvoid WasteBuild theSystemRight• Changeability• Emerging Design• Refactoring• Testing• Sustainability• Focus on Value-Added Delivery• Efficient Collaboration• Adaptable ProcessSlide 13; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights Reserved15

4 Vorträge und DiskussionChangeability Needs Several Aspects You Haveto Focus on• Changeability means:– Lean architecture and design– Avoidance of redundancy– Refactoring skills– Automated regression testing– Claim for quality work The focus on changeability is one of the majoradvancements over the Rapid Application Developmentof the ninetiesSlide 15; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedTo Build the System RightYou Need a Lean Architecture and DesignTraditional Architecture• Detailed upfront design• Based on extensiveanalysis• Tries to anticipate futureevolvement• Tries to avoid futurechange• Often very complexSlide 16; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedEmergent Architecture• Starts with coarsemetaphor• Based on frameworks andpatterns (past experience)• Doesn’t predict the future(“YAGNI”)• Is based on change• Leads to lean solutions Emergent architectures are efficient solutions if youmaster the art to change software16

4.2 Jens Coldewey: ”Agile Entwicklung aus Management-Sicht“Meta-RuntimeJNIElaborate Architectures May EmergeOver TimeRegel-SystemRuntimeLaufzeitmodell1TechnischeSichtenGenerierungGenerierungGenerierung111Basis-GenerierungSimulationKomponentenDruckWebDAV PVCSKopplungRechenkernFormelnParserBaumOODB Datei- XMLPersistenzMigrationSmalltalk C XSLTPlug-InsPL/IJavaSlide 17; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedTo Build the System RightYou Need Refactoring Skills• Refactoring is the art to change code withouteffecting its functionality• Sound research in the nineties (Bill Opdyke,“idempotent code transformations”…)• Growing tool support for Java and Smalltalk(e.g. Eclipse Refactoring Plug-In) Refactoring is the basis for growingdesigns (“Emergent Architecture”)Slide 18; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights Reserved17

4 Vorträge und DiskussionTo Build the System RightYou Need Elaborate Testing• Refactoring needsautomated tests• At least two levels oftesting:– Programmers write unittests: “Test DrivenDevelopment”– Customer writesacceptance tests• One mouse-click:Compile-(Link)-Test• Every night all tests arerun and have to pass About 30-50% of the effortaccounts for writing testsSlide 20; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedAgile Development Optimizes the OverallBusiness Value of Development• Understand the Domain• Learn from the System• React to ChangeBuild theRightSystemBusinessBusiness … ValueValueAvoid WasteBuild theSystemRight• Changeability• Emerging Design• Refactoring• Testing• Sustainability• Focus on Value-Added Delivery• Efficient Collaboration• Adaptable ProcessSlide 22; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights Reserved18

4.2 Jens Coldewey: ”Agile Entwicklung aus Management-Sicht“To Avoid WasteYou Have to Focus on Value-Adding Delivery• Each increment has to deliver at least somebusiness value• The business value should exceed theoverall cost of the increment withinreasonable time (e.g. quarter)• The steady accrual of business value is themajor controlling tool Delivering value is more important than to dowhat you thought you would do today oneyear agoSlide 23; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedTo Avoid WasteYour Collaboration Needs to be Efficient• Software development isbased upon communication• Face-to-face communicationis more efficient than writingand reading documents• A ten person team may bemore productive than ahundred person team• Collaborative work savescommunication costs• Beware: Sometimesdocumentation is part ofgenerating value (e.g.medical systems) – try togenerate it“Information Radiator”Source: http://www.lunatech.com/archives/2005/10/07/information-radiatorsSlide 24; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights Reserved19

4 Vorträge und DiskussionTo Avoid WasteYour Development Process Needs to Adapt• Agile development works at theedge:– Highsmith: “Management at theedge of chaos”– Cockburn: “Find the barelysufficient methodology”– Schwaber: “Control Chaos”• If you skip too much from yourprocess you may fail, if you skiptoo few you may get stuck – andfail too• As time goes by the problemschange and so should thesolutionsThe team reviews its process aftereach increment or deploymentand adapts it (“Retrospective”)Norm KerthSlide 25; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedThese Ideas Gave Raise to the Agile ManifestoWe are uncovering better ways of developingsoftware by doing it and helping others do it.Through this work we have come to value:Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a planThat is, while there is value in the items onthe right, we value the items on the left morehttp://www.agilemanifesto.orgSlide 26; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights Reserved20

4.2 Jens Coldewey: ”Agile Entwicklung aus Management-Sicht“Pro’s and Con’s of Agile+ Agile is a proven, wellworkingway to developsoftware+ Agile is in most casesmore efficient thantraditional development+ Agile yields more satisfiedcustomers and lesscrashed projects+ Standish Group: “Onemajor success factor”+ Agile complies to modernmanagement theories+ Agile is more fun- Integrating Agile intocontrolling and contractstructures is still hard- Agile does not work innon-collaborativeenvironments- Agile works best with OOand good tools (Java,Smalltalk)- Agile needs training andexperience- Agile doesn’t supportpeople who don’t knowabout softwaredevelopment (Taylor…)Slide 35; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedAgile Development Increases CustomerSatisfactionCustomer Satisfaction in 159 Organizations100%6%10%90%24%80%35%70%6 (very satisfied)Share of Answers60%50%40%33%32%5 (satisfied)4 (rather satisfied)3 (rather unsatisfied)2 (unsatisfied)1 (completely unsatisfied)30%28%20%16%10%4%4%4%3%0%Traditional ProcessesAgile DevelopmentSource: „Benchmark Review“, 12/2001, Cutter ConsortiumSlide 36; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights Reserved21

4 Vorträge und DiskussionBook Recommendations for Agile Development[Bec05] Kent Beck: Extreme Programming Explained - Embrace Changes - Second Edition;Addison-Wesley, Reading, Massachusetts, 2005; ISBN 0-321-27865-8[Coc02] Alistair Cockburn: Agile Software Development; Addison-Wesley, Reading,Massachusetts, 2002; ISBN 0-201-69969-9[Coc05] Alistair Cockburn: Crystal Clear - A Human-Powered Methodology for Small Teams;Addison-Wesley, Reading, Massachusetts, 2005; ISBN 0-201-69947-8[Fow99] Martin Fowler: Refactoring - Improving the Design of Existing Code; Addison-Wesley,Reading, Massachusetts, 1999; ISBN 0-201-48567-2[Hig00] James A. Highsmith III: Adaptive Software Development - A Collaborative Approachto Managing Complex Systems; Dorset House, New York, 2000; ISBN 0-932633-40-4[KBP02] Cem Kaner, James Bach, Brett Pettichord: Lessons Learned in Software Testing;John Wiley & Sons, New York, 2002; ISBN 0-471-08112-4[Ker05] Joshua Kerievsky: Refactoring to Patterns; Addison-Wesley, Reading,Massachusetts, 2005; ISBN 0-321-21335-1[Pop03] Mary Poppendieck, Tom Poppendieck: Lean Software Development - An AgileToolkit; Addison-Wesley, Reading, Massachusetts, 2003; ISBN 0-321-15078-3[Sch04] Ken Schwaber: Agile Project Management with Scrum; Microsoft Business Solutions,ApS, 2004; ISBN 0-7356-1993-XSlide 37; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights ReservedLinks on Agile Development• Agile Alliance: http://www.agilealliance.org• Adaptive Software Development: http://http.adaptivesd.com• Crystal:http://alistair.cockburn.us/index.php/Crystal_methodologies_main_foyer• Lean Development: http://www.poppendieck.com/• eXtreme Programming: http://www.xprogramming.com/• Scrum: http://www.controlchaos.com, http://www.scrumalliance.org• Refactoring (Martin Fowler): http://www.refactoring.com• Unit Testing:– http://sunit.sourceforge.net/ (Original Framework in Smalltalk)– http://www.junit.org (Java)– http://www.nunit.org (.NET)– http://sourceforge.net/projects/cppunit (C/C++)Slide 38; © Copyright Jens Coldewey, Coldewey Consulting 2007, All Rights Reserved22

4.2 Jens Coldewey: ”Agile Entwicklung aus Management-Sicht“4.2.2 Diskussion• Gemischte AnsätzeGemischte Ansätze, die agilen Prinzipien nur teilweise folgen und nur einzelne Technikenaus agilen Methoden entlehnen sind grundsätzlich möglich. Fraglich ist jedoch, ob dieseauch erfolgreich, bzw. genauso erfolgreich sind.• Öffentlich AuftraggeberDie öffentliche Hand ist als Auftraggeber im Zusammenspiel mit agilen Methoden problematisch.Oft erlauben die damit verbundenen Bürokratien nicht die vertragliche Flexibilität,die agile Methoden benötigen. Es gibt in den Ämtern intern gute Gründedafür, warum sie unflexibel sind, so dass es nicht immer sinnvoll ist, zu versuchen siedavon abzubringen. Manche Behörden sind jedoch flexibel, so dass agile Entwicklungmit diesen unproblematisch ist.• Umgang mit Abweichungen vom vereinbarten Plan seitens des AuftraggebersMan muss sich fragen ob man lieber Vorkehrungen treffen will um im Falle des Scheiternsabgesichert zu sein oder ob man es vorzieht zu versuchen das Scheitern zu verhindern.( ”play to win“ vs. ”play not to lose“)23

4 Vorträge und Diskussion4.3 Dr. Carsten Ohlemeyer und Robert Weidinger: ”eXtreme Programming beider LV1871“4.3.1 FolieneXtreme Programming bei der LV1871Dr. C. Ohlemeyer, „XP-Master“Robert Weidinger, Leiter Bereich ITHot Spots der Software-Entwicklung, 20.6.20071 eXtreme Programming bei der LV1871LV1871InhaltWarum eXtreme Programming?Einführung eXtreme Programming 2002Was bedeutet eXtreme Programming?Ergebnisse nach Jahr 1Zur Nachahmung empfohlen?Projekte 2004 – 2007eXtreme Programming in 2006fFragen?2 eXtreme Programming bei der LV1871LV187124

4.3 Dr. Carsten Ohlemeyer und Robert Weidinger: ”eXtreme Programming bei der LV1871“Warum eXtreme Programming?1999-2002: Z.T. unbefriedigende Softwareprojekte bei der LV 1871(insb. Neuentwicklung)- Massen an Fachanforderungen- Komplexes Datenmodell – zum Teil für die Entwickler nicht mehrbeherrschbar- Releasebau 4-6 Wochen- Lange Releasezyklen von bis zu ½ Jahr- Umfangreiche Fachtests (erst) vor Freigabe eines Releases- Unbefriedigende Systemstabilität- Akzeptanzprobleme auf der internen KundenseiteVentillösung an dieser Stelle: ein Outsourcer.- Von ihm stellt sich heraus, dass er nach „eXtreme Programming“entwickelt.Der Vorstand der LV 1871 beschloss, sich das mal genaueranzusehen ...3 eXtreme Programming bei der LV1871LV1871EinführungeXtreme Programming 20021. Überschaubares Team- 10 Software-Entwickler, 2 Spezialisten für technischeInfrastruktur, 4 Fachleute, 1 Projektleiter2. Kickoff-Veranstaltung außerhalb der LV 1871- eXtreme Programming kennen lernen- Technik diskutieren, Ängste überwinden, Vertrauen insich und den anderen schaffen ...3. Beginn mit einem „einfachen“ Meilenstein- Erst Delta Direkt-Tarifsoftware: 5 Haupt-, 1 Zusatztarife- Dann LV 1871-Tarifsoftware: 20 Haupt-, 7 Zusatztarife4 eXtreme Programming bei der LV1871LV187125

4 Vorträge und DiskussionEinführungeXtreme Programming 20024. Sofort loslegen- Druck auf die Fachseite, mit Anforderungen zu kommen- Keine langwierigen Technik- und Tooldiskussionen (Tests + yagnierleichtern Kurswechsel)- Nach einer Woche das erste Release liefern5. Begleitung durch externe Coaches- Einüben der neuen Arbeitsweise- Benutzen der neuen Werkzeuge5 eXtreme Programming bei der LV1871LV1871Was bedeutet eXtreme Programming?Die wichtigsten Regeln– Offene Arbeitsumgebung: Bei der LV1871zwei große, aneinander grenzende Räume mitTafeln, Flipcharts etc.– Kunde vor Ort: Der (Vertreter des) Kunde(n)ist für die Entwickler stets erreichbar bzw.sitzt im Projektraum.– Kurze Iterationen: Jede Woche ein funktionsfähigesSystem mit neuer, wertvoller Funktionalität.Große Aufgaben herunterbrechen.– Benutzergeschichten: Anforderungen in Formeinfacher Geschichten auf gewöhnlichenKarteikarten. Verfeinerung im Dialog mit demEntwickler.– Tägliches Standup-Meeting: Im Stehenberichtet jeder kurz, was er am Vortaggemacht hat und was er an diesem Tagmachen wird.6 eXtreme Programming bei der LV1871LV187126

4.3 Dr. Carsten Ohlemeyer und Robert Weidinger: ”eXtreme Programming bei der LV1871“Was bedeutet eXtreme Programming?Die wichtigsten Regeln für die Entwicklung– Programmieren in Paaren: Bei der LV1871angewendet aber nur mäßig beliebt.– Gemeinsame Verantwortlichkeit: Der Code„gehört“ dem Team.– Erst Testen: Vor der Entwicklung einer Methodefür das eigentliche System: Testmethoden.Alle Testmethoden zusammen beweisen dieKorrektheit des Systems.– „Refactoring“ (Verbessern vonProgrammteilen): „Schlechter“ Code darfjederzeit ersetzt werden. Testmethodenverhindern Fehlereinbau.– Design für heute („yagni“): Es wird keineunnötig komplexe Funktionalität programmiert,die momentan nicht gefordert ist.– Velocity-Messung: Story-Points pro PT7 eXtreme Programming bei der LV1871LV1871Was bedeutet eXtreme Programming?Was benötigt das Management?– Gute Nerven: Technologieentscheidungenwerden erst getroffen, wenn sie unausweichlichgeworden sind. („Design für heute“)– Vertrauen in die Entwickler: Sie werden dasRichtige tun, wenn sie ein neues Themaangehen.Was kann sich das Management schwervorstellen?– Keine klassischen Fachkonzepte(„Benutzergeschichten“)– Keine Programmdokumentation– Keine Kommentare im Code („Erst Testen“ersetzt Dokumentation und Kommentare)Weitere Herausforderungen– Mitarbeiter können keine„Alleinstellungsmerkmale“ entwickeln8 eXtreme Programming bei der LV1871LV187127

4 Vorträge und DiskussionErgebnisse nach Jahr 1 eXtreme Programming: in der LV1871 als Entwicklungsprozessakzeptiert und geschätzt Seit 08/2003: Tarifsoftware als Offline CD und Online überInternet Das System läuft absolut stabil – zu Beginn wurde diePerformance noch als zu schwerfällig empfunden Im ersten Release: nur 2 (!) Programmierfehler aufgetreten Neuanforderungen und Korrekturen fachlicher Fehler werdenrasch eingebaut Vorgehen „passt gut zur LV1871“9 eXtreme Programming bei der LV1871LV1871Zur Nachahmung empfohlen?Zur Nachahmung empfohlen?Ja! Folgendes sollte man beachten:– Zunächst: Kennen lernen anhandüberschaubarer Projekte undAufgabenstellungen– Am besten: Voraussetzung „grüne Wiese“ odervollständiges Testsystem bereits vorhanden– Gute Werkzeugunterstützung gibt es für diegängigen OO-Sprachen– Besetzen der ersten Projekte mit hochgradigveränderungsbereiten Mitarbeitern– Hohe „Management Attention“, damit derEntwicklungsprozess weiterlebt!10 eXtreme Programming bei der LV1871LV187128

4.3 Dr. Carsten Ohlemeyer und Robert Weidinger: ”eXtreme Programming bei der LV1871“Projekte 2004 – 2007„Infomaske“– Gesammelte Informationen über einenKunden und seine Verträge ausverschiedenen Systemen– Integration von Daten und Oberflächen derEinzelanwendungen– Produktiv seit 5/2005Bestandssystem für FondsgebundeneVersicherungen– J2EE-Anwendung– Anbindung Host Kunden- undVermittlersystem, SAP Inkasso– Produktiv seit 11/2005Neue Releases der Tarifsoftware– Ca. 2 / Jahr11 eXtreme Programming bei der LV1871LV1871eXtreme Programming in 2006f2006– Audit durch externen Coach– Entwickler kommunizieren,dass die XP-Regeln zu wenigeingehalten werden Juni 2006: 2-tägiger Workshopam Schliersee12 eXtreme Programming bei der LV1871LV187129

4 Vorträge und DiskussioneXtreme Programming in 2006f - MaßnahmenRegelEinhaltungMaßnahmeAllgemeinOffeneArbeitsumgebungKunde vor Ort Kein(e) Fachmann/frau direkt in derArbeitsumgebung aber schneller Zugriff+ Teilnahme am Standup-MeetingBenennung des „XP-Master“Kurze IterationenBenutzergeschichtenTägliches Standup-MeetingNeue Versionen zum Test: ja.Manchmal zu umfangreiche Karten.Vereinbarung:Keine Kartelänger als 5 Tage13 eXtreme Programming bei der LV1871LV1871eXtreme Programming in 2006f - MaßnahmenRegelEinhaltungMaßnahmeProgrammieren inPaarenGemeinsameVerantwortlichkeitErst Testen„Refactoring“Design für heute(„yagni“)neinTeilweise ja: z.B. beiFehlern. I.d.R. „a little bitof code, a little bit of test“ (weitgehend) (weitgehend)„Visitor Pattern“: Each person on the teamvisits someone else, once a week. The visitor workson the host’s assignment for two hours, and thevisitor must drive.Ziel „Know-How-Verteilung“keineVelocity-MessungNein (Argument: HoheAbh. von der Schätzung)Übergang auf Function Points14 eXtreme Programming bei der LV1871LV187130

4.3 Dr. Carsten Ohlemeyer und Robert Weidinger: ”eXtreme Programming bei der LV1871“eXtreme Programming in 2006fFlankierende Maßnahmen– Veränderung als Prinzip– Einflüsse „von außen“– „Image-Kampagne“ im Haus– XP als Standard-Vorgehensmodell für die LV1871 XP-Workshops 1-2mal/Jahr Artikel in Hauszeitschrift Entwickler im Unternehmen desCoaches eingesetzt (3 Wo. inSan Francisco)15 eXtreme Programming bei der LV1871LV1871Fragen?Fragen?16 eXtreme Programming bei der LV1871LV187131

4 Vorträge und DiskussionDanke!Danke für die Aufmerksamkeit!17 eXtreme Programming bei der LV1871LV187132

4.3 Dr. Carsten Ohlemeyer und Robert Weidinger: ”eXtreme Programming bei der LV1871“4.3.2 Diskussion• Wie wird Controlling durchgeführt?Zur Fortschrittskontrolle orientiert sich die LV1871 am Stand der Umsetzung von Anforderungen.Ansonsten ist das Entwicklerteam sehr selbstständig. Über viele informelleGespräche war es zudem in der kleinen Gruppe einfach, Informationen über den Entwicklungsstandzu gewinnen.• Qualifikation der MitarbeiterFür den erfolgreichen Einsatz agiler Methoden braucht man nach Einschätzung derGruppe Leute die ihr Handwerk verstehen.• In house Entwicklung und Fachwissen?Fachwissen war stets innerhalb der LV1871 vorhanden. Die Entwicklung fand jedochnicht nur in house statt.• Tests7000 Entwicklertests und 7000 Akzeptanztests wurden geschrieben. Die Abdeckung desCodes beträgt dabei geschätzte 80%. Es war kein Problem Leute dazu zu bringen Akzeptanztestszu schreiben. Der Aufwand war nach Einschätzung der Beteiligten auf dieseWeise letztendlich geringer als wenn keine Akzeptanztests geschrieben worden wären.Es wurde FIT (Framework for Integration Testing) eingesetzt. Das Werkzeug wurdejedoch an die eigenen Bedürfnisse angepasst.33

4 Vorträge und Diskussion4.4 Dr. Peter Braun: ”Experience with an Agile Process in a TelecommunicationProject“4.4.1 FolienExperience with an Agile Process in aTelecommunication ProjectDr. Peter Braun, Nokia Siemens NetworksDr. Christian Legl, Nokia Siemens Networks1 © Nokia Siemens Networks HotSpots_SE / 20070620Outline• The Policy Control Server – It´s role and position in thenetwork• Initial Process – Waterfall• Why did we go agile?• Our Agile process– From a lifecycle point of view– From the development point of view• Some examples on the benefits with the agile process• Current status of the project2 © Nokia Siemens Networks HotSpot_SE / 2007062034

4.4 Dr. Peter Braun: ”Experience with an Agile Process in a Telecommunication Project“Policy Control – It‘s role in the network• Trends in network technology: The world is going towards all IP– Circuit Switched voice replaced by VoIP– New Service emerge:▪ IPTV / Video on demand▪ Real time gaming▪ …• Challenges when introducing these services in the network– reliable Quality of Service– regulatory issues (lawful interception, emergency calls)– service differentiation (user specific policies, different charging models)– new business models for network and service operators– reduce operational costs• All these needs can be addressed by Policy Servers3 © Nokia Siemens Networks HotSpot_SE / 20070620Policy Control – It’s position in the NetworkIMS VoC Gaming, Streaming, …SPRRx, Gq‘pkt-mm-3WSIPolicy ManagerSOAPSpPCS 5000-3GPP PCRF- PCMM PS- ETSI SPDF/A-RACF- Policy Rule EngineGxpkt-mm-2IaReExternal NetworkMediaProxyAAA2G/3GPS-DomainGGSNDMHCMTSCableNetworkEMTA/CMGigasetSX551B-RASxDSL NetworkDMH4 © Nokia Siemens Networks HotSpot_SE / 2007062035

4 Vorträge und DiskussionPCS 5000 is a CableLabs certified Policy ControlServer5 © Nokia Siemens Networks HotSpot_SE / 20070620Initial Process for the first PCS Release –Waterfall• The first release was developed according to the waterfallprocess• But we could not get customer contracts because– Standardization had changed in the meantime– Customers changed their requirements for PCS• We assumed that there still will be a lot of changes incustomer requirements as well as standardization=> We had to be much more flexible6 © Nokia Siemens Networks HotSpot_SE / 2007062036

4.4 Dr. Peter Braun: ”Experience with an Agile Process in a Telecommunication Project“Why Did We Go Agile? –Requirements for the Second Release• Pre-deliveries had to be done (qualification/trials)• Requirements and their priorities were not fixed at projectstart• Requirements change often in PCS market (newtechnology, immature market)• PCS has to be provided for different markets (MobileNetworks, Cable Networks, DSL Networks). Prioritieschange customer driven=> The water fall process did not fit7 © Nokia Siemens Networks HotSpot_SE / 20070620Principle of the Agile Development ProcessesTraditional “Waterfall” Processplanninganalysis design implementation testingclosureAgile Processsprint………sprintplanning development closuredevelopment8 © Nokia Siemens Networks HotSpot_SE / 2007062037

4 Vorträge und DiskussionKey Elements of Agile DevelopmentStrong customer orientation and involvementEmbracing change, no Big Upfront Requirement FreezeFocus on business valueEarly addressing of riskShort release cyclesShort iterations with “potentially shippable” (tested) increments9 © Nokia Siemens Networks HotSpot_SE / 20070620Benefits / RisksBenefits:• Flexibility to react to changing customer and market needs• Improved ability to manage innovation and control risks• Predictable, reduced time-to-market• Increased product quality• Early look and feel of the product visible• Avoid surprises• Transparency (progress, quality)Risks• Loose the focus – too many changes10 © Nokia Siemens Networks HotSpot_SE / 2007062038

4.4 Dr. Peter Braun: ”Experience with an Agile Process in a Telecommunication Project“Transformation of the Product Lifecycle WaterfallProcess into the Agile ProcessWaterfall Process• Definition of requirements• End of Analysis &Stakeholder funding• End of Load Bring up• Completion of SystemIntegration• Pilot Release• World Market ReleaseAgile Process• Prioritized Feature List+ stakeholder funding• Pilot Release• World Market ReleaseDefined mapping and synchronization points between“Waterfall” and “Agile” pre-requisite to get approval11 © Nokia Siemens Networks HotSpot_SE / 20070620Scope of the Initial Milestone in the Agile ProductLifecycle to Get Stakeholder FundingBusiness CaseInitial Feature set prioritized:– Must -- Project commits to realize the feature– Should -- High possibility that the feature will be realized– Can -- Low priority that the feature will be realized– won‘t -- Feature will not be realizedPriorities can be adopted due to new requirementsNew features may be added later• Agreed Effort and resource planning• Risk list• Agreed planning for Sales Enabling and Offer Process• Definition of quality targets12 © Nokia Siemens Networks HotSpot_SE / 2007062039

4 Vorträge und DiskussionAgile Development Methods Applied• Sprint duration: currently 6 weeks• Scrum (largely applied)– product and sprint backlog– Daily Scrum in teams plus weekly Scrum of Scrums– Sprint planning and review sessions• eXtreme Programming (applied with care)– MUST: Continuous Integration– MUST: Automated integration and unit tests– Test Driven Development for new code– Weak code ownership (not collective)– Pair programming (for critical areas and knowledge sharing)13 © Nokia Siemens Networks HotSpot_SE / 20070620It was the right decision to go „Agile“Some changes we took during the progress of the project:• Suspend pre-standard Mobile Policy Server in trial statuswait for 3GPP standard for product• Take into account latest Packet Cable Multimediaspecification to get cable certification• Customer trials before product release• Early Interoperability tests and integration with partnerspossible• Platform change to benefit from better cost position• Extend the scope: new “target networks” DSL, WiMaX• …Traditionally every change needs formal change request14 © Nokia Siemens Networks HotSpot_SE / 2007062040

4.4 Dr. Peter Braun: ”Experience with an Agile Process in a Telecommunication Project“It was the right decision to go „Agile“ (cont.)Pre-deliveries we did during the progress of last PCSrelease• PCS within LTE demonstrator in May 06• Cable certification in June 06• PCS for Perfect Voice Solution in August 06• Customer trials are out for the major use cases.• Live operation is expected beginning of 200815 © Nokia Siemens Networks HotSpot_SE / 20070620Summary• Waterfall process was not flexible enough for our newPolicy Control Server• PCS is now realized in agile manner mainly in order to– be able to early support trials– flexibly react on market requirements• Success factors for Agility– Good customer relationship▪ to use early customer feedback▪ while not loosing the focus– A self responsible, experienced team– Continuous improvement– State of the art development tooling (continuous integration,automated regression testing, collaboration and planning)16 © Nokia Siemens Networks HotSpot_SE / 2007062041

4 Vorträge und Diskussion4.4.2 Diskussion• WerkzeugeEinige agile Planungstools sind momentan in der Einführung. Es gestaltet sich jedochschwierig das komplizierte Projektsetup in den Tools abzubilden. Zudem ist es schwieriggeeignete Werkzeuge für Kommunikationstests zu finden, da es nur wenige auf demMarkt gibt.• Welche Qualitätsmetriken wurden eingesetzt?Zur Bewertung der Korrektheit wurden Tests, Zahl der offenen Fehler, Codeabdeckungdurch die Tests und Anzahl der build failures hinzugezogen. Andere Qualitätsmerkmalewie z.B. Wartbarkeit wurden nicht gemessen.• Wie wurde die Methode eingeführt?Die Einführung wurde durch interne Coachs begleitet. Es gab einen Kick-Off Workshopbei dem Vertreter aller beteiligten Gruppen teilnahmen. Zudem wurden Weiterbildungendurchgeführt. Einzelne Mitarbeiter erwarben Scrum Master Zertifikate.42

4.5 Dr. Markus Pizka: ”Lean Software Production“4.5 Dr. Markus Pizka: ”Lean Software Production“4.5.1 FolienLean Software ProductionMarkus Pizka20. Juni 2007„One per pixel“itestra• Robert C. Martin, 8. Mai 2003• 50 developers working on a simple GUI• several dozen dialog boxes• five years or more• 250 man-years, 25 man-decades, 2.5 man-centuries!• one developer per pixel … wrote code for his pixel• a large fraction of projects are overstaffed by a huge factor• I wonder if we'd get a lot more done if 90% of us quitM. Pizka 243

4 Vorträge und DiskussionErfahrungenitestra• Projekt 1• ca. 5 Jahre (>100 PJ)• 1200 Use Cases, keine SoftwareABM• Projekt 2• Versuch 1- 16 Projektmanager, Architekten, Designer, Modell-/Dokumentierer, …- 3 Programmierer- 1 Jahr (ca. 20 PJ)- ca. 150 (ungelesene) Dokumente, kein nutzbares System• Versuch 2- 6 MA, 11 Monate (ca. 7 PJ)- Zielorientierung- Ersparnis 65% + AuszeichnungM. Pizka 3Begründung?itestra• Siehe Literatur Jones, Boehm et al: „Faktor 10-20“• Skills, Motivation, Verantwortung• Ergebnisorientierung ~ Unterstützung Business durch Software• Zielführung versus Requirements-Management• Produktqualität versus Prozessqualität• Verzicht auf Flexibilität, ausführliche Konzepte, Modelle, Doku., …• Asynchrone Kommunikation• Peer-Reviews• Generierung, Tools (Fremd- / Eigenentwicklung)• (Längere) Iterationen – Early• Klimageräte und Ruhe!M. Pizka 444

4.5 Dr. Markus Pizka: ”Lean Software Production“Vertikale Projektorganisationitestra1Projektleiter3 Software Software FachIngenieur Ingenieur Experte12AnalyseKonzeptImplement.ModultestKoordinator (optional)AnalyseKonzeptImplement.ModultestProzessFunktionTestsSoftwareIngenieurxAnalyseKonzeptImplement.ModultestSEManagerVorgehenCMKMTest-MgmtSE-ToolsSoftware-ArchitektPlattform, Richtlinien, QS2M. Pizka 5Agil?itestra• Keine „agile Methode“• Kein Test-First• Keine User Stories• Kein Stand-Up Meeting, Pair Programming• Kaum „Refactoring“ – aber konsequentes Löschen• Teilweise Konzeptarbeit• Optimierung von Beginn an• Im Umfeld Systemprogrammierung i.w. unbekannt• Betriebssysteme, Compiler, High Performance Computing, …• Microsoft (Research), IBM Labs, OpenSource, …• „Glückliche“ Programmierer M. Pizka 645

4 Vorträge und DiskussionGlaubensfragen?itestraContra AgilChaotisches HackertumNur für kleine ProjekteProduces unmaintainable systems (MML)Feste Requirements, fester Pries (nur so)Pro AgilFührt zu höherer QualitätNachträgliches Refactoring leichtGrundsätzlich schnellerÖkonomische Realität –Produktivität?M. Pizka 7EffizienzWaterfall (Royce)1970CleanroomSpiral Model1980 1990 2000Open Source, E-BizV-ModellRUPAgile Manifestoitestra• Historie• Software wiederholbar zu kalkulierbaren Kosten / Zeit realisieren• Große Teams, unterschiedliche Qualifikation• Ordnung (Rollen, Abläufe), Disziplin (Regeln, Papier), Kontrolle• Mehraufwand Ineffizient!• Verbesserung der Ausbildung, Technische Innovationen• Nicht nur kalkulierbar, Zeit/Kosten entscheidend!LeanM. Pizka 8Zeit46

4.5 Dr. Markus Pizka: ”Lean Software Production“These 1itestraEinsatz eines Agiles VorgehensmodellEffizenzM. Pizka 9Analogie Qualitätitestra• Fehler pro Function Point in Relation zu CMMi-LevelCMMi LevelMinAvgMax(initial) 10,1500,7504,50020,1200,6243,60030,0750,4732,25040,0230,2281,200(optimized) 50,0020,1050,500C. Jones ´03Vorgehensmodell allein schafft weder Qualität noch Effizienz!M. Pizka 1047

4 Vorträge und DiskussionLeanitestra• „MIT 5-Million-Dollar 5-Year Study“„Who‘s Ahead in … Auto Industry And Why“„What Other Industry Can Learn“• Aus Notwendigkeit von Entwicklern• Optimierung FertigungsprozessStartOp 1 Op 2Ende• Durchlaufzeit (Lead-Time)• Software-Vorgehensmodell ~ FertigungsprozessM. Pizka 11Lean Principlesitestra• Value-Added Activity – zahlt der Kunde für Aktivität?• Bug Fix V EUR• Warten W EUR• Restrukturieren X EUR• Interne Meetings Y EURSumme:ZZZ EUR• %VAT = ( Operation-Times) / Lead-Time * 100• in der Regel < 5%• Ziel der Prozessoptimierung: %VAT = 100%• Lead-Time hat und • Minimierung Mittel: Effizienz• Reduzierung Variation: Zuverlässigkeithttp://ohmyapt.apartmentratings.com/images/handing_money.jpgM. Pizka 1248

4.5 Dr. Markus Pizka: ”Lean Software Production“Verschwendung?InventoryMotion?WaitingitestraTransportationTIM WOODSis no friendof wasteOverproductionSkillsDefectsOverprocessingM. Pizka 13KaizenitestraKlassische ProzessverbesserungKaizenMerwan Mehta, 2007• Schrittweise Perfektion statt Innovation• Führungskräfte + MitarbeiterM. Pizka 1449

4 Vorträge und DiskussionLean Principles ctd.itestra• Just-in-Time Pull• Kompromislose Qualität von Beginn an• Fehlerfrei• Mängel: Identifikation und Beseitigung an der Wurzel• Einbindung und Bevollmächtigung der Mitarbeiter• Qualifikation – Ausbildung, Ausbildung, Ausbildung, …• Partizipation an Erfolg• „What get‘s measured gets controlled“M. Pizka 15Lean Software Developmentitestra• 22 Werkzeuge, u.a.• Seeing Waste• Value Stream Mapping• 7 Prinzipien, u.a.• Eliminate Waste• Amplify Learning… test soon?M. Pizka 1650

4.5 Dr. Markus Pizka: ”Lean Software Production“Lean = Agile?itestra• Agile Lean?• TestFirst – Antwort auf Q-Probleme?• Iteration – Undo / Wiederholung?• (Starrer) Prozess – „fix process“• YAGNI – Antizipation?• Invarianten statt Änderbarkeit!• Skalierung Kommunikation – Amdahl‘s LawM. Pizka 17Amdahl‘s LawitestraM. Pizka 1851

4 Vorträge und DiskussionLean = Agile?itestra• Lean Agile?Lean ist kein Vorgehensmodell sondernein Managementparadigma.• These 2Nicht der Prozess ermöglicht Effizienzsondern Ökonomie gestaltet den Prozess.M. Pizka 19Software KPIsitestraEconomics• Productivity in RFSLOC / PT (5-300)• Bugs per kSLOC (0,5 – 20)• Annual TCO per SLOC (0,1 – 10 EUR)System• Code redundancy (15% - 90%)• Literal redundancy (2 - 18)• SLOC per FP 15-100• ”IF“ per kSLOC (30 - 70)• Performance O(c • n x )Organization• Team members knowing software (0-10)M. Pizka 2052

4.5 Dr. Markus Pizka: ”Lean Software Production“Resuméeitestra• Die Zukunft ist aufgrund Wettbewerb lean!• Agile Methoden sind ein wichtiger Schritt• Business Value - Ergebnisorientierung• Produktqualität• Zentrale Voraussetzungen für Fortentwicklung:• Messen• Hersteller benötigt Prozessverantwortung• Leistungssensibilität bei AGM. Pizka 2153

4 Vorträge und Diskussion4.5.2 Diskussion• Lean Development vs. Lean ProductionAgile Methoden sind dem Lean Development näher als der Lean Production. Daher sollteein Vergleich eher mit diesem gezogen werden. Dagegen lässt sich jedoch anführen, dassProzessmodelle stets Produktionsprozesse beschreiben.• KommunikationsformUneinigkeit bestand darin, inwiefern Meetings durch schriftliche Kommunikation ersetztwerden sollten. Lange Meetings mit vielen Personen werden als Verschwendung vonArbeitskraft angesehen. Daher sollten Meetings kurz gehalten werden. Inwiefern dies beigroßen Teams möglich ist und inwieweit auf schriftliche Kommunikation ausgewichenwerden soll ist ein Diskussionspunkt.• IterationenIterationen sind nützlich wenn sich zwischen Iterationen Änderungen ergeben. Wenndem jedoch nicht so ist, sind sie nicht gezwungenermaßen sinnvoll. Wenn etwas imvornherein planbar ist, dann ist es auch sinnvoll die Planung so durchzuführen. Eingutes Beispiel hierfür sind eingebettete Systeme.• Testen und InspektionenDer Aufwand, der mit Tests verbunden ist, ist üblicherweise sehr hoch. Auch dieser Aufwandmuss gerechtfertigt werden. Wenn ein Großteil der Tests niemals etwas entdeckt,muss man sich fragen, ob diese wirklich sinnvoll sind. Sinnvoller wäre es unterschiedlicheBereiche des Systems je nach Bedarf unterschiedlich intensiv mit Tests abzudecken.Zudem sollte die Möglichkeit von Inspektionen nicht vergessen werden. Inspektionenkönnen Probleme aufdecken, die durch Tests nicht gefunden werden. Testen allein genügtalso nicht. Eine Praktik aus den agilen Methoden, die versucht diesen Aspektabzudecken, ist die Paarprogrammierung.• Anpassung des ProjektsDer angewendete Prozess sollte stets die Spezifika des jeweiligen Projekts berücksichtigen.Der Prozess sollte also stets an das jeweilige Projekt angepasst werden. Dabei istes nicht förderlich unter allen Umständen agil zu entwickeln, sondern eben nur wenndies für das Projekt als günstig erscheint.54