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