Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
We have standard issue tracking system (home grown for internal use only) and plan to add planing capabilities as all task have all necessary data to make estimation.
So each task have:
more or less accurate estimated time
accurate spent time
more or less accurate percentage completeness
accurate beginning/schedule date
task owner
Also we have scheduled version which is a group of tasks.
We don't know how to ask to question:
how many hours we must spend to release end
according to tasks time data and version schedule date?
or:
do we finish version to specified schedule?
PS Seems that percentage completeness is less accurate and we decide to drop it...
Estimation is trickier than it looks. For example, when people are asked to give time estimates, they generally systematically underestimate (it's called "optimism bias").
My best suggestion is that you should get a book on the topic and read it. McConnell's Software Estimation: Demystifying the Black Art is a good place to start.
Related
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
Scrum is one methodology in agile software development right? What are the main activities in Scrum?
I hope this will help.
Nains...
Scrum is indeed an agile software development methodology.
It's more then a set of activities - there are a set of core assumptions and ideas that underlie the activities. Nains' answer contains a cheat sheet explaining very briefly the important concepts.
To answer your question in the most basic sense.
Gather user stories
Determine priority within these stories, chop them up in small, manageable tasks.
Code-code-code
Every day: short meeting where team members explain their progress, what they're working on, and where they get stuck on.
Every two weeks (or week, or month... depends on your project): deliver a working copy of what you have.
Return to step 1.
One such loop is called a Sprint. The essential step is that you begin by revisiting your assumptions what the software needs to do - the user stories, and their priorities.
Also note that this is a short cycle, within a very short period of time, the users get feedback.
Note that there is a lot more to be said about Scrum - if you want more details, I recommend a good book, or at the very least reading the Wikipedia article.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In our projects we are often asked to give ball park estimates for activities. My question does it really help in taking decisions based on the estimate.
Yes as pointed out above.
No if the client later says "Oh, but that's much more than the X days you initially estimated"
You need to be careful in explaining and agreeing on what "ballpark" really means
Yes .. it can help to give rough estimates to the client but later on these estimates can show upto +/- 50% variation.
But it can help to gauge the size of the project and roughly manday efforts
Something to add to the existing responses.
Pros:
Helpful for a teamleader to assess
the number of resources needed for a
set of activities.
Useful to assess
whether a task would fit in a pre
defined timeline
Cons:
Very rough estimate
Need to be very careful while sharing with the customer.
I often use these ballpark estimates to give a quick price quote to a client, when based on models such as WMFP or COCOMO-II they can also help me make an unbiased assessment.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
In your experience, what phase of software development takes the most time? That is besides maintenance, of course. And which phase takes the second most time? Which methodology do you use?
The final 20% always takes the longest - roughly 80% of the total time of the project.
I don't think there is any methodology that will change this. As a project begins to take its final form and is demoed its always easier for clients to think of new ideas and improvements. I think the best way to handle it is to keep open communication with the client, be open to change suggestions, but make sure they are aware that their changes will increase the development cost.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
Someone within my organization has started pushing for us to pilot the CMU SEI's TSP process (see website here). I have an instinctual aversion to any attempts to cure software development illnesses with alphabet soup, but I would like to know if anyone has experience with this process and can provide tangible facts.
I used to be a fan of SEI's CMM. I even read Watts Humphrey's "Managing the Software Process" book cover to cover. I haven't used TSP but I suspect it has similar strenghts and weaknesses as the other software processes.
Definitely read about it and what they claim it can do and how to implement it, but be vigilant about keeping your software process small and flexible. You need one, but be careful about taking processes from someone else.
good luck.
We've been using this process for a few months now and I'm not particularly impressed. This process is only suitable for a strict command and control style of management where programmers are essentially bean counters. Most of the good parts of this process (size estimates rather than time estimates, self reviews, detailed plans, logging time against plans, and keeping a log of defects and errors for later review) can be implemented without throwing a bunch of money at SEI.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
As a project manager, you are required to organize time so that the project meets a deadline.
Is there some sort of equations to use for estimating how long the development will take?
let's say the database
time = sql storedprocedures * tables manipulated or something similar
Or are you just stuck having to get the experience to get adequate estimations?
As project manager you have to remember that the best you will ever we be able to do on your own is give your best guess as to how long a given project will take. How accurate you are. depends on your experience and the scope of the project.
The only way I know of to get a reasonably accurate estimate that is it to break the project into individual tasks and get the developer who will be doing the actual work to put an estimate on each task. You can then use an evidence based algorithm that takes the estimation accuracy of each developer into account to give you the probability of hitting a given deadline.
If the probability is too low, you have two choices: remove features or move the deadline.
Further reading:
http://www.joelonsoftware.com/items/2007/10/26.html
http://www.wordyard.com/2007/10/11/evidence-based-scheduling/
http://en.wikipedia.org/wiki/Monte_Carlo_method
There's no set formula out there that I've seen that would really work. Fogbugz has its monte carlo simulator which has somewhat of a concept for this, but really, experience is going to be your best point of reference. Every developer and every project will be different!
There will be such a formula as soon as computers can start generating all code themselves. Until then you are stuck with human developers who all have different levels of skill and development speed.