Поделиться через


Errata: Divide Scenarios into Tasks

Activity: Divide Scenarios into Tasks

role icon
Project Manager
role icon

Plan an Iteration

role icon

Task

Participating Roles

Responsible:

Project Manager

Consult:

Architect

Developer

Tester

Overview

A scenario is divided into the development tasks to implement the scenario. Dividing scenarios further provides better cost estimates and divides the work among the developers. Some scenarios might impact multiple subsystems within an application. In this case, separate tasks are created for each affected area. The key to successfully dividing the scenario into tasks is to have developers and testers do the division and encourage them to select their own tasks. All tasks must be selected.

Entry Criteria

Dependencies:

  • The scheduled scenario description is written and storyboarded if necessary.

Sub-Activities

1

Gather the Team

  • Gather the architects, developers, and testers who will be working on or impacted by this scenario. The project manager facilitates this brief meeting or email discussion and records the tasks.

2

Identify Architecture and Development Tasks

  • Begin where the scenario differs from previously implemented scenarios and follow the control path through the system. Consider user visible features, changes to the underlying infrastructure or data structures and items that have architectural impact. Identify how system components are affected when implementing the planned scenario.
  • Ensure that the architecture will be able to handle the scenario. If architectural changes are necessary, create the roadmap and tasks for refactoring the architecture to the new state. Split the scenario if necessary. 
  • Create a new development task for each major area of the system impacted by the scenario. For each task, describe the new or changed functionality. Keep the tasks broad enough to allow design to emerge but focused enough that a single person could complete them in one to three days. Group low level changes that are logically related into higher level tasks. Further divide high level changes and additions into lower level tasks if they are broad.
  • Review the set of tasks to ensure that they adequately address the scenario.

3

Choose Architecture and Development Tasks

  • Architects and developers choose their own tasks.
  • Check to make sure all architecture and development tasks are chosen.

4

Reassign Scenario to a Developer

  • Reassign the scenario to one of the developers who owns development tasks for that scenario. This developer’s job is to test the end-to-end integration of the development tasks.

5

Create Test Tasks

  • Update the test approach document for the iteration, filling in the test data and other sections. Create a set of tasks to create the necessary test cases to achieve the goal of the iteration.
  • Determine which tests can be automated and added to the iteration tests. The iteration tests run after the build verification tests.

6

Choose the Test Tasks

  • Allow the testers to choose their test tasks.
  • Check to make sure all test tasks are chosen.

Exit Criteria

The initial iteration plan contains tasks describing all work necessary to fulfill all the scenarios scheduled for the iteration.

All tasks created during the brief meeting are chosen.

Comments

  • Anonymous
    April 19, 2006
    Manish Agarwal talks about configuring desktop builds for building specific solutions in Team Build....