Sophie 2.0 Process

Т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).

This should improve the situation with the following challenges:

• Internal quality (quality of code)
• External quality (quality of the visible product)
• Documentation reading (many things are written, few things are read)
• Not to produce too much process overhead

Rules

This is a list of rules you have to follow. It is not final yet, but disobeying them may lead to penalties.

General

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!

• 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!

• 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!

• 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)

• 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!.

• 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 (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.
• 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.
• 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

• 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!

• 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.
• There is no "How to make the next generation desktop publishing software"!

Discipline

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. Our workday starts at 09:30 am.

3. You may work from home, or from other locations, but with the approval of the team leader.

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 REPORTS page to learn how to write reports.

Task In Time

1. Integrate continuously.

• Do not hold a source code very long (or prolong the task).

2. 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.

3. 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.

4. It is recommended not to design/implement a task which analysis is written by you.

SCRUM

We are continuing to use SCRUM (info at ​http://en.wikipedia.org/wiki/SCRUM). What is new, is that:

• Becoming much more strict (and unfortunately increasing the process overhead).
• Trying to have much higher quality.
• Hoping that the lost of speed will be compensated by non lost of momentum (that we usually suffer from).
• The sprint backlogs will be wiki page (ITERATION_01).
• The four states of a story/task are:
  • to [analyzing, designing, implementing, testing]
• Each passing between states requires a review.

We create the internal backlog which should track:

• Impediments backlog
• Documentation backlog
• Smells
• Open Questions

Here is the document: ​Backlog

Task States

Each taken task in the current sprint should pass trough the following phases:

• new
  • task is waiting to be taken, and someone to determine What should be done?
• analysis started
  • to learn how to write good analysis, see Platform Standards Analysis
  • there should be at least one example how to do one or more things that should be done.
  • It should take not more than 0.25 of the task effort.
• analysis finished
  • It is already determined what should be done.
  • the task is waiting for review (Wait for the review of the analysis before starting the design otherwise your work can be for nothing!)
• review
  • the reviewer look through the analysis to see if it is correct
  • the analysis should apply to its template
• analysis ok - the reviewer decides that the analysis of the task is correct
• design started
  • The implementer is designing the task or in other words tries to decide How it should be done?
  • It is not compulsory but recommended that the design should be made by the implementer.
  • It is recommended that the design should not be made by the analyzer of the task.
  • Designing is not only getting an idea of how to do it, but a detailed concept, step by step.
  • For many tasks the design phase should take most of the time.
• design finished
  • It is determined how the task should be done.
  • It is designed and is waiting for review.
• review
  • The reviewer look through the design to see if it is correct.
  • The reviewer can imagine himself as an implementer and see if he/she can implement the task following the design without problems.
• design ok - The reviewer decides that the design of the task is correct.
• implementation started
  • The implementer makes an attempt to complete the task.
  • He/she should follow the design strictly.
  • He/she should write in Implementation section of the task the result of the implementation.
• implementation finished - The implementer decides that the implementation of the task is ready.
• review - The reviewer look through the implementation to see if it is correct.
• implementation ok
  • The reviewer decides that the implementation of the task is correct.
  • The implementation section must be filled.
• test started - There should be appropriate tests written for the task.
• test finished - Testing state is done, waiting for review
• review
  • the reviewer looks for missing or wrong tests.
  • if there are any, the reviewer may decide they can be added later.
  • if they are too important or wrong they should be fixed - the review fails.
• test ok

• Notes
  • 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.
  • The transitions of each state are defined in Workflow diagram.
  • 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 SCS_ISSUE_TRACKER_SETUP_R1 for more info about our issue tracking.

Task Tips

• Implementing a new external feature (visible from the user):
  • analyzing
    • should have a specification, and a manual testing scenario
  • designing
    • write an automatic test/tests which verifies that your feature is working
    • look at the related code
    • decide what needs to be added
    • if you add new library feature
      • write use case tests for it
    • You may also write skeleton types (only declaration) and demos
      • write an outline of your design.
    • implementing
      • Make all the designed things work.
      • Ensure that all tests pass.
      • During the process, add more tests.

• Researching about a technology or library
  • analyzing - specify what needs to be researched
    • what the research will solve
    • what is needed to be solved (this is important)
  • designing
    • You can try things, but do not pollute the main source (for example with libraries).
    • If you need to use other libraries, do it in another project (or in another branch)
    • 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.
  • implementing
    • You present the written results / conclusions of your research, demo codes, etc.
  • reviewers - 1-2 developers

• Implementing a new internal feature (a library or something, not directly visible).
  • analyzing - what the library will provide
  • designing - should include:
    • use case tests,
    • samples,
    • (in some cases demo),
    • design outline
  • implementing
    • the library should be implemented
    • enough tests should be written during the process
  • reviewers: 2 developers

• Performing some structure changes, or refactoring.
  • analyzing - what the issues are
  • designing - understanding it, and providing an idea how to fix the issues
  • implementing - fixing the issues
  • reviewers: 1-2 developers

• Writing a specification
  • analyzing - what needs to be specified
  • designing - brief ideas about the thing
  • implementing - writing the specification exactly
  • reviewers: - 1 qa + 1 developer

• Doing documentation.
  • analyzing - what needs to be document
  • designing - what it will contain (outline) and understanding of the content
  • implementing - adding the appropriate content.
  • reviewers: - 1-2 team members

• External testing (the usual testing task).
  • analyzing - has to state what the focus of the tests will be.
  • designing - has to select test scenarios, and make new if necessary.
  • implementing - should apply testing scenarios and provide bugs and recommendations (things that probably the users will like/dislike).
  • reviewers: 1 developer

• Fixing a bug.
  • analyzing - what the bug is. needs a manual testing scenario (in bugzilla)
  • 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
  • implementing - fixing the bug, making the tests pass, and some refactoring
  • reviewers: 1 QA and 1 developer

Templates for logging specific task kinds should be added.

Roles

• leader - someone assigned to do the management (default: milo)
• implementers - the workers on given task
• reviewers - someone, which is assigned to review something.
  • the reviewer and the implementer may not intersect!

Comments

You can put your comments here.

Links to this Page

BackLinks?