I've previously recommended Bullseye. And there is another nifty feature with Bullseye you should know; the ability to merge reports. This is pretty useful when you have one report from your unit tests and one from some other type of test run. Use this command to merge reports with Bullseye:
covmerge.exe -c -fMergedData.cov file1.cov file2.cov
Today we had our first coding dojo in our team. We did the MineSweeper kata and once again the dojo ended up doing the same thing as usual; got to focused on the end to end tests and string parsing. During the retrospect we concluded that event though we had a short design session in the beginning we didn't really use that design for anything else than naming conventions. We also recognized that the first test written kinds of sets the key for the session. If the first test is testing end to end, then it is easy to continue on that path since you need a second test to refine the design. Instead a better approach is probably to pick some part from the design and start testing that. The school book BDD with outside in demands faking things underneath and if you don't do that you should probably not start outside in - you should to it the classical TDD way; create building blocks as needed - inside out. Or my favorite; middle out...
But all in all (as usual) I think it was a fun experience and I'm already looking forward to the next session.
Your favorite agile literature probably talks about the importance of defining what done means so everybody (team and product owner if we use Scrum terms) knows what we mean when we say something is done. And having a catchy acronym to remember what your definition of done is is in my opinion a good thing.
When I did my Scrum certification a few years ago I learned an acronym that was a suggestion for what done meant. The catchiness in this acronym is that it is the Swedish word for done:
If you're a BDD/TDD practitioner you're probably used to create a failing test whenever you have a new bug reported and you want to fix it. But sometimes a situation arises where you have to do the opposite; creating a passing test before you fix a bug.
Let me explain with an example. Let's say that you have code that uses date and time to calculate something. It all works fine. Then you go into daylight savings time and the test fails. Your first reaction might be to change the code to work but since you only have one test you might end up changing the code so that in half a year when you stop using daylight savings time the test fails again. So a better approach to handle this problem is to first create a test that passes before you change the code. Once that is done you have your (old) failing test and you fix the problem. Now you know you have code that works both with and without daylight savings time.
Your favorite Scrum book will say "seven - give or take two". If you look at group theory (such as FIRO) you'll see things like "five through eight" or "if the group is more than ten people you'll have smaller groups forming within the group". Another interesting way to decide on team size I read about is the "two pizza rule"; If you can't feed your team on two pizzas or less the team is to big.
I think this a great way to describe maximum team size since it's funny and I guess it sticks. There might be a problem though since pizza size may vary. Two typical Swedish pizzas would not feed more than two or three hungry developers. If you go family size (or a typical US pizza I guess) you easily feed around five hungry developers. But I guess that is over analyzing the two pizza rule... Don't do that... Just buy two pizzas!
Some teams come up with a number of team rules that are posted next to the task-board. The idea is to have a number of rules that everybody in the team are committed to follow. And there is typically one rule at the top:
Anybody can remove a rule they are not committed to at any time, this rule excluded.
I think this is a great exercise to force the team to talk about their expectations on each other. Because rules can be anything from detailed practices to general things. So the discussion is actually more important than the resulting list of rules in some cases.
An observation we made in our team when we recently had a team rule discussion is that the word "rule" implies a punishment when not followed. So in my opinion a better word for this exercise is "team values" because that's what we're discussing. A number of common values that the whole team have the same understanding of. Because if you just list a number of values without discussion the meaning, then different people with interpret them differently. So what kind of values can a team come up with? Well here are a few examples:
Do you have more examples of values you think a team should consider?
A typical problem in an organization "starting to be agile" is that some managers (typically middle managers) don't see where they fit into the new process. So in order to complete the transition successfully you need to have especially middle management in the plan. At a talk at Scrum Gathering 2008 it was mentioned that middle managers should be involved early and encouraged to participate in the process of identifying their new roles.
So what are these new roles? If we use Scrum as an example (because it is popular and has three well defined roles) it is obvious that managers typically don't are part of the team. They're manager and often cannot contribute to the sprint just like any other team member. Managers also typically dislikes being demoted to team members. They worked hard to be managers...
So many managers thinks Scrum master sounds like a new cool title for them. I think this is where many companies go wrong. The Scrum master is not a manager. It's a coach, facilitator and guardian of the process, the team and product owner. As such the Scrum master must be skilled and be really excited about the cause. Another warning. Even when the manager actually has the skills and desire a Scrum master needs it might still be a bad idea making him a Scrum master because of the risk that the team will hear him speak as a manager and not Scrum master hence "following orders" rather than "listening to advice".
So that leaves us with the product owner role. In my experience companies successfully adopting Scrum tend to make their former managers product owners. This way their old management backpack does not affect the team's evolution and also the managers are doing what they've always done; prioritizing and deciding what the team should do (but now in a new way).
Sometimes the manager is not skilled enough to be a product owner because someone else has more knowledge of customer requests and so on. Don't panic! In my experience people with good knowledge of what the customers really want often feel they have little or no time to spend with the team. So even though this is not an ideal scenario the former manager can step in as a product owner proxy when needed. You can also be assured that the team will come up with a list of impediments they cannot solve. So you as their former manager can come to their rescue help the team unblock some impediments.
And even if you're not the Scrum master nor the product owner you can still help the team by coaching them toward "better". For more tips on what managers can do read about daily stand-ups and impediment involvement.
I recently was involved in troubleshooting a problem on a HPUX system.It turned out that the system command iostat showed one disk and the configuration (/etc/lvmtab) showed another disk. Yet another symptom was that lvdisplay didn't work at all. Since there had been a bunch of activity on that system it took some detective work to find out that the reason for the problem was that the raid controller had been replaced.
So this still amazes me. The configuration said one thing and the monitoring tools another but still the host worked just fine. Actually it was a little slow but apparently the mix-up of disk devices didn't matter. So when other systems have their hardware changed you need to rescan it so how do you do that on HPUX? Well this is how you fix your disk configuration if you have one volume group named "vg00":
In multiuser mode:#/sbin/vgexport -m /vg00.map -s -p -v vg00 Reboot the system and go to maintenance mode:#shutdown -ry 0 [Esc]
Main Menu: boot pri islInteract with the IPL?> yISL> hpux –lm #/sbin/vgexport -v vg00#/sbin/mkdir /dev/vg00 Create the special device file (SDF), use the next available minor number:#/sbin/mknod /dev/vg00/group c 64 0x##0000#/sbin/vgimport -m /vg00.map -N -v -s vg00 vgchange -a y vg00 Reboot the system to multiuser mode again.
Preemptive comment response: No I don't know why the system was not reconfigured immediately after replacing the RAID controller. Probably because everything seamed to work after booting.