1 / 32

Course Summary and Reminders

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. Summary. Software development is a composite activity It should be solid and modifyable

valariep
Download Presentation

Course Summary and Reminders

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related