It's been a while since I've been 'in the blogging scene', and I suppose the only way to get back is to start posting again! So, whilst this post may be small, I'm hoping it's beautiful.
Google have decided to address that age old problem... getting your new PC from the point it's at when you first buy it to actually being useful and on the way to being safe to use on the web.
They've put together the 'Google Pack'.
OK, so I like Google Earth, but I'm not sure it's quite essential, but the rest:
Google Desktop
Picasa
Google Toolbar for IE
Norton Antivirus
Ad-Aware
Adobe Reader
And THE most important one:
Mozilla Firefox
It's a stunning idea, though I'd probably add to that:
Open Office
AVG (Ok, so you've already got Norton, but AVG is ACTUALLY free)
Skype
Hitman Pro (Ad-aware is only one part of the anti spyware suite)
Sunday, January 08, 2006
Wednesday, December 07, 2005
Valued estimation
In "User Stories Applied", Mike Coen puts forward a method for estimating the cost of developing stories (or any other piece of work).
In summary:
* The development team get together with the customer.
* The customer describes a story.
* The developers quiz the customer until they are happy they understand the story.
* Each developer that wants to participate writes an estimate down.
* All developers show their estimates.
* The developer with the highest estimate states why they think it's so big.
* The developer with the lowest estimate states why they thing it's so small.
* The developers discuss the problem further until they're all happy they understand what's involved, and they estimate again.
The loop keeps going round until the team all have the same estimate, or they're happy to accept a compromise on one.
Once the stories are all estimated, they're put in a line of ascending cost and examined to make sure there are no discrepancies. If there are, then that story is re-stimated.
It works a treat, and the customers like it.
In fact they like it so much that they've come up with a variation...
Excluding the project manager, our customer team consists of two full time members and a number of people that work on our project only part-time. One slight issue is that over the last 18 months the full time members are becoming more a part of the Information Systems team and less in touch with 'The Shop Floor'. The part-time members help to ground them in the reality of the system.
On the other hand, the part time members aren't available to instantly evaluate new stories, and prioritise them accordingly.
So, once a week the customer team now get together in a 'Value and Take-up estimation'. It works in the same way as the developer estimates except the customer team are evaluating the value that a given story will add to the system, and then the take-up level expected for that part of the system in a scale of one to ten,
Obviously, the priority of a story is based on the combination of all three variables, Value / Take-up and Cost. Still, as a general rule, a story that scores high on Value and high on Take-up is going to be a story that will be prioritised very highly unless the cost is extortionate!
In fact the particular values may not be that important; there is no point discussing if a Value 8, Take-up 7 story is more important that a Value 7, Take-up 8 story on the basis of the raw values alone.
Rather it's the forum for the discussion of the values that provides the real insight, and allows everyone to have their input.
It's working to ensure that the team is working on what the whole customer team decide is the most important task, and not just the one with the loudest voice...
Technorati Tags: XP, Extreme+Programming, agile, software, development, programming, estimating, user+stories, software+development, Robert+Baillie
In summary:
* The development team get together with the customer.
* The customer describes a story.
* The developers quiz the customer until they are happy they understand the story.
* Each developer that wants to participate writes an estimate down.
* All developers show their estimates.
* The developer with the highest estimate states why they think it's so big.
* The developer with the lowest estimate states why they thing it's so small.
* The developers discuss the problem further until they're all happy they understand what's involved, and they estimate again.
The loop keeps going round until the team all have the same estimate, or they're happy to accept a compromise on one.
Once the stories are all estimated, they're put in a line of ascending cost and examined to make sure there are no discrepancies. If there are, then that story is re-stimated.
It works a treat, and the customers like it.
In fact they like it so much that they've come up with a variation...
Excluding the project manager, our customer team consists of two full time members and a number of people that work on our project only part-time. One slight issue is that over the last 18 months the full time members are becoming more a part of the Information Systems team and less in touch with 'The Shop Floor'. The part-time members help to ground them in the reality of the system.
On the other hand, the part time members aren't available to instantly evaluate new stories, and prioritise them accordingly.
So, once a week the customer team now get together in a 'Value and Take-up estimation'. It works in the same way as the developer estimates except the customer team are evaluating the value that a given story will add to the system, and then the take-up level expected for that part of the system in a scale of one to ten,
Obviously, the priority of a story is based on the combination of all three variables, Value / Take-up and Cost. Still, as a general rule, a story that scores high on Value and high on Take-up is going to be a story that will be prioritised very highly unless the cost is extortionate!
In fact the particular values may not be that important; there is no point discussing if a Value 8, Take-up 7 story is more important that a Value 7, Take-up 8 story on the basis of the raw values alone.
Rather it's the forum for the discussion of the values that provides the real insight, and allows everyone to have their input.
It's working to ensure that the team is working on what the whole customer team decide is the most important task, and not just the one with the loudest voice...
Technorati Tags: XP, Extreme+Programming, agile, software, development, programming, estimating, user+stories, software+development, Robert+Baillie
Friday, November 11, 2005
Firefox past 10 percent
According to this week's New Scientist, Firefox has managed to get more than 10% of the web browser market.
When I read that I was surprised.
It seems that readers of this blog are much more discerning than your average internet user. For some time now Firefox has been the browser used in more than HALF the requests to this site!
I'm sure that says more about bloggers and their readers than it does about this site in-particular...
When I read that I was surprised.
It seems that readers of this blog are much more discerning than your average internet user. For some time now Firefox has been the browser used in more than HALF the requests to this site!
| New Scientist report | Bobablog readers | |
| MSIE | 85.45% | 44.42% |
| Firefox / Mozilla | 11.51% | 51.44% |
| Safari | 1.75% | 1.56% |
| Netscape | 0.77% | 0.32% |
| Opera | 0.26% | 1.56% |
I'm sure that says more about bloggers and their readers than it does about this site in-particular...
Non-techie Tip of the Month
Sorry to still be way off topic, but I was given a beautiful gem of a tip today.
Have you ever accidentally written on a whiteboard with a permanent marker?
If so, you'll know how painful it is trying to remove it again with solvents. Far too much elbow grease required for my liking.
Well, we had one of those moments today and someone piped up with a glorious bit of help.
Simply write over the existing text with a proper whiteboard marker, then rub it off with a normal whiteboard rubber.
Zero effort and a clean whiteboard!
I promise that normal Oracle and PHP based services will be resumed soon...
Have you ever accidentally written on a whiteboard with a permanent marker?
If so, you'll know how painful it is trying to remove it again with solvents. Far too much elbow grease required for my liking.
Well, we had one of those moments today and someone piped up with a glorious bit of help.
Simply write over the existing text with a proper whiteboard marker, then rub it off with a normal whiteboard rubber.
Zero effort and a clean whiteboard!
I promise that normal Oracle and PHP based services will be resumed soon...
Tuesday, November 08, 2005
Subversion de-perversion
Mr Mason has done it again.
For those that use Subversion for their version control, Mike Mason's blog is a must subscribe. He doesn't post often, but when he does it's invariably useful. His latest post covers splitting and merging Subversion repositories. As usual, reading it leads to an "Of course that's how you it!" moment.
If you haven't already picked it up, his book, "Pragmatic Version Control with Subversion" is a great introduction to Subversion.
Technorati Tags: Subversion, version+control, CVS, VCS, SCM, Mike+Mason, Robert+Baillie
For those that use Subversion for their version control, Mike Mason's blog is a must subscribe. He doesn't post often, but when he does it's invariably useful. His latest post covers splitting and merging Subversion repositories. As usual, reading it leads to an "Of course that's how you it!" moment.
If you haven't already picked it up, his book, "Pragmatic Version Control with Subversion" is a great introduction to Subversion.
Technorati Tags: Subversion, version+control, CVS, VCS, SCM, Mike+Mason, Robert+Baillie
Subscribe to:
Posts (Atom)