<?xml version="1.0" encoding="UTF-8"?>
<xmi:XMI xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.6/uma.ecore" xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.1">
  <org.eclipse.epf.uma:ProcessDescription xmi:id="-VruQpYc8KsnwGZtquAzGng" name="Lean,_MRbqYbkkEe2ItPaV9bHRfA" guid="-VruQpYc8KsnwGZtquAzGng"/>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-bF5t3oATYaIJGDEGH4K8YA" name="task_board,_laInWLqcEe2ItPaV9bHRfA" guid="-bF5t3oATYaIJGDEGH4K8YA">
    <refinedDescription>&lt;p>&#xD;
    The task board shows all the work the team is&amp;nbsp;doing during a sprint or daily work. It is updated&amp;nbsp;continuously&#xD;
    throughout the sprint–if someone thinks of a new task they&amp;nbsp;write a new card and puts it on the board. Either&#xD;
    during or before Daily Meeting, estimates are changed (up or down) and cards are moved around the board.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The task board might look like this:&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span class=&quot;articleImage&quot;>&lt;img style=&quot;HEIGHT: 336px; WIDTH: 461px&quot; alt=&quot;&quot; src=&quot;./../../waad/workproducts/./resources/MockedTaskBoard.jpg&quot;&#xD;
    width=&quot;600&quot; height=&quot;447&quot; />&lt;a&#xD; 
    href=&quot;http://www.mountaingoatsoftware.com/system/hidden_asset/file/29/MockedTaskBoard.jpg&quot; >&lt;u>&lt;font&#xD;
    color=&quot;#0000ff&quot;>&amp;nbsp;&lt;/font>&lt;/u>&lt;/a>&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span class=&quot;articleImage&quot;>&lt;br />&#xD;
    &amp;nbsp;&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Each row on the task board is a product backlog item (in this&amp;nbsp; particular example stories). During&#xD;
    the&amp;nbsp;planning meeting the team selects thework items they can complete during the coming sprint or day.&#xD;
    Each&amp;nbsp;work item is turned into multiple backlog&amp;nbsp;items. Each of these is represented by one task card that is&#xD;
    placed on the task board. Each task card starts on the task board in the “To Do” column. The columns are:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Story&lt;/b>–The story description (“As a user I want to…”) shown on that row.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>To Do&lt;/b>–This holds all the cards that are not done or in process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Work In Process&lt;/b>–Any card being worked on goes here. The programmer who chooses to work on it moves it over&#xD;
        when she’s ready to start the task. Often this happens during the Daily Scrum when someone says, “I’m going to work&#xD;
        on the boojum today.”&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>To Verify&lt;/b>–A lot of tasks have corresponding test task cards. So, if there’s a “Code the boojum class” card&#xD;
        there is likely one or more task cards related to testing: “Test the boojum”, “Write FitNesse tests for the&#xD;
        boojum,” “Write FitNesse fixture for the boojum,” etc. Some task cards don’t often get corresponding test cards&#xD;
        (“Fix Bug #321 in Bugzilla”) so those are placed in the “To Verify” column.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Done&lt;/b>–Cards pile up over here when they’re done. They’re removed at the end of the sprint.&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-oWbJqUtbps3-uIqmtm82Xg" name="enterprise_vendor,_laVbrbqcEe2ItPaV9bHRfA" guid="-oWbJqUtbps3-uIqmtm82Xg">
    <refinedDescription>&lt;p>&#xD;
    The resuable assets of enterprise are placed in this vendor for resuse in other project.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-QA_RYlSb036UvYYPQjmn-Q" name="work_item_pool,_lacJV7qcEe2ItPaV9bHRfA" guid="-QA_RYlSb036UvYYPQjmn-Q">
    <refinedDescription>The pool of Requirements, Bugs, Tutorials, Support, Fixed Delivery Date and Intangilble items.</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-FjJqSytdSFHwWf3VgNnXnA" name="vision,_lavET7qcEe2ItPaV9bHRfA" guid="-FjJqSytdSFHwWf3VgNnXnA">
    <keyConsiderations>&lt;p>&#xD;
    It is good practice to keep this artifact brief, so you can release it to stakeholders as soon as possible, and to make&#xD;
    the artifact easy for stakeholders to read and understand. You can accomplish this by including only the most important&#xD;
    features and avoiding details of requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Projects that focus on product development might extend the marketing section and include a more detailed product&#xD;
    position statement that is based on their needs and research.&#xD;
&lt;/p></keyConsiderations>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-23UX9i0suIq5f7W0Zt6Y_Q" name="enterprise_vendor,_pO4rUbqcEe2ItPaV9bHRfA" guid="-23UX9i0suIq5f7W0Zt6Y_Q">
    <refinedDescription>&lt;p>&#xD;
    The resuable assets of enterprise are placed in this vendor for resuse in other project.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-GmhpMjng7n3u9lJM6_ZGCQ" name="work_item_pool,_pO4rY7qcEe2ItPaV9bHRfA" guid="-GmhpMjng7n3u9lJM6_ZGCQ">
    <refinedDescription>The pool of Requirements, Bugs, Tutorials, Support, Fixed Delivery Date and Intangilble items.</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-7JRgDiBnf_gxBHhygepTtw" name="enterprise_vendor,_W-MgPrqyEe2ItPaV9bHRfA" guid="-7JRgDiBnf_gxBHhygepTtw">
    <refinedDescription>&lt;p>&#xD;
    The resuable assets of enterprise are placed in this vendor for resuse in other project.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-aSVer-suWNaE8xCTVkcDLg" name="work_item_pool,_W-MgU7qyEe2ItPaV9bHRfA" guid="-aSVer-suWNaE8xCTVkcDLg">
    <refinedDescription>The pool of Requirements, Bugs, Tutorials, Support, Fixed Delivery Date and Intangilble items.</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-MnTjKCr_g0PcvCPYfs9utw" name="task_board,_kE0_RLqyEe2ItPaV9bHRfA" guid="-MnTjKCr_g0PcvCPYfs9utw">
    <refinedDescription>&lt;p>&#xD;
    The task board shows all the work the team is&amp;nbsp;doing during a sprint or daily work. It is updated&amp;nbsp;continuously&#xD;
    throughout the sprint–if someone thinks of a new task they&amp;nbsp;write a new card and puts it on the board. Either&#xD;
    during or before Daily Meeting, estimates are changed (up or down) and cards are moved around the board.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The task board might look like this:&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span class=&quot;articleImage&quot;>&lt;img style=&quot;HEIGHT: 336px; WIDTH: 461px&quot; alt=&quot;&quot; src=&quot;./../../waad/workproducts/./resources/MockedTaskBoard.jpg&quot;&#xD;
    width=&quot;600&quot; height=&quot;447&quot; />&lt;a&#xD; 
    href=&quot;http://www.mountaingoatsoftware.com/system/hidden_asset/file/29/MockedTaskBoard.jpg&quot; >&lt;u>&lt;font&#xD;
    color=&quot;#0000ff&quot;>&amp;nbsp;&lt;/font>&lt;/u>&lt;/a>&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    &lt;span class=&quot;articleImage&quot;>&lt;br />&#xD;
    &amp;nbsp;&lt;/span>&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Each row on the task board is a product backlog item (in this&amp;nbsp; particular example stories). During&#xD;
    the&amp;nbsp;planning meeting the team selects thework items they can complete during the coming sprint or day.&#xD;
    Each&amp;nbsp;work item is turned into multiple backlog&amp;nbsp;items. Each of these is represented by one task card that is&#xD;
    placed on the task board. Each task card starts on the task board in the “To Do” column. The columns are:&#xD;
&lt;/p>&#xD;
&lt;ul>&#xD;
    &lt;li>&#xD;
        &lt;b>Story&lt;/b>–The story description (“As a user I want to…”) shown on that row.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>To Do&lt;/b>–This holds all the cards that are not done or in process.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Work In Process&lt;/b>–Any card being worked on goes here. The programmer who chooses to work on it moves it over&#xD;
        when she’s ready to start the task. Often this happens during the Daily Scrum when someone says, “I’m going to work&#xD;
        on the boojum today.”&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>To Verify&lt;/b>–A lot of tasks have corresponding test task cards. So, if there’s a “Code the boojum class” card&#xD;
        there is likely one or more task cards related to testing: “Test the boojum”, “Write FitNesse tests for the&#xD;
        boojum,” “Write FitNesse fixture for the boojum,” etc. Some task cards don’t often get corresponding test cards&#xD;
        (“Fix Bug #321 in Bugzilla”) so those are placed in the “To Verify” column.&#xD;
    &lt;/li>&#xD;
    &lt;li>&#xD;
        &lt;b>Done&lt;/b>–Cards pile up over here when they’re done. They’re removed at the end of the sprint.&#xD;
    &lt;/li>&#xD;
&lt;/ul></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-iO0q36zY5uXYxKzj41vJfQ" name="vision,_kE0_TbqyEe2ItPaV9bHRfA" guid="-iO0q36zY5uXYxKzj41vJfQ">
    <keyConsiderations>&lt;p>&#xD;
    It is good practice to keep this artifact brief, so you can release it to stakeholders as soon as possible, and to make&#xD;
    the artifact easy for stakeholders to read and understand. You can accomplish this by including only the most important&#xD;
    features and avoiding details of requirements.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    Projects that focus on product development might extend the marketing section and include a more detailed product&#xD;
    position statement that is based on their needs and research.&#xD;
&lt;/p></keyConsiderations>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-gDfND9xKztQokq3up1-viw" name="non-compete_clause,_kE6e1rqyEe2ItPaV9bHRfA" guid="-gDfND9xKztQokq3up1-viw">
    <refinedDescription>&lt;p>&#xD;
    A&amp;nbsp;non-compete clause (often NCC) is a clause under which one party (usually an employee) agrees not to enter into&#xD;
    or start a similar profession or trade in competition against another party (usually the employer).&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    The use of such clauses is premised on the possibility that upon their termination or resignation, an employee might&#xD;
    begin working for a competitor or start a business, and gain competitive advantage by exploiting confidential&#xD;
    information about their former employer's operations or trade secrets, or sensitive information such as customer/client&#xD;
    lists, business practices, upcoming products, and marketing plans.&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-6r9TmAzTiNuPb8qlob59UQ" name="non-disclosure_agreement,_kE6e2bqyEe2ItPaV9bHRfA" guid="-6r9TmAzTiNuPb8qlob59UQ">
    <refinedDescription>&lt;p>&#xD;
    A non-disclosure agreement (NDA) is a legal contract or part of a contract between at least two parties that outlines&#xD;
    confidential material, knowledge, or information that the parties wish to share with one another for certain purposes,&#xD;
    but wish to restrict access to.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    It is a contract through which the parties agree not to disclose any information covered by the agreement. An NDA&#xD;
    creates a confidential relationship between the parties, typically to protect any type of confidential and proprietary&#xD;
    information or trade secrets&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-km7bj9hSW8De4Y82Cf6ESw" name="engine_design,_pOlJULqcEe2ItPaV9bHRfA" guid="-km7bj9hSW8De4Y82Cf6ESw">
    <refinedDescription>Before start implementation need to design work item and class diagram as minimum design is mandatory.</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-43wi3BMAyU_Mm0PZ10Ws_A" name="engine_implementation,_pOlJUbqcEe2ItPaV9bHRfA" guid="-43wi3BMAyU_Mm0PZ10Ws_A">
    <refinedDescription>Developer programming work items until all test for work item&amp;nbsp;pass</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-XktUveDAw0WcF3OqHW79Dg" name="engine_integration,_pOlJUrqcEe2ItPaV9bHRfA" guid="-XktUveDAw0WcF3OqHW79Dg">
    <refinedDescription>After all test passed programmed code integrated to code base.</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-2qBb295j9c_Cf6FAdqkxOA" name="engine_test,_pOlJU7qcEe2ItPaV9bHRfA" guid="-2qBb295j9c_Cf6FAdqkxOA">
    <refinedDescription>&lt;p>&#xD;
    Befor programming solution must be write test. After programming, it may be need to write a test&#xD;
&lt;/p></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-ath-IPZCfDaWuYbiQxZivg" name="scrum_daily_scrum,_lZ_dYLqcEe2ItPaV9bHRfA" guid="-ath-IPZCfDaWuYbiQxZivg">
    <keyConsiderations>There is an old joke in which a chicken and a pig are talking and the chicken says, &quot;Let's start a restaurant.&quot; The pig&#xD;
replies, &quot;Good idea, but what should we call it?&quot; &quot;How about 'Ham and Eggs'&quot; says the chicken. &quot;No thanks,&quot; says the pig,&#xD;
&quot;I'd be committed, you'd only be involved.&quot; The joke is meant to point out the difference between those who are committed&#xD;
on a project and those who are only involved. &#xD;
&lt;p>&#xD;
    Any impediments that are raised become the Coach's responsibility to resolve as quickly as possible. Typical&#xD;
    impediments are:&lt;br />&#xD;
    &lt;br />&#xD;
    * My ____ broke and I need a new one today.&lt;br />&#xD;
    * I still haven't got the software I ordered a month ago.&lt;br />&#xD;
    * I need help debugging a problem with ______.&lt;br />&#xD;
    * I'm struggling to learn ______ and would like to pair with someone on it.&lt;br />&#xD;
    * I can't get the vendor's tech support group to call me back.&lt;br />&#xD;
    * Our new contractor can't start because no one is here to sign her contract.&lt;br />&#xD;
    * I can't get the ____ group to give me any time and I need to meet with them.&lt;br />&#xD;
    * The department VP has asked me to work on something else &quot;for a day or two.&quot;&#xD;
&lt;/p></keyConsiderations>
    <refinedDescription>&lt;p>&#xD;
    Meetings are typically held in the same location and at the same time each day. Ideally the daily&amp;nbsp;plannings are&#xD;
    held in the morning as they help set the context for the coming day's work.&#xD;
&lt;/p>&#xD;
&lt;p>&#xD;
    All team members are required to attend the daily planning. Anyone else is allowed to attend but is there only to&#xD;
    listen. This makes the daily&amp;nbsp;planning an excellent way for a team to disseminate status information--if you're&#xD;
    interested in hearing where things are at, attend that day's meeting.&#xD;
&lt;/p>&#xD;
The daily&amp;nbsp;planning is not used as a problem-solving or issue resolution meeting. Issues that are raised are taken&#xD;
offline and usually dealt with by the relevant sub-group immediately after the daily planning. During the&#xD;
daily&amp;nbsp;planning each team member provides answers to the following three questions:&lt;br />&#xD;
&lt;br />&#xD;
1. What did you do yesterday?&lt;br />&#xD;
2. What will you do today?&lt;br />&#xD;
3. Are there any impediments in your way? &#xD;
&lt;p>&#xD;
    By focusing on what each person accomplished yesterday and will accomplish today the team gains an excellent&#xD;
    understanding of what work has been done and what work remains. The daily planningis not a status update meeting in&#xD;
    which a boss is collecting information about who is behind schedule. Rather, it is a meeting in which team members make&#xD;
    commitments to each other. If a programmer stands up and says &quot;Today I will finish the data storage module&quot; everyone&#xD;
    knows that in tomorrow's meeting he will say whether or not he did finish. This has the wonderful effect of helping a&#xD;
    team realize the significance of these commitments and that their commitments are to each other, not to some far-off&#xD;
    customer or salesman.&lt;br />&#xD;
    &lt;br />&#xD;
    In cases where the&amp;nbsp;Coach cannot remove these impediments directly himself (e.g., usually the more technical&#xD;
    issues) he still takes responsibility for making sure someone on the team does quickly resolve the issue.&#xD;
&lt;/p>&#xD;
&lt;br /></refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
  <org.eclipse.epf.uma:DescriptorDescription xmi:id="-UnUlznoaCgKoZX0h31eE8w" name="lean_evolve_wow,_kACl4LqyEe2ItPaV9bHRfA" guid="-UnUlznoaCgKoZX0h31eE8w">
    <refinedDescription>All part of process, product or people can be Modified</refinedDescription>
  </org.eclipse.epf.uma:DescriptorDescription>
</xmi:XMI>
