[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
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