Introduction Professional Scrum Developer for Java

3,933 views

Published on

Introduction to the official PSD for Java training from scrum.org. It doesn't cover all topics from the official curriculum, and serves as a intro and teaser to actually follow the official training.

Published in: Technology

Introduction Professional Scrum Developer for Java

  1. 1. Introduction PSD Professional Scrum Developer Java
  2. 2. Who am I? Who are you? Name From What would I be if I did not end up in IT?
  3. 3. Rules during the course ● Questions? – Ask!!!! – Or put them on the board ● Mobile phones ● Laptops ● Breaks
  4. 4. Course content 1. Introduction 2. Scrum explained 3. Scrum courses 4. Agile Testing & TDD 5. Pair Programming 6. Clean Code 7. Continuous Delivery 8. Tools 9. Books
  5. 5. Scrum explained (5 min.) ● Question: What is Scrum for you? ● Put in one sentence on a post-it what you think Scrum is.
  6. 6. Scrum explained ● What are the results? Discuss.
  7. 7. Scrum explained ● Definition: Scrum is a framework for developing and sustaining complex products.
  8. 8. Scrum explained: Roles ● Product Owner – Maximize value of the product – Manages Product Backlog – 1 person! – Prioritizes PBI's ● Scrum Master – Ensures Scrum is understood & enacted – Servant leader – Helps Product Owner, Development Team & Organization – Applies Scrum theory, practices & rules © 1993 - 2013 Scrum.org, All Rights Reserved
  9. 9. Scrum explained: Roles ● Development Team – Professionals – Self organizing – Everyone is a developer – Cross functional – Self Organizing ● Scrum Team – Consists of “Development Team”, “Product Owner” and “Scrum Master” © 1993 - 2013 Scrum.org, All Rights Reserved
  10. 10. Scrum explained: Roles
  11. 11. Scrum explained: Events ● Sprint Planning – Define work to be performed during the upcoming Sprint. – Timeboxed: 8 hours for 4 week sprint – Two parts ● What will we do ● How will we do it – Sprint Goal ● Daily Scrum – Daily 15 minute time boxed event – For the Development Team – No status meeting © 1993 - 2013 Scrum.org, All Rights Reserved
  12. 12. Scrum explained: Events ● Sprint Review – Inspect the increment and adapt Product Backlog – Invite stakeholders – Timeboxed: 4 hours for 4 week sprint ● Sprint Retrospective – Opportunity to inspect how we are working and to adapt – For the Scrum Team – Timeboxed: 3 hours for 4 week sprint http://davidemanske.com/wp-content/uploads/2013/06/SpeedBoatRetrospective-300x128.png http://www.flickr.com/photos/92328289@N02/
  13. 13. Scrum explained: Events ● Sprint – The heart of Scrum – Timeboxed: Max one month. – Delivers a “Done”, useable and potentially releasable product increment – Contains all the other events http://www.flickr.com/photos/gareth_price/
  14. 14. Scrum Explained: Artifacts ● Product Backlog – Ordered list – Never complete – Contains PBI's – Product Owner is responsible ● Sprint Backlog – Set of Product Backlog Items – Plan for delivering Product Increment – Contains Sprint Goal ● Increment – Sum of all PBI's done during a Sprint
  15. 15. Management by walking around ● Round 1 – Pair up: one person will be manager, other the worker – Simulation: shopping mall traffic, by walking from one shop to another – Goal: Take 60 steps – Instructions: ● Go 1 step forward ● Turn 1 step left ● Turn 1 step right ● Stop – Manager counts the number of steps – You get 60 seconds
  16. 16. Management by walking around ● Round 1 evaluation – How many steps did you take? – How did you feel? Managers? Workers?
  17. 17. Management by walking around ● Round 2 – No more pairs – Goal: Take 60 steps – Each person counts his own steps – You get again 60 seconds
  18. 18. Management by walking around ● Round 2 evaluation – How many steps? – How did you feel? https://upload.wikimedia.org/wikipedia/commons/thumb/d/d6/Fugle,_%C3%B8rns%C3%B8_073.jpg/250px-Fugle,_%C3%B8rns%C3%B8_073.jpg
  19. 19. Scrum explained: self organizing ● No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality. ● The Development Team self-organizes to undertake the work in the Sprint Backlog, both during the Sprint Planning Meeting and as needed throughout the Sprint. ● Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team.
  20. 20. Scrum explained: self organizing Old style Scrum Team lead assigns tasks Development figures it out ;-) No such thing as people working together Pair programming All communication is done through team lead Direct communication between developers Weekly status meeting, reporting to manager Daily Scrum Team lead is responsible The whole Scrum Team is responsible, including ALL developers.
  21. 21. Scrum explained: transparency, inspect & adapt ● Pillars of empirical process control – Transparency: be realistic, no hidden stuff – Inspection: Look back, measure stuff – Adaption: Be open for changes! ● You can NOT predict the future
  22. 22. Scrum explained: transparency, inspect & adapt Cirkel van Deming PlanPlan Inspect Do Goal • Constantly improve • Deliver faster • Deliver more efficient • Deliver with higher quality Act
  23. 23. Scrum explained: Cross functional DBA Testing Development Analysis Operations DBA Testing Development Analysis Operations DBA Testing Development Analysis Operations DBA Testing Development Analysis Operations DBA Testing Development Testing Analysis Operations TEAM 1 TEAM 2 Testing Development Testing TEAM 3 TEAM 4 Analysis Testing Analysis
  24. 24. Scrum explained: DoD “Done”: Means a PBI is potentially shippable. Definition of Done (DoD) ● Checklist ● Visible ● Inspected & adapted
  25. 25. Scrum explained: DoD (5min.) ● Answer the following questions: – What is your Definition of Done? – Who owns the Definition of Done? – Who or what influences it and how?
  26. 26. Scrum explained: DoD (5min.) ● Answer the following questions: – What is your Definition of Done? – Who owns the Definition of Done? – Who or what influences it and how?
  27. 27. Scrum explained: Estimation Architect Team Customer When? During BDUF Sprint Planning All the time How? Hours Fibonacci Beers ...
  28. 28. Scrum explained: Estimation ● How? – In group! – Discussion & Conversation is most important. – Relative to other things ● Hours??? – Parkinson's law: When an item is finished earlier, the developer will fill remaining time. – Ideal or working hours? Example: Why 16 hours and not 15?
  29. 29. Scrum explained: Poker planning http://wendysdogwalking.co.uk/wp-content/uploads/2013/04/dog-on-sofa-300x225.jpg
  30. 30. Scrum explained: Backlog refinement ● aka Grooming ● Refine PBI's – Clear and understood – Estimated – Broken down in small enough items – Have acceptance criteria Product Owner + Development Team During EACH Sprint Timeboxed As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … So that …. As a … I want to … As a … I want to … So that …. 3 1 0 8 13 ● ● ●
  31. 31. Scrum explained: Cone of Uncertainty www.construx.comInitial Estimate Product Backlog Item Estimate Sprint Backlog Item Estimate
  32. 32. Scrum explained: Waterfall vs. Scrum Requirements BDUF Development Testing Done Requirements BDUF Development Testing Done Requirements BDUF Development Testing Done Requirements BDUF Development Testing Done Requirements BDUF Development
  33. 33. Scrum explained: Waterfall vs. Scrum D O N E D O N E D O N E D O N E DO N E ● Done is Live ● Collaboration ● Communication ● Requirements, Design, Development, Testing – All done in parallel, during Sprint
  34. 34. Scrum explained: Waterfall vs. Scrum Visibility Ability to Change Business Value Risk Waterfall Scrum © 1993 - 2013 Scrum.org, All Rights Reserved
  35. 35. Scrum explained: Scope, Resources, Time and Quality ● Project Management Triangle QUALITY SCOPE TIME RESOURCES
  36. 36. Scrum explained: Where to start? ● Read the Scrum guide! ● Embrace failure. ● Do some assessments http://www.scrum.org/Assessments/Open-Assessments ● Practice, practice, practice ● And practice ● Follow the rules, no exception. © 1993 - 2013 Scrum.org, All Rights Reserved
  37. 37. Scrum.org courses Professional Scrum Product Owner Professional Scrum Foundations Professional Scrum Master Professional Scrum Developer .NET | Java Product Owners Executives Scrum Masters Architects Business Analysts DB Specialists Designers Developers Testers Everyone © 1993 - 2013 Scrum.org, All Rights Reserved
  38. 38. Scrum.org courses Courses Public and private courses are offered worldwide Assessments Certification Professional Scrum Foundations Hands-on training for people looking to start Scrum or reboot a struggling implementation. Professional Scrum Master In-depth training for Scrum Masters and experienced practitioners needing more advanced instruction. Professional Scrum Product Owner Teaches people how to maximize ROI, and optimize the Total Cost of Ownership of products and systems. Professional Scrum Developer Students work as part of a self-organizing team to learn how to use ALM tools and Software development best practices in Scrum. Certification only granted to those that achieve a passing score on the associated assessment
  39. 39. Scrum.org vs Scrum Alliance ● Scrum.org – Assessments have more value. – Each course is the same (doesn't depend on the trainer) – Open for feedback and improvements – Home of Scrum! ● Scrum alliance – Easier to get certified – ...
  40. 40. Time for ….
  41. 41. Agile Testing ● Quadrants Acceptance Testing Functional Tests Integration Tests Exploratory Testing Scenario Testing Usability Testing Test by End User (UAT) Unit Test Module Tests Component Tests Performance & Load Testing Security Testing *ility Testing Technology Facing Business Facing Automated Automated Manual Manual? © 1993 - 2013 Scrum.org, All Rights Reserved Brian Marick, http://bit.ly/PrsMY1
  42. 42. Agile Testing ● Test Pyramids Mike Cohn, Succeeding with Agile UI Service Unit ● Not executed frequently ● Take long time to execute ● Executed frequently ● Take short time to execute
  43. 43. Agile Testing (5min.) ● What is wrong with the following? UI Service Service Unit Unit UI Service Unit UI Service Unit UI Service Unit How do your current tests look like? Explain.
  44. 44. TDD (Test Driven Development) ● TDD Cycle Write Test Watch Test Fail Write simplest code Run all tests Refactor Run all tests Idea?
  45. 45. TDD (Test Driven Development) ● Three Laws of TDD – First: You may not write production code until you have written a failing unit test. – Second: You may not write more of a unit test than is sufficient to fail, and not compiling is failing. – Third: You may not write more production code than is sufficient to pass the currently failing test. ● Keep test clean! ● One Assert per Test. ● Single Concept per Test. Robert C. Martin
  46. 46. TDD (Test Driven Development) ● F.I.R.S.T. – Fast Tests should be fast. – Independent Tests should not depend on each other. – Repeatable Tests should be repeatable in any environment. – Self-Validating Tests should have a boolean output (pass or fail). – Timely Tests should be written before the production code. Robert C. Martin
  47. 47. TDD (Test Driven Development) Kata String Calculator ● Before you start: – Try not to read ahead. – Do one task at a time. The trick is to learn to work incrementally. – Make sure you only test for correct inputs. there is no need to test for invalid inputs for this kata http://osherove.com/tdd-kata-1/
  48. 48. Kata String Calculator (10min.) Part 1 ● Create a simple String calculator with a method int Add(string numbers) – The method can take 0, 1 or 2 numbers, and will return their sum (for an empty string it will return 0) for example “” or “1” or “1,2” – Start with the simplest test case of an empty string and move to 1 and two numbers – Remember to solve things as simply as possible so that you force yourself to write tests you did not think about – Remember to refactor after each passing test http://osherove.com/tdd-kata-1/
  49. 49. Kata String Calculator (2 min.) Part 1: Review ● Who has written first a test, before writing the Calculator class? ● How many tests do you have now? ● How many times did you run the test? ● How many times did you refactor your code? http://osherove.com/tdd-kata-1/
  50. 50. Kata String Calculator (10 min.) Part 2 ● Allow the Add method to handle an unknown amount of numbers ● Allow the Add method to handle new lines between numbers (instead of commas). – the following input is ok: “1n2,3” (will equal 6) – the following input is NOT ok: “1,n” (not need to prove it - just clarifying) http://osherove.com/tdd-kata-1/
  51. 51. Kata String Calculator (2 min.) Part 2: Review ● Who followed TDD Cycle? ● How many tests do you have now? ● Who wrote multiple tests at once? ● What about exceptions? http://osherove.com/tdd-kata-1/
  52. 52. Kata String Calculator (10 min.) Part 3 ● Support different delimiters – to change a delimiter, the beginning of the string will contain a separate line that looks like this: “// [delimiter]n[numbers…]” for example “//;n1;2” should return three where the default delimiter is ‘;’ . – the first line is optional. all existing scenarios should still be supported http://osherove.com/tdd-kata-1/
  53. 53. Kata String Calculator (2 min.) Part 3: Review ● Who followed TDD Cycle? ● How do the names of your tests look like? [MethodUnderTest]_[Given]_[Then]? ● How many asserts does one test contain? http://osherove.com/tdd-kata-1/
  54. 54. Kata String Calculator (10 min.) Part 4: ● Calling Add with a negative number will throw an exception “negatives not allowed” - and the negative that was passed. If there are multiple negatives, show all of them in the exception message http://osherove.com/tdd-kata-1/
  55. 55. Kata String Calculator (10 min.) Part 4: Review ● Who wants to show the result? http://osherove.com/tdd-kata-1/
  56. 56. Agile Testing: Code Coverage What does this mean?
  57. 57. Agile Testing: Tools
  58. 58. Time for ….
  59. 59. Time for ….
  60. 60. Pair Programming
  61. 61. Pair Programming ● Roles – Driver – Navigator ● Rules – Pair on everything you'll need to maintain. – Allow pairs to form fluidly rather than assigning partners. – Switch partners when you need a fresh perspective. – Avoid pairing with the same person for more than a day at a time. – Sit confortable, side by side. – Produce code through conversation. Collaborate, don't critique. – Switch driver and navgator role frequently.
  62. 62. Pair Programming ● Advantages – Higher quality – Constant knowledge sharing – Deliver faster – Faster development – An extra pair of eyes – If Bob (the guru) leaves for a round-the-world trip → He Can! – If Rob (the junior) joines the company, he gets up to speed in notime.
  63. 63. Pair Programming ● Disadvantages – Are there?
  64. 64. Clean Code ● Michael Feathers, author of Working Effectively with Legacy Code “Clean code always looks like it was written by someone who cares. There is nothing obvious that you can do to make it better” Elegant Efficient Straightforward Simple Direct Well written Meaningfull Clear Beautifull
  65. 65. Time for ….
  66. 66. Clean Code: Boy Scout Rule “Leave the campground cleaner than you found it.”
  67. 67. Clean Code: Broken Windows Theory The broken windows theory is a criminological theory of the norm-setting and signaling effect of urban disorder and vandalism on additional crime and anti-social behavior. The theory states that maintaining and monitoring urban environments in a well-ordered condition may stop further vandalism and escalation into more serious crime. http://en.wikipedia.org/wiki/Broken_windows_theory ● Just add another “if”. ● Dirty code invites to add more smells. ● Growing method length ● Growing class length ● ...
  68. 68. Clean Code: How to measure? ● The # tests? ● The # bugs? ● The # duplicated code? ● The # unused code? ● ...
  69. 69. Clean Code: How to measure? http://www.osnews.com/story/19266/WTFs_m
  70. 70. Clean Code: Clean Kitchen 3 Michelin sushi chef Saito is a master with the knife http://youtu.be/robvvJZkfcU
  71. 71. Clean Code: Names ● Use meaningful names ● Use intention – revealing names ● Avoid disinformation ● Use pronounceable names ● Avoid encodings – No Hungarian Notation – Member prefixes? ● Use solution domain names ● Use problem domain names ● Pick one word per Concept – No “get”, “retrieve”, “fetch”, ….
  72. 72. Clean Code: Names (15min.) ● Checkout the code @ https://github.com/jdewinne/PSDExamples ● Refactor the following code: Names.java
  73. 73. Clean Code: Names (10min.) ● Who wants to show the result?
  74. 74. Clean Code: Functions ● Small! ● Do one thing! ● Reading code from Top to Bottom The stepdown rule ● Arguments – No flags – As less as possible – Don't use it for returning values ● Have no side effects – “checkPassword” should not create a session ● Exceptions over Error codes ● DRY
  75. 75. Clean Code: Functions Any comments?
  76. 76. Clean Code: Comments “Don't comment bad code – rewrite it.” Brian W. Kernighan and P.J. Plaugher ● Explain in code, not in comments ● Redundant comments :-( ● Misleading comments :-( ● Commented out code :-( ● HTML comments :-( ● Too much information (Do not add the whole specification document)
  77. 77. Clean Code: Comments (20 min.) ● Checkout the code @ https://github.com/jdewinne/PSDExamples ● Refactor the following code: Comments.java
  78. 78. Clean Code: Comments (10min.) ● Who wants to show the result?
  79. 79. Clean Code: Formatting ● Vertical formatting – Lines per file. – Each class should be max 200 lines! – Vertical openness ● Use some white lines ;-) – Vertical Density ● Tightly related lines should be close to each other ● Horizontal formatting – Line length – Each line should max be 120characters long – Horizontal Openness and Density – Indentation ● Team rules!!!!!!!!!
  80. 80. Clean Code: Law of Demeter ● A module should not know about the innards of the objects it manipulates. customer.getAddress().getBillingAddress().getLine1() government.getPresident().getJobDescription().setName()
  81. 81. Clean Code: Exceptions ● Use exceptions, instead of return codes. ● Use meaningful exceptions ● Don't return null ● Don't pass null ● Write the try / catch / finally first ● Use unchecked exceptions
  82. 82. Clean Code: Emergent Architecture (5min.) ● How does your architecture looks like? ● First design, then implement? ● You think also of the future? And have statements like: – It must be scalable – It must be extensible for any feature we can think of – … Discuss!
  83. 83. Clean Code: Emergent Architecture ● BDUF is waste! ● TDD is design. ● BDD is design. ● Allow your architecture to emerge as you develop. ● Think in slices (not in layers)
  84. 84. Clean Code: Technical debt Code Rots in Presence of Change!
  85. 85. Clean Code: Technical debt Broken window Phenomena
  86. 86. Clean Code: Technical debt ● Technical debt = Defects, complexity, coupled code, lack of testing, duplication, … ● Do NOT let it grow! Value Technical debt
  87. 87. Clean Code: SOLID SRP (Single Responsibility Principle) DB Customer Persistence System DB Customer Enterprise Java Beans 1/2 Java Persistence API
  88. 88. Clean Code: SOLID OCP (Open Close Principle) http://lostechies.com ● Open for Extension ● Closed for Modification
  89. 89. Clean Code: SOLID LSP (Liskov Substitution Principle) Functions that use pointers to base classes must be able to use objects of derived classes without knowing it. http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/
  90. 90. Clean Code: SOLID ISP (Interface Segregation Principle) http://javiernavarromachuca.blogspot.nl/2011/07/interface-segregation-principle.html ● One interface per kind of client. ● No methods in interface that client does not use. ● No “fat” interfaces.
  91. 91. Clean Code: SOLID DIP (Dependency Inversion Principle) http://lostechies.com/derickbailey/2009/02/11/solid-development-principles-in-motivational-pictures/ ● “High-level modules should not depend on low-level modules. Both should depend on abstractions” ● “Abstractions should not depend on details. Details should depend on abstractions”
  92. 92. Time for ….
  93. 93. Continuous Delivery Row 1 Row 2 Row 3 Row 4 0 2 4 6 8 10 12 Column 1 Column 2 Column 3 Source Control Automated build Continuous integration Automated Testing Automated Deployments Continuous Delivery Automated Provisioning
  94. 94. Continuous Delivery
  95. 95. Continuous Delivery Deployment Pipeline provides constant quick feedback Continuous Integration Middleware Provisioning Virtualized Infrastructure Test ToolingDevelopment Central Monitoring & Logging Application Release Automation O T A P all identical On Demand Environments
  96. 96. Continuous Delivery Time to Market
  97. 97. Continuous Delivery Cost Reduction
  98. 98. Continuous Delivery Building Blocks
  99. 99. Videos: www.cleancoders.com
  100. 100. Videos: Dan Pink The surprising truth about what motivates us
  101. 101. Videos: Pentagon wars
  102. 102. Tools ● Management: Jira, Trello, Excel ● Continuous Integration: Jenkins, Bamboo, Hudson ● Testing: JUnit, FitNesse, Cucumber, DBUnit, TestNG, Greenpepper, Jbehave, Jacoco, Arquillian, ... ● Automated Deployment: Deployit, Nolio, uDeploy ● Collaboration: Confluence, xWiki ● Automated Provisioning: Puppet, Chef, Vagrant, MCollective ● Quality: Sonar ● Build tools: ant, ivy, maven, gradle ● Source safety: subversion, git ● Cloud solutions – Continuous Integration: Cloudbees – Public PAAS: Heroku, OpenShift – Issue Management: Atlassian (Jira), Trello – Don't forget Amazon
  103. 103. Books
  104. 104. Books
  105. 105. Books
  106. 106. Books

×