| 115 | | * '''analyzing''' - task is waiting to be taken, and someone to determine What should be done? |
| 116 | | * to learn how to write good analysis, see [wiki:PLATFORM_STANDARDS_ANALYSIS Platform Standards Analysis] |
| 117 | | * '''analyzed''' - it is already determined what should be done and the task is waiting for review. |
| 118 | | * '''review''' - The reviewer look through the implementation to see if it is correct. |
| | 115 | * '''analyzing''' |
| | 116 | * task is waiting to be taken, and someone to determine What should be done? |
| | 117 | * to learn how to write good analysis, see [wiki:PLATFORM_STANDARDS_ANALYSIS Platform Standards Analysis] |
| | 118 | * there should be at least one example how to do one or more things that should be done. |
| | 119 | * It should take not more than 0.25 of the task effort. |
| | 120 | * '''analyzed''' |
| | 121 | * It is already determined what should be done. |
| | 122 | * the task is waiting for review (Wait for the review of the analysis before starting the design otherwise your work can be for nothing!) |
| | 123 | * '''review''' |
| | 124 | * the reviewer look through the analysis to see if it is correct |
| | 125 | * the analysis should apply to [wiki:PageTemplates/TaskPageTemplate#Analysis its template] |
| 122 | | * It is recommended that the design should not be made by the analyzer. |
| 123 | | * designing is not only getting an idea of how to do it, but a detailed concept step by step |
| 124 | | * for many tasks the design phase should take most of the time |
| 125 | | * '''designed''' - The task is designed and is waiting for review. |
| 126 | | * '''review''' - The reviewer look through the implementation to see if it is correct. |
| | 130 | * It is recommended that the design should not be made by the analyzer of the task. |
| | 131 | * Designing is not only getting an idea of how to do it, but a detailed concept, step by step. |
| | 132 | * For many tasks the design phase should take most of the time. |
| | 133 | * '''designed''' |
| | 134 | * The task is already determined how should be done. |
| | 135 | * It is designed and is waiting for review. |
| | 136 | * '''review''' |
| | 137 | * The reviewer look through the design to see if it is correct. |
| | 138 | * The reviewer can imagine himself as an implementer and see if he/she can implement the task following the design without problems. |
| 131 | | * '''implementation accepted''' - The reviewer decides that the design of the task is correct. |
| 132 | | * '''testing''' |
| 133 | | * '''review''' - the reviewer looks for missing or wrong tests and decides if there are minor and can be added later or they are important and have to be written (or fixed) now. |
| | 146 | * '''implementation accepted''' |
| | 147 | * The reviewer decides that the implementation of the task is correct. |
| | 148 | * The implementation section must be filled. |
| | 149 | * '''testing''' - There should be appropriate tests written for the task. |
| | 150 | * '''tested''' - Testing state is done, waiting for review |
| | 151 | * '''review''' |
| | 152 | * the reviewer looks for missing or wrong tests |
| | 153 | * if there are any decides they can be added later |
| | 154 | * if they are too important or wrong they should be fixed - the review fails. |
| 138 | | You may note that some bigger tasks can not be easily made with these phases. However this is a problem to the task. Big tasks should be decomposed to smaller so that they can fit. |
| 139 | | |
| 140 | | = Requirements = |
| 141 | | |
| 142 | | Refactoring should be continuous process(not doing again great refactorings!). |
| 143 | | |
| 144 | | == General == |
| 145 | | |
| 146 | | The following are valid for no matter what kind of task we are doing: |
| 147 | | |
| 148 | | * Analysis - What is to be done? |
| 149 | | * Design - How will we do it? |
| 150 | | * Implementation - The actual "do it". |
| 151 | | |
| 152 | | Review may be applied after each phase. Each activity should be logged (in the sprint backlog), and all information needed to log it should be filled. If implementers want, they can (and are encouraged to) ask for guidelines early. This is something like an early review, which is not logged. |
| 153 | | |
| 154 | | At first month, each review should be rechecked by Milo. |
| 155 | | |
| 156 | | However, to clarify the things further: |
| | 159 | = States depends on task kinds = |
| 235 | | * reviewers - someones (it needs to be two, usually one developer and one QA) which is assigned to review something. |
| 236 | | * the reviewers and the implementers may not intersect! |
| 237 | | |
| 238 | | |
| 239 | | Things to be read tracking - [wiki:ImportantDocs] |
| 240 | | |
| 241 | | = Other notes = |
| 242 | | |
| 243 | | == Reverting == |
| 244 | | |
| 245 | | If some bad code is committed (for example one that breaks changes) there may be a need to revert it. |
| 246 | | |
| 247 | | Reverting is done by: |
| 248 | | * creating an inverting diff (between revisions, or several revision numbers) |
| 249 | | * applying that diff to the current source code. |
| 250 | | * commiting |
| | 237 | * reviewers - someone, which is assigned to review something. |
| | 238 | * the reviewer and the implementer may not intersect! |
| | 239 | |
| | 240 | = Documents to read = |
| | 241 | [wiki:Important Docs] |
| | 242 | |
| | 243 | = Comments = |
