Open Source Software Development Practices that Works


Published on

Open Source Software Development Practices that Works

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Open Source Software Development Practices that Works

  1. 1. Open Source Software Development Practices that Works (or how to get software done) #mosc2010
  2. 2. Hi! I develop software for a living. I think a lot about making good software -- and that is what I am going to talk about today. Basically, I learned enough tricks to be good at what I do.
  3. 3. Be Agile because it works
  4. 4. Ya use Agile methodology? No. Me neither.
  5. 5. " We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more.
  6. 6. Agile Methodologies Extreme Programming Scrum Crystal Clear Lean Software Development Kanban Software Development Rational Unified Process Test Driven Development ...
  7. 7. It basically means we got a pretty good plan to get things done. You can worry less now. ; -)
  8. 8. It Works because it's simple
  9. 9. User Stories Just enough details to make time estimate, priority and purpose. Must be simple and easy to understand. Make them testable. E.g., "Load in 3 seconds" Requirements are never final, so be flexible.
  10. 10. Deliver Iteratively Have clear milestones and short iterations Break all tasks down to iteration Plan in iteration -- 1 to 3 weeks
  11. 11. VS
  12. 12. Estimation It's very hard to plan for next 6 months. Break big thing down to smallest things. How to eat an elephant? One piece at a time
  13. 13. Respect / trust Respect your teammates or staffs Move responsibility down the chain Let workers decide the best approach Encourage passionate commitment Expect top quality from everyone
  14. 14. Source:, Agile Romania UG Meeting Bucharest
  15. 15. Daily Standup What I accomplished yesterday What I plan to accomplish today What issues are blocking progress 5-10 minutes
  16. 16.
  17. 17. Short to-do list Because long todo-list don't get done Limit the number of tasks Usually it looks like a checklist
  18. 18. Write Tests The idea is to build quality in. Unit test, integration test, .. any sensible test! Automate the testing Learn to write good test cases
  19. 19. Refactor Keep it really simple and continue to keep it simple as you go along. Make code clean and easy to read. Remove dead code, unused functions, and simplify further. Not worried about throwing code out for sake of better software
  20. 20. Quality is Easy Track bug -- assign to someone, set deadline + priority CAR -- Corrective Action / Prevention Action Poka Yoke -- Fail-proof Automation -- automate build, test and deploy CANI -- Continuous And Never Ending Improvement
  21. 21. Poka Yoke
  22. 22. Bug Tracking
  23. 23. Retrospective Over lunch if you have to. How did we screwed up?! What went well? What did we learn? How can we do better next round? This is NOT a blame session!
  24. 24. FACE FAILURE
  25. 25. Continuous Improvement Keep learning -- new tech, architecture, techniques, process Keep adjusting -- make it fit your needs or size Keep improving -- measure and improve, faster, less bug, happier customer
  26. 26. Summary 1. User stories instead of heavy requirement docs 2. Deliver iteratively and deliver working software asap 3. Estimation is hard, make it easier by breaking it down 4. Respect and trust is very necessary 5. Daily standup works, please do it Mon to Fri 6. Short to-do list works, use it 7. Write tests 8. Quality is easy, or easier if you build quality in 9. Retrospective to learn and improve more 10. CANI -- Continuous And Never ending Improvement
  27. 27. Because it's simple you can adapt and improvise
  28. 28. Thank You