Changes between Version 42 and Version 43 of PROCESS
- Timestamp:
- 01/08/09 19:44:50 (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
PROCESS
v42 v43 38 38 We define six teams for improved performance and management while developing sophie 2. The team diagram showing the splitting of the developers to teams is located here: http://sophie2.org/trac/browser/manage/sched/teams.odg [[BR]] 39 39 The six teams are as follows: 40 * Analysis team - responsible for analysing the tasks for the current and the next iteration .40 * Analysis team - responsible for analysing the tasks for the current and the next iteration and for the testing reviews. 41 41 * Base team - responsible for the Platform, Core and Base categories. 42 42 * Main team - responsible for Main and End Product categories. 43 43 * Server Team - responsible for Supporting, SCS and S2S categories. 44 * Release Team - responsible for the releases and the reviews of the implementation phases(See [wiki:PROCESS#TaskStates]).45 For now the analysis and design reviews are made internally in the team.44 * Release Team - responsible for the releases, the reviews of the implementation phase, the testing phase and bug fixing(See [wiki:PROCESS#TaskStates]). 45 For now the analysis reviews are made internally in the team. The design reviews are done by a functional team member(not necessary from the same team). 46 46 47 47 Note: The categories are described in the work breakdown structure: [source:/manage/sched/sophie2_wbs.py]. The teams are not fixed, it is recommended to change the team members each iteration or for every several iterations. … … 84 84 * the task is waiting for review. (Wait for the review of the analysis before starting the design otherwise your work can be for nothing!) 85 85 * '''review''' 86 * the reviewer looks through the analysis to see if it is correct 86 * the reviewer looks through the analysis to see if it is correct(observing the [wiki:PLATFORM_STANDARDS_ANALYSIS] document and trying to improve it) 87 87 * the analysis should apply to [wiki:PageTemplates/TaskPageTemplate#Analysis its template] 88 88 * '''analysis ok''' … … 98 98 * it is designed and is waiting for review. 99 99 * '''review''' 100 * the reviewer looks through the design to see if it is correct. 100 * the reviewer looks through the design to see if it is correct.observing the [wiki:PLATFORM_STANDARDS_DESIGN] document and trying to improve it) 101 101 * The reviewer can imagine himself as an implementer and see if he can implement the task following the design without problems 102 102 * '''design ok''' … … 123 123 * failing a state (for example moving from implementing to analyzing because implementation failed) requires that the state of the product is reversed to the initial state 124 124 * the transitions of each state are defined in [source:/trunk/sophie2-platform/doc/uml-design-diagrams/workflow.png Workflow diagram] 125 * for every task we have tickets which are available for reading and filtering in the View Tickets section in Trac. For every state of a particular task, you have to go to its ticket and update its status depending on the state you are working on. See [wiki:SCS_ISSUE_TRACKER_SETUP_R1] for more information about our issue tracking. 126 127 125 * for every task we have tickets which are available for reading and filtering in the View Tickets section in Trac. For every state of a particular task, you have to go to its ticket and update its status depending on the state you are working on. There are custom ticket fields which we should filled with information about the task phase owner, reviewer and score. There is also importance field(See [wiki:SCHEDULE_WBS_DEPENDENCIES_R1#Design] for its usage). See [wiki:SCS_ISSUE_TRACKER_SETUP_R1] for more information about our issue tracking. 126 * Reviews should have reasoning for the given mark. These better be connected to concrete requirements in the standards, 128 127 == Rules == 129 128 This is a list of rules you have to follow. It is not final yet, but disobeying them may lead to penalties. … … 131 130 === General === 132 131 133 1. Work towards the goal!132 1. '''Work towards the goal! ''' 134 133 * No matter what this document defines, or how specifically your task is defined, there is no way to define exactly what should be considered good for reaching our goal, and what should be considered bad. 135 134 * You have to work towards the goal. … … 177 176 4. You have to write in the end of every working day a daily report about what have you done that day. You have to write at the end of every iteration a monthly report - see [wiki:REPORTS] page to learn how to write reports. 178 177 179 5. You have to fill the internal backlog every working day or at least before weekly meeting. Here it is: http://spreadsheets.google.com/ccc?key=p-0Oq38E1ayuX-E_kPfPxbg&hl=en178 5. You have to fill the internal backlog(especially the Daily Availability Sheet) every working day or at least before weekly meeting. Here it is: http://spreadsheets.google.com/ccc?key=p-0Oq38E1ayuX-E_kPfPxbg&hl=en 180 179 181 180 6. You must be presents at the weeklies and the progress points or at least you have to be represented by someone.
