Folks, its time to withhold your Republican Party dues until the is something in writing that states that Donald Trump will be allowed in the rest of the debates. They are considering banning him because he won't promise to run as a third party candidate if he doesn't get the nomination, and because he's to conservative. He also has this tendency to tell the truth, a huge no-no in Washington, D.C. So call you're (Republican) congressman today and tell them: "No debates from Trump, No Money FOREVER!"
|
The softcopy is now available for free, but please come back and tell about your experience with it.
Once your estimate becomes accurate enough that you get past worrying about
large estimation errors on either the high or low side, truly accurate estimates produce additional benefits, Improved status visibility – One of the best ways to track progress is to compare planned progress with actual progress. If the planned progress is realistic (that is, based on accurate estimates) , it’s possible to track progress according to plan. If the planned progress is fantasy, a project typically begins to run without paying much attention to its plan and it soon becomes meaningless to compare actual progress with planned progress. Godd estimates thus provide important support for project tracking, Higher Quality – Accurate estimates help avoid schedule stress related qualiry problems. Almost 40% of all software errors have been avoided by scheduling appropriatly and by less stress on the developers (Glass 1994), When schedule pressure is extreme, about four times as many defects are reported in the released software as are reported for software developed under less exteme pressure (Jones 1994). One reason is that teams implement quick and dirty versions of features that absolutly must be completed in time to release the software. Excessive schedule pressure has also been found to be the most significant cause of extrenely costly error-prone modules (Jones 1997). Projects that aim from the beginning to have the lowest number of defects usually also have the shortest schedules (Jones 2000). Projects that apply pressure to create unrealistic estimates and subsequently shortchange quality are rudely awakened when they discover that they have also shortchanged cost and schedule. Better coordination with nonsoftware functions – Software projects usually need to coordinate with other business functions, including testing, document writing, marketing campaigns, sales staff training, financial planning, software support training, and so on. If the software schedule is not reliable, that can cause related functions to slip, which can cause the entire project schedule to slip. Better software estimates allow for tigher coordination of the whole project, including both software and nonsoftware activities. Better budgeting – Although it is almost to obvious to state, accurate estimates support accurate budgets, An organization that doesn’t support accurate estimates undermines its ability to forecast the costs of its projects. Increased credibility for the devolopment team – One of the great ironies in software development is that after a project team creates an estimate, managers, marketers, and sales staff take the estimate and turn it into an optimistic business target – over the objections of the project team, The developers then overrun the optimistic business, at which point , managers, marketers, and sales staff blame the developers for being poor estimators! A project team that holds its ground and insists on an accurate estimate will improve its credibility within its organization. Early risk information – One of the most common wasted opportunities in software development is the failure to correctly interpret the meaning of an initial mismatch project goals and project estimates. Consider what happens when the business sponser says, "This project needs to be done in 4 months because we have a major trade show coming up.." and the project team says, "Our best estimate is that this project will take 6 months." The most typical interaction is for the business sponsor and the project leadership to negotiate the estimate, and for the project team eventually to be pressured into committing to try to achieve the 4-month schedule. Bzzzzzt! Wrong answer! The detection of a mismatch between the project goal and the project estimate should be interpreted as incredibly useful, incredibly rare, early-in-the-project risk information. The mismatch indicates a sudstantial that the project will fail to meet its business odjective. Detected early, numerous corrective actions are available, and many of them are high leverage. You might redefine the scope of the project, you might increase staff, you might transfer your best staff onto the project, or you might stagger the delivery of different functionality. You might even decide the project is not worth doing after all. But if this mismatch is allowed to persist, the options that will ba available for corrective action will be far fewer and will be much lower leverage. The options will generally consist of "overrun the schedule and budget" or "cut painful amounts of functionality." The Federal Government's health care bill, Obamacare, while a waste of time, and of resources was not properly tested, This was a disgrace. To not properly stress test shows a lack in other areas as well. How many of you feel comfortable about singing on to a site that could have been saved by the use of the TRAM to get it done properly? The cost compared to the failure of the website is a nit and well worth it.
Obamacare does not calculate the amount be charged to United States citizens correctly. Of course this may only be a problem depending on what side of the issue you are on. Its either a defect, if you are a conservative, or a feature, if you are a liberal. While I won’t go into detail of whether or not this is a defect it seems to be rather pointless to approach it as a feature. The original article can be found at
http://www.breitbart.com/Big-Government/2013/09/20/Obamacare-Software-Glitch-Giving-Wrong-Prices For the sake of this article, we will assume the coder is intellectually honest and this is indeed a defect. First it needs to be assigned a severity and priority as follows: as a severity it ranks a a Showstopper, and Exciter for priority. Showstopper: The defect makes the product or a major component entirely unusable. In mission or life-critical systems, failure could be hazardous. This severity level must have at least Recommended priority. Exciter: The defect has significant impact upon the customer and inclusion of this functionality would greatly increase customer satisfaction with the product. As a Showstopper-Exciter defect if has a total of 5 Verification points and 96 Defect points. (If you’d like to know how this if calculated, you can order the T.R.A.M. from elsewhere in this site.) If the project turned on 2.5 VP/day then this piece of functionality will take two days for completion. How to Give an Accurate Answer
Written by Scott G. Ames Thursday, 10 November 2011 Published: December, 2011 in the Agile Journal “How long’s it gonna take?” My response, “Six weeks, plus or minus two days. No more.” In this article, I’ll give a rebuttal to Daryl Kulak’s article, “Let’s Stop the Wishful Thinking.” I will show why his beliefs about software estimating, while understandable, are questionable, at best, because of the advent of the Test Requirements Agile Metric (T.R.A.M.). We Are Such Good Estimators! The previous example uses a real world experience. The head of development at NEC was asking, for the customer, how long it would be until the final release of the software. They wanted it within three weeks. Everyone felt it would be possible to release within that timeframe. I knew a six week estimate would be more realistic. The use of TRAM helped me to justify my statement, not just to the rest of the development staff, but also, to the client. Storypoints This is where Scrum’s “storypoints” would have failed us. Equating storypoints to an amount of time is ludicrous for a development team. As Mr. Kulak says, “It’s ridiculous. The power of the storypoint in estimating user stories is that it is vague. Keep that power.” Since we are trying to eliminate the vagaries, we will eliminate the storypoints. “Oh. No! How will we estimate?” You ask. By using the TRAM’s method of Verification points. Verification points, or VP, are a defined, rather than a fuzzy, metric. Each requirement is given a score based on the type of defect it would cause if it failed, as follows: Catastrophic: The defect could cause disasters like loss of life, mass destruction, economic collapse, etc. This severity level should only be used in mission or life-critical systems and must have at least Exciter priority. Showstopper: The defect makes the product or a major component entirely unusable. In mission or life-critical systems, failure could be hazardous. This severity level must have at least Recommended priority. High: The defect makes the product or a major component difficult to use, and the workaround, if one exists, is difficult or cumbersome. Medium: The defect makes the product or a major component difficult to use, but a simple workaround exists. Low: The defect causes user inconvenience or annoyance, but does not affect any required functionality. These are then modified by the priority level: Mandatory: The defect is highly visible or has critical impact upon the customer; it must be repaired prior to general availability release. Exciter: The defect has significant impact upon the customer and inclusion of this functionality would greatly increase customer satisfaction with the product. Moderate: The defect has moderate impact upon the customer and should be repaired before a general availability release, but it is not necessary unless at least Medium severity. This level is also used for requirements that have not been prioritized. Recommended: The defect has some impact upon the customer and should be repaired before a general availability release, but it is not necessary unless at least High severity. Desired: The defect has a low impact upon the customer and should be repaired before a general availability release, but it is not necessary. As you can see, while defects are still prioritized, some requirements will have the same priority. This is not a problem, rather it is the developer’s choice to determine which defect to fix next or the requirement will be re-scored. The team decides on the requirement’s severity, and the Product Owner on the requirement’s priority. Since the estimation does not handle time in “man-hours,” but rather in “team-weeks,” the estimation has more value because all those little bumps in time are smoothed out. You don’t even need to show an employee’s time off as other members of the team will be able to pick up his tasks. Verification points, being a defined metric, are the same no matter who calculates them. New York, Denver, or New Delhi, a Verification point is a Verification point and means the same thing. This is not true of storypoints. With VP, you’ll be able to determine which of two teams should develop faster by the use of simple velocity. The total Verification points for a project are a good metric for determining the overall size of the development effort. Using a form of iterative development, over time, it can be accurately determined how many Verification points can be cleared during each iteration. Cleared Verification points represent deliverable software. Verification points cleared by the team per day, week, iteration, or sprint is a valuable metric that can be used to: Show how much effort was required per Verification point, determine how rapidly a project can be completed, estimate a project’s duration and cost. At NEC, I implemented the TRAM on the mobility project to aid in determining how much functionality to attempt during each sprint. 14 weeks into the project, the customer asked us to make final delivery of the project within 3 weeks. Management hoped that we could do that for them; however, we had only cleared 280 VP of product during those 14 weeks. That gave us a velocity of 20 VP/week. As there were 120 VP of product still in the backlog, we told them that our best estimate for completion would be 6 weeks. It is worth noting that the TRAM analysis estimate was 100% accurate. We made the final delivery of the project in exactly 6 weeks. One thing that I was asked at NEC was, “What if we made more overtime mandatory to attempt to get the project out in 3 weeks.” We already had mandatory overtime on Saturdays for the prior three weeks, and the effects were not helpful. During the first week, the team worked an additional day and produced an additional day’s worth of product. In the second week, production started to fall. The team only produced 90% of what it had accomplished during a normal work week. The third week, production slipped to 80%. Obviously the team was burning-out. Rather than slip further to 60%, which is where the team was heading, cessation of mandatory overtime was recommended and implemented. Velocity then returned to pre-overtime levels. This saved the company two weeks of development time and associated costs. For a team of 60, this was a significant monetary savings for NEC. This is the power of Verification points. Verification points from the Test Requirements Agile Metric are a very good way to save your company time and money while producing very accurate estimates that will be useful to business people. About the Author Scott G. Ames has 15 years in software quality, is a Certified ScrumMaster, and is the Chief TRAM Engineer at Good-To-Go! Published: February, 2006 in Better Software
Over the years, I have seen many stress testing projects, and one question that I am often asked is how to go about ramping up the amount of stress in a project. Now, please understand, I know that what is really being asked is how to go about ramping up the amount of load, not stress, in a test. Since I, however, am a quality engineer by trade and like specifics, this article will attempt to answer the question, not as it was intended, but rather, as it was asked. If you really want to increase the overall stress on your people and in your testing project, these are some of the best practices to follow. Skip any “unnecessary” steps. Defining goals, requirements, and test specifications takes a long time. These steps not only cause test engineers to create tests that will execute properly with something other than just simple test data but seriously cuts into their functional testing of Bejeweled and load testing of internet web servers. If a test works with any possible type of data, it significantly reduces the amount of stress in a testing project. Not taking the time to do this right increases stress by forcing people to have to do it over, and possibly over again, under deadline pressure. Also, defined goals, requirements, and specifications remove any possibility of scapegoating outsourced resources for any failures that occur in the test project. This is especially important when validation that a system works is more important than actually fixing any problems that might arise. Have a meeting. Better still, have lots of meetings. Require that everyone connected to the project attend, no matter how small his or her role, and without regard to his or her other responsibilities. The meetings should require preparation and follow up tasks that take at least twice as long as the meetings themselves. To increase stress, it is far more important that everyone know everybody else's responsibilities rather than actually accomplishing anything productive. This process creates stress two ways: it increases micromanagement, and it aids in choosing potential scapegoats. Delegate, Delegate, Delegate. You probably think this actually reduces stress, but proper delegation to increase stress is almost an art form. Delegate critical tasks to people who are completely inappropriate for those tasks. For example, make your testing tool consultants, who will have little or no knowledge of your business processes, responsible for collecting the data necessary to execute the tests. Give them no direction as to how to collect the data and no authority to obtain assistance from the subject matter experts who know how to collect and validate the data. Be careful to not go overboard here. Later on, when the project is approaching its deadline, you can re-delegate this task to people who are capable of actually accomplishing it. In this manner, you can increase stress on multiple fronts and still keep the project from failing. If the project does fail, you can always scapegoat any of the people to whom these tasks were originally delegated. In the case above, since it is impossible for the consultants to deliver a successful project, it may even be possible to avoid paying them for their work. This is best accomplished when used in combination with the previous items. Don't bother to validate the test environment. This is really an important step for increasing the stress in a testing project. It's even better to ignore any piddling little details like test tool environmental requirements, such as the operating system, networking protocols, and any other necessary software and system configuration settings. Just make blanket statements like: "All of the machines have exactly identical configurations." "The test system is an exact duplicate of the system we have here." "Everything has been set up as you requested." Later, when these statements are proven inaccurate, the project stress will greatly increase. The third statement above was once combined with "Our people spent the whole weekend working on it." Of course, that was before an automatic system restore early the next morning undid all of the system configuration work that had just been completed. Having to rebuild an environment two or three times while working on a project deadline is a wonderful way to increase stress. You will be amazed by the amount of stress added to a project by not having a properly configured environment and by making people scramble to make inadequate work-arounds in a short amount of time. Better yet, don't bother with a test system at all. Simply use the production system as the test bed, and don't bother to back anything up. Remember, backups are only for people who make mistakes. And finally, Ignore the stupid questions. Just make assumptions. This is a combination of all the above items. What assumptions, made at all levels, keep the project from running smoothly and greatly increase the amount of stress on the project? As complex and detailed as a software testing project is now, there are no stupid questions, only bad assumptions. On second thought, just do it right the first time; otherwise, you may not be around to do it over. Who needs all that extra stress anyway? |
AuthorScott G. Ames is a Certified ScrumMaster with 17 years of Software Quality and Estimation. Archives
March 2015
|