The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by manuel aldana:
I am very cautious about buying microsoft press books...
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
<a href="http://www-306.ibm.com/software/rational/bios/ambler.html" target="_blank" rel="nofollow">Scott W. Ambler</a><br />Practice Leader Agile Development, IBM Rational<br /> <br />Now available: <a href="http://www.ambysoft.com/books/refactoringDatabases.html" target="_blank" rel="nofollow">Refactoring Databases: Evolutionary Database Design</a>
Originally posted by Stan James:
I think the honesty and transparency the agile methods provide in tracking estimates to reality and reality to future plans are a fantastic improvement over other methods I have been subjected to in the last (cough)30 years.
The agile value of people over process drives the need to get the right people. Process proponents argue that a good process will compensate for less capable staff, and therefore getting the right people isn't as critical to the success as getting the right process. Agilists believe that process can provide a common framework within which people can work effectively, but it cannot replace capability and skill.
Originally posted by Peer Reynders:
Of course Steve McConnell is a bit more cautious � he has to avoid the "one-size-fits-all" trap.
He acknowledges that most business executives (8 out of 10) will choose "predictability" over "agility" (i.e. the ability to change the requirements).
As far as I can tell it is notoriously difficult to predict the total project duration for highly agile methods � they usually make up for it by generating the most business value possible within any given time period while minimizing waste. But this is a hard approach to sell in the "can you deliver functionality X by date Y � if you can't we don't even need to start" situation.
Extreme Programming (highly iterative) � Defines requirements for one iteration only (~1 month). Use when requirements are fluid.
RUP (sequential for estimation purposes) � RUP describes it's stages as "iterations", but seeks to define 80% of the requirements before construction begins.
Ever since the initial publication of Kent Beck's Extreme Programming I suspected that a team of competent/motivated individuals was a pivotal ingredient to the success of agile methods (i.e. people that are already competent, productive, good at estimating and keeping their commitments without the shackles of a heavy process).
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
there is also the infamous "but-my-project-is-special" trap.
Originally posted by Ilja Preuss:
A project can only be really predictable if you expect not to learn much during the project.
Originally posted by Ilja Preuss:
Agile projects have a rather good record of hitting delivery dates.
Originally posted by Ilja Preuss:
XP teams have release plans that go several months into the future, up to half a year and more. Iterations, on the other hand, are typically one to two weeks in length, not a month.
Originally posted by Ilja Preuss:
That's interesting - I'm not sure that Grady Booch would agree. (In fact I'd bet that he wouldn't.)
15.4.1 Requirements
With this introduction to the construction phase, we turn next to finding use cases and actors, prototyping the user interfaces, detailing the use cases and structuring the use cases. In the elaboration phase we identified all the use cases and actors; we understood about 80% of the mass but we described in detail something on the order of 20% - from this number we were able to pick a small number (less than 10%) that we needed to implement at that time) because we needed only enough detail to establish the architectural baseline. In the construction phase, of course, we are going all the way to the initial operational system, so we have to carry requirements capture all the way (i.e. identify and detail 100% of them).
Originally posted by Ilja Preuss:
One of the advantages of Agile methods is that with their emphasis on feedback, collaboration and humanity, they actively foster team members becoming competent and motivated.
Originally posted by Peer Reynders:
Every project is special!
If you learn everything during the project then you have no baseline data for making an estimate in the first place. Unless you have done exactly the same project before � in which case you are not learning anything new the second time around.
But did anyone actually estimate how much work will be accomplished in the given time period? Not just one iteration. The entire project, before the project starts.
For any estimate you have to put in some up front work. You need to understand the requirements in enough breadth to estimate the extent of the project; use tracers, spikes or whatever to understand the technical complexities; define the requirements just deeply enough to give you the detail you need to estimate without venturing into premature assumptions.
Ultimately project control is responsible for keeping the project on target but project control also changes the project i.e. the project that was completed is usually different from the one that was originally estimated.
According to McConnell a project manager can only keep the project on target (based on an estimate) if the actual effort is within +/- 30% of the estimate.
Do those release plans commit to specific features and functionality? It's not very agile if they do. Agility was never about slavishly sticking to a plan.
Kent Beck cites "one-to-four week iterations" (Extreme Programming, p.133).
I think he was referring to this:
Jacobson, Ivar, Grady Booch, James Rumbaugh, 1999. The Unified Software Development Process, Reading, MA: Addison Wesley. P.387
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Ilja Preuss:
That's what allows us to make a rough plan from the beginning, but also makes it necessary to adjust the plan regularly.
Originally posted by Ilja Preuss:
Yes, of course. Everything else would be economically unsound.
Originally posted by Ilja Preuss:
Well, yes. Are you somehow suggesting that Agile or XP projects don't do that?
Originally posted by Ilja Preuss:
I'm not familiar with the term "project control", and I'm not sure I understand what you are getting at here.
Typical project control activities include removing non-critical requirements, redefining requirements, replacing less-experienced staff with more experienced staff, etc.
Originally posted by Ilja Preuss:
Wouldn't a project where actual effort is within +/- 30% of the estimate be +/-30$ off target, typically?
Problems arise when the gap between business targets and the schedule and the effort needed to achieve those targets becomes too large. I have found that if the initial target and initial estimate are within about 20% of each other, the project manager will have enough maneuvering room to control the feature set, schedule, team size, and other parameters to meet the project's business goals; other experts concur (Boehm 1981, Stutzke 2005).
Originally posted by Ilja Preuss:
And I know of no methodology that can *guarantee* delivery of a fixed feature set, at a fixed price, to a fixed date.
Over the years, the software industry has focused on time to market, cost, and flexibility. Each of these goals is desirable, but what top executives usually value most is predictability. Businesses need to make commitments to customers, investors, suppliers, the marketplace, and other stakeholders. These commitments are all supported by predictability.
Originally posted by Ilja Preuss:
Anyway, if you google for Booch and XP, you will find statements from him that he thinks Agile/XP and RUP are very much compatible.
Originally posted by Stan James:
Any of that useful?
Originally posted by Peer Reynders:
It was my impression (I have been wrong before and I may be once again) that the economic soundness of agile methods stems from the fact that you will always know due to the rapid feedback whether the project continues to generate business value.
How can you predict how long it will take until you will run out of high value/high priority user stories?
So when you plan a release you are simply committing to releasing the completed user stories.
Unless you lock all the user stories for a particular release you can't make a case for saying that the release was estimated.
Initially a rough estimate was used to make the plan � but after that the plan takes on a life of its own.
I still fail to see how I can estimate the entire project when I don't know all of the user stories at the beginning and which will ones make the cut?
And I�m not saying that to criticize agile methods. It's simply an effective strategy for dealing with the unknown.
--------------------------------------------------------------------------------
Problems arise when the gap between business targets and the schedule and the effort needed to achieve those targets becomes too large. I have found that if the initial target and initial estimate are within about 20% of each other, the project manager will have enough maneuvering room to control the feature set, schedule, team size, and other parameters to meet the project's business goals; other experts concur (Boehm 1981, Stutzke 2005).
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
Over the years, the software industry has focused on time to market, cost, and flexibility. Each of these goals is desirable, but what top executives usually value most is predictability. Businesses need to make commitments to customers, investors, suppliers, the marketplace, and other stakeholders. These commitments are all supported by predictability.
--------------------------------------------------------------------------------
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
RUP is a process framework not a process. However the RUP instantiation discussed in that text is definitely of the BRUF/BDUF kind. It's probably due to that text that RUP and BRUF/BDUF are mistakenly used interchangeably.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Originally posted by Ilja Preuss:
What you can predict is whether you will be able to generate enough value for the customer that he won't be likely to want to cancel it early.
Originally posted by Ilja Preuss:
I don't see why I have to lock the stories to estimate the release. Of course the estimate will likely change when we change the content of the release, but that doesn't invalidate the value of the estimate, does it?
Originally posted by Ilja Preuss:
It's exactly the opposite what happens - the plan is tightly controlled and checked against reality.
Originally posted by Ilja Preuss:
The typical project, in my experience, has a fixed length and fixed costs. You estimate how many of the original stories can be done, and you later change the plan by replacing lower value stories by higher value ones.
Originally posted by Ilja Preuss:
I'm not convinced that it's that black and white. In fact I'd argue that what business people want is a balanced mix of predictability and flexibility.
None of this proves that predictability is the top priority of your business, but it suggests that you shouldn't make assumptions about your business priorities.
Tip #10: Many business value predictable more than development time, cost, or flexibility. Be sure you understand what your business values the most.
Originally posted by Ilja Preuss:
After all, when talking about Agile teams, we are talking about teams that deliver running tested features week for week, and who get massive feedback about their quality of estimation and planning, who know how much they are able to do in an iteration.
Originally posted by Stan James:
With the help of senior management and the project office team we have reinvented the waterfall.
Originally posted by Peer Reynders:
And this still sounds like a requirements phase to me. It may be "requirements-lite" and it may not be BRUF � but it still is a requirements phase.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Booch and Rational have since embraced almost all the agile ideas, maybe because they believe it, maybe because marketing required it.
....
....
I've read and heard Booch say the main thing he doesn't buy is "emergent architecture." Last I heard, he still thought it was worth doing more architecture up front than agile leaders might.
Don Morgan, Founder
www.DeveloperAdvantage.com - FREE Audiobooks for Software Developers
I claim this furniture in the name of The Ottoman Empire! You can keep this tiny ad:
We need your help - Coderanch server fundraiser
https://coderanch.com/wiki/782867/Coderanch-server-fundraiser
|