program development and documentation

Had an interesting discussion with one of my colleagues the other day. He said that the team he is working in has adopted a 'sprint' approach. I thought that was good, until he went on to say that he had no time to document the work that was being done. That is not at all good, and goes against one of the main principles - "Done means done". In my view, if work is not documented, then it is not completed. It becomes impossible to maintain, and hard for someone else to deal with when the originator goes on holiday (or is ill).

It is something I will bring up at the monthly staff discussion group next week.

testing and Agile

One of the problems regarding how to test in an agile development team is the area of system integration and I include performance testing as well. It is all well and good getting the designers to write tests for their pieces of work, but who can write the tests that cover those units being integrated into a working whole?
The plan we have come up with, and one that seems to work reasonably well is to have the integration testing done "one sprint behind" the development work. Of course, it is mostly automated scripts so that regression testing can be performed easily.
The difficulty of writing tests whilst the code is being developed can best be seen when trying to test user interfaces. It is quite possible that the position of buttons, selection lists and text areas changes whilst the program is being worked on, so writing tests that check for the operation of those items is best left until the work is done.

Testing in an Agile development team

I have been reading up on Agile development over the last few weeks, and one thing that has concerned me when looking at Xtreme Programming is the apparent lack of dedicated testing staff. Indeed some proponents feel there is no need for any specialists at all. The view is that each developer tests their own unit of code.

But, there is much more to testing than testing individual units. There is integration and system testing as well as performance, resilience and load testing. However, the developers feel that they are not skilled enough to do anything except unit testing.

I was happy to come across a couple of sites that to me at least, put forward a more balanced approach to development and testing. One of them, testobsessed.com I have found to be particularly helpful.

burning the candle at both ends

Just sat watching the BBC news this morning and heard the item on the effects of lack of sleep. Must admit that I have recently been working late nights and early mornings (called burning the candle at both ends) especially with the unpaid work I have been doing outside of my regular employment.
Anyway, last night I went to bed earlier and clocked up a good 7 hours sleep, and must say I felt much better this morning as a result.
I notice in my reading on the Agile development methodology (philosophy/approach/paradigm?) that it is stated the team should not work more than 40 hours per week. And I can see why. Performance suffers when working longer hours.