Discussion on:
View:
Show:
Fast tracking is OK. Extreme programming is the last resource. I agree that paralel activities are sometimes a way to go. And if posible mesure things graphically to detect adverse tendencies. Examples are in "Practical Sw and Systems Measures - PSM". Take a look at their site.
Every time the almighty schedule is valued above quality, quality suffers. This is reason Number One why most software sucks. All other reasons place a very distant second.
Fast Tracking:
The reason things are done in sequence is that one activity feeds the next. You just can't pretend that this doesn't happen. Wishful thinking is always expensive. If any activities can be done in parallel, they should have been scheduled that way in the first place.
Crashing:
Here's a term used to describe a software system in the process of failure. When that process is complete, we say that the system has "crashed". It seems fitting that this same term is now being used to add inappropriate resources to "speed up" a project. Someone should be (re-)reading Brook's "The Mythical Man-Month". Nine women cannot make a baby in a month. And girls cannot make a baby at all! Will they never learn?
In short, software takes a certain amount of time to build successfully. Any attempt to use arbitrary means to speed up the process WILL make it take longer and therefore, cost more. Just the opposite of what is desired. Software will NEVER achieve the reliability and security we all seek as long as the suits and bean counters are making what amounts to engineering decisions. They just aren't qualified.
Fast Tracking:
The reason things are done in sequence is that one activity feeds the next. You just can't pretend that this doesn't happen. Wishful thinking is always expensive. If any activities can be done in parallel, they should have been scheduled that way in the first place.
Crashing:
Here's a term used to describe a software system in the process of failure. When that process is complete, we say that the system has "crashed". It seems fitting that this same term is now being used to add inappropriate resources to "speed up" a project. Someone should be (re-)reading Brook's "The Mythical Man-Month". Nine women cannot make a baby in a month. And girls cannot make a baby at all! Will they never learn?
In short, software takes a certain amount of time to build successfully. Any attempt to use arbitrary means to speed up the process WILL make it take longer and therefore, cost more. Just the opposite of what is desired. Software will NEVER achieve the reliability and security we all seek as long as the suits and bean counters are making what amounts to engineering decisions. They just aren't qualified.
In this case, if you are talking about a sizable project and it is seriously slipped and you must catch up to a deadline, then you should concentrate on being luckier.
Somethings in big projects are done just for the safety of the project at the cost of taking more time. As it turns out, the whole project is at risk so now you should dump anything that is taking time away from development - testing, documentation, regular meetings and reporting. Those sorts of things are related to quality and reporting - replace that with hope. Swing for the fences!
Somethings in big projects are done just for the safety of the project at the cost of taking more time. As it turns out, the whole project is at risk so now you should dump anything that is taking time away from development - testing, documentation, regular meetings and reporting. Those sorts of things are related to quality and reporting - replace that with hope. Swing for the fences!
Back in the 80's I was on a project team whose mandate was to replace all its legacy customer service and billing systems with a packaged solution. Senior management wanted the whole thing done in two years.
We spent almost a month creating an elaborate project plan. The planning tool we used told us that, with current resources, the project would take four years.
IT management then ordered us to rework the plan to fit it into 24 months. We accomplished this by estimating that everyone on the team would work a 60 hour week for two years straight: no vacations, no sick time, no holidays, no family emergencies, no training classes.
And management wonders why deadlines are so rarely met.
We spent almost a month creating an elaborate project plan. The planning tool we used told us that, with current resources, the project would take four years.
IT management then ordered us to rework the plan to fit it into 24 months. We accomplished this by estimating that everyone on the team would work a 60 hour week for two years straight: no vacations, no sick time, no holidays, no family emergencies, no training classes.
And management wonders why deadlines are so rarely met.
This is another can of worms and seems to depend on schools of thought. I've seen managers who advocate that a task is either complete or not when tracking the schedule. No, 50% complete or nearly done.
The explanation was simple and to the point.
Respected sir, what's the condition/criteria for crashing activity duration ? please emphasize on this part of crashing(activity duration) . I found a following formula on internet? [min{normal duration-crash? duration , float limit}]..note: float limit is not equal to float..please help.
And I'm not sure if the author still writes for TR but regardless with something so old I personally would not be expecting any form of answer.
Col
Col
- Keyboard Shortcuts:
- Prev
- Next
- Toggle
