blob: 64a3858091744a8adf5e3209be1057745c93bd27 [file] [log] [blame]
<?xml version="1.0" encoding="UTF-8"?>
<org.eclipse.epf.uma:TaskDescription xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.3/uma.ecore" epf:version="1.0.0" xmi:id="-W67fNE0rT1c2PM-20yXbrw" name="develop_xp_vision,{A8708FFB-BB20-40AF-BEF2-7A8A814FF74D}" guid="-W67fNE0rT1c2PM-20yXbrw" changeDate="2005-12-02T08:56:23.177-0800" version="1.0.0">
<sections xmi:id="_oB58MGE-EdqnIZeW8YpHcA" name="Gain Agreement on the Problem Being Solved " guid="_oB58MGE-EdqnIZeW8YpHcA">
<sectionDescription>&lt;a id=&quot;Gain&quot; name=&quot;Step1&quot;&gt;&lt;/a&gt;
&lt;p&gt;
One of the simplest ways to gain agreement on the definition of the problem is to write it down and see if everyone
agrees.
&lt;/p&gt;
&lt;p&gt;
Ask the group: What is the problem?
&lt;/p&gt;
&lt;p&gt;
It is very common to rush headlong into defining the solution rather than taking time to first understand the problem.
Write down the problem and see if you can get everyone to agree on the definition.
&lt;/p&gt;
&lt;p&gt;
Then ask the group again: What is the problem, really?
&lt;/p&gt;
&lt;p&gt;
Search for root causes or the &quot;problem behind the problem&quot;. The real problem is often hiding behind what is perceived
as a problem. Don't accept the first statement of a problem. Continue to ask &quot;why?&quot; to find out what the problem
&quot;really&quot; is. Sometimes the group can be so focused on an envisioned solution that it is hard to get them to formulate
the underlying problem. In such cases, it can be beneficial to explore the benefits of the solution and then try to
find the problems being solved by those benefits. You can then explore whether or not those problems are &quot;real&quot;
problems in the organization.
&lt;/p&gt;</sectionDescription>
</sections>
<sections xmi:id="_oB58MWE-EdqnIZeW8YpHcA" name="Identify Stakeholders " guid="_oB58MWE-EdqnIZeW8YpHcA">
<sectionDescription>&lt;a id=&quot;Identify&quot; name=&quot;Step2&quot;&gt;&lt;/a&gt;
&lt;ul&gt;
&lt;li&gt;
Who are the users of the system?
&lt;/li&gt;
&lt;li&gt;
Who is the economic buyer for the system?
&lt;/li&gt;
&lt;li&gt;
Who else will be affected by the output that the system produces?
&lt;/li&gt;
&lt;li&gt;
Who will evaluate and bless the system when it is delivered and deployed?
&lt;/li&gt;
&lt;li&gt;
Are there any other internal or external users of the system whose needs must be addressed?
&lt;/li&gt;
&lt;li&gt;
Who will maintain the new system?
&lt;/li&gt;
&lt;li&gt;
Is there anyone else?
&lt;/li&gt;
&lt;li&gt;
Okay, is there anyone else?
&lt;/li&gt;
&lt;/ul&gt;</sectionDescription>
</sections>
<sections xmi:id="_oB58MmE-EdqnIZeW8YpHcA" name="Define the Primary Features of the System " guid="_oB58MmE-EdqnIZeW8YpHcA">
<sectionDescription>&lt;a id=&quot;Define&quot; name=&quot;Step3&quot;&gt;&lt;/a&gt;
&lt;p&gt;
What primary features of the system allow the stakeholders to solve their problems? This should be a list of very
high-level features.&lt;br /&gt;
&lt;/p&gt;</sectionDescription>
</sections>
<sections xmi:id="_oB58M2E-EdqnIZeW8YpHcA" name="Communicate the Vision " guid="_oB58M2E-EdqnIZeW8YpHcA">
<sectionDescription>&lt;a id=&quot;Com&quot; name=&quot;Step4&quot;&gt;&lt;/a&gt;
&lt;p&gt;
Once agreed upon by the stakeholders, the vision is communicated clearly to all project team members. When the project
starts, XP teams often write up the vision on one of the whiteboards in the team's open workspace so it can easily be
seen by all team members. After a short time, the team usually internalizes the vision and no longer needs the
reminder.
&lt;/p&gt;</sectionDescription>
</sections>
<purpose>&lt;a id=&quot;XE_define_vision__activity_definition&quot; name=&quot;XE_define_vision__activity_definition&quot;&gt;&lt;/a&gt;
&lt;ul&gt;
&lt;li&gt;
The Vision defines the stakeholder's view of the product being developed specified in terms of the stakeholder's
key needs and features.
&lt;/li&gt;
&lt;/ul&gt;</purpose>
</org.eclipse.epf.uma:TaskDescription>