1 / 22

Common Planning Component

Common Planning Component. Tentative UX Model. This is intended to present a brief model of the common planning component from the user’s perspective. It is based on the goals, tasks and capabilities understood to be supported.

cclodfelter
Télécharger la présentation

Common Planning Component

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Common Planning Component Tentative UX Model This is intended to present a brief model of the common planning component from the user’s perspective. It is based on the goals, tasks and capabilities understood to be supported. This is intended for internal feedback and to generate discussions. This is not intended as a UI design. The layout and other aspects of the UI used here are only used for conceptual purposes. Last Update: February 11, 2010

  2. The Main Parts

  3. The Main Parts “Plans” would be one of those dahsboards sets, showing one ore more plans. Those plans could be hierarchically related, allowing stakeholders to breakdown a plan into component plans that could be, thus, managed modularly. Those plans could be nested within each other. In this example. The release plan (above) references an iteration, but the iteration plan for that iteration is detailed in a “child” plan (next chart) Combines aspects from RTC’s Agile Planner….. And from RPC Gantt Dashboard Mini: A common jazz navigation component containing sets of artifacts which set context for what is presented in the UI Will scale to handle gracefully and productively very large numbers of elements No product banner… No reference to a specific product. The Planning Component is product agnostic

  4. The Main parts (2) Includes a view for managing the Resources in a Program, Product, Release or Iteration, including (RPC’s) support for assigning resources to items on the basis of availability, skills, contours, and other resource properties The plan includes the Criteria against which Releases and Iterations will be evaluated. These criteria are associated with Goals. Includes a view for viewing (RPC’s) financial data, rolled up to Iteration, Release, Product, and Program Resources, Risks and Financials be part of the Component

  5. Their Interactions Release-Level Plan shows items belonging to the release as a whole, that may not be part of a specific iteration, along with references to iterations that will be planned separated. This would bee the more “traditional”, top-down planning carried out top-down by a program manager, acting as a product backlog Users can drag items from Product Plan (Product Backlog) to Release Plan, and from there to Iteration Plan (Iteration Backlog)

  6. Their Interactions (2) Iteration-level Plan shows items belonging in a specific iteration, This would address more “agile” planning carried out by team leads. Will support RTC’s Taskboards and Ranked List Views on the plan The UI design needs to conceive a mechanism for showing the team/organization layer along with the WBS hierarchy layer in the most efficient, intuitive and non-obstrusive way while making the differentiation clear

  7. The Main Actions • Elements can be: • - Created (by type) • - Deleted • ------------------------------------- • - Filtered • - Reordered (through direct manipulation) Dependencies can be: - Created - Deleted - Resolved • Plans can be • - Created • - Imported (?) • - Deleted (deletion constraints?) • - Snapshut (for comparison). Snapshot • includes schedule, resources, and financials • - Printed Actions that control the display of the elements in the plan and their visualization: - Time scale - Refresh - sorting - Navigation

  8. Cross-C/ALM linking possibilities 1. Scope Management RPC often gets questioned about managing project scope, and about the need to distinguish between execution (WBS) and Scope. The common planning component could address this through the OSLC integration with RRC. The following illustrates how this would take place form a user’s perspective…

  9. Scope Management (linking) A requirement can be added… Scope Management view

  10. Scope Management (linking) A requirement can be added… Scope Management view

  11. Scope Management (linking) The gesture to “Add” would bring an RRC dialog (OSLC call) listing the available collections These dialogs are already in used by RTC and RQM in the context of C/ALM.

  12. Scope Management (linking) Specific requirements within a collection can be selected

  13. Scope Management (linking) The “added” requirements represent the scope for a given project.

  14. Scope Management (linking) Once added, detailed information on a requirement can be viewed through a Riche Hover.

  15. Scope Management (linking) Once the scope is defined for a project (i.e., the requirements to be addressed), work items can be generated… similarly to how they are generated from actions in risk strategies.

  16. Scope Management (linking) Once the scope is defined for a project (i.e., the requirements to be addressed), work items can be generated… similarly to how they are generated from actions in risk strategies… … similar to how work items are generated from actions in risk strategies.

  17. Scope Management (linking) Once generated, the work item becomes part of the WBS, where it’s planned, assigned to iterations, resourced, etc…

  18. Scope Management (linking) Furthermore, a Project Manager could assign Test Plans… or see those assigned in RQM by someone else.

  19. Scope Management (linking) Furthermore, a Project Manager could assign Test Plans… or see those assigned in RQM by someone else.

  20. Cross-C/ALM linking possibilities 2. Enriching Requirement and Test information in plan items We could incorporate requirement (RRC) and Test (RQM) information in the WBS views. These would include linking that information to artifacts in RRC and RQM The following illustrates how this would take place form a user’s perspective…

  21. Integration with Requirements and Test (linking) Include entries to show Requirement and Test artifacts for a given WBS element.

  22. Integration with Requirements and Test (linking) Details on those artifacts could be accessed in RRC and RQM through Rich Hovers. .

More Related