On Tue, March 13, 2007 5:44 am, [EMAIL PROTECTED] said: > Thanks Scott. > > Having spent some more time looking deeper into the content, it looks to > me > like OpenUP/Basic handles prioritization of requirements in a number of > places. I thought I'd share what I have found. Please chip in if I have > misunderstood the approach. > > In the Requirements task Define Vision, we "Define features of the system" > which includes "Work with stakeholders to capture a list of features that > stakeholders want in the system, briefly describing them and giving > attributes to help define their general status and priority in the project > ." > > In the Task: Plan Project (perhaps not as big surprise...). The PM "works > with the team" to map the work items list to time, introducing the phase > milestones and deciding on how many iterations are required. We outline > the > features targeted for each iteration "putting the top priority work items > first." This is all done with a view to refining on each iteration rather > than being set in stone predictive planning, naturally.
I'm a bit worried about this wording. We need to make it explicit that stakeholders are responsible for prioritizing the requirements. > > In the PM task Plan Iteration, "The Role: Project Manager works with the > rest of the team, and especially the project stakeholders, to identify the > high-priority work items from the Artifact: Work Items List to be > addressed > within the iteration." Sounds like the PM is responsible for prioritization in this wording. I'm not convinced that's the message we should be sending. > > That seems to define the general approach to prioritization as it stands, > as far as I can see. At a project level, this seems to be feature-driven, > with the stakeholder defining the relative priority of the features. That's definitely what we want, but we need to ensure that it says exactly that. > > At an iteration level, "the team" (which should include the Stakeholder) > decide the items from the work items list that need to be implemented, > working against the overall plan, phase objectives and the prioritized > feature set defined in the vision. (As an aside - there might be some > questions arising from this about the relationship between a "feature" and > an item on the work items list such as a scenario. Maybe those discussions > have already happened?) The definition of work item should address this issue, IMHO. I don't have easy access to EPF right now so can't verify. > > We are in the process of writing an architecture step called "Identify > architecturally significant requirements." This will effectively define a > subset of the requirements that need to be delivered in order to achieve > the Elaboration Phase milestone. The architectural priority of > requirements > should be a factored into the team discussion within "Plan Project" and > "Plan Iteration" in determining the overall priority on the Work Items > List. The implication being that the longer it takes to deliver this > subset, then the longer it takes to get out of Elaboration and into > Construction. Definitely. A discussion of the relationship between business prioritization and architecturally-significant prioritization should be included somewhere. I've found that there is very often a direct co-relation between architecturally-significant and high-business value, and that the reworking of the work item list shouldn't be significant in most situations. > > Introducing this step should provide a means to balance the prioritization > of requirements to meet Stakeholder needs and achieving architectural > stability. From a purely architectural perspective, it also seems more > explicitly collaborative than the stark "architect prioritizes the use > cases" approach in RUP, which was often misunderstood to mean "Architect > is > Planning King" (IMHO). Hard to argue with that. - Scott Practice Leader Agile Development, IBM Rational http://www-306.ibm.com/software/rational/bios/ambler.html Refactoring Databases ( http://www.ambysoft.com/books/refactoringDatabases.html ) is now available. _______________________________________________ epf-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/epf-dev
