Re: late role assignment, IMO the text we write for tasks shouldn't be
impersonal. We don't want to lose the collaboration aspect that should
be clear in the text.
That's actually going to be a good exercise :-)
One example, consider the step "Define the iteration objectives" from
task "Plan Iteration":
"At the beginning of an iteration, the _Role: Project Manager_ works
with the team to define 1-5 objectives. These objectives should be a
refinement of the iteration objectives found in the Artifact: Project
Plan, and should provide high-level direction to what should be
targeted for the iteration. The objectives should be driven based on
_Role: Stakeholder_ priorities, and will be revised as the iteration
plan is finalized. The objectives are usually defined as high-level
capabilities or scenarios that need to be implemented and tested
during the iteration."
In the first sentence, we could use active voice to say "/At the
beginning of an iteration, work with the team to define 1-5
objectives/ /to be achieved in that iteration/".
In this case I think it is clear that the primary performer has to do
that, no matter what role is assigned to perform this task: project
manager, project lead, project guru, etc.
In the third sentence, we could also use active voice like that:
"/Establish the objectives for an iteration based on priorities
defined by interested parties, such as end users, customer and the
team/".
In general, there may be some generic words we can use to make the
text emphasize collaboration, without "hard coding" the role names in it.
My 2 cents,
Ricardo Balduino
Senior Software Engineer
IBM Rational (www.ibm.com/rational)
EPF Committer (www.eclipse.org/epf)
*Per Kroll/Cupertino/IBM@IBMUS*
Sent by: epf-dev-bounces@xxxxxxxxxxx
01/25/2007 02:08 PM
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
To
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
cc
Subject
RE: [epf-dev] Restructuring OpenUP - Meeting Thu Jan 25, 8-10 AM PST
Hi Brian,
please see comments below
Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
(M) 408-219-2963
*"Brian Lyons" <blyons@xxxxxxxxxxxxx>*
Sent by: epf-dev-bounces@xxxxxxxxxxx
01/25/2007 02:46 PM
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
To
"Eclipse Process Framework Project Developers List"
<epf-dev@xxxxxxxxxxx>
cc
Subject
RE: [epf-dev] Restructuring OpenUP - Meeting Thu Jan 25, 8-10 AM PST
hiho,
On slide 7, I take issue with the intermixing of development process
stuff and the definition and adoption of the process. I think that the
Process items are sort of Environment discipline things that should
not be demarked as blue “OpenUP/Basic Practices”. /
PKR: Good point. These are valuable practices for OpenUP, but should
probably not be listed under OpenUP/Basic./
I am also concerned with replacing our project management with
something explicitly called Scrum. We are adopting Scrum techniques,
but must we say we are unambiguously “doing Scrum”? Scrum has a
Product Backlog and a separate Iteration Backlog; we have one Work
Item List. Are we going to toe-the-line with Scrum terms and work
products? What if we meet and decide that we have a better technique
than the Scrum way of doing things for some aspect of project
management? I appreciate adopting a Scrum perspective in OpenUP
project management, but I am concerned about simply labeling it as
Scrum. /
PKR: I think the point was not that we should provide a Scrum
practice, but rather showcase that if you do not like a practice, you
can replace it with another practice. So, we should clarify and
provide another example that may be less confusing, since we think we
are providing a mgmt approach heavily borrowing from, but improving
upon, Scrum./
On slide 11, I would be careful to use the words “Test Cases” rather
than just “Tests” in the Intent area so they are not confused with
“Test Scripts”. /
PKR: I could be wrong, but I think this include 1) writing test case,
2) writing test script, 3) validate script by running it .
This means that it is more than just the Intent portion of testing. It
is tricky to know where to pace work patterns that cross these areas.../
I’m psyched for Work Patterns. They provide a very good chunk of
methodology to be able to talk about and adopt piecemeal./
PKR: I agree. I actually this this is the most valuable piece of all.
Practices are good when assembling processes, but only few people do
that. Work patterns are a great concept for using a process, which all
team members do. I think that if we think work patterns when we write
a process, we will write better process content./
As discussed on the call, I want to make sure the late addition of
roles to the methodology content is not going to be more effort than
it is worth. I don’t discount that it could add value. But I am
concerned that the repository is too complicated already with three
roles making up the Analyst role for example. Furthermore, we often
have text in the tasks that talks about collaborating with others. The
tool currently can publish the right name when the role is mentioned
in the text, but if we decouple the tasks from any knowledge of roles
the text could get so abstract that we lose clarity (e.g. “Collaborate
with someone who knows how to do detailed requirements on this”,
“ensure that someone who has authority over the scope agrees with
that”). /
PKR: Your concerns are fair. We need to make sure that this works in
practice. I think work patterns will help us to write extremely
concrete process guidance. "No, do not tell me how I do design of a
scenario, tell me how I do design using TDD, when my scenario will
impact the architecture". We need to make sure that late role
assignment does not make the process too vague. I think there is a
solution, but we need to make sure that is the case./
------------ b
------------------------------------------------------------------------
*
From:* epf-dev-bounces@xxxxxxxxxxx
[mailto:epf-dev-bounces@xxxxxxxxxxx] *On Behalf Of *Per Kroll*
Sent:* Wednesday, January 24, 2007 8:06 PM*
To:* Eclipse Process Framework Project Developers List*
Subject:* Fw: [epf-dev] Restructuring OpenUP - Meeting Thu Jan 25,
8-10 AM PST
Hi,
attached you find the slides we will walk through tomorrow. We are
looking forward to a constructive discussion.
Cheers
Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
(M) 408-219-2963
----- Forwarded by Per Kroll/Cupertino/IBM on 01/24/2007 08:03 PM -----
*Per Kroll/Cupertino/IBM@IBMUS*
Sent by: epf-dev-bounces@xxxxxxxxxxx
01/19/2007 10:35 AM
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
To
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
cc
epf-dev@xxxxxxxxxxx, epf-dev-bounces@xxxxxxxxxxx
Subject
Re: [epf-dev] Restructuring OpenUP - Meeting Thu Jan 25, 8-10 AM PST
Hi,
corrected date and specified timezone...
Thu Jan 25, 8-10 AM PST.
Cheers
Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
(M) 408-219-2963
*Per Kroll/Cupertino/IBM@IBMUS*
Sent by: epf-dev-bounces@xxxxxxxxxxx
01/19/2007 12:38 AM
Please respond to
Eclipse Process Framework Project Developers List <epf-dev@xxxxxxxxxxx>
To
epf-dev@xxxxxxxxxxx
cc
Subject
[epf-dev] Restructuring OpenUP - Meeting Thu Jan 24, 8-10 AM
Hi,
We would like to discuss some problems we have identified with the
current structure, and propos some ideas on how they could be
addressed. We hope this presentation will generate a good discussion
and additional innovation. Topics will include:
1) How to achieve a higher degree of reuse of process content between
different processes
2) How to allow more flexibility around role assignments
3) How to allow you to provide a more easily configurable proces
4 ) How to improve usability, and align the presentation of OpenUP
with OpenUP's adaptive mgmt approach and work-item focused approach to
development.
Toll-free dial-in: 1-877-421-0003
Toll dial-in: 1-770-615-1374
<For IBMers> Tie-line dial-in: 421-0003
Participant passcode: 667201
http://tech.groups.yahoo.com/group/eclipseprocessframework/cal///group/eclipseprocessframework?v=4&t=1169712000&i=727&pv=2
Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
(M) 408-219-2963_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
------------------------------------------------------------------------
_______________________________________________
epf-dev mailing list
epf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/epf-dev
