Eclipse Community Forums: EPF » Initiate Project

Help

Home

Home » Archived » EPF » Initiate Project

Show: Today's Messages :: Show Polls :: Message Navigator

Initiate Project [message #36279]

Wed, 01 August 2007 12:31

Roman Smirak

Messages: 136
Registered: July 2009

Senior Member

Hi,

the Initiate project activity says that we prepare Vision and then plan
the project based on understanding of stakeholder's needs and features of a
system which should address the needs; the Project plan contains milestone
per every phase and iteration. Does it mean we define the iteration
objectives based on features and refine it later in terms of use
cases/scenarios? (I see this scenario or transactional way of thinking or
objectives as a prerequisite for proper iteration which should produce
something demo-able or shippable, i.e. complete scenario from a user
perspective). If so, can this be explicitly stated in Plan Iteration task? I
guess this is quite important to mention since it touches the core of the
principle..

Next issue: RUP says at several places that Inception phase should remain
short and simple in order to avoid analysis paralysis, big requirements
up-front or still-enough-time syndrome (and many others - e.g. you don't
focus on right risk mitigation) - e.g. RUP (RUP Lifecycle page) says
Inception usually takes 10 % of the schedule, or it uses term "short
Inception" several times. I didn't find any warning or practical limit in
OpenUP - is there any other mechanism avoiding all the anti-patterns
mentioned above?

Substantiation: I see "Big Inception phase" anti-pattern in projects
migrating to RUP from traditional model since they don't want to provide any
estimates until they analyse entire domain (- which often leads to analysis
paralysis, etc.); moreover, as they remain in Inception, they don't plan
proper iteration as they do in Elaboration - i.e. risk driven, including
early integration and testing, the developers continue in fragmented and
separated work (often just reading or learning which is quite inefficient in
many cases) - and so I'm forcing them to move to Elaboration as soon as
possible, however, some tool or rule making this more visible or explicit
would be great. What do you make about that? Do you have similar experience?

Thanks,

Roman

Report message to a moderator

Re: Initiate Project [message #37505 is a reply to message #36279]

Sun, 12 August 2007 18:40

Per Kroll

Messages: 60
Registered: July 2009

Member

Roman,

good questions, and I would love to here other people's view on this.

1) Plan a Project
I personally like to do a draft UC model early on, and have both that and
the vision (including features listed in Vision) to reflect what goes into
the project plan. Now, this does not come out clearly in the current
description of Task: Plan Project. I think it warrants a discussion on
whether having the Work Items List as input is enough, since you can create
work items to reflect the different UCs to be considered for implementation.
Having only Work Items List allows a better decoupling between the 'way you
document requirements" from 'the way you plan", but you loose some
clarity... What does other say about this, and is the above capturing of
trade-offs fair?
My suggestion is to add some somment on that we also look at high-level
requirements and their priorizitization, as captured in the WIL, to improve
clarity, while creating close coupling to tthe way you capture requirements.

2) Plan Iteration
There is a clear assumption here that Use Cases and Scenarios have been
captured and that their implementation is prioritized through the Work Items
List. The way we have describe Plan Iteration makes it independent on
whether you choose to use UCs or User Stories...

In both 1) and 2) I would prefer to keep the textual description free from
the means used to capture requirements to create a more extensible and
customizable process. I am more open to having structural links to Use Case
Model and other Requirements type since the EPF Composer resolves those
based on your plug-in / content package selection, but it can not rewrite
textual descriptions automatically....

Maybe the solution is to more clearly capture that UCs / Scenarios (or
subsets of them) are mapped to Work Items that are then prioritize in
various planning tasks... 3rd paragraph in Guideline: Managing Work Items
does however say
"A Work Item may represent work associated with a defect, enhancement
request, change request, use case, scenario, user story, supporting
requirement, stakeholder request, or anything else that captures a potential
requirement or improvement to your system. A Work Item may reference any
type of requirement or other useful information that guides you in what
needs to be done." Also, the Artifact: Work items List is clear on this.
Anythign we can do to improve that part of the story?

3) Emphasis on Iteration
We had hoped that the opening graphic would help avoiding the
analysis-paralysis you describe. Each iteration produces a demoable or
potentially shippable product increment.
I think you make a good point, and I suggest that we add a sentence in "Key
Considerations" for Concept: Inception Phase that states that you should by
default have one (potentially short) iteration in Inception to avoid
analysis-paralysis, and then go into that there could be reasons for
exceptions... The risk with the current writeup is that too many will look
at the reasons for more than one iteration and say "that applies to me'. If
nobody believes differently, I can add a bug for that.

Cheers

/Per

"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
news:f8pufi$vrs$1@build.eclipse.org...
> Hi,
>
> the Initiate project activity says that we prepare Vision and then plan
> the project based on understanding of stakeholder's needs and features of
> a system which should address the needs; the Project plan contains
> milestone per every phase and iteration. Does it mean we define the
> iteration objectives based on features and refine it later in terms of use
> cases/scenarios? (I see this scenario or transactional way of thinking or
> objectives as a prerequisite for proper iteration which should produce
> something demo-able or shippable, i.e. complete scenario from a user
> perspective). If so, can this be explicitly stated in Plan Iteration task?
> I guess this is quite important to mention since it touches the core of
> the principle..
>
> Next issue: RUP says at several places that Inception phase should remain
> short and simple in order to avoid analysis paralysis, big requirements
> up-front or still-enough-time syndrome (and many others - e.g. you don't
> focus on right risk mitigation) - e.g. RUP (RUP Lifecycle page) says
> Inception usually takes 10 % of the schedule, or it uses term "short
> Inception" several times. I didn't find any warning or practical limit in
> OpenUP - is there any other mechanism avoiding all the anti-patterns
> mentioned above?
>
> Substantiation: I see "Big Inception phase" anti-pattern in projects
> migrating to RUP from traditional model since they don't want to provide
> any estimates until they analyse entire domain (- which often leads to
> analysis paralysis, etc.); moreover, as they remain in Inception, they
> don't plan proper iteration as they do in Elaboration - i.e. risk driven,
> including early integration and testing, the developers continue in
> fragmented and separated work (often just reading or learning which is
> quite inefficient in many cases) - and so I'm forcing them to move to
> Elaboration as soon as possible, however, some tool or rule making this
> more visible or explicit would be great. What do you make about that? Do
> you have similar experience?
>
> Thanks,
>
> Roman
>

Report message to a moderator

Re: Initiate Project [message #38008 is a reply to message #37505]

Tue, 14 August 2007 15:02

Roman Smirak

Messages: 136
Registered: July 2009

Senior Member

Hi Per,

thanks for reply; my comments:

Ad 1)
I also do draft of UC model (focus on high value & risky UCs to be processed
first) and I know I shouldn't settle down there for long time and I can
intuitively mentor others to effectively avoid the traps we are discussing
here, however, once we use the intuition there might be (at least I have)
communication problems and some may (and do:) interpose: "Well, that
is what we mean 'identify use cases' or 'mitigate risk about
understanding...' - we feel we don't understand *enough* of the problem to
proceed..." and vice versa. The
appropriate level (of a risk, understanding, etc.) is not clear.

Of course we cannot define precisely what to do when (that is not my point
here); however, it would be very helpful to get early warning like: 'Hey
dude, this is too much...' or (the best way) even to avoid the misuse.

E.g. Several times I have succeeded to solve this issue by shifting people's
perspective from a completeness, progress or existence of an artefact (e.g.
vision, risk list, use case model - simply because they are just a tool on
our road like a car, however, they are not a target - the proper level of it
strongly depends on the context and our target - which is not clear) to the
time or value perspective; e.g.: 1/ Have a time frame (road-map for the
product + internal milestones, i.e. phases + iterations as the
risk-mitigation tool) following experience (a pattern): major release: ~ 6
months, minor: ~3 months, etc. 2/ According to this, the Inception should
not take more than 3 weeks - if you cannot optimise your work in a way you
can meet the deadline (of the Inception, Project) then you should consider
to make the initial vision simpler and smaller (i.e. feasible); I mean
reasonable time-frame helping people to follow "early & on-time" principle
from the very beginning along with every next step.

This could make sort of early alarm for traps like big-reqs up-front or "too
hungry eyes" at the very beginning, to build it in the process and ensure
people cannot get lost.

Does it make sense?

Ad 2/
Did I understand correctly that "structural links" means a Task description
uses terms like Requirement or "Story" and the Guidance section at the
bottom includes a link to How to model requirements using Use cases if one
selects Use case modelling package to be included in a configuration?

This sounds very good to me.

Ad 3/
Great! Thanks.

Regards,

Roman

"Per Kroll" <pkroll@us.ibm.com> wrote in message
news:f9nk7j$dcq$1@build.eclipse.org...
> Roman,
>
> good questions, and I would love to here other people's view on this.
>
> 1) Plan a Project
> I personally like to do a draft UC model early on, and have both that and
> the vision (including features listed in Vision) to reflect what goes into
> the project plan. Now, this does not come out clearly in the current
> description of Task: Plan Project. I think it warrants a discussion on
> whether having the Work Items List as input is enough, since you can
> create work items to reflect the different UCs to be considered for
> implementation. Having only Work Items List allows a better decoupling
> between the 'way you document requirements" from 'the way you plan", but
> you loose some clarity... What does other say about this, and is the above
> capturing of trade-offs fair?
> My suggestion is to add some somment on that we also look at high-level
> requirements and their priorizitization, as captured in the WIL, to
> improve clarity, while creating close coupling to tthe way you capture
> requirements.
>
> 2) Plan Iteration
> There is a clear assumption here that Use Cases and Scenarios have been
> captured and that their implementation is prioritized through the Work
> Items List. The way we have describe Plan Iteration makes it independent
> on whether you choose to use UCs or User Stories...
>
> In both 1) and 2) I would prefer to keep the textual description free from
> the means used to capture requirements to create a more extensible and
> customizable process. I am more open to having structural links to Use
> Case Model and other Requirements type since the EPF Composer resolves
> those based on your plug-in / content package selection, but it can not
> rewrite textual descriptions automatically....
>
> Maybe the solution is to more clearly capture that UCs / Scenarios (or
> subsets of them) are mapped to Work Items that are then prioritize in
> various planning tasks... 3rd paragraph in Guideline: Managing Work Items
> does however say
> "A Work Item may represent work associated with a defect, enhancement
> request, change request, use case, scenario, user story, supporting
> requirement, stakeholder request, or anything else that captures a
> potential requirement or improvement to your system. A Work Item may
> reference any type of requirement or other useful information that guides
> you in what needs to be done." Also, the Artifact: Work items List is
> clear on this. Anythign we can do to improve that part of the story?
>
> 3) Emphasis on Iteration
> We had hoped that the opening graphic would help avoiding the
> analysis-paralysis you describe. Each iteration produces a demoable or
> potentially shippable product increment.
> I think you make a good point, and I suggest that we add a sentence in
> "Key Considerations" for Concept: Inception Phase that states that you
> should by default have one (potentially short) iteration in Inception to
> avoid analysis-paralysis, and then go into that there could be reasons for
> exceptions... The risk with the current writeup is that too many will look
> at the reasons for more than one iteration and say "that applies to me'.
> If nobody believes differently, I can add a bug for that.
>
> Cheers
>
> /Per
>
> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
> news:f8pufi$vrs$1@build.eclipse.org...
>> Hi,
>>
>> the Initiate project activity says that we prepare Vision and then
>> plan the project based on understanding of stakeholder's needs and
>> features of a system which should address the needs; the Project plan
>> contains milestone per every phase and iteration. Does it mean we define
>> the iteration objectives based on features and refine it later in terms
>> of use cases/scenarios? (I see this scenario or transactional way of
>> thinking or objectives as a prerequisite for proper iteration which
>> should produce something demo-able or shippable, i.e. complete scenario
>> from a user perspective). If so, can this be explicitly stated in Plan
>> Iteration task? I guess this is quite important to mention since it
>> touches the core of the principle..
>>
>> Next issue: RUP says at several places that Inception phase should remain
>> short and simple in order to avoid analysis paralysis, big requirements
>> up-front or still-enough-time syndrome (and many others - e.g. you don't
>> focus on right risk mitigation) - e.g. RUP (RUP Lifecycle page) says
>> Inception usually takes 10 % of the schedule, or it uses term "short
>> Inception" several times. I didn't find any warning or practical limit in
>> OpenUP - is there any other mechanism avoiding all the anti-patterns
>> mentioned above?
>>
>> Substantiation: I see "Big Inception phase" anti-pattern in projects
>> migrating to RUP from traditional model since they don't want to provide
>> any estimates until they analyse entire domain (- which often leads to
>> analysis paralysis, etc.); moreover, as they remain in Inception, they
>> don't plan proper iteration as they do in Elaboration - i.e. risk driven,
>> including early integration and testing, the developers continue in
>> fragmented and separated work (often just reading or learning which is
>> quite inefficient in many cases) - and so I'm forcing them to move to
>> Elaboration as soon as possible, however, some tool or rule making this
>> more visible or explicit would be great. What do you make about that? Do
>> you have similar experience?
>>
>> Thanks,
>>
>> Roman
>>
>
>

Report message to a moderator

Re: Initiate Project [message #38350 is a reply to message #38008]

Wed, 22 August 2007 16:12

Per Kroll

Messages: 60
Registered: July 2009

Member

Hi Roman,

on 1)
Yes, this makes sense. Not sure how to best add that type of guidance.
Solution per 3) will help, but is that enough? Any concrete proposals on
where to add what text to clarify?

2) Yes, you are correct. All of the generated links to Concepts, Guidelines,
Tool mentors, Input and Output work productsm etc are all generated, based
on what packages you select....

3) I added bug.
https://bugs.eclipse.org/bugs/show_bug.cgi?id=200845

Cheers

"Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
news:f9sh7s$hmb$1@build.eclipse.org...
> Hi Per,
>
> thanks for reply; my comments:
>
> Ad 1)
> I also do draft of UC model (focus on high value & risky UCs to be
> processed
> first) and I know I shouldn't settle down there for long time and I can
> intuitively mentor others to effectively avoid the traps we are discussing
> here, however, once we use the intuition there might be (at least I have)
> communication problems and some may (and do:) interpose: "Well, that
> is what we mean 'identify use cases' or 'mitigate risk about
> understanding...' - we feel we don't understand *enough* of the problem to
> proceed..." and vice versa. The
> appropriate level (of a risk, understanding, etc.) is not clear.
>
> Of course we cannot define precisely what to do when (that is not my point
> here); however, it would be very helpful to get early warning like: 'Hey
> dude, this is too much...' or (the best way) even to avoid the misuse.
>
> E.g. Several times I have succeeded to solve this issue by shifting
> people's perspective from a completeness, progress or existence of an
> artefact (e.g. vision, risk list, use case model - simply because they are
> just a tool on our road like a car, however, they are not a target - the
> proper level of it strongly depends on the context and our target - which
> is not clear) to the time or value perspective; e.g.: 1/ Have a time frame
> (road-map for the product + internal milestones, i.e. phases + iterations
> as the risk-mitigation tool) following experience (a pattern): major
> release: ~ 6 months, minor: ~3 months, etc. 2/ According to this, the
> Inception should not take more than 3 weeks - if you cannot optimise your
> work in a way you can meet the deadline (of the Inception, Project) then
> you should consider to make the initial vision simpler and smaller (i.e.
> feasible); I mean reasonable time-frame helping people to follow "early &
> on-time" principle from the very beginning along with every next step.
>
> This could make sort of early alarm for traps like big-reqs up-front or
> "too hungry eyes" at the very beginning, to build it in the process and
> ensure people cannot get lost.
>
> Does it make sense?
>
>
> Ad 2/
> Did I understand correctly that "structural links" means a Task
> description uses terms like Requirement or "Story" and the Guidance
> section at the bottom includes a link to How to model requirements using
> Use cases if one selects Use case modelling package to be included in a
> configuration?
>
> This sounds very good to me.
>
>
> Ad 3/
> Great! Thanks.
>
>
> Regards,
>
> Roman
>
> "Per Kroll" <pkroll@us.ibm.com> wrote in message
> news:f9nk7j$dcq$1@build.eclipse.org...
>> Roman,
>>
>> good questions, and I would love to here other people's view on this.
>>
>> 1) Plan a Project
>> I personally like to do a draft UC model early on, and have both that and
>> the vision (including features listed in Vision) to reflect what goes
>> into
>> the project plan. Now, this does not come out clearly in the current
>> description of Task: Plan Project. I think it warrants a discussion on
>> whether having the Work Items List as input is enough, since you can
>> create work items to reflect the different UCs to be considered for
>> implementation. Having only Work Items List allows a better decoupling
>> between the 'way you document requirements" from 'the way you plan", but
>> you loose some clarity... What does other say about this, and is the
>> above
>> capturing of trade-offs fair?
>> My suggestion is to add some somment on that we also look at high-level
>> requirements and their priorizitization, as captured in the WIL, to
>> improve clarity, while creating close coupling to tthe way you capture
>> requirements.
>>
>> 2) Plan Iteration
>> There is a clear assumption here that Use Cases and Scenarios have been
>> captured and that their implementation is prioritized through the Work
>> Items List. The way we have describe Plan Iteration makes it independent
>> on whether you choose to use UCs or User Stories...
>>
>> In both 1) and 2) I would prefer to keep the textual description free
>> from
>> the means used to capture requirements to create a more extensible and
>> customizable process. I am more open to having structural links to Use
>> Case Model and other Requirements type since the EPF Composer resolves
>> those based on your plug-in / content package selection, but it can not
>> rewrite textual descriptions automatically....
>>
>> Maybe the solution is to more clearly capture that UCs / Scenarios (or
>> subsets of them) are mapped to Work Items that are then prioritize in
>> various planning tasks... 3rd paragraph in Guideline: Managing Work Items
>> does however say
>> "A Work Item may represent work associated with a defect, enhancement
>> request, change request, use case, scenario, user story, supporting
>> requirement, stakeholder request, or anything else that captures a
>> potential requirement or improvement to your system. A Work Item may
>> reference any type of requirement or other useful information that guides
>> you in what needs to be done." Also, the Artifact: Work items List is
>> clear on this. Anythign we can do to improve that part of the story?
>>
>> 3) Emphasis on Iteration
>> We had hoped that the opening graphic would help avoiding the
>> analysis-paralysis you describe. Each iteration produces a demoable or
>> potentially shippable product increment.
>> I think you make a good point, and I suggest that we add a sentence in
>> "Key Considerations" for Concept: Inception Phase that states that you
>> should by default have one (potentially short) iteration in Inception to
>> avoid analysis-paralysis, and then go into that there could be reasons
>> for
>> exceptions... The risk with the current writeup is that too many will
>> look
>> at the reasons for more than one iteration and say "that applies to me'.
>> If nobody believes differently, I can add a bug for that.
>>
>> Cheers
>>
>> /Per
>>
>> "Roman Smirak" <roman.smirak@tietoenator.com> wrote in message
>> news:f8pufi$vrs$1@build.eclipse.org...
>>> Hi,
>>>
>>> the Initiate project activity says that we prepare Vision and then
>>> plan the project based on understanding of stakeholder's needs and
>>> features of a system which should address the needs; the Project plan
>>> contains milestone per every phase and iteration. Does it mean we define
>>> the iteration objectives based on features and refine it later in terms
>>> of use cases/scenarios? (I see this scenario or transactional way of
>>> thinking or objectives as a prerequisite for proper iteration which
>>> should produce something demo-able or shippable, i.e. complete scenario
>>> from a user perspective). If so, can this be explicitly stated in Plan
>>> Iteration task? I guess this is quite important to mention since it
>>> touches the core of the principle..
>>>
>>> Next issue: RUP says at several places that Inception phase should
>>> remain
>>> short and simple in order to avoid analysis paralysis, big requirements
>>> up-front or still-enough-time syndrome (and many others - e.g. you don't
>>> focus on right risk mitigation) - e.g. RUP (RUP Lifecycle page) says
>>> Inception usually takes 10 % of the schedule, or it uses term "short
>>> Inception" several times. I didn't find any warning or practical limit
>>> in
>>> OpenUP - is there any other mechanism avoiding all the anti-patterns
>>> mentioned above?
>>>
>>> Substantiation: I see "Big Inception phase" anti-pattern in projects
>>> migrating to RUP from traditional model since they don't want to provide
>>> any estimates until they analyse entire domain (- which often leads to
>>> analysis paralysis, etc.); moreover, as they remain in Inception, they
>>> don't plan proper iteration as they do in Elaboration - i.e. risk
>>> driven,
>>> including early integration and testing, the developers continue in
>>> fragmented and separated work (often just reading or learning which is
>>> quite inefficient in many cases) - and so I'm forcing them to move to
>>> Elaboration as soon as possible, however, some tool or rule making this
>>> more visible or explicit would be great. What do you make about that? Do
>>> you have similar experience?
>>>
>>> Thanks,
>>>
>>> Roman
>>>
>>
>>
>
>
>

Report message to a moderator