Course Summary and Reminders

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 http://agileconsortium.pbwiki.com/Self-Organization-in-Scrum

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

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 • ...

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

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 http://www.implementingscrum.com/2008/02/19/

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 http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

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 • Ask the customer • 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