Lions, Tigers, and Bears: Scrum, XP, and Eclipse

1,972 views

Published on

The Eclipse Project's Development Process is not the only way a project can be run and still meet the requirements of the overall Eclipse Development Process. This talks describes how concepts from Scrum and XP can be applied successfully to delivering eclipse projects on the release train, or ahead of it.

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,972
On SlideShare
0
From Embeds
0
Number of Embeds
590
Actions
Shares
0
Downloads
68
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Lions, Tigers, and Bears: Scrum, XP, and Eclipse

  1. 1. Lions, Tigers, and Bears: Scrum, XP and Eclipse <ul>David Carver Blog: intellectualcramps.blogspot.com Twitter: kingargyle Email: [email_address] </ul>[email_address]
  2. 2. Project Experience PsychoPath Xpath 2.0 Processor <ul><li>Xpath 2.0 Processor
  3. 3. 8300 Unit Tests
  4. 4. Originally Failed over 90 % of Xpath 2.0 Test Suite
  5. 5. 3 Part-Time Community Developers not Paid by Members </li></ul>
  6. 6. Project Experience PsychoPath Xpath 2.0 Processor <ul><li>Development Time 6 months
  7. 7. Passes 8300 Unit Tests
  8. 8. Test Results, FindBugs Trends, and Duplicate Code Stats available on Hudson.
  9. 9. Project run using Techniques in this Talk.
  10. 10. Adopters – Apache Xerces-J for XSD 1.1 Assertion support. </li></ul>
  11. 11. Possible Project Pains <ul><li>Project Planning </li><ul><li>May not necessarily reflect the work that is happening.
  12. 12. Plan is produced 3 months into the Development.
  13. 13. Not all features done have a corresponding bugzilla
  14. 14. Time for IP approval </li></ul><li>Developer Bug Assignment/Management </li><ul><li>Too many bugs ASSIGNED to a Developer
  15. 15. Too many bugs that LOOK like they are being fixed but are not. </li></ul></ul>
  16. 16. Possible Project Pains <ul><li>Features Emphasised over Bug Fixes
  17. 17. Failure to have Unit Tests or Functional Tests
  18. 18. Developer/User Documentation is treated as an after thought
  19. 19. No Frequent Releases </li><ul><li>Maybe once a year is too long for your community? </li></ul><li>Becoming Popular/Successful </li><ul><li>Time and Resources are limited. </li></ul></ul>
  20. 20. Communication
  21. 21. The Agile Manifesto–a statement of values Mountain Goat Software and www.agilemanifesto.org Process and tools Individuals and interactions over Following a plan Responding to change over Comprehensive documentation Working software over Contract negotiation Customer collaboration over
  22. 22. Project Planning
  23. 23. Eclipse Project Development Process <ul><li>Does NOT equal the Eclipse Development Process </li></ul>Source: Eric Gamma - How (7 years of) Eclipse Changed my Views on Software Development – InfoQ
  24. 24. Scrum In Pictures Image available at www.mountaingoatsoftware.com/scrum
  25. 25. Product Backlog <ul><li>Contains the Features and Bugs for the Product
  26. 26. Manages by the Product Owner. </li><ul><li>Community votes weigh more than individual company needs. </li></ul><li>Reviewed and reprioritized by the Product Owner before the start of the next iteration. </li></ul>
  27. 27. Sprint Backlog <ul><li>Contains a mixture of bugs and features
  28. 28. Prioritized by the Product Owner/Community.
  29. 29. The work that is PLANNED to be done during an iteration.
  30. 30. TEAM reviews at the very beginning of an iteration. </li><ul><li>Sprint planning should take no more than a Day. Ideally less. </li></ul><li>Make the Backlog easily viewable consumable by the Community. </li></ul>
  31. 31. No changes during a sprint <ul><li>Plan sprint durations around how long you can commit to keeping change out of the sprint </li></ul>Change
  32. 32. Eclipse Bug/Feature/Task Assignment on WST.XSL <ul><li>Only Assign a task during the iteration it is being worked on.
  33. 33. Allows for clear communication to the community
  34. 34. Shows what is ACTUALLY being worked on
  35. 35. Keeps Developer/Committer backlog manageable
  36. 36. Review at the end of each iteration and before the next iteration begins. Re-evaluate the backlog. </li></ul>
  37. 37. Technical Practices
  38. 38. Software Craftsmanship <ul><li>Not only working software, </li><ul><li>but also well-crafted software </li></ul><li>Not only responding to change, </li><ul><li>but also steadily adding value </li></ul><li>Not only individuals and interactions, </li><ul><li>but also a community of professionals </li></ul><li>Not only customer collaboration, </li><ul><li>but also productive partnerships </li></ul></ul>That is, in pursuit of the items on the left we have found the items on the right to be indispensable.
  39. 40. Builds <ul><li>Continuous Integration Builds need to be fast </li><ul><li>30 Minutes or less </li></ul><li>If a build fails, FIX IT before anything else.
  40. 41. Write Unit Tests.
  41. 42. Integrate with Source Control Daily, Hourly, as often as possible. </li><ul><li>Most failures happen from poor integration practices. </li></ul><li>Make the Build Results Public...Communicate the Health of your Builds </li></ul>
  42. 43. Communicate Project Health
  43. 44. XP Concepts <ul><li>Unit Tests – Test Drive Development if Possible.
  44. 45. Continuous Integration </li><ul><li>Synchronize Daily with the Repository. </li></ul><li>Only check in code that passes tests.
  45. 46. Work is not completed until all tests pass on both your machine and the build machine.
  46. 47. Fix Failing Tests as soon as they happen. There is no such thing as a random failure.
  47. 48. Do not be afraid to Refactor. Tests can allow you to refactor ugly code to Clean maintanable code. </li></ul>
  48. 49. Additional Resources <ul><li>Books </li><ul><li>Agile Estimating and Planning – Mike Cohn
  49. 50. Clean Code – Robert Martin
  50. 51. Refactoring – Martin Fowler </li></ul><li>Web Sites </li><ul><li>Extreme Programming
  51. 52. Scrum Alliance
  52. 53. Mountain Goat Software
  53. 54. Eclipse Development Process </li></ul></ul>

×