Changes between Version 34 and Version 35 of PROCESS
- Timestamp:
- 01/07/09 11:01:35 (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
PROCESS
v34 v35 3 3 4 4 == Overview == 5 5 6 In order to produce the highest quality product (both internal and external), we have defined process guidelines in this section. (This is related to the SCRUM mandatory definition of the done status state.) 6 7 … … 18 19 * Trying to have much higher quality. 19 20 * The sprint backlogs will be on the wiki page ([wiki:ITERATION_01] for example). 21 * The meetings are: 22 * weekly meetings - one per week, team members have to be present or to be represented by someone. 23 * progress checks - one per week between two weekly meetings, team leaders have to be present with prepared information about his/her team progress. 20 24 * The four states of a story/task are analyzing, designing, implementing, and testing. 21 25 * Each passage between states requires a review. … … 31 35 32 36 == Teams == 37 33 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]] 34 39 The six teams are as follows: … … 43 48 44 49 == Team Roles == 50 45 51 For each team there is team leader defined. They are not fixed also and can be changed even during the process depending on their productivity as team leaders. The other developers are called team members. The team leader should: 46 52 * be responsible for the progress of his/her team on the progress checks (see ?) … … 49 55 * helps the team members if they have questions and obscurities or directs them to the person who can help them. 50 56 57 The team members for each task can be in the role of: 58 * reviewers - a person who is assigned to review a task 59 * implementers - the workers on a given task 60 The reviewers and the implementers of a task must not intersect! 61 51 62 The Release team has an internal process described in http://sophie2.org/trac/wiki/ITERATION_03/Release/Process. 52 63 53 64 54 == Workflow == =65 == Workflow == 55 66 56 67 Each taken task in the current sprint should pass trough the following phases described in this diagram: … … 58 69 59 70 === Task States === 71 60 72 These are the states descriptions: 61 73 62 * new74 * '''new''' 63 75 * task is waiting to be taken, and someone to determine what should be done 64 76 * '''analysis started''' … … 72 84 * the reviewer looks through the analysis to see if it is correct 73 85 * the analysis should apply to [wiki:PageTemplates/TaskPageTemplate#Analysis its template] 74 * '''analysis ok''': the reviewer decides that the analysis of the task is correct 86 * '''analysis ok''' 87 * the reviewer decides that the analysis of the task is correct 75 88 * '''design started''' 76 89 * the implementer is designing the task or in other words tries to decide how it should be done … … 85 98 * the reviewer looks through the design to see if it is correct. 86 99 * The reviewer can imagine himself as an implementer and see if he can implement the task following the design without problems 87 * '''design ok''': the reviewer decides that the design of the task is correct 100 * '''design ok''' 101 * the reviewer decides that the design of the task is correct 88 102 * '''implementation started''' 89 103 * the implementer makes an attempt to complete the task … … 91 105 * he/she should write an Implementation section of the task as the result of the implementation 92 106 * '''implementation finished''': the implementer decides that the implementation of the task is ready 93 * '''review'' : the reviewer look through the implementation to see if it is correct107 * '''review''': the reviewer look through the implementation to see if it is correct 94 108 * '''implementation ok''' 95 109 * the reviewer decides that the implementation of the task is correct 96 110 * the implementation section must be filled 97 * '''test started''': there should be appropriate tests written for the task98 * '''test finished''': testing state is done, waiting for review111 * '''testing started''': there should be appropriate tests written for the task 112 * '''testing finished''': testing state is done, waiting for review 99 113 * '''review''' 100 114 * the reviewer looks for missing or wrong tests 101 115 * if there are any, the reviewer may decide they can be added later 102 116 * if they are too important or wrong they should be fixed - the review fails 103 * '''test ok''' 117 * '''testing ok''' 118 * the last task state 104 119 105 120 * notes … … 160 175 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. 161 176 177 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=en 178 179 6. You must be presents at the weeklies and the progress points or at least you have to be represented by someone. 180 162 181 === Task In Time === 163 182 … … 172 191 4. It is recommended that no one design/implement a task for which that person wrote the analysis. 173 192 174 175 == Task Tips ==176 177 * Implementing a new external feature (visible from the user):178 * analyzing179 * should have a specification, and a manual testing scenario180 * designing181 * write an automatic test or tests that verifies that your feature is working182 * look at the related code183 * decide what needs to be added184 * if you add new library feature185 * write use case tests for it186 * you may also write skeleton types (only declaration) and demos187 * write an outline of your design.188 * implementing189 * make all the designed things work.190 * ensure that all tests pass.191 * during the process, add more tests.192 193 * Researching about a technology or library194 * analyzing: specify what needs to be researched195 * what the research will solve196 * what is needed to be solved (this is important)197 * designing198 * you can try things, but do not pollute the main source (for example with libraries)199 * if you need to use other libraries, do it in another project (or in another branch)200 * if you don't need other libraries, you can do it in a research package, but you should make sure that you don't introduce warnings, failing tests, etc.201 * implementing202 * you present the written results / conclusions of your research, demo codes, etc.203 * reviewers: 1-2 developers204 205 * implementing a new internal feature (a library or something, not directly visible)206 * analyzing: what the library will provide207 * designing: should include:208 * use case tests209 * samples210 * demo (in some cases),211 * design outline212 * implementing213 * the library should be implemented214 * enough tests should be written during the process215 * reviewers: 2 developers216 217 * Performing structure changes or refactoring.218 * analyzing: what the issues are219 * designing: understanding it, and providing an idea how to fix the issues220 * implementing: fixing the issues221 * reviewers: 1-2 developers222 223 * Writing a specification224 * analyzing: what needs to be specified225 * designing: brief ideas about the subject of the specification226 * implementing: writing the specification exactly227 * reviewers: 1 qa + 1 developer228 229 * Doing documentation.230 * analyzing: what needs to be documented231 * designing: what it will contain (outline) and understanding of the content232 * implementing: adding the appropriate content233 * reviewers: 1-2 team members234 235 * External testing (the usual testing task).236 * analyzing: has to state what the focus of the tests will be237 * designing: has to select test scenarios, and make new scenarios if necessary238 * implementing: should apply testing scenarios and provide bugs and recommendations (things that probably the users will like/dislike)239 * reviewers: 1 developer240 241 * Fixing a bug.242 * analyzing: what the bug is. Needs a manual testing scenario (in trac)243 * designing: an automatic test (failing) should be present, an idea what is causing it, more tests (which detect related internal bugs), and an idea of how can be fixed244 * implementing: fixing the bug, making the tests pass, and some refactoring245 * reviewers: 1 QA and 1 developer246 247 Templates for logging specific task types should be added248 249 == Roles ==250 251 * leader: someone assigned to do the management (default: Milo)252 * implementers: the workers on a given task253 * reviewers: a person who is assigned to review a task254 * the reviewer and the implementer may not intersect!255 256 193 = Comments = 257 194 ''You can put your comments here.''
