CDD resembles TDD (Test-Driven Development) but is a little bit different on its soundness. As TDD generates code fastly and concisely otherwise CDD constructs the code on the strong ground. That is, CDD generates the code slower than TDD, but it can prevent most critical bugs in advance. Let me explain it further.

It focuses on checking and removing duplications including data dups and proc dups. You can check them in a ROUND. In every round, there are three steps to do:

1. Construct a small, unduplicated structure and test it within initial, medium and final state.
2. Search for dups out of the round.
3. Remove dups and replace it with better abstraction.

It seems like making a decision. When we have a meeting about some agenda, we firstly set a goal of the meeting. That really helps and propels the discussion but something would be missing: repetition of the same thing uselessly. Even though one thing is determined, that can be changed by other agenda (because we normally miss the relation among the subjects and they crash in some time).

I hate duplication and hope you too. Duplication may incur the breach of security rules and damage integrity. And I could avoid lots of dup-problems by CDD and couldn’t find any problem in it except keeping-deadline problem. In some business, it may not be a proper solution but I convince that it is a sort of cool methods to develop application.

Agile management comprise 2 steps: Top view called “Release planning” and bottom view called “Iteration planning”. Each has its special mission. Release planning makes the fundamental sketch onto a paper. Iteration is a part of the paper and participants focus on the part for a certain period. This is the main process of agile project management.

The basic planning unit is STORY which is not in the perspective of the task but of the functionality. Participants could consider many stories of user experience like clicking the start button and launching the program for instance. They should depict the case people might meet while using and should represent the function definitely.

Each story has its own score of difficulty. But there’s no absolute rule to estimate the difficulty. If you took a story of 3rd level of difficulty, then you could rate other stories by comparing with the story. The keyword is, RELATIVE.

Release planning collects stories to develop as many as possible and rates their difficulty scores. Then the load of the project would be determined by the sum. Secondly, you should know the velocity of your team, that is, how much score the team can afford in an iteration. Suppose that there’s a project named Abra which total score is 124 and the team’s velocity is estimated as 20. Then the team manager would expect that the project would be released within 7~8 weeks including buffer period.

Iteration planning concentrates on stories either, but more specific matters. First of all, the team manager should know the proper term for an iteration. That could be a week or even a month, but I think 2 weeks are moderate. In the example of Abra, we can assume that the velocity 20 is in an iteration with 2 weeks period. Then list up the stories and choose some of them up to score 20. (It can be varied in a few)

In the midst of iteration, there should not be any variation. Additional demands can be discussed after the iteration has ended. Then the team can re-estimate the score and update the release planning and the next iteration. Of course additional tasks should be written in stories.

This method is far better than traditional project managing tools I think. It can show the midterm result in the intermission between iterations and would suffice who wants to see the developing process visually. And it could be adjusted though there are many variations from special offerings. Anyway, agile management is a trend.