3

I have 10 developers and 3 Testes team and I want to setup CruiseControle as CI for automated builds, tests and deployment to production server and some repository for SCM ( Source Code Management). I need something that would enable the team lead to create tickets (tasks) for each sprint in SCRUM and issue/bug tracking and task time tracking. I want to use simplest possible solution that just gets the job done with the minimum requirements specified in this SO question. I do not want to use heavy weight or feature rich software ( either free or costly), just the simplest possible setup.

Each developer is using Eclipse STS IDE. So it must be something that is integrated into STS (like available as STS plugin, again to keep things as simple as possible).

This is for development of Java web application.

Improve this question

3 Answers 3

Reset to default
9

The best ticketing system by far is a white board with sticky notes.

This doesn't meet the requirement of integrating with STS, but I find sticky notes beat any software solution (as long as the team is not geographically dispersed).

  • They're extremely easy to visualize and work with.
  • Adding work to a sprint means physically adding a sticky to the board. This is a good barrier against scope creep.
  • The high visibility of progress is motivating.
  • It's easy to show nontechnical stakeholders what's going on.
  • The board becomes a meeting point where people talk to each other and exchange information.
  • It helps me get away from my desk and stretch my legs. As a desk jockey, I can use every health advantage I can get!

As for source control, use SVN or Git. If your employer demands you use some kind of heavyweight, bogged down "enterprise scm" that only gets in your way, use Git anyway and push to the central SCM on sprint boundaries.

Continuous Integration in Java projects is usually handled by Hudson/Jenkins these days. It's very quick to set up. Make sure you put up a radiator screen in a visible place!

Improve this answer
2
  • I wouldn't call it the best, but it's the best for the OP's requirements; +1.
    – Dave Newton
    Oct 30, 2011 at 21:59
  • Thank you but in my case the team is distributed globally.
    – ace
    Oct 30, 2011 at 22:49
1

I would recommend one of two approaches depending on your needs.

Firstly with a small fast team, where status reporting to your management can be done informally. In this scenario I would consider card based story boards, estimation poker (or what ever it's called), etc. Simply because in all the agile projects I've worked, the ones that have worked the best in terms of developers, testers and customers staying in sync and having a clear picture of what they are building and it's status, nothing beats the wall.

Secondly, if you have requirements for remote reporting, emailing status to others, and remote developers, then I would shift towards the Atlassian suite tools. They have a variety of online/offline tools and facilities, either free or reasonably priced. The reason I recommend their tools over the others I have seen and tried is simply because I think they are extremely well integrated, yet able to run standalone and play nice with others. This means that they are very flexible in how you use them. They are also very well built.

Improve this answer
1

I like Barend's approach.

If you have geographically dispersed teams, it is always a good idea to define them so they have as little overlap as possible. You can use architectural boundaries for this. Make sure each team is co-located and cross functional, then you get the best productivity.

Adding a ticketing system to a small team amounts to adding overhead. The nice thing of Scrum is that it only has a 10% overhead [Ivar Jacobson], which adds to the great productivity.

If you have tickets (bugs, work items, features etc) that cross team/architectural boundaries then an overall ticketing system might be useful, but then you should split these tickets up and create sub-tickets that are single team only.

You can then handle them in Barend's way, and you update/close them in the overall ticketing system when necessary/applicable.

Adding work during a Sprint is questionable, but if you do things a little more continuous, then you can use the ticketing system to represent the work backlog.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.