RE: [epf-dev] Inconsistency: Additional Performers

["Brian Lyons" <blyons@xxxxxxxxxxxxx>]

hiho,

 

I like the idea of adding the additional performers.

 

The original strategy (whether right or wrong) had been to include an additional performer only if one of the steps can clearly call out how that person participates.  I like the idea of getting the additional performers on board, but we should adhere to some the strategy of calling out where that performer fits in.

 

I mention the Analyst in Task: Design Solution; I’ll add that role in as an additional performer <… done>.  I also had had a notion that the Developer should consider collaborating with the Tester when Implementing Developer Tests.  Tomorrow I’ll add in some mention of optionally engaging the Tester in the steps and I’ll add the additional performer.

 

In regard to Scott’s specific question on bugs, I would personally rather re-open the bugs with a comment of “add additional performers”, but we could open up new bugs as well.

 

                                   --------- b

---

From: epf-dev-bounces@xxxxxxxxxxx [mailto:epf-dev-bounces@xxxxxxxxxxx] On Behalf Of Per Kroll
Sent: Thursday, September 28, 2006 5:36 PM
To: epf-dev@xxxxxxxxxxx
Subject: [epf-dev] Inconsistency: Additional Performers
Importance: High

 

Hi,

we have a pretty significant difference in usage of Additional Performance.

For the Intent and PM tasks , we have many additional performers to articulate the collaborative nature, which is enabled by having all roles in teh collaboration layer
For the Solutions tasks, we have normally no additional performers. I am fine with that for some tasks like "Run tests", where you do not need to collaborate with tons of people, but I do not like that the architect is more or less doing all architecture work without collaborating with everybody in the team, or the developer do design without working with analyst and tester (architect is already there). I think Design shold be a collaborative task....

What do you others think? I am afraid that current implementation will come across as more traditional than agile....

I think this can be addressed by addressing the 3 arch tasks, + design task..

Cheers

Per Kroll
STSM, Manager Methods: RUP / RMC
Project Lead: Eclipse Process Framework
Rational Software, IBM Corp
408-342-3815