Changes between Version 28 and Version 29 of PROCESS


Ignore:
Timestamp:
11/14/08 11:05:36 (16 years ago)
Author:
boyan
Comment:

--

Legend:

Unmodified
Added
Removed
Modified

  • PROCESS

    v28 v29  
    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. 
    23  * You have to try to drive the whole team towards the goal (no one alone is capable of reaching it)  
     23 * You have to try to drive the whole team towards the goal (no one alone is capable of reaching it). 
    2424 2. Be honest! 
    2525 * You have to present the situation to the leader as is. 
    … …  
    3838 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). 
    40  * 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. 
     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. 
    4141 * 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. 
    4242 * What we should do, is seeking something between just make it work, and perfect, but more close to perfect than just works. 
    … …  
    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  2. Our work-time for half-time working (all of us currently) is 09:30 to 13:30(vote for this) by default. 
    60  * 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. 
    61  * you can not shift more than the half of the working time 
    62  
    63  3. You have to make 20 working hours per week by default. 
    64  * This means 20 productive work hour not 20 hours staying in the office. 
    65  * 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).  
     59 2. Our workday starts at 09:30 am. 
    6660  
    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. 
    70  * Or at least you may not count more than 8 hours per day as productive time. 
    71  * This means, that you need to work at least 3 days per week in order to complete your time.  
    72  
    73  6. You should be present on our weekly meeting every Mondays on 09:30 AM. 
    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. 
     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. 
    7764 
    7865== Task In Time == 
    … …  
    9279We are continuing to use SCRUM (info at http://en.wikipedia.org/wiki/SCRUM). What is new, is that: 
    9380 
    94  * Becoming much more strict (and unfortunately increasing the process overhead) 
     81 * Becoming much more strict (and unfortunately increasing the process overhead). 
    9582 * Trying to have much higher quality. 
    96  * Hoping that the lost of speed will be compensated by non lost of momentum (that we usually suffer from) 
     83 * Hoping that the lost of speed will be compensated by non lost of momentum (that we usually suffer from). 
    9784 * The sprint backlogs will be wiki page ([wiki:ITERATION_01]). 
    9885 * The four states of a story/task are: 
    … …  
    10592 * Documentation backlog 
    10693 * Smells 
    107  * Daily Availability 
    10894 * Open Questions 
    10995 
    … …  
    114100Each taken task in the current sprint should pass trough the following phases: 
    115101 
     102 * new 
     103  * task is waiting to be taken, and someone to determine What should be done? 
    116104 * '''analysis started''' 
    117   * task is waiting to be taken, and someone to determine What should be done? 
    118105  * to learn how to write good analysis, see [wiki:PLATFORM_STANDARDS_ANALYSIS Platform Standards Analysis] 
    119106  * there should be at least one example how to do one or more things that should be done. 
    … …  
    133120  * For many tasks the design phase should take most of the time. 
    134121 * '''design finished''' 
    135   * The task is already determined how should be done. 
     122  * It is determined how the task should be done. 
    136123  * It is designed and is waiting for review. 
    137124 * '''review''' 
    … …  
    151138 * '''test finished''' - Testing state is done, waiting for review 
    152139 * '''review''' 
    153   * the reviewer looks for missing or wrong tests 
    154   * if there are any decides they can be added later 
     140  * the reviewer looks for missing or wrong tests. 
     141  * if there are any, the reviewer may decide they can be added later. 
    155142  * if they are too important or wrong they should be fixed - the review fails. 
    156143 * '''test ok''' 
    157144 
    158145 * Notes 
    159   * 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.  
     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.  
    160147  * The transitions of each state are defined in [source:/trunk/sophie2-platform/doc/uml-design-diagrams/workflow.png Workflow diagram]. 
    161   * 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 the 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. 
     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. 
    162149 
    163150= Task Tips = 
    … …  
    193180 * Implementing a new internal feature (a library or something, not directly visible). 
    194181  * analyzing - what the library will provide 
    195   * designing - should include 
     182  * designing - should include: 
    196183   * use case tests, 
    197184   * samples, 
    … …  
    223210 * External testing (the usual testing task). 
    224211  * analyzing - has to state what the focus of the tests will be. 
    225   * designing - has to select test scenarios, and make new if necessary 
    226   * implementing - should apply testing scenarios and provide bugs and recommendations (things that probably the users will like/dislike) 
     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). 
    227214  * reviewers: 1 developer  
    228215 
    … …  
    242229  * the reviewer and the implementer may not intersect!  
    243230 
    244 = Documents to read = 
    245 [wiki:ImportantDocs] 
    246  
    247231= Comments = 
     232''You can put your comments here.'' 
    248233 
    249234= Links to this Page =