We have released a new version of our agile project management software. It has many small, but very useful improvements that significantly simplify project planning and tracking processes.
Per user pricing is $149. But we offer free version for non-commercial open source projects. So contact us at info@targetprocess.com if you participate in open source project and want to use TargetProcess for collaboration and planning. In fact, TargetProcess works fine for remote teams.
Dr.Explain is an interesting tool that can create nice help files. But I wonder how often such help files required. Huge software like powerful IDE or complex web application should definitely have comprehensive user guide, since there are so many features. On my opinion, most software should be intuitive. In some cases context help is a good idea, but moderate user should be able to figure out how to do things without help.
At least I’ve wrote some FIT tests. FIT is an acceptance testing framework for business logic. So here are my first impressions:
FIT tests are simpler to write than Unit tests. One of the main reason is external data. In FIT you set all data right in table, while in unit test you often set data in test method. Looks like useful separation.
FIT is more convenient for integration tests. It is possible to create integration tests in XUnit, for example, but it takes more time
Test tables could live with specification without any problems. You could include them in user story description, save document as html and use these html as input data for tests. Very simple and keep docs and tests in sync.
But in general I don’t see huge difference between FIT tests and Unit tests from developers point of view. The result is almost the same – the only difference is that test tables could be provided before development by customer. Well, on the other side, this difference is huge :)
How to determine Project Health with Burn Down Chart? Let suppose that the Project consists of 18 User Stories and 3 Iterations were finished. We would like to estimate the date when the Project will be finished.
Let look the picture bellow. At beginning of the project we have sorted all User Stories by Risk and Business value. We have started from the most risky tasks. That is why only 4 of them were made at first 2 iterations. As we see, the team’s productivity increasing from previous iteration to next.
At the first look to receive correct finishing date of the project it is enough to approximate last iteration productivity until it crosses the time axis. We assuming, that our team will work at least with the same productivity or even better. There are good reasons for our assumption: inter-team organization and understanding of the project have increased, complexity of User Stories have decreased. This can be true for ideal project. However in real project Burn Down Chart will look mostly like below.
What has happened? We have just forgotten about integration and bug fixing. The count of bugs and integration time are increasing with the increasing of completed User Stories number. That is why the time left to make new features was decreased.
I’ve checked my experience and it seems Ron is absolutely right. In every team I start exactly from Test-Driven Developmet+Iterations and Trainings. Short and regular releases together with TDD greatly increase project focus and team productivity. While without training nothing will work at all. I never worked with developer who has been doing TDD before I showed him. I never worked with developer who knew XP before my team. That’s sad, maybe, but training is a key.
