Changes between Version 15 and Version 16 of PROCESS

Timestamp:

10/20/08 14:58:02 (17 years ago)

Author:

pavlina

Comment:

--

PROCESS

@@ -17 +17 @@
 == General ==
 
-1. Work towards the goal!
+ 1. Work towards the goal!
  * 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.
  * You have to work towards the goal.
  * When you work on something, you have to understand why and how it is related to our goal.
  * You have to try to drive the whole team towards the goal (no one alone is capable of reaching it) 
-2. Be honest!
+ 1. Be honest!
  * You have to present the situation to the leader as is.
  * Even if it does not look good.
  * For example, if you have no idea how to make something, don't tell "almost done" to the leader. 
-3. Be initiative!
+ 1. Be initiative!
  * If you find a way that, you can make something good to the team, don't wait, but propose it to be done. 
-4. Look around!
+ 1. Look around!
  * If you see problems in the code, in the product, in the organization, or whatever, announce them.
  * Try to keep an eye about what other people do (either for things you can learn from, or for things they are doing bad).
  * Try to get a global vision of what is happening in our team. 
-5. Seek improvements (for yourself, and for the team)
+ 1. Seek improvements (for yourself, and for the team)
  * 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..)
  * Improving and learning is your responsibility.
  * 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. 
-6. Seek the most appropriate solution!.
+ 1. Seek the most appropriate solution!.
  * There is no perfect code. There is no perfect solution also (or maybe there is, but it is not reachable).
  * 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.
@@ -42 +42 @@
  * What we should do, is seeking something between just make it work, and perfect, but more close to perfect than just works.
  * That is, seek a good solution. 
-7. Quality is not negotiable! - but scope and resources are
+ 1. Quality is not negotiable! - but scope and resources are
  * 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.
  * We are not allowed to reduce the quality! 
-8. Accept the challenge!
+ 1. Accept the challenge!
  * 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
  * What we are doing, is something that only few companies in the world can do, and even they are not good enough.
@@ -53 +53 @@
 == Discipline ==
 
-1. You have to try to follow the process as much as possible.
+ 1. You have to try to follow the process as much as possible.
  * Self discipline is needed.
  * 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). 
-2. By default, our work-time for half-time working (all of us currently) is 11:00 to 15:00.
+
+ 1. Our work-time for half-time working (all of us currently) is 11:00 to 15:00(vote for this) by default.
  * 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.
  * you can not shift more than the half of the working time
-3. By default you have to make 20 working hours per week.
+
+ 1. You have to make 20 working hours per week by default.
  * This means 20 productive work hour not 20 hours staying in the office.
  * 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). 
-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]]
-
-5. Unless having approval from the leader, you may not work more than 8 hours per day.
-          * Or at least you may not count more than 8 hours per day as productive time.
-          * This means, that you need to work at least 3 days per week in order to complete your time. 
-6. You should be present in at least 2/3 of the team meetings.
- * For one month, we usually have 10 meetings, which means you may skip at most 3. 
-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]]
-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 how much effort each activity takes. See report structure in the repository /manage/reports/0README.txt.
+ 
+ 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]]
+
+ 1. Unless having approval from the leader, you may not work more than 8 hours per day.
+ * Or at least you may not count more than 8 hours per day as productive time.
+ * This means, that you need to work at least 3 days per week in order to complete your time. 
+
+ 1. You should be present on our weekly meeting every Mondays on 10:00 AM (vote for this).
+
+ 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]]
+ 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.
 
 == Other ==
 
-1. SVN commits should have clear message!
- * no commits without message
- * if it is hard to state what the change is, then probably you are not working on one thing. 
-2. Integrate continuously.
+ 1. Integrate continuously.
  * Do not hold a source code very long (or prolong the task). 
-3. Time box to 150% the estimate.
+ 1. Time box to 150% the estimate.
  * If you see that you are about to exceed the estimated time, warn the leader immediately.
  * 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.
  * A task reaching 150% (or 200% if the leader agrees) its estimate should be dropped, even if it is 99.9% complete. 
-4. Do not commit bad code!
- * Generally, you should not commit before a review is passed!
-5. Do not start implementation phase of a task if the design phase is not reviewed yet!
+ 1. Do not start implementation phase of a task if the design phase is not reviewed yet!
  * wait for the review of the design otherwise your work will be for nothing.
+ 1. It is recommended not to design/implement a task which analysis is written by you. 
 
 = SCRUM =