| <?xml version="1.0" encoding="UTF-8"?> |
| <org.eclipse.epf.uma:ContentDescription xmi:version="2.0" |
| xmlns:xmi="http://www.omg.org/XMI" xmlns:org.eclipse.epf.uma="http://www.eclipse.org/epf/uma/1.0.5/uma.ecore" |
| xmlns:epf="http://www.eclipse.org/epf" epf:version="1.5.0" xmlns:rmc="http://www.ibm.com/rmc" |
| rmc:version="7.5.0" xmi:id="-0z-Uxv57_5cIS3Q0Jim8HA" |
| name="how_to_adopt_practice_authoring,_OZHJYCXKEd2dSdS2FPKaIA" guid="-0z-Uxv57_5cIS3Q0Jim8HA" |
| changeDate="2008-11-13T14:45:21.078-0800" version="7.2.0"> |
| <mainDescription><h3>
 |
| Getting started&nbsp;
 |
| </h3>
 |
| <p>
 |
| Begin by making sure the team, including the key stakeholders, understands the&nbsp;and the key concepts and the
 |
| roadmaps.
 |
| </p>
 |
| <p>
 |
| The Practice Authoring practice assumes that the method authoring environment and the underlying method framework in
 |
| which the practice is to reside has been set up.&nbsp;Make sure that all team members can access the environment and
 |
| understand how to use it.
 |
| </p>
 |
| <p>
 |
| This practice supports authoring a new practice, as well as customizing an existing practice.
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| To adopt the "author new practice" aspects, start by identifying the practice to be authored.&nbsp;It is
 |
| recommended that the first time you apply this practice that you apply it to author a practice where the content to
 |
| be included in the practices is well understood and where subject matter experts&nbsp;of the practice are part of
 |
| the authoring team. Author the practice incrementally, defining the overall practice structure (the practice
 |
| design) first, followed by the detailing of the practice elements. See <a class="elementLinkWithType"
 |
| href="./../../../practice.mdev.auth.practice_auth.base/guidances/roadmaps/author_new_practice_DECF4754.html"
 |
| guid="_t8M_4CXOEd2dSdS2FPKaIA">Roadmap: Author a New Practice</a>&nbsp;for details.
 |
| </li>
 |
| <li>
 |
| To adopt the "customize existing practice" aspects, start by identifying the practice you want to customize and how
 |
| you want to customize it.&nbsp;It is recommended that the first time you apply this practice that you apply it to
 |
| customize a practice that is well understood and where subject matter experts&nbsp;of the practice (and the
 |
| customization) are part of the authoring team. See&nbsp;<a class="elementLinkWithType"
 |
| href="./../../../practice.mdev.auth.practice_auth.base/guidances/roadmaps/customize_existing_practice_65E4C6F3.html"
 |
| guid="_1DeVACYEEd2Hqsxn1d0Dyg">Roadmap: Customize an Existing Practice</a>&nbsp;for details.
 |
| </li>
 |
| </ul>
 |
| <p>
 |
| As you apply the recommendations described in the practice, capture what you have learned, what worked for your team
 |
| and what didn't so that you can continually fine-tune how your team applies the practice.
 |
| </p>
 |
| <h3>
 |
| Common pitfalls
 |
| </h3>
 |
| <p>
 |
| The following are some common pitfalls when adopting this practice.
 |
| </p>
 |
| <ul>
 |
| <li>
 |
| Selecting a practice whose content is not well understood as your first practice using this practice.&nbsp;If this
 |
| is done, more time is spent understanding the practice itself rather than in effectively applying the practice
 |
| techniques.
 |
| </li>
 |
| <li>
 |
| Spending too much time structuring the practice.&nbsp;If this is done, the time it takes to deliver the practice is
 |
| extended as a lot of time is spent structuring as opposed to just enough to get an initial practice out to get
 |
| feedback, refining the structure, as needed. Try to keep the documentation clear and concise.&nbsp;Make sure that
 |
| the consumers of the practice documentation (the development team) are comfortable with the format and content of
 |
| the documentation.&nbsp; Is there more or different information they would like see?&nbsp;Would they like to see
 |
| less?
 |
| </li>
 |
| </ul></mainDescription> |
| </org.eclipse.epf.uma:ContentDescription> |
