Designing An Agile Community Program Funambol Code Sniper v. 2 Stefano Maffulli,  Community Manager Agile Day  Bologna Nov...
Open Source and Agile Main assumption: customer = community
Funambol Code Sniper v 1 <ul><ul><li>Current setup </li></ul></ul><ul><ul><ul><li>Funambol maintains a list of 'wanted' so...
Community members pick one and write a proposal
The proposal is discussed with the Funambol engineers and approved
Code Sniper developer writes a full specifications and submits them for approval to Funambol
The development starts
Once code is working according to specs the grant is released
End </li></ul></ul></ul>
Sniper Developer Code Sniper v1 process Community &  Funambol Eng
Limits <ul><ul><li>Too much 'solo' work
Upcoming SlideShare
Loading in...5
×

Designing An Agile Community Program: Funambol Code Sniper v. 2

1,150

Published on

Funambol Code Sniper redefined with a more agile process.

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

  • Be the first to like this

No Downloads
Views
Total Views
1,150
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Transcript of "Designing An Agile Community Program: Funambol Code Sniper v. 2"

  1. 1. Designing An Agile Community Program Funambol Code Sniper v. 2 Stefano Maffulli, Community Manager Agile Day Bologna Nov 20 th 2009
  2. 2. Open Source and Agile Main assumption: customer = community
  3. 3. Funambol Code Sniper v 1 <ul><ul><li>Current setup </li></ul></ul><ul><ul><ul><li>Funambol maintains a list of 'wanted' software
  4. 4. Community members pick one and write a proposal
  5. 5. The proposal is discussed with the Funambol engineers and approved
  6. 6. Code Sniper developer writes a full specifications and submits them for approval to Funambol
  7. 7. The development starts
  8. 8. Once code is working according to specs the grant is released
  9. 9. End </li></ul></ul></ul>
  10. 10. Sniper Developer Code Sniper v1 process Community & Funambol Eng
  11. 11. Limits <ul><ul><li>Too much 'solo' work
  12. 12. Possible conflicts </li></ul></ul><ul><ul><ul><li>Two people or groups want to develop the same project </li></ul></ul></ul><ul><ul><li>Risk of abandonment </li></ul></ul><ul><ul><ul><li>decreased incentive to maintain the software after version alpha is released </li></ul></ul></ul><ul><ul><li>Not agile </li></ul></ul>
  13. 13. Funambol Code Sniper v. 2 <ul><ul><li>Funambol keeps a list of desired software
  14. 14. Customers (community) write user stories, create backlog
  15. 15. Developers (community) evaluate user stories and take them to develop
  16. 16. For each story written and completed, community members earn Sniper Points </li></ul></ul><ul><ul><ul><li>Write a User Story = 1 point
  17. 17. Develop a User Story = X points (according to evaluation)
  18. 18. Test a User Story = x/2 points </li></ul></ul></ul><ul><ul><li>Sniper Points can be exchanged with money or goods </li></ul></ul>
  19. 19. Code Sniper Process v. 2
  20. 20. Challenges <ul><ul><li>Overcome the cultural barrier </li></ul></ul><ul><ul><ul><li>Educate on what a user story is or how to write an effective one </li></ul></ul></ul><ul><ul><li>Provide effective and easy to use tools </li></ul></ul><ul><ul><ul><li>Few free-as-in-freedom software suitable for Agile mgmt </li></ul></ul></ul><ul><ul><li>Balance the mixed roles of owner, developer and customer with very small teams </li></ul></ul><ul><ul><ul><li>Some projects may not be well suited for an Agile Open Source method (example: those few users) </li></ul></ul></ul>
  21. 21. Advantages <ul><ul><li>The community takes an active role </li></ul></ul><ul><ul><ul><li>involve users, not just developers, at early stage
  22. 22. involve users for testing and approving stories  </li></ul></ul></ul><ul><ul><li>  Requirements emerge as a shared effort of the community (the Product Owner)
  23. 23.   The project grows step by step, each step is releasable  </li></ul></ul><ul><ul><ul><li>as per the definition of user story </li></ul></ul></ul><ul><ul><li>Developers can pick up small chunks of functionality (it better meets people's time constraints)
  24. 24. Increased incentives to contribute after initial release </li></ul></ul><ul><ul><ul><li>as long as more user stories are added there is incentive to contribute and maintain the code </li></ul></ul></ul>
  25. 25. Open questions <ul><ul><li>How to estimate User Stories? </li><ul><li>Hours? Weeks? Story Points? Do they make sense? </li></ul><li>How to define 'Done'? </li><ul><li>The community should define DONE </li><ul><li>Ideas: </li></ul></ul></ul></ul><ul><ul><ul><ul><li>Changes Log and Design Document updated
  26. 26. Unit tests implemented and passed
  27. 27. Acceptance tests defined and passed </li><ul><li>no new bugs on the user story, no regression bugs </li></ul><li>Releasable (installable and working in real life conditions)
  28. 28. Documentation, upgrade impact, backward compatibility, performance impact </li></ul></ul></ul></ul>
  29. 29. Further discussion <ul><li>Join Funambol Discussion Forum
  30. 30. https://core.forge.funambol.org/discuss
  31. 31. http://identi.ca/group/funambol
  32. 32. http://twitter.com/funambol </li></ul>

×