Your SlideShare is downloading. ×
Lions, Tigers, and Bears: Scrum, XP, and Eclipse
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

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

1,626

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 …

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,626
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
66
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

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

×