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 firstname.lastname@example.org 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.
Rod Johnson, founder of Spring framework, made great presentation on persistence strategies. He suggests to use O/R mapping framework in 90% of cases and layering/interfaces/Spring to separate persistence and domain model. I wonder when good IoC frameworks with persistence integration support will appear in .NET world. Spring.NET does not provide anything useful, Castle provides NHibermate integration and it works, but I don’t like Castle. I can’t clearly express my impression, but something in Castle is not attractive for me. Well, the one reason is in lack of IoC configuration, so you have to extend Castle to do something useful. Maybe this is the case.
But, anyway, Castle is the only useful thing for now and its architecture is quite flexible. So I hope things will change. And Castle project needs more support from .NET community for sure.
Ron Jeffries emphasizes two key practices for starting agile process:
1. Running Tested Software
2. Coaching and Training.
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.
More I read about Rails, more I think it is a good thing to try. David Geary writes that Rails development is much more faster than Java and it seems that it’s true.
I wrote on PHP some years ago and it was quite good experience. With TDD PHP development is easy and architecture could be very clear and robust. But I like .NET as well for component-based architecture, speed and scalability. It seems Rails is even better than PHP.
Oh, how to take some few hours from TargetProcess and try new technology?