Changes between Version 16 and Version 17 of PROCESS


Ignore:
Timestamp:
10/20/08 16:01:25 (17 years ago)
Author:
pavlina
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • PROCESS

    v16 v17  
    2222 * When you work on something, you have to understand why and how it is related to our goal. 
    2323 * You have to try to drive the whole team towards the goal (no one alone is capable of reaching it)  
    24  1. Be honest! 
     24 2. Be honest! 
    2525 * You have to present the situation to the leader as is. 
    2626 * Even if it does not look good. 
    2727 * For example, if you have no idea how to make something, don't tell "almost done" to the leader.  
    28  1. Be initiative! 
     28 3. Be initiative! 
    2929 * If you find a way that, you can make something good to the team, don't wait, but propose it to be done.  
    30  1. Look around! 
     30 4. Look around! 
    3131 * If you see problems in the code, in the product, in the organization, or whatever, announce them. 
    3232 * Try to keep an eye about what other people do (either for things you can learn from, or for things they are doing bad). 
    3333 * Try to get a global vision of what is happening in our team.  
    34  1. Seek improvements (for yourself, and for the team) 
     34 5. Seek improvements (for yourself, and for the team) 
    3535 * 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..) 
    3636 * Improving and learning is your responsibility. 
    3737 * 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  1. Seek the most appropriate solution!. 
     38 6. Seek the most appropriate solution!. 
    3939 * There is no perfect code. There is no perfect solution also (or maybe there is, but it is not reachable). 
    4040 * There are no general good design rules - a design is good if it works well, it is easy to use (like if it is library, the clients need not to write much), is simple, has good performance, is modifiable/extensible, testable, etc. Nor the number of design patterns used solves this, nor a code convention... nothing. You have to find a design that is good. 
    … …  
    4242 * What we should do, is seeking something between just make it work, and perfect, but more close to perfect than just works. 
    4343 * That is, seek a good solution.  
    44  1. Quality is not negotiable! - but scope and resources are 
     44 7. Quality is not negotiable! - but scope and resources are 
    4545 * 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. 
    4646 * We are not allowed to reduce the quality!  
    47  1. Accept the challenge! 
     47 8. Accept the challenge! 
    4848 * 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 
    4949 * What we are doing, is something that only few companies in the world can do, and even they are not good enough. 
    … …  
    5757 * 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).  
    5858 
    59  1. Our work-time for half-time working (all of us currently) is 11:00 to 15:00(vote for this) by default. 
     59 2. Our work-time for half-time working (all of us currently) is 11:00 to 15:00(vote for this) by default. 
    6060 * If you need to shift it, or not work some days, but work more other days, you need to warn the leader, or the appropriate person. 
    6161 * you can not shift more than the half of the working time 
    6262 
    63  1. You have to make 20 working hours per week by default. 
     63 3. You have to make 20 working hours per week by default. 
    6464 * This means 20 productive work hour not 20 hours staying in the office. 
    6565 * You may stay at the office as much as you like, take breaks, study, play games, whatever, but you should make 20 productive hours (working on a task).  
    6666  
    67  1. You may work from home, or from other locations, but unless you have approval from the leader (like when we had no electricity), at least 3/4 of your time you should work from the office.[[BR]] 
    68  
    69  1. Unless having approval from the leader, you may not work more than 8 hours per day. 
     67 4. You may work from home, or from other locations, but unless you have approval from the leader (like when we had no electricity), at least 3/4 of your time you should work from the office.[[BR]] 
     68 
     69 5. Unless having approval from the leader, you may not work more than 8 hours per day. 
    7070 * Or at least you may not count more than 8 hours per day as productive time. 
    7171 * This means, that you need to work at least 3 days per week in order to complete your time.  
    7272 
    73  1. You should be present on our weekly meeting every Mondays on 10:00 AM (vote for this). 
    74  
    75  1. In case you can not be present in a meeting, you have to warn the leader before this, and have a representative (someone else in the team) who will represent you. [[BR]] 
    76  1. You have to write in the end of every working day daily report about what have you done during the day. You have to write in the end of every iteration monthly report - see [wiki:REPORTS] page to learn how to write reports. 
     73 6. You should be present on our weekly meeting every Mondays on 10:00 AM (vote for this). 
     74 
     75 7. In case you can not be present in a meeting, you have to warn the leader before this, and have a representative (someone else in the team) who will represent you. [[BR]] 
     76 8. You have to write in the end of every working day daily report about what have you done during the day. You have to write in the end of every iteration monthly report - see [wiki:REPORTS] page to learn how to write reports. 
    7777 
    7878== Other == 
    … …  
    8080 1. Integrate continuously. 
    8181 * Do not hold a source code very long (or prolong the task).  
    82  1. Time box to 150% the estimate. 
     82 2. Time box to 150% the estimate. 
    8383 * If you see that you are about to exceed the estimated time, warn the leader immediately. 
    8484 * 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. 
    8585 * A task reaching 150% (or 200% if the leader agrees) its estimate should be dropped, even if it is 99.9% complete.  
    86  1. Do not start implementation phase of a task if the design phase is not reviewed yet! 
     86 3. Do not start implementation phase of a task if the design phase is not reviewed yet! 
    8787 * wait for the review of the design otherwise your work will be for nothing. 
    88  1. It is recommended not to design/implement a task which analysis is written by you.  
     88 4. It is recommended not to design/implement a task which analysis is written by you.  
    8989 
    9090= SCRUM = 
    9191 
    92 We are continuing to use SCRUM (see Sophie-JR-Process-Optimization#Scrum). What is new, is that: 
     92We are continuing to use SCRUM (info at http://en.wikipedia.org/wiki/SCRUM). What is new, is that: 
    9393 
    9494 * Becoming much more strict (and unfortunately increasing the process overhead) 
    … …  
    9696 * Hoping that the lost of speed will be compensated by non lost of momentum (that we usually suffer from) 
    9797 * The sprint backlogs will be wiki page ([wiki:ITERATION_01]). 
    98  * The four state of a story/task are: 
    99   * to [analyzing, designing, implementing, done, testing]  
     98 * The four states of a story/task are: 
     99  * to [analyzing, designing, implementing, testing]  
    100100 * Each passing between states requires a review.  
    101101 
    … …  
    103103 
    104104 * Impediments backlog 
    105  *  ?Documentation backlog?? (reading tracking?) 
    106  *  ?Code reviewing?  
    107  
    108 = Task  Phases = 
     105 * Documentation backlog 
     106 * Smells 
     107 * Daily Availability 
     108 * Open Questions 
     109 
     110= Task  States = 
    109111 
    110112Each taken task in the current sprint should pass trough the following phases: 
     113Note: The transitions of each state are defined in [source:/trunk/sophie2-platform/doc/uml-design-diagrams/workflow.png Workflow diagram]. 
    111114 
    112115 * '''analyzing''' - task is waiting to be taken, and someone to determine What should be done? 
    113   * to learn how to write good analysis, see [wiki:PLATFORM_STANDARDS_ANALYSIS_R0 Platform Standards Analysis]  
    114   * transitions: 
    115    * to designing when all the post-conditions are met 
    116    * to analyzing when post-conditions are not met 
    117  
    118   * '''designing''' - The implementer is designing it, that is, tries to decide How it should be done? 
    119    * pre-conditions: 
    120     * the post-conditions of analyzing  
    121     * work: 
    122      * designing is not only getting an idea of how to do it, but a detailed concept, 
    123      * for many tasks the design phase should take most of the time  
    124      * post-conditions - see below 
    125      * transitions: 
    126       * implementing if the reviewers decide, that the task is designed well 
    127       * designing if the reviewers decide, that the task needs better design, or does not satisfy the requirements 
    128       * analyzing if the reviewers or implementers decide that the task can not be done in acceptable time or have no idea how to do it  
    129  
    130   * '''implementing''' - The implementer makes an attempt to complete the task. 
    131    * pre-conditions: 
    132     * the post-conditions of designing  
    133    * post-conditions - see below 
    134     * transitions: 
    135      * done if 
    136       * the reviewers decide, that there are no any issues. 
    137       * the reviewers decide, that there are very minor issues which should be fixed later 
    138       * the issues are reported as bugs (or something) 
    139       * the leader agrees on this 
    140       * *note: it is usually better to face the reality, that it is just not done.  
    141      * implementing if the reviewers decide that the requirements are not fully satisfied 
    142      * designing if the reviewers decide, that the initial design will not do the work, and needs to be fixed. 
    143      * analyzing if the reviewers decide, that the task can not be done in acceptable time or quality.  
    144    
    145   * '''done''' 
    146    * when the task is really done  
    147  
    148   * '''testing''' 
    149    * pre-conditions: 
    150     * the task is in '''done''' phase 
    151    * post-conditions: 
    152     * transitions: 
    153      * done if  
    154       * the reviewers decide, that there are no more tests to be added 
    155       * the reviewers decide, that minor missing tests can be added later 
    156       * the leader agrees on this 
    157      * implementing if the reviewers decide that the requirements are not fully satisfied 
    158      * designing if the reviewers decide, that the current tests need to be fixed 
    159      * analyzing if the reviewers decide, that the task can not be done in acceptable time or quality. 
    160  
    161  * *Note that, failing a state (for example moving from implementing to analyzing because implementing failed) requires that the state of the product is reversed to the initial.  
     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. 
     119 * '''analysis accepted''' - the reviewer decides that the analysis of the task is correct 
     120 * '''designing''' - The implementer is designing the task or in other words tries to decide How it should be done? 
     121  * It is not compulsory but recommended that the design should be made by the implementer. 
     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. 
     127 * '''design accepted''' - The reviewer decides that the design of the task is correct. 
     128 * '''implementing''' - The implementer makes an attempt to complete the task. 
     129 * '''implemented''' - The implementer decides that the implementation of the task is ready. 
     130 * '''review''' - The reviewer look through the implementation to see if it is correct. 
     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. 
     134 * '''testing accepted''' 
     135 
     136 * Note that, failing a state (for example moving from implementing to analyzing because implementing failed) requires that the state of the product is reversed to the initial.  
    162137 
    163138You 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.