Embedded Systems Conference 2007 in San Jose, California, is having some interesting events. James Grenning is giving several sessions and people from Atomic Object are coming to tell about their low level system agile testing methods.
The best news is that right after my vacation (still have some three to four weeks to burn) I'm going to attend the conference with a colleague. Talking about nice return to work! I'll try to have energy to write something about the conf'.
2/27/2007
2/12/2007
Scrum Simulation Rocks
Last week I gave an introduction to agile development and Scrum for a global project organization in Shanghai, China. After the lunch on first day it was time for 59min Scrum simulation. I have written about bad experiences when trying to achieve too much, so it was back to the basics.
There were participants from Finland, China, and Mexico. We used the product backlog for Family Cookbook. Only addition to original Scrum simulation was the use of relative complexity estimations on product backlog items. This time it worked. Estimating the tasks in numbers gave birth to discussion on whether something is simple, or not, not just dividing an item into tasks. Some items were also soon identified to be too large to fit in one 14 minutes Sprint. Team was immediately forced to seek for collaboration with Product Owner.
On retrospective the main thing experienced was the time pressure. I do not see this as a bad thing, it is just the beginning of understanding the discipline needed for time-boxed development. Time pressure will decrease when the team builds trust and improves estimating.
Everyone valued the exercise and though that it was a good lesson. I might consider adding a separate exercise for planning and estimating before the final Scrum Simulation. With this early experience I do not think that I will ever try meaningful work inside the simulation again. The difference was so clear.
There were participants from Finland, China, and Mexico. We used the product backlog for Family Cookbook. Only addition to original Scrum simulation was the use of relative complexity estimations on product backlog items. This time it worked. Estimating the tasks in numbers gave birth to discussion on whether something is simple, or not, not just dividing an item into tasks. Some items were also soon identified to be too large to fit in one 14 minutes Sprint. Team was immediately forced to seek for collaboration with Product Owner.
On retrospective the main thing experienced was the time pressure. I do not see this as a bad thing, it is just the beginning of understanding the discipline needed for time-boxed development. Time pressure will decrease when the team builds trust and improves estimating.
Everyone valued the exercise and though that it was a good lesson. I might consider adding a separate exercise for planning and estimating before the final Scrum Simulation. With this early experience I do not think that I will ever try meaningful work inside the simulation again. The difference was so clear.
2/02/2007
TDD'ing State Machines
I'm an electrical engineer. Everything in programming seems to be very very hard for me. Last week I spent 40 hours in aeroplanes, so I had some quality reading time. I did read Agile Estimating and Planning and Test-Driven Development from cover-to-cover. I had quickly gone through them earlier, but this was enlightening experience.
First of all, I have told that we have been trying to figure out effective TDD for our FW development. To be honest, we've struggled. We wrote tests for a state machine implementation. We expected the tests to be run in certain sequence, and that the state was always left where it should be after the test. We of course ended up in lot of rework on test code when our state machine design emerged. We thought that we need to design the state machine up-front in order to be able effectively write tests for it. This did not sound like test driven development at all. This required some more thorough thinking.
So back to my flight. Kent Beck writes that coupling is bad also between tests. A test should leave the system as it was. So writing unit tests in the same sequence as you expect your state machine to work does not seem like a right thing to do. You should be able to execute individual tests and to change the order of individual tests. So instead we are starting to recognize a single state as something to test.
Ph.D. Miro Samek writes about state machines being a killer app for function pointers. He further defines a design pattern for state chart implementation. Our state chart interface has become to be something like:
construct()
dispatch(event)
construct is self explaining and dispatch dispatches new event. We have specific event tick that gives resource time to state machine every 10ms (based on our 50Hz mains). We could also implement a timeout as OS service, and not to have local counters for timed events. Anyway, if we implement each state as a function as Mr. Samek proposes, and we hold our state as a function pointer we can write
dispatch( me, event )
{
me.myState(event);
}
We get rid of cryptic switch -structures. This solution helps us to unit test each state as a function with natural feel.
I'm going to write some benchmarking code to see the actual overhead, but at the moment I like this idea.
First of all, I have told that we have been trying to figure out effective TDD for our FW development. To be honest, we've struggled. We wrote tests for a state machine implementation. We expected the tests to be run in certain sequence, and that the state was always left where it should be after the test. We of course ended up in lot of rework on test code when our state machine design emerged. We thought that we need to design the state machine up-front in order to be able effectively write tests for it. This did not sound like test driven development at all. This required some more thorough thinking.
So back to my flight. Kent Beck writes that coupling is bad also between tests. A test should leave the system as it was. So writing unit tests in the same sequence as you expect your state machine to work does not seem like a right thing to do. You should be able to execute individual tests and to change the order of individual tests. So instead we are starting to recognize a single state as something to test.
Ph.D. Miro Samek writes about state machines being a killer app for function pointers. He further defines a design pattern for state chart implementation. Our state chart interface has become to be something like:
construct()
dispatch(event)
construct is self explaining and dispatch dispatches new event. We have specific event tick that gives resource time to state machine every 10ms (based on our 50Hz mains). We could also implement a timeout as OS service, and not to have local counters for timed events. Anyway, if we implement each state as a function as Mr. Samek proposes, and we hold our state as a function pointer we can write
dispatch( me, event )
{
me.myState(event);
}
We get rid of cryptic switch -structures. This solution helps us to unit test each state as a function with natural feel.
I'm going to write some benchmarking code to see the actual overhead, but at the moment I like this idea.
Subscribe to:
Posts (Atom)