[100efforts] What Productivity Factor is and how should one use it?

This is a post on how to use our requirements management and efforts estimation tool and more precisely it is a discussion on what Productivity Factor is. It gives you a simple method of finding reasonable values to start with, in order to receive results that align with real life from the very beginning.

Productivity factor (PF) serves the purpose of translating Use Case points into man-hours. PF is a ratio of number of man-hours per use case point.

Needless to say that PF will be different for various teams and for various phases of a project. The more experienced and well managed team is the more effortless work is.

There are a number of empiric suggestions for choosing a PF value.

First of all, as suggested by industry experts, PF should be between 15 and 30.

Several studies has established a typical PF value of 20, that is why it is a default value for every release you create in 100effors.com

Use this approach to adjust PF for a specific project or phase of a project:

1. Count the number of environmental factor ratings of E1-E6 that are below 3 and the number of factor ratings of E7-E8 that are above 3.
2. If the total is 2 or less, then use 20 man-hours per UCP.
3. If the total is 3 or 4, use 28 man-hours per UCP.
4. If the total is 5 or more then consider restructuring the project team so that the numbers fall at least below 5. A value of 5 indicates that this project is at significant risk of failure with this team.

And for sure the most reliable method is your past experience. Compare estimated and actual efforts of completed projects/phases (100efforts.com   provides an easy tool for this) and perform adjustments of Productivity Factor for following releases accordingly.

How to set a Productivity Factor in 100efforts.com:

1. Open your project of interest
2. Be sure that you have already created at least one release for the project
3. Go to “Efforts” tab
4. Click on release name under “Use case points estimation” section and you’ll be landed on the “Summary” page
5. Click “Productivity factor (PF)” link to enter your value.

References:

• Estimating Software Via Use Cases 
• Project Estimation with Use Case Points 

Status or state after all?

Which of them do you use and when?

This is what I've decided for myself:

"State" - is a set of attributes that define object's behavior and have a state machine of transitions. 

"Status" - is an attribute that holds a single character value.

Other options, suggested by my colleagues:

• use unthinkingly;
• use only one of them. always;

That's it, good luck!

A business to IT people collaboration tool announcement.

Something tells me that people occasionally landing this page are not so far from software development as my grandma is. 


Thus, I suspect, some of you guys out there might find my new endeavour useful.
We've developed a tool to help collaborate on requirements and usecases, trace them and estimate project efforts. 
A tool I desperately needed at my fulltime job before. 


Starting is simple, either someone adds you as a collaborator of his project and you get an email with a signup link, or you visit our awesome site and signup for our services yourself.

Nothing could have been easier. You will receive a welcome email and can now start working. Anyone can create a project and become its self perpetuating Creator. 

After you've created a project, you are welcome to invite more people to collaborate. When adding people to your project you have to assign them roles. There are three roles except for your exclusive one, namely: Project Owner - usually a business person in charge for requirements; Contributor - any one allowed to contribute to project's items, a Project Manager or Business Analyst; Viewer - a person, whose sole need is to read and observe activities boiling in a project.

So you've created a project and invited your colleagues to collaborate with you. Then you start by creating requirements, functional and nonfunctional. You define a release, you declare it to be mandatory and, say if you know what Kano is, you declare it as a Must have.

You categorize your requirement with tags. Though we provide a powerful set of tools to search through requirements, to sort and filter by literally every attribute, it is always useful to have a short sticker on an item to filter fast.  Filter by releases is in place, of course, for you to laser focus on what's vital for you now.

After you've created a requirement, your colleague takes up and traces it with a number of use cases that define works to be done to achieve required function. He also defines how complex a use case is and who is the actor to participate in it.

And now it comes to the most interesting moment, my favorite - discussion. You've required something no one knows how to accomplish. What can they do? Comment on your requirement or usecase!

Ok, everything is fine. You've managed to figure things out during your long discussion, and now you are ready to estimate how long it will take to develop a project you require.

Wow, it turns out that it is a rather simple task to find an answer.
The last thing to do is specify some details required to tune estimation calculation and you're through with it.

So it goes. 


I want to remind you that we are still in early stage, and there are plenty of things we have to improve. We need your feedback in order to make our service the bestest =).


Good luck!

How do you tell a good code?

Agreed with Ayende:
"... most good code bases are actually fairly boring. That is pretty much the definition of a good codebase..."


Source.


Good luck!

Speed up rails3 rspec2

If you've eventually fell asleep while waiting for your test suits to run, here's a good description on how to speed it up.


PS One little nitpick: all of the spork commands should be executed in bundle exec context as long we use bundler insted of rubygems.


Good luck!