Changes between Version 30 and Version 31 of PROCESS


Ignore:
Timestamp:
12/15/08 20:45:26 (16 years ago)
Author:
danvisel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • PROCESS

    v30 v31  
    22= '''Sophie 2.0 Process''' =   
    33 
    4 Тo keep the quality of the product (both internal and external) high, we need to define some additional things (this is related to the SCRUM mandatory definition of done). 
    5  
    6 This should improve the situation with the following challenges: 
     4In 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.) 
     5 
     6This will help us meet the following challenges: 
    77 * Internal quality (quality of code) 
    88 * External quality (quality of the visible product) 
    99 * Documentation reading (many things are written, few things are read) 
    10  * Not to produce too much process overhead  
     10 * Reducing unuseful process overhead  
    1111 
    1212 
    … …  
    1818 
    1919 1. Work towards the goal! 
    20  * No matter what this document defines, or how concrete your task is defined, there is no way to define exactly what should be good for our goal, and what should be bad. 
     20 * 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. 
    2121 * You have to work towards the goal. 
    2222 * When you work on something, you have to understand why and how it is related to our goal. 
    … …  
    2424 2. Be honest! 
    2525 * You have to present the situation to the leader as is. 
    26  * Even if it does not look good. 
    27  * For example, if you have no idea how to make something, don't tell "almost done" to the leader.  
    28  3. Be initiative! 
    29  * If you find a way that, you can make something good to the team, don't wait, but propose it to be done.  
     26 * Do this, even if it does not look good. 
     27 * For example, if you have no idea how to make something, don't say "almost done" to the leader.  
     28 3. Take initiative! 
     29 * If you find a way that you can make something better for the team, don't wait but propose that it to be done.  
    3030 4. Look around! 
    3131 * If you see problems in the code, in the product, in the organization, or whatever, announce them. 
    32  * Try to keep an eye about what other people do (either for things you can learn from, or for things they are doing bad). 
     32 * Try to keep an eye on what other people do (either for things you can learn from, or for things they are doing poorly). 
    3333 * Try to get a global vision of what is happening in our team.  
    34  5. Seek improvements (for yourself, and for the team) 
    35  * No matter how good you are, there are always more things you can learn, or skills you can get (note that knowledge and skills are different things..) 
     34 5. Seek improvements (for yourself and for the team) 
     35 * No matter how good you are, there are always more things you can learn, or skills you can acquire (note that knowledge and skills are different things). 
    3636 * Improving and learning is your responsibility. 
    37  * Not trying to understanding how things work, but learning that this does this, and that does that will lead you nowhere! Really! Even if you program for 20 years. I've seen such people.  
    38  6. Seek the most appropriate solution!. 
    39  * There is no perfect code. There is no perfect solution also (or maybe there is, but it is not reachable). 
    40  * There are no general good design rules - a design is good if it works well, it is easy to use (for example, if it is library, the clients don't need to write much), is simple, has good performance, is modifiable/extensible, testable, etc. Neither the number of design patterns used solves this, nor a code convention... nothing. You have to find a design that is good. 
    41  * Hacking around just to make things work is usually a time bomb. It is not acceptable to do this, because saving 1 day this month, usually costs 7 days the next month. 
    42  * What we should do, is seeking something between just make it work, and perfect, but more close to perfect than just works. 
     37 * Not trying to understand how things work, but learning that this does this, and that does that will lead you nowhere! Really! Even if you've programmed for 20 years it's possible to make this mistake.  
     38 6. Seek the most appropriate solution! 
     39 * There is no perfect code. There is no perfect solution (or even if there is it is not reachable). 
     40 * There are no general good design rules - a design is good if it works well, if it is easy to use (for example, if it is a library, the clients don't need to write much), if it is simple, has good performance, is modifiable/extensible, testable, etc. Neither the number of design patterns used solves this, nor a code convention... nothing. You have to find a design that is good. 
     41 * Hacking around just to make things work is usually a time bomb. It is not acceptable to do this, because saving 1 day this month usually costs 7 days the next month. 
     42 * What we should do is to seek something between just making it work and making it perfect, but closer to perfection than just working. 
    4343 * That is, seek a good solution.  
    44  7. Quality is not negotiable! - but scope and resources are 
    45  * If something can not be done in acceptable quality, given the resources (time) and scope (functionality) it has, then we either reduce the scope, or increase the resources. 
    46  * We are not allowed to reduce the quality!  
     44 7. Quality is not negotiable! Scope and resources are 
     45 * If something cannot be done with acceptable quality, given the resources (time) and scope (functionality) that it has, then we will either reduce the scope or increase the resources. 
     46 * We are not allowed to reduce quality!  
    4747 8. Accept the challenge! 
    48  * We are not doing the next Store Information System, the next Lawyer's web site, nor the next database module for the big company X 
    49  * What we are doing, is something that only few companies in the world can do, and even they are not good enough. 
    50  * There is no "How to make the next generation desktop publishing software"!  
     48 * We are not doing the next Store Information System, the next Lawyer's web site, nor the next database module for big company X 
     49 * What we are doing is something that only few companies in the world can do, and even many of them are not good enough. 
     50 * There are no instructions on "how to make the next generation desktop publishing software"!  
    5151 
    5252 
    … …  
    5454 
    5555 1. You have to try to follow the process as much as possible. 
    56  * Self discipline is needed. 
    57  * If you don't have enough self discipline, then this team is not appropriate for you (you should go to a company which forces you to be disciplined by other means).  
    58  
    59  2. Our workday starts at 09:30 am. 
     56 * Self-discipline is needed. 
     57 * If you don't have enough self-discipline, then this team is not appropriate for you (you should go to a company that forces you to be disciplined by other means).  
     58 
     59 2. Our workday starts at 09:30 am sharp. 
    6060  
    61  3. You may work from home, or from other locations, but with the approval of the team leader. 
    62  
    63  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 in the end of every iteration a monthly report - see [wiki:REPORTS] page to learn how to write reports. 
     61 3. You may work from home, or from other locations but only with the approval of the team leader. 
     62 
     63 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. 
    6464 
    6565== Task In Time == 
    6666 
    6767 1. Integrate continuously. 
    68  * Do not hold a source code very long (or prolong the task).  
     68 * Do not hold source code for very long (or prolong the task).  
    6969 2. Time box to 150% the estimate. 
    7070 * If you see that you are about to exceed the estimated time, warn the leader immediately. 
    71  * If you leader agrees, and it seems that the task can be completed with little more time, it is possible to work a bit more on it. 
    72  * A task reaching 150% (or 200% if the leader agrees) its estimate should be dropped, even if it is 99.9% complete.  
     71 * If you leader agrees, and it seems that the task can be completed with a little more time, a bit more time to complete it may be allowable. 
     72 * A task reaching 150% (or 200% if the leader agrees) of its estimate should be dropped, even if it is 99.9% complete.  
    7373 3. Do not start implementation phase of a task if the design phase is not reviewed yet! 
    74  * wait for the review of the design otherwise your work will be for nothing. 
    75  4. It is recommended not to design/implement a task which analysis is written by you.  
     74 * Wait for the review of the design, otherwise your work will be for nothing. 
     75 4. It is recommended that no one design/implement a task for which that person wrote the analysis.  
    7676 
    7777= SCRUM = 
    7878 
    79 We are continuing to use SCRUM (info at http://en.wikipedia.org/wiki/SCRUM). What is new, is that: 
    80  
    81  * Becoming much more strict (and unfortunately increasing the process overhead). 
     79We are continuing to use SCRUM (info at [http://en.wikipedia.org/wiki/SCRUM]). What is new: 
     80 
     81 * We are becoming much more strict (and unfortunately increasing the process overhead). 
    8282 * Trying to have much higher quality. 
    83  * Hoping that the lost of speed will be compensated by non lost of momentum (that we usually suffer from). 
    84  * The sprint backlogs will be wiki page ([wiki:ITERATION_01]). 
    85  * The four states of a story/task are: 
    86   * to [analyzing, designing, implementing, testing]  
    87  * Each passing between states requires a review.  
     83 * We expect that the lost of speed will be compensated by removing the loss of momentum that we have suffered from. 
     84 * The sprint backlogs will be on the wiki page ([wiki:ITERATION_01]). 
     85 * The four states of a story/task are  analyzing, designing, implementing, and testing.  
     86 * Each passage between states requires a review.  
    8887 
    8988We create the internal backlog which should track: 
    … …  
    101100 
    102101 * new 
    103   * task is waiting to be taken, and someone to determine What should be done? 
     102  * task is waiting to be taken, and someone to determine what should be done 
    104103 * '''analysis started''' 
    105104  * to learn how to write good analysis, see [wiki:PLATFORM_STANDARDS_ANALYSIS Platform Standards Analysis] 
    106   * there should be at least one example how to do one or more things that should be done. 
    107   * It should take not more than 0.25 of the task effort. 
     105  * there should be at least one example of how to do one or more things that should be done 
     106  * it should take not more than 0.25 of the task effort 
    108107 * '''analysis finished''' 
    109   * It is already determined what should be done. 
    110   * the task is waiting for review (Wait for the review of the analysis before starting the design otherwise your work can be for nothing!) 
     108  * it is already determined what should be done 
     109  * the task is waiting for review. (Wait for the review of the analysis before starting the design otherwise your work can be for nothing!) 
    111110 * '''review'''  
    112   * the reviewer look through the analysis to see if it is correct 
     111  * the reviewer looks through the analysis to see if it is correct 
    113112  * the analysis should apply to [wiki:PageTemplates/TaskPageTemplate#Analysis its template] 
    114  * '''analysis ok''' - the reviewer decides that the analysis of the task is correct 
     113 * '''analysis ok''': the reviewer decides that the analysis of the task is correct 
    115114 * '''design started'''  
    116   * The implementer is designing the task or in other words tries to decide How it should be done? 
    117   * It is not compulsory but recommended that the design should be made by the implementer. 
    118   * It is recommended that the design should not be made by the analyzer of the task.  
    119   * Designing is not only getting an idea of how to do it, but a detailed concept, step by step. 
    120   * For many tasks the design phase should take most of the time. 
     115  * the implementer is designing the task or in other words tries to decide how it should be done 
     116  * it is not compulsory but recommended that the design should be made by the implementer 
     117  * it is recommended that the design should not be made by the analyzer of the task 
     118  * designing is not only getting an idea of how to do something but understanding the concept, step by step 
     119  * for many tasks the design phase should take most of the time 
    121120 * '''design finished''' 
    122   * It is determined how the task should be done. 
    123   * It is designed and is waiting for review. 
     121  * it is determined how the task should be done 
     122  * it is designed and is waiting for review. 
    124123 * '''review''' 
    125   * The reviewer look through the design to see if it is correct. 
    126   * The reviewer can imagine himself as an implementer and see if he/she can implement the task following the design without problems. 
    127  * '''design ok''' - The reviewer decides that the design of the task is correct. 
     124  * the reviewer looks through the design to see if it is correct. 
     125  * The reviewer can imagine himself as an implementer and see if he can implement the task following the design without problems 
     126 * '''design ok''': the reviewer decides that the design of the task is correct 
    128127 * '''implementation started''' 
    129   * The implementer makes an attempt to complete the task. 
    130   * He/she should follow the design strictly. 
    131   * He/she should write in Implementation section of the task the result of the implementation. 
    132  * '''implementation finished''' - The implementer decides that the implementation of the task is ready. 
    133  * '''review''' - The reviewer look through the implementation to see if it is correct. 
     128  * the implementer makes an attempt to complete the task 
     129  * he/she should follow the design strictly 
     130  * he/she should write an Implementation section of the task as the result of the implementation 
     131 * '''implementation finished''': the implementer decides that the implementation of the task is ready 
     132 * '''review'': the reviewer look through the implementation to see if it is correct 
    134133 * '''implementation ok''' 
    135   * The reviewer decides that the implementation of the task is correct. 
    136   * The implementation section must be filled. 
    137  * '''test started''' - There should be appropriate tests written for the task. 
    138  * '''test finished''' - Testing state is done, waiting for review 
     134  * the reviewer decides that the implementation of the task is correct 
     135  * the implementation section must be filled 
     136 * '''test started''': there should be appropriate tests written for the task 
     137 * '''test finished''': testing state is done, waiting for review 
    139138 * '''review''' 
    140   * the reviewer looks for missing or wrong tests. 
    141   * if there are any, the reviewer may decide they can be added later. 
    142   * if they are too important or wrong they should be fixed - the review fails. 
     139  * the reviewer looks for missing or wrong tests 
     140  * if there are any, the reviewer may decide they can be added later 
     141  * if they are too important or wrong they should be fixed - the review fails 
    143142 * '''test ok''' 
    144143 
    145  * Notes 
    146   * 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.  
    147   * The transitions of each state are defined in [source:/trunk/sophie2-platform/doc/uml-design-diagrams/workflow.png Workflow diagram]. 
    148   * For every task we have tickets which are available for reading and filtering in View Tickets section in Trac. For every state of 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 info about our issue tracking. 
     144 * notes 
     145  * 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 
     146  * the transitions of each state are defined in [source:/trunk/sophie2-platform/doc/uml-design-diagrams/workflow.png Workflow diagram] 
     147  * 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. 
    149148 
    150149= Task Tips = 
    … …  
    154153   * should have a specification, and a manual testing scenario  
    155154  * designing  
    156    * write an automatic test/tests which verifies that your feature is working 
     155   * write an automatic test or tests that verifies that your feature is working 
    157156   * look at the related code 
    158157   * decide what needs to be added 
    159158   * if you add new library feature 
    160159    * write use case tests for it  
    161    * You may also write skeleton types (only declaration) and demos 
     160   * you may also write skeleton types (only declaration) and demos 
    162161    * write an outline of your design.  
    163162   * implementing 
    164     * Make all the designed things work. 
    165     * Ensure that all tests pass. 
    166     * During the process, add more tests.  
     163    * make all the designed things work. 
     164    * ensure that all tests pass. 
     165    * during the process, add more tests.  
    167166 
    168167 * Researching about a technology or library 
    169   * analyzing - specify what needs to be researched 
     168  * analyzing: specify what needs to be researched 
    170169   * what the research will solve 
    171170   * what is needed to be solved (this is important)  
    172171  * designing 
    173    * You can try things, but do not pollute the main source (for example with libraries). 
    174    * If you need to use other libraries, do it in another project (or in another branch) 
    175    * 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.  
     172   * you can try things, but do not pollute the main source (for example with libraries) 
     173   * if you need to use other libraries, do it in another project (or in another branch) 
     174   * 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.  
    176175  * implementing 
    177    * You present the written results / conclusions of your research, demo codes, etc.  
    178   * reviewers - 1-2 developers  
    179  
    180  * Implementing a new internal feature (a library or something, not directly visible). 
    181   * analyzing - what the library will provide 
    182   * designing - should include: 
    183    * use case tests, 
    184    * samples, 
    185    * (in some cases demo), 
     176   * you present the written results / conclusions of your research, demo codes, etc.  
     177  * reviewers: 1-2 developers  
     178 
     179 * implementing a new internal feature (a library or something, not directly visible) 
     180  * analyzing: what the library will provide 
     181  * designing: should include: 
     182   * use case tests 
     183   * samples 
     184   * demo (in some cases), 
    186185   * design outline  
    187186  * implementing 
    … …  
    190189  * reviewers: 2 developers  
    191190 
    192  * Performing some structure changes, or refactoring. 
    193   * analyzing - what the issues are 
    194   * designing - understanding it, and providing an idea how to fix the issues 
    195   * implementing - fixing the issues 
     191 * Performing structure changes or refactoring. 
     192  * analyzing: what the issues are 
     193  * designing: understanding it, and providing an idea how to fix the issues 
     194  * implementing: fixing the issues 
    196195  * reviewers: 1-2 developers  
    197196 
    198197 * Writing a specification 
    199   * analyzing - what needs to be specified 
    200   * designing - brief ideas about the thing 
    201   * implementing - writing the specification exactly 
    202   * reviewers: - 1 qa + 1 developer  
     198  * analyzing: what needs to be specified 
     199  * designing: brief ideas about the subject of the specification 
     200  * implementing: writing the specification exactly 
     201  * reviewers: 1 qa + 1 developer  
    203202 
    204203 * Doing documentation. 
    205   * analyzing - what needs to be document 
    206   * designing - what it will contain (outline) and understanding of the content 
    207   * implementing - adding the appropriate content. 
    208   * reviewers: - 1-2 team members  
     204  * analyzing: what needs to be documented 
     205  * designing: what it will contain (outline) and understanding of the content 
     206  * implementing: adding the appropriate content 
     207  * reviewers: 1-2 team members  
    209208 
    210209 * External testing (the usual testing task). 
    211   * analyzing - has to state what the focus of the tests will be. 
    212   * designing - has to select test scenarios, and make new if necessary. 
    213   * implementing - should apply testing scenarios and provide bugs and recommendations (things that probably the users will like/dislike). 
     210  * analyzing: has to state what the focus of the tests will be 
     211  * designing: has to select test scenarios, and make new scenarios if necessary 
     212  * implementing: should apply testing scenarios and provide bugs and recommendations (things that probably the users will like/dislike) 
    214213  * reviewers: 1 developer  
    215214 
    216215 * Fixing a bug. 
    217   * analyzing - what the bug is. needs a manual testing scenario (in bugzilla) 
    218   * designing - an automatic test (failing) should be present, idea what is causing it, more tests (which detect related internal bugs), idea how can be fixed 
    219   * implementing - fixing the bug, making the tests pass, and some refactoring 
     216  * analyzing: what the bug is. Needs a manual testing scenario (in bugzilla) 
     217  * 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 fixed 
     218  * implementing: fixing the bug, making the tests pass, and some refactoring 
    220219  * reviewers: 1 QA and 1 developer  
    221220 
    222 Templates for logging specific task kinds should be added. 
     221Templates for logging specific task types should be added 
    223222 
    224223= Roles = 
    225224 
    226  * leader - someone assigned to do the management (default: milo) 
    227  * implementers - the workers on given task 
    228  * reviewers - someone, which is assigned to review something. 
     225 * leader: someone assigned to do the management (default: Milo) 
     226 * implementers: the workers on a given task 
     227 * reviewers: a person who is assigned to review a task 
    229228  * the reviewer and the implementer may not intersect!  
    230229