Advanced C++ Programming Seminar Anton Kaiser, Summer Term 2012
Advanced C++ Programming Seminar Anton Kaiser, Summer Term 2012 1. 2. 3. 4. 5. 1. 2. 1. 2. 3. 4. 1. 2. 3. 4. 5. 6. Overview Agile Manifest Agile Methods Extreme Programming Values Principles Rules and Practices Lifecycle Scrum Backlogs Sprints Daily Scrum Review and Retrospective Summary Common Mistakes Remarks and Conclusions Sources 2 We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan 3 Extreme Programming (XP) Scrum Agile Unified Process (AUP) Crystal Clear Feature Driven Development (FDD) GSD Kanban (development) Open Unified Process (OpenUP) … 4 1. 2. 3. 4. 5. 1. 2. 1. 2. 3. 4. 1. 2. 3. 4. 5. 6. Overview Agile Manifest Agile Methods Extreme Programming Values Principles Rules and Practices Lifecycle Scrum Backlogs Sprints Daily Scrum Review and Retrospective Summary Common Mistakes Remarks and Conclusions Sources 5 Extreme Programming is based on ◦ ◦ ◦ ◦ ◦ Simplicity Communication Feedback Courage Respect Extreme Programming ◦ Brings the whole team together with simple practices ◦ Gives feedback to the team and enables it to tune the practices to their unique situations 6 Communication ◦ ◦ ◦ ◦ ◦ On-site customer User Stories Pair Programming Collective Ownership Daily Standup Meetings Simplicity ◦ KISS – „Keep it simple, stupid“ ◦ YAGNI – „You ain‘t gonna need it“ ◦ DTSTTCPW – „Do the simplest thing that could already work“ 7 Feedback ◦ ◦ ◦ ◦ Feedback from code by unit-testing regularily Short iteration cycles for continuous feedback Integrating the customer for important feedback The more feedback on all levels the better Courage ◦ Open communication with all team members, including the customer ◦ Prototypes shall be thrown away ◦ Refactoring 8 Embrace change ◦ It is better to learn how to react to changes than to predict the future Incremental Changes ◦ Small steps are faster and easier Quality ◦ The team has to be proud of its work Communication ◦ Use the collective knowledge of the whole team 9 10 Managing ◦ ◦ ◦ ◦ ◦ ◦ Provide a dedicated open work space Set a sustainable pace Start the day with a stand up meeting Measure the project‘s velocity Move people around Fix XP when if breaks 11 12 Coding ◦ ◦ ◦ ◦ ◦ ◦ ◦ The customer is always available Code the unit tests first Agree on collective ownership Code must be written to agreed standards All production code is pair programmed Integrate often Refactor whenever and wherever possible 13 Designing ◦ Simplicity ◦ Choose a system metaphor A vision for the whole system Also means choosing appropriate names and locations for functions ◦ Write class-responsibility-collaboration cards (CRC cards) for brainstorming ◦ No functionality is added early 14 Testing ◦ All code must have unit tests ◦ All code must pass all unit tests before it can be released ◦ When a bug is found, tests are created ◦ Acceptance tests are run often 15 16 17 18 19 1. 2. 3. 4. 5. 1. 2. 1. 2. 3. 4. 1. 2. 3. 4. 5. 6. Overview Agile Manifest Agile Methods Extreme Programming Values Principles Rules and Practices Lifecycle Scrum Backlogs Sprints Daily Scrum Review and Retrospective Summary Common Mistakes Remarks and Conclusions Sources 20 Scrum ◦ Is an empirical process control theory (EPC) Iterative, incremental approach Optimize predictability and control risk ◦ Can be seen as a framework within which you can employ various processes and techniques The three legs that uphold EPC are ◦ Transparency ◦ Inspection ◦ Adaption 21 22 23 The daily scrum ◦ Takes 15 minutes at the start of each day ◦ Every team member answers to three questions: What have I accomplished since the last daily scrum? What got in my way? What will I do until the next daily scrum? 24 25 26 Changing the basics ◦ ◦ ◦ ◦ „Let‘s make each sprint last 6 Weeks for the next 5 months“ „Daily scrum will be every second day“ „All features have first priority to me!“ Prolonging the daily scrum into endless technical discussions Keeping distance from the Product Owner ◦ „He is too busy for our daily scrum“ ◦ Switching and merging roles Product owner + scrum master = project manager Team ◦ Creating huge teams (> 9 developers) ◦ Tools instead of oral communication ◦ Let the „rock stars“ do the whole work 27 Tools ◦ „I don‘t need to understand scrum, my tool will manage everything for me“ ◦ „Why use flipcharts? We have expensive tools for communication!“ ◦ Not making use of scrum tools at all 28 Artifacts ◦ Product Backlog No preparation for sprint planning meetings User stories without any statement Stories are too big ◦ Sprint Backlog Not visible in the daily scrum Too many tasks „in progress“ ◦ Burndown Chart Not visible in the daily scrum Used as management control instrument instead of a helping instrument to the team Not drawing consequences from unfavorable progress chart 29 1. 2. 3. 4. 5. 1. 2. 1. 2. 3. 4. 1. 2. 3. 4. 5. 6. Overview Agile Manifest Agile Methods Extreme Programming Values Principles Rules and Practices Lifecycle Scrum Backlogs Sprints Daily Scrum Review and Retrospective Summary Common Mistakes Remarks and Conclusions Sources 30 Agile programming = common sense! Easier and faster reaction to changes Always having a compiling and running program is great! Less bugs thanks to constant testing Satisfaction with both programmers and customers Heavy focus on communication Hard to apply with offshore development 31 1. 2. 3. 4. 5. 6. 7. Agile Principles, Patterns, and Practices in C#, Martin C. Robert, Prentice Hall, 2006 http://www.XProgramming.com http://www.it-agile.de http://www.agile-process.org Presentation „Überblick über XP“ by Dr. Martin Geier, methodpark AG, 2011 Presentation „Anleitung zum Ruinieren eines Scrum-Teams“, Udo Wiegärtner, .NET day Franken 2012 Video „Explaining Scrum in less than 120 seconds“ (http://youtu.be/WxiuE-1ujCM) 32
© Copyright 2024