Entaggle: an Agile Software Development Case Study


Published on

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

No notes for slide

Entaggle: an Agile Software Development Case Study

  1. 1. Entaggle.com<br />A Case Study in Agile Software Development with Rails<br />Give Recognition<br />Get Recognition<br />Tag, you’re it.<br />Elisabeth Hendrickson<br />esh@qualitytree.com<br />Last updated April 11, 2011<br />This presentation is licensed under the Creative Commons Attribution 3.0. Permission granted to distribute and excerpt. Attribute this work to Elisabeth Hendrickson, Quality Tree Software, Inc.<br />
  2. 2. Overview<br />First code written in October 2010.<br />Announced to the public March 1, 2011.<br />Automated continuous deploy in place from the beginning.<br />Test-driven from the beginning.<br />Built with Rails using Devise, Paperclip, Kaminari, HAML, SASS, JQueryUI with Rspec & Cucumber for testing and Fixjour for test data creation.<br />Build w/ all tests currently takes 13 mins.<br />…and it’s a “spare time” project.<br />
  3. 3. Ch-ch-changes<br />Two complete UI rewrites since the first placeholder UI put in place. (3 UI designs total since the beginning.)<br />The core “Tagging” user flow has changed uncountable times based on feedback.<br />New features added at least weekly.<br />Backlog reprioritized frequently based on user feedback.<br />
  4. 4. User Suggestions Come From…<br />Email<br />Conversations<br />
  5. 5. Reprioritizing<br />I thought these things would be critically important:<br />Moderation & admin features<br />User “credibility” and Tag “prestige”<br />I was wrong.<br />Turns out these things were more important:<br />More engaging UI/flow<br />“Since you were last here…”<br />Instrumenting & Metrics<br />
  6. 6. Key Factors for Agility<br />Frequent checkins<br />Automated “checks” at both unit & acceptance levels<br />Automated deploy to Staging<br />Relentless attention to removing sources of friction<br />
  7. 7. My Workflow<br />Develop until green & clean. Then check in.<br />Pick up the next story.<br />Back to start.<br />If ready, manual deploy<br />Build kicks off.<br />If build passes, automatic deploy to Staging<br />Exploratory Testing<br />Go see it in multiple browsers.<br />My CI Box (running Hudson)<br />PRODUCTION<br />STAGING<br />
  8. 8. Frequent Checkins<br />Github “Punchcard” Graph<br />
  9. 9. Automated “checks”<br />239 Rspec examples (includes unit & integration tests)<br />90 Cucumber scenarios with 684 steps<br />Over 93% code coverage<br />All major user flows covered in Cucumber scenarios<br />
  10. 10. Code Coverage (Rcov)<br />WHY THE DIP? For no apparent reason, Rcov suddenly started counting coverage for standard ruby libraries. Edited the rake task to explicitly exclude them & coverage went back to normal.<br />
  11. 11. Automated Deploy<br />If the tests pass, Hudson CI server uses a shell command to deploy:<br />git pull && <br /> bundle install &&<br /> rake db:migrate &&<br /> touch tmp/restart.txt<br />(in the past I’ve used Capistrano; may decide I need it again. But not yet.)<br />
  12. 12. Examples of Relentlessly Removing Sources of Friction<br />Regularly refactoring to remove crufty code.<br />Avoiding the generators: they spew large amounts of templated code.<br />Investing in making deploy to staging automatic, smooth, & secure w/ RSA key authentication.<br />Investing in making deploy to production trivially easy.<br />Creating shell command aliases for frequent command sequences.<br />
  13. 13. Results…<br />Stats:<br />93 user stories completed including 22 user-requested enhancements<br />10 user reported bugs (only 1 critical in production). 41 self-reported bugs. 46 of 51 bugs closed. All 5 remaining open are self-reported.<br />Production busted for ~3mins once on a bad deploy. Otherwise it’s been up.<br />Almost non-existent “WTF?!?!” incident count.<br />
  14. 14. Lessons Learned (and Reinforced)<br />The tests are totally worth it, even when it is tempting to skip them.<br />However, high code coverage != well tested. Exploratory Testing is essential.<br />Building up an inventory of unused acceptance tests was an unfortunate waste.<br />Splitting stories until they represent <= 2 days worth of work is essential for keeping momentum.<br />
  15. 15. Appreciations…<br />…to the following contributors:<br />Pat Maddox, Dale Emery, Joseph Wilk, Michael Dowling, Richard Scherek, and LasseKoskela all paired with me on writing code.<br />Andy Hohenner helped with System Administration.<br />Yves Hannoulle has been an ardent supporter and evangelist.<br />Marcus Smith created our cheerful “e” logo and Darren McMillan created the favicon.<br />The Entaggle community has helped me steer the project with great suggestions.<br />The Weekend Testers kept me busy with bug reports.<br />