Monday, November 29, 2010

How to accurately estimate projects.....

Most people estimate how long something will take by trying to figure out how long a task will take. Most of the time that works, however for software, it fails miserably. See, it's not about the task, it's about the behavior the user wants. Behavior can't be easily defined the same way a task can be.
Take for instance this task:
Resolve issue with business stuff that's irrelevant (default materials lists were not being created w/ new programs)

The key here is the word issue. It's not defined. So you have to figure it's at least10 hours to get it defined. Then you can get actually implement what they want. Then you have to define what a default materials list is, and what they mean by default. The more people that are involved, the longer that will take. Say another 10 hours at least.
See, the easy part is writing the code. The hard part is figuring out what the heck it's supposed to do. Most project managers, and project management software think that's a task. It's not even a requirement.
Here's another one:
Final notification would be provided to someone indicating that they were something good

Here again the words final notification provide a whole world of unknowns. How will this happen? Will the user have the option to specify the method of notification? That's probably another 10-15 hours of wrangling right there. Then, another 5 hours for the actual content of the notice itself. If it's different formats, you might have another 5 hours wrangling over typography, format etc.
Another one:
Ability for roles within some department to search for people and leave notes

Roles? Which roles? Are they new roles? Search for people? By what SSN? customer ID, email? phone number? Do you know how many ways there are to find someone? Then how do you present the list? How does the user know that they have found the right person? *SIGH* Another 15-20 hours of wrangling.
Here's one more, and one of my favorites:
Business status identified and managed effectively

Manage? Manage? What does that mean? Simple Create/Read/Update/Delete functionality? Do we need a business rules engine? There's a huge difference between managing a 3 person business, and a multi-national corporation. Manage.. really... not even close to being a good requirement.
So what makes a good requirement? Anything that defines behavior. That's not something that can be defined in a single sentence. It's certainly not something that can be defined easily in MS Project, or any other project management software. It's at least a paragraph, probably more.
See not only do you have to define what you want the software to do (how it behaves) when things are good, but also when things go badly. There are usually more things that can go wrong then can go right. Each of those is it's story, it's own behavior.
Project management says you can start when you have all the tasks that need to be accomplished specified. This is just not possible. You're not done when all the tasks have been accomplished. You're done when the software behaves as the user wants.
This is where Behavior Driven Design comes in. It's not a methodology for project management. It's not a silver bullet for all your software project woes. It's a method of doing the hardest thing there is to do in any project: communicate. It focuses the attention of everyone on the project on the two single most important things in any project: Behavior, and communication.
You can find out more at: the wiki article and at the website

Wednesday, February 17, 2010

Critical Thinking in the corporate world, by the top brA55es

We get a 22 page document on how to fill out a defect report in Jira. This would not be so bad if it was 22 pages of how to describe and detail defects in a coherent way. It was instead 22 pages of work-flow, which is entirely driven by Jira anyway, and therefore does not need documentation.
Instead it was describing the use of 3 fields in order to allow management to do apples-to-apples comparisons of bugs. Only an MBA (Massively Bad Advice) could come up with something so incredibly asinine. Bugs, like real estate are unique. A bug in one application is not the same as a bug in another application.
What they mean is that they want a way to determine which bugs they want to get rid of, and which ones they want to keep. This means that by definition defective software is acceptable. Which means that at my employer, quality is not a primary concern.
Yes folks, MBA's think defective software is acceptable to deliver to the customer.
Is there any wonder why I call being made a manager, a demotion.......