Best concrete “How-To Manual” on *Managing* Test Driven and/or Agile development? [closed]

Answer 1

I suggest that you start with what you agree on: Nightly Builds and Automated tests. Nightly builds is a no-brainer. For Automated tests I would start with:

• Each commit with new functionality should have at least one automated test
• Each commit that fixes a bug should have at least one automated test that fails without the fix and succeeds with the fix

If you do this, you will start to gain experience. With this experience it will be much easier to understand all the good advice that the literature has.

There is a lot of good books on good practises, but you have to figure out what works for your team.

Answer 2

my favorite is Planning Extreme Programming

EDIT: it provides a complete replacement for traditional project management geared towards an XP/Agile team

the danger is, adopting modern development methods and then strangling them with archaic project-management and administration practices!

Answer 3

You can print him Scrum and XP from the Trenches by Henrik Kniberg, It's more focusing on agile development process that on TDD, but it's an easy and quick read.

Answer 4

Check out books by Marty Cagan.

Answer 5

Sadly, even the most clear and specific plan can turn out to be disputable.

I'll tell you what works. Starting TDD immediately. It has boundaries. It's relatively easy. You'll still have a million questions.

You are free to say, "But what about nightly builds?" "What about using the bug tracker?"

A lot of pondering can mean one of two things.

First, it can mean that someone is muddying the waters with "concerns" and "questions". Sometimes this is really displeasure at changing, voiced as "concerns". Sometimes this is really crushed egos ("I thought I was pretty sharp, now someone is saying I must have improvements imposed on me.")

Second, it can mean that this is dauntingly large. Consequently, don't look at this as "Many New Best Practices". Look at this as just a few incremental improvements. You're not changing yourselves fundamentally (well, that could happen, but don't start out with that as your plan.)

My experience is that you can only do one new thing at a time. Do TDD until it's boring. Then do something else. Often nightly builds become obvious after you have a robust test suite. Then when that's boring, do some other small, incremental process improvement.

One thing at a time. Baby steps. Avoid throwing out babies with bath-water. All you want is to be a little better next month than you are this month.

If there are concerns on adopting one small incremental improvement, find the root cause. Who's ego is bruised? Who's worried about change?

Answer 6

Agile methods are not really methods...

There are more a spirit. The main is a focus on :

• communication

• reactivity to changes

• customers orientation

This can be achieved in lot of ways, and it's more important to find your way to do it. If you want an example of what this spirit can be, you can read the free 37signals' online book, Getting Real.

But there are some steps you can start with

They are no big rules you must enforce, but you can try the following and see how it goes with you team :

• Quick stands up meetings. 5-15 minutes daily meeting where everybody stays up on his feet and explain what he has accomplished, what need to be done and what can prevent him from doing it. Keep it under 15 minutes, with the minimum number of people.

• Set simple goals for short term deadlines instead of big goals in weeks.

• Build small team (3 persons) and divide the work between them. Put them in the same room and ensure they have at least half a day to work without ANY interruption.

• Set many little regular review with your customer. Don't write specs. Sketch, design, prototype, show to the customer, fix/adapt/change then build. Then do it again.

• Testing, versioning, bug tracking are tools, not methods. No one cares how you do it and with what software are long as you do it. They are not the issue.