Changes between Version 33 and Version 34 of PROCESS


Ignore:
Timestamp:
01/06/09 19:53:00 (16 years ago)
Author:
pav
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • PROCESS

    v33 v34  
    3737 * Main team - responsible for Main and End Product categories. 
    3838 * Server Team - responsible for Supporting, SCS and S2S categories. 
    39  * Release Team - responsible for the releases and the reviews of the implementation phases(See [wiki:PROCESS#Workflow]). 
    40 Note: The categories are described in the work breakdown structure: [source:/manage/sched/sophie2_wbs.py]  
    41 == Rules ==        
    42  
    43 This is a list of rules you have to follow. It is not final yet, but disobeying them may lead to penalties. 
    44  
    45 === General === 
    46  
    47  1. Work towards the goal! 
    48  * 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. 
    49  * You have to work towards the goal. 
    50  * When you work on something, you have to understand why and how it is related to our goal. 
    51  * You have to try to drive the whole team towards the goal (no one alone is capable of reaching it). 
    52  2. Be honest! 
    53  * You have to present the situation to the leader as is. 
    54  * Do this, even if it does not look good. 
    55  * For example, if you have no idea how to make something, don't say "almost done" to the leader.  
    56  3. Take initiative! 
    57  * If you find a way that you can make something better for the team, don't wait but propose that it to be done.  
    58  4. Look around! 
    59  * If you see problems in the code, in the product, in the organization, or whatever, announce them. 
    60  * Try to keep an eye on what other people do (either for things you can learn from, or for things they are doing poorly). 
    61  * Try to get a global vision of what is happening in our team.  
    62  5. Seek improvements (for yourself and for the team) 
    63  * 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). 
    64  * Improving and learning is your responsibility. 
    65  * 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.  
    66  6. Seek the most appropriate solution! 
    67  * There is no perfect code. There is no perfect solution (or even if there is it is not reachable). 
    68  * 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. 
    69  * 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. 
    70  * What we should do is to seek something between just making it work and making it perfect, but closer to perfection than just working. 
    71  * That is, seek a good solution.  
    72  7. Quality is not negotiable! Scope and resources are 
    73  * 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. 
    74  * We are not allowed to reduce quality!  
    75  8. Accept the challenge! 
    76  * We are not doing the next Store Information System, the next Lawyer's web site, nor the next database module for big company X 
    77  * What we are doing is something that only few companies in the world can do, and even many of them are not good enough. 
    78  * There are no instructions on "how to make the next generation desktop publishing software"!  
    79  
    80  
    81 === Discipline === 
    82  
    83  1. You have to try to follow the process as much as possible. 
    84  * Self-discipline is needed. 
    85  * 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).  
    86  
    87  2. Our workday starts at 09:30 am sharp. 
    88   
    89  3. You may work from home, or from other locations but only with the approval of the team leader. 
    90  
    91  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. 
    92  
    93 === Task In Time === 
    94  
    95  1. Integrate continuously. 
    96  * Do not hold source code for very long (or prolong the task).  
    97  2. Time box to 150% the estimate. 
    98  * If you see that you are about to exceed the estimated time, warn the leader immediately. 
    99  * 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. 
    100  * A task reaching 150% (or 200% if the leader agrees) of its estimate should be dropped, even if it is 99.9% complete.  
    101  3. Do not start implementation phase of a task if the design phase is not reviewed yet! 
    102  * Wait for the review of the design, otherwise your work will be for nothing. 
    103  4. It is recommended that no one design/implement a task for which that person wrote the analysis.  
    104  
    105  
    106  
    107 == Task States == 
    108  
    109 Each taken task in the current sprint should pass trough the following phases: 
     39 * Release Team - responsible for the releases and the reviews of the implementation phases(See [wiki:PROCESS#TaskStates]). 
     40For now the analysis and design reviews are made internally in the team. 
     41 
     42Note: 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. 
     43 
     44== Team Roles == 
     45For 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 * be responsible for the progress of his/her team on the progress checks (see ?) 
     47 * represents team members on the weeklies if they are not present 
     48 * gives adequate tasks to the team members if they don't know which to take 
     49 * helps the team members if they have questions and obscurities or directs them to the person who can help them. 
     50 
     51The Release team has an internal process described in http://sophie2.org/trac/wiki/ITERATION_03/Release/Process. 
     52 
     53 
     54== Workflow === 
     55 
     56Each taken task in the current sprint should pass trough the following phases described in this diagram: 
     57[source:/trunk/sophie2-platform/doc/uml-design-diagrams/workflow.png] 
     58 
     59=== Task States === 
     60These are the states descriptions: 
    11061 
    11162 * new 
    … …  
    157108  * 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. 
    158109 
     110 
     111== Rules == 
     112This is a list of rules you have to follow. It is not final yet, but disobeying them may lead to penalties. 
     113 
     114=== General === 
     115 
     116 1. Work towards the goal! 
     117 * 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. 
     118 * You have to work towards the goal. 
     119 * When you work on something, you have to understand why and how it is related to our goal. 
     120 * You have to try to drive the whole team towards the goal (no one alone is capable of reaching it). 
     121 2. Be honest! 
     122 * You have to present the situation to the leader as is. 
     123 * Do this, even if it does not look good. 
     124 * For example, if you have no idea how to make something, don't say "almost done" to the leader.  
     125 3. Take initiative! 
     126 * If you find a way that you can make something better for the team, don't wait but propose that it to be done.  
     127 4. Look around! 
     128 * If you see problems in the code, in the product, in the organization, or whatever, announce them. 
     129 * Try to keep an eye on what other people do (either for things you can learn from, or for things they are doing poorly). 
     130 * Try to get a global vision of what is happening in our team.  
     131 5. Seek improvements (for yourself and for the team) 
     132 * 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). 
     133 * Improving and learning is your responsibility. 
     134 * 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.  
     135 6. Seek the most appropriate solution! 
     136 * There is no perfect code. There is no perfect solution (or even if there is it is not reachable). 
     137 * 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. 
     138 * 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. 
     139 * What we should do is to seek something between just making it work and making it perfect, but closer to perfection than just working. 
     140 * That is, seek a good solution.  
     141 7. Quality is not negotiable! Scope and resources are 
     142 * 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. 
     143 * We are not allowed to reduce quality!  
     144 8. Accept the challenge! 
     145 * We are not doing the next Store Information System, the next Lawyer's web site, nor the next database module for big company X 
     146 * What we are doing is something that only few companies in the world can do, and even many of them are not good enough. 
     147 * There are no instructions on "how to make the next generation desktop publishing software"!  
     148 
     149 
     150=== Discipline === 
     151 
     152 1. You have to try to follow the process as much as possible. 
     153 * Self-discipline is needed. 
     154 * 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).  
     155 
     156 2. Our workday starts at 09:30 am sharp. 
     157  
     158 3. You may work from home, or from other locations but only with the approval of the team leader. 
     159 
     160 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 
     162=== Task In Time === 
     163 
     164 1. Integrate continuously. 
     165 * Do not hold source code for very long (or prolong the task).  
     166 2. Time box to 150% the estimate. 
     167 * If you see that you are about to exceed the estimated time, warn the leader immediately. 
     168 * 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. 
     169 * A task reaching 150% (or 200% if the leader agrees) of its estimate should be dropped, even if it is 99.9% complete.  
     170 3. Do not start implementation phase of a task if the design phase is not reviewed yet! 
     171 * Wait for the review of the design, otherwise your work will be for nothing. 
     172 4. It is recommended that no one design/implement a task for which that person wrote the analysis.  
     173 
     174 
    159175== Task Tips == 
    160176