ESSAP Agile Loops

354 views

Published on

Published in: Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
354
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

ESSAP Agile Loops

  1. 1. Agile loops from jargon to understanding (cc) F. Gobbo, S. Gentilini, F. Bertone, V. Del Bianco, please refer to: federico.gobbo@uninsubria.it Dipartimento di Informatica e Comunicazione Università degli Studi dell'Insubria
  2. 2. Acknowledgements <ul><li>This is a derivative work from the talk &quot;XP loops&quot; </li></ul><ul><li>presented in XP BE 2007 </li></ul><ul><li>by </li></ul><ul><ul><li>Vera Peeters (Tryx) </li></ul></ul><ul><ul><li>Pascal Van Cauwenberghe (NAYIMA) </li></ul></ul>
  3. 3. Wannabe Agile?
  4. 4. What Agile is not <ul><ul><li>Not a panacea. </li></ul></ul><ul><ul><li>Not a silver bullet. </li></ul></ul><ul><li>It doesn't tell you if a project is worth starting. </li></ul><ul><li>It tells you how to start and when to stop in time. </li></ul><ul><li>(c) artwork / graphic by Michael Whitehead for Next 16-9-2003 </li></ul>
  5. 5. Ready to start?
  6. 6. Start from your (onsite) customers... Business decisions are taken by the customers Technical decisions are taken by the developer team ...and trust!
  7. 7. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul>
  8. 8. User stories <ul><ul><li>Customers tell: </li></ul></ul><ul><li>                     the value </li></ul><ul><ul><li>Developers tell: </li></ul></ul><ul><li>                       the price </li></ul>Don't show the kitchen, serve the dishes!
  9. 9. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul>
  10. 10. Small releases <ul><ul><li>Steering and adapting </li></ul></ul><ul><li>               </li></ul><ul><ul><li>Short-time planning </li></ul></ul><ul><ul><li>release = iteration (XP) </li></ul></ul><ul><ul><li>release = sprint (Scrum) </li></ul></ul><ul><ul><li>Timeboxing everywhere </li></ul></ul><ul><li>                       </li></ul>Be realistic, don't pretend to look in a crystal ball!
  11. 11. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul>
  12. 12. Planning game <ul><li>How much business  value can you deliver in the next release?              </li></ul><ul><ul><li>Pair writing </li></ul></ul><ul><ul><li>Product backlog </li></ul></ul><ul><li>                       </li></ul>Delivering business value early and often
  13. 13. Principles and values <ul><ul><li>Collaboration       instead of:      negotiation </li></ul></ul><ul><ul><li>Communication   instead of:      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of: overdesign & unused features </li></ul></ul>
  14. 14. Sustainable  pace <ul><li>Find your natural  rhythm of work </li></ul><ul><li>(for all involved!) </li></ul><ul><ul><li>Think about the long run </li></ul></ul><ul><ul><li>No overtime </li></ul></ul><ul><li>                  </li></ul>Our suggestion: the Pomodoro Technique
  15. 15. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul>
  16. 16. Daily Standup  Meetings <ul><li>3 questions: </li></ul><ul><ul><li>What I have done? </li></ul></ul><ul><ul><li>What I will complete today? </li></ul></ul><ul><ul><li>I need help with... </li></ul></ul><ul><li>                  </li></ul>Keep it short!
  17. 17. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul><ul><ul><li>Small, realistic chunks of work every day </li></ul></ul>
  18. 18. Pair Programming <ul><li>Two programmers work together at one keyboard: driver types in code, observer- navigator reviews code and considers the strategic direction of the work. Not for everyone... </li></ul>
  19. 19. Pair Programming and Productivity... <ul><li>PairProgramming reduces productivity! That would be true if the most time consuming part of programming was typing... Martin Fowler </li></ul><ul><ul><li>Start with a reasonably well-defined task </li></ul></ul><ul><ul><li>Agree on one tiny goal at a time </li></ul></ul><ul><ul><li>TDD please </li></ul></ul><ul><ul><li>Rely on and support your partner </li></ul></ul><ul><ul><li>Sync up frequently </li></ul></ul><ul><ul><li>Be especially courteous </li></ul></ul><ul><ul><li>Take a moment to celebrate </li></ul></ul><ul><ul><li>Often switch roles </li></ul></ul>
  20. 20. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul><ul><ul><li>Small, realistic chunks of work every day </li></ul></ul><ul><ul><li>Fun and quality    instead of   heroism </li></ul></ul>
  21. 21. Unit Tests <ul><li>Automated test that validates that units of source code are working properly. </li></ul>Test cases written in the same language as the production code. Each test case is independent from the others.
  22. 22. So what? <ul><ul><li>Safety Net </li></ul></ul><ul><ul><li>Facilitates change </li></ul></ul><ul><ul><li>Facilitates refactoring </li></ul></ul><ul><ul><li>Simplifies integration </li></ul></ul><ul><ul><li>Documentation </li></ul></ul><ul><ul><li>Design </li></ul></ul><ul><ul><li>Separation of interface from implementation </li></ul></ul><ul><ul><li>Force code being testable </li></ul></ul><ul><ul><li>... </li></ul></ul>
  23. 23. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul><ul><ul><li>Small, realistic chunks of work every day </li></ul></ul><ul><ul><li>Fun and quality    instead of   heroism </li></ul></ul><ul><ul><li>Quality work every time </li></ul></ul>
  24. 24. Test Driven Development <ul><li>without inmagine.com </li></ul><ul><li>with forbes.com </li></ul>
  25. 25. Test Driven Development <ul><li>write a test implement code  to pass the test refactor </li></ul><ul><li>testdriven.com </li></ul><ul><li>forbes.com </li></ul>
  26. 26. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul><ul><ul><li>Small, realistic chunks of work every day </li></ul></ul><ul><ul><li>Fun and quality    instead of   heroism </li></ul></ul><ul><ul><li>Quality work every time </li></ul></ul><ul><ul><li>Technical excellence </li></ul></ul>
  27. 27. Refactoring <ul><li>without </li></ul><ul><li>with </li></ul>
  28. 28. Refactoring <ul><li>clean code that works! get rid of smelling code: duplication large classes large methods long parameters list etc etc.. </li></ul><ul><li>  </li></ul>
  29. 29. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul><ul><ul><li>Small, realistic chunks of work every day </li></ul></ul><ul><ul><li>Fun and quality    instead of   heroism </li></ul></ul><ul><ul><li>Quality work every time </li></ul></ul><ul><ul><li>Technical excellence </li></ul></ul><ul><ul><li>Simplicity </li></ul></ul>
  30. 30. Continuous Integration <ul><ul><li>Small steps </li></ul></ul><ul><ul><li>Small changes </li></ul></ul><ul><ul><li>Small problems </li></ul></ul>Integrate frequently (multiple integrations per day). Each integration is verified by an automated build.
  31. 31. Not so easy... <ul><li>Once you are there, great benefits: </li></ul><ul><ul><li>Control </li></ul></ul><ul><ul><li>Visibility </li></ul></ul><ul><ul><li>Early warnings </li></ul></ul><ul><ul><li>Availability of a &quot;current&quot; build </li></ul></ul>
  32. 32. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul><ul><ul><li>Small, realistic chunks of work every day </li></ul></ul><ul><ul><li>Fun and quality    instead of   heroism </li></ul></ul><ul><ul><li>Quality work every time </li></ul></ul><ul><ul><li>Technical excellence </li></ul></ul><ul><ul><li>Simplicity </li></ul></ul><ul><ul><li>Be in control </li></ul></ul>
  33. 33. Collective Code Ownership <ul><li>Everyone can contribute to everything Any developer can change any line of code Everyone is responsible for all the code No one person becomes a bottle neck for changes </li></ul>
  34. 34. Prerequisites and Alternatives <ul><li>Prerequisites, at least: CodingStandards Version management Unit tests </li></ul><ul><li>Alternatives? CodeStewardship ... So what? Define who ones the code! More &quot;collective&quot;, is better, but has more prerequisites </li></ul>
  35. 35. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul><ul><ul><li>Small, realistic chunks of work every day </li></ul></ul><ul><ul><li>Fun and quality    instead of   heroism </li></ul></ul><ul><ul><li>Quality work every time </li></ul></ul><ul><ul><li>Technical excellence </li></ul></ul><ul><ul><li>Simplicity </li></ul></ul><ul><ul><li>Be in control </li></ul></ul><ul><ul><li>Trust your teammates </li></ul></ul>
  36. 36. Acceptance Tests <ul><li>Customers specifies scenarios to test when a user story has been correctly implemented A story can have one or many acceptance tests Acceptance tests are black box system tests </li></ul>Customers sign completed stories  when their acceptance tests pass
  37. 37. Acceptance Tests HowTo <ul><ul><li>Written at the start of each iteration </li></ul></ul><ul><ul><li>Start a story executing acceptance tests </li></ul></ul><ul><ul><li>Write unit tests </li></ul></ul><ul><ul><li>Keep adding unit tests and production code until all the acceptance tests pass </li></ul></ul>
  38. 38. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul><ul><ul><li>Small, realistic chunks of work every day </li></ul></ul><ul><ul><li>Fun and quality    instead of   heroism </li></ul></ul><ul><ul><li>Quality work every time </li></ul></ul><ul><ul><li>Technical excellence </li></ul></ul><ul><ul><li>Simplicity </li></ul></ul><ul><ul><li>Be in control </li></ul></ul><ul><ul><li>Trust your teammates </li></ul></ul><ul><ul><li>Working software is measure of progress </li></ul></ul>
  39. 39. Velocity <ul><li>Velocity is the rate at which you complete your work, in a certain period of time. In project management terms: velocity is the amount of work that a team can complete in a specified period of time. </li></ul>
  40. 40. Velocity and Burndown <ul><li>Velocity to make commitments in future iterations If a team does not know its velocity, how will that team be able to know how much work to put into an iteration? </li></ul><ul><li>Burndown to meet commitments in one iteration If a team doesn't focus burndown, it is probable that the team will miss the scope of the iteration </li></ul>
  41. 41. Open Workspace Self-organizing teams Collaboration Comunication Trust Simplicity Self-organization Feedback!!
  42. 43. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul><ul><ul><li>Small, realistic chunks of work every day </li></ul></ul><ul><ul><li>Fun and quality    instead of   heroism </li></ul></ul><ul><ul><li>Quality work every time </li></ul></ul><ul><ul><li>Technical excellence </li></ul></ul><ul><ul><li>Simplicity </li></ul></ul><ul><ul><li>Be in control </li></ul></ul><ul><ul><li>Trust your teammates </li></ul></ul><ul><ul><li>Working software is measure of progress </li></ul></ul>
  43. 44. μεταφορά : &quot;a transfer&quot;, in rhetoric &quot;transference of a word to a new sense&quot;, from μεταφέρω - metaphero , &quot;to carry over, to transfer&quot; Metaphor Shared Vision      Ubiquitous Language            Communication                   Simplicity 
  44. 45. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul><ul><ul><li>Small, realistic chunks of work every day </li></ul></ul><ul><ul><li>Fun and quality    instead of   heroism </li></ul></ul><ul><ul><li>Quality work every time </li></ul></ul><ul><ul><li>Technical excellence </li></ul></ul><ul><ul><li>Simplicity </li></ul></ul><ul><ul><li>Be in control </li></ul></ul><ul><ul><li>Trust your teammates </li></ul></ul><ul><ul><li>Working software is measure of progress </li></ul></ul><ul><ul><li>Shared understanding </li></ul></ul>
  45. 46. Retrospectives
  46. 47. Principles and values <ul><ul><li>Collaboration       instead of      negotiation </li></ul></ul><ul><ul><li>Communication   instead of      requirement elicitation </li></ul></ul><ul><ul><li>Feedback, feedback, feedback! </li></ul></ul><ul><ul><li>Business value instead of overdesign & unused features </li></ul></ul><ul><ul><li>Respect for people  instead of pretending </li></ul></ul><ul><ul><li>Small, realistic chunks of work every day </li></ul></ul><ul><ul><li>Fun and quality    instead of   heroism </li></ul></ul><ul><ul><li>Quality work every time </li></ul></ul><ul><ul><li>Technical excellence </li></ul></ul><ul><ul><li>Simplicity </li></ul></ul><ul><ul><li>Be in control </li></ul></ul><ul><ul><li>Trust your teammates </li></ul></ul><ul><ul><li>Working software is measure of progress </li></ul></ul><ul><ul><li>Shared understanding </li></ul></ul><ul><ul><li>Continuous improvement </li></ul></ul>
  47. 48. Agilemanifesto.org (re-read it!) <ul><ul><li>Individuals and interactions  </li></ul></ul><ul><ul><li>Working software </li></ul></ul><ul><ul><li>Customer collaboration </li></ul></ul><ul><ul><li>Responding to change </li></ul></ul><ul><ul><li>Naturally  non-fondamentalist: many methodologies, many technologies.   </li></ul></ul>over processes and tools over comprehensive documentation over contract negotiation over following a plan based on the community!
  48. 49. Thanks for your attention! Questions? The answers during this week!

×