1. Course Summary and Reminders
Part 1: Develop the Software Right
Continuous Practices
Daily Practices
Part 2: Develop the Right Software
Practices per Iteration
Practices per Release

2. Summary Software development is a composite activity
It should be solid and modifyable
It should respond to a user demand
Part 1: Develop the Software Right
Continuous Practices
Daily Practices
Part 2: Develop the Right Software
Practices per Iteration
Practices per Release
All parts must be understood for a successful product development
They play together, but require different focus

3. Levels of concern D C B A

4. Part 1: Develop the Software Right
What are the process and engineering practices that allow us to build solid, changeable software with sustainable quality
Continuous practices
Daily practices

5. Continuous Practices Programming Pair programming TDD Refactoring
Agile design
Architecture

6. Programming
Good engineering implicitly assumed good, basic craftmanship
Programming education
Experience
Are not taught in this course
This course focuses on
Additional engineering principles and practices

7. Pair Programming Discussion partner and continuous inspection
Navigator
Driver
Swap roles frequently
Distribution of knowledge and competence

8. TDD Set the goals in advance Example driven development
Helps focus development on goal
Explicit goals promote design
Uncle Bob’s three laws of testing
What are they?
TDD mantra
Red
Green
Refactor
Uncle Bob’s three laws on next slide
Do not write a line of production code until you have written a failing unit test
Do not write more of a unit test than is sufficient to fail, and not compiling is failing
Do not write more production code than is sufficient to pass the test

9. Uncle Bob’s Three Laws of Testing
Do not write a line of production code until you have written a failing unit test
No production code can be written until there is a failing unit test
Do not write more of a unit test than is sufficient to fail, and not compiling is failing
So you cannot write very much of the unit test before you write production code
Do not write more production code than is sufficient to pass the test
You cannot write a little bit of unit test and then run off and write production code.
These three laws lock you into a cycle that is perhaps 30 seconds long
You are actually writing unit tests and production code concurrently, with the tests perhaps 30 seconds to a minute ahead

10. Refactoring Continuous repayment of technical dept
Reorganizing (part of) system while maintaining interface
Only refactor a ”green” system
Refactor in tiny steps
While rerunning tests frequently to detect broken system early
Example: To remove redundancy
Successively change the two occurrences to be identical
Extract one of the occurrences to a separate method
”Extract method” refactoring
Let the other occurrences call that new method
Remove redundant copies
Requires good tools

11. Agile Design Form and shape on a lower level Agile practices
Design patterns
Agile design principles

12. Agile Practices YAGNY DRY PLA ...
YAGNY = You Ain’t Gonna Need It, XP practice
DRY = Don’t Repeat Yourself, Andy Hunt, The Pragmatic Programmer
PLA = Principle of Least Astonishment

13. Design Patterns Template method Facade Abstract factory Factory method
Singleton
Observer
...

14. Agile Design Principles
SPR
OCP
LSP
DIP
ISP
UML
Group design sessions on whiteboard
Static structures: Packages and classes, domain classes
Dynamic structures: Communication diagrams with objects
SPR = Single responsibility principle
OCP = Open/closed principle
LST = Liskov substitution principle
DIP = Depencency inversion principle
ISP = Interface segregation principle

15. Architecture Form and shape on a higher level Protected variations
Identify and isolate points of change behind a stable interface
But only once it has manifested itself
Architecture patterns
Three layer architecture
No circular dependencies
Separate presentation and Model-view-controller
Domain model and Layer supertype
Data mapper and Identity map
Relational to object mapping
Lazy loading
Dummy test database

16. Daily Practices Stand-up meeting Daily integration Scrum Master tasks
Daily burndown
Work towards sprint goals

17. Stand-up meeting Time box: 15 minutes Answer three questions
What was done since last meeting
What is planned till next meeting
What are the impediments that prevent me from reaching my goal
Schedule a separate meeting for discussion issues that arise

18. Daily integration Be prepared to deliver On a separate machine
Build the system from scratch every time
Automate the build
Use a source control system to save changes
Commit your changes before you leave for the day
Integrate at least once per day
Or after each commit
Automatically or manually

19. Scrum Master tasks Facilitation
Help team members practice and understand the process
Remove impediments
For instance: Integration server does not build web projects
Allow team members to work uninterrupted
Catch interventions
When a user wants a new, important feature ”now”

20. Daily burndown Radar reading A visible display of the current status
Updated for each daily stand-up meeting

21. Work towards sprint goals
Enforced by daily standup
What have I done? Should be on the spring backlog
What am I planning to do?`Should be on the sprint backlog
No YAGNI
Unplanned activities steal resources from the planned ones
Will make you fall behind schedule
Your nice feature may be included at a later stage

22. Part 2: Develop the Right Software
What are the process and engineering practices that allows us to build software that corresponds to the real needs of the stakeholders
There are different stakeholders
User
Customer
Experts
All represented by Scrum ”Product Owner”
Practices sprint by sprint
Practices release by release

23. Sprint by Sprint
Planning
Negociation
Ask the customer
Retrospect

24. Planning: Product backlog and User Stories
A prioritized list of business level features wanted in the product
High priority items at the top, to be done first
Items for near future more in detail
Express the needs as User Stories
Set focus on the stakeholder, the need, the purpose
As a <stakeholder>, I need to <feature> in order to <purpose>
As a reserver, I need to see available times in order to make a new reservation
A user story is a reminder to talk to the customer
It is not a complete specification for a feature
A user story typically only covers one or a few scenarios of a use case
Or a particular quality aspect

25. Planning: Estimations
Cone of uncertainty
The further away an event is in the future, the more uncertain it is
Make detailed plans only for the near future
Estimate the user stories for the next iteration
Discuss each feature with the customer before estimating it
To make sure you understand it sufficiently well to make an estimate

26. Negociation: Customer Owns Scope and Importance
The estimates for the next sprint may exceed the velocity
Typically, the PO will think it is easier than you
Negociate with the PO to bring scope within velocity
Remove features
Split features and include only a part
Reduce scope of features
Change priority
Estimate is yours

27. Negociation: Team Owns Estimate
Learn to know yourself
Keep track of your velocity
The number of story points completed per sprint
Do not accept forcing speed
Apparently possible, but
Results in poorer quality
Results in technical debt
When under pressure
Negociate scope
Time and quality are preset
Scope
Non-negociable
Quality
Time
Predefined sprint length

28. Ask the customer During the sprint, you need to make decisions
Represented by the Product Owner
Don’t make your own assumptions
You will more often than not be wrong
The right answer depends on business practices
The customer pays your salary
The customer is always right
Even when he/she is wrong?
To discuss in class?

29. Retrospect The most important factor for continuous improvement
What went well, what can we improve
Don’t choose many improvement issues at the same time
Focus on one or two issues so that you can manage it
Team is self-organizing
”It would have helped us to have the database on the database server instead of in a file with an absolute path”
It is up to the team to decide to do that

30. Release by Release Release rate For instance each third sprint
Roughly estimate the scope for each release
“Supersprint”

31. Release Rate and Release Scope
A larger system may go through many releases
A rough, initial release plan may se set up early
The customer may want staged releases
Group features that need to be released together
Prioritize groups of features in a tempted release plan
Plan a release frequencey, for instance for each 3rd or 4th sprint
Release 1: Features 1a, 2, 4c-d
Release 2: Features 1b and d, 3, 4a
etc
Kniberg, Ch 12, Mike Cohn, Agile Estimating and Planning

32. Make release estimates
Make a rough, but realistic estimate of the first release
Similar to sprint planning meeting in story points, but more coarse grained
If possible, calibrate velocity and estimate time for release 1
Start negociating scope vs time
Make a similar, but rougher plan for the next 2 releases
Only first release is broken down in sprints now
Remember
The release plan is a preliminary forecast, not a commitment
Adjust and renegociate as soon as deviations are discovered
Time box your release planning
To prevent it going out of hand
Make your effort visible in the current sprint plan