Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

My Agile team is following practices of XP like pair programming(J2EE), 45 work hours/week, TDD etc. Do you have any recommendations of open source tools (dev, test & build integration) and templates(user story, burndown charting) etc. for enabling my team to focus on business value delivery. I am the iteration manager and we have tried Hudson, Junit and Selenium.

share|improve this question

migrated from stackoverflow.com Dec 7 '11 at 9:39

This question came from our site for professional and enthusiast programmers.

closed as not constructive by ChrisF Dec 12 '11 at 15:12

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.If this question can be reworded to fit the rules in the help center, please edit the question.

3  
This question would find a better audience at Programmers, where I've voted to migrate it -- however, I think they would want this question to be expanded upon significantly before it would be a "good fit" there. I'm not often over there, but I expect you should probably say what you liked / disliked about the tools you used and where your team has issues or doesn't see the promised improvement in quality, satisfaction, job satisfaction, etc.. –  sarnold Dec 7 '11 at 9:29
3  
45 work hours a week? Bummer. –  Bryan Oakley Dec 7 '11 at 12:01
1  
I've never heard of a 45 hour week as an agile practice. Do you have a reference for that? –  Karl Bielefeldt Dec 8 '11 at 21:34

2 Answers 2

Without rehashing all the litterature out there regarding agile organisation, I will just say, in my opinion, is the most important for a successful Agile project:

  • Communication You may have read that somewhere, it's the truth: agile is all about communication. It's all based on the fact you get frequent updates from the users (if they're actually involved in writing story, and maybe even in designing acceptance tests, that's even better), but also giving them frequent feeback (release after every iteration) and also communication within the team: pair-programming, daily stand-up, iteration planning meetings, retrospective meetings, etc. I found that an invaluable tool for communication is the story board: despite all our tries for online versions, we always came back to a physical board. Nothing beats being able to manually handle the cards to move them around, pick them when you're working on them, and having the standup meeting around the board where everyone can see what people are talking about, and decide what to do for the day.

  • In term of development, the most important is testing. Aim for a very high coverage (ideally 100%, but the most important is functional coverage), that's the only way to enable refactoring (paramount in agile dev) in a safe and efficient way. The ideal test coverage has three layers of tests:

    • Acceptance tests (ideally written by the users) maybe using something like JBehave or FITness to give the ability the write the stories in natural language, while being dynamically ran against your production code. Thus, these tests/story also act as documentation to your project. Very valuable to provide visual feedback to users and visitors, and remind you of everything your code is doing. ALL the stories yo're working on should have at least one of these tests attached to it, so that you know when the work is complete on that story: when the acceptance test(s) is(are) passing.

    • System / integration tests: These are tests designed to make sure all the various components in your project (database, web server, etc.) can interact nicely (this includes CRUD tests for your db entitities).

    • Unit-tests preferably using TDD (ideally BDD) to design the details of the system. Using JUnit and a mocking framework (My favourite is JMock v2)

And also

  • Flexibility. Don't try to blindly follow XP or Scrum as written in the books. Try different approaches, for a couple of weeks each time, see what works with your team and increase your productivity, and don't be afraid to adopt or dismiss practices. It's all about pragmatism and what works with your team. For example, I've been in project where we switched pair every day, every couple of days, and even every couple of hours. What's best for you will depend on the rate of your project, your users, and the developers in the team. Try everything, then decide. And feel free to change anytime you feel there's an advantage doing so. Use retrospective meetings (every month or couple of months) to discuss what works and what doesn't and get feedback from everyone. It's very important to discuss how the various practices are perceived by the team. Invite some users, and some external observers to these. It's amazing how someone who doesn't know anything about your project can sometimes contribute and bring a very interesting fresh point of view on a problem you may have.

Another couple of things that served us well in the past:

  • Always maintain a very detailed release notes document. Ideally available to your users for reference (through a website, or a wiki), it shows what went on a release iteration after iteration. Link to that document as often as you can. An agile project evolves very quickly (if you release after each iteration) and it's sometimes confusing for the users or related systems, who are not used to that pace for releases, and expect less frequent "big bang" releases. Educate them.

  • Always favor a flexible (spreadsheet-based?) approach for measures and reporting: a burndown chart is very nice to maintain daily and have available during standups, to see how good you are at estimating stories (it is not a measure of the productivity of the developers, in XP it's assumed everyone do the best they can)

share|improve this answer
    
For burndown our company use http://epf.eclipse.org/wikis/scrum/Scrum/guidances/templates/burndown_chart_D18‌​2CF23.html –  Shree Dec 7 '11 at 9:58

We use a combination of FogBugz and Stefan Rusek's excellent Kanban board. FogBugz handles ticket tracking, burndown charts (and much more), and recently they've added Kiln, which is an integrated, hosted Mercurial.

Also, though I haven't tried it, I understand some smart Java folk I know are interested in JBehave, a BDD framework for Java.

I wholeheartedly concur with @Guillaume's much more thorough response. I would add one thing to that however, though I'm in danger of stating the obvious:

For agile to work, you have to write user stories to express the functionality you want. Perhaps what I really mean is that you can't let people only write old school functional specifications and expect agile to work. The user story really is the basic building block for the whole thing.

share|improve this answer
    
+1 for your last point. I've seen loads of projects where the manager suddenly decides that he wants to go agile because it's trendy, so he hires "agile" devs, split the time in iterations or sprints, and call it agile. Wait, what? Aren't you forgetting something? –  Guillaume Dec 7 '11 at 16:10