openerp-dev-web team mailing list archive

[Navrang Oza <noz@xxxxxxxxxxx>]

Hello Team,

Please try to follow the way of working mentioned over here.

Support tools
=============

We'll be using the openerp instance on http://openerp.my.odoo.com to
track everything, it's the new project management module, which is
made of 3 main sections (for us):

* scrum / product backlog

* tasks

* scrum / scrum meetings


The product backlog (everybody)
===============================

The product backlog is basically the future of the product. All things
that could/would be interesting should be dumped there, clearly if
possible. Later on, they're triaged and prioritized, and turned into
tasks to accomplish.

*Anybody* can add stuff to the product backlog. That includes
functional teams and dev teams, both in India and in Belgium. Ideas
can be good or bad, accepted or rejected, but they should go into the
backlog anyway, and be as clear as possible.

Sprint planning & sprint backlog (tasks) (belgium)
==================================================

A sprint is a period of two weeks during which work is done. It's
simply used to split the whole backlog into more manageable
iterations.

The sprint planning is done before the start of a new sprint (on
Friday), and the goal is to decide what will be done during the next
two weeks.

Spring review
-------------

The first part of the meeting is to review what's been done during the
ending sprint, have a presentation/demo of what was achieved (done and
verified tasks) and to reevaluate and re-prioritize tasks that
weren't/couldn't be done (for whatever reason, maybe not enough time,
maybe some preconditions were missing, maybe direction changed).

Also, understand why things couldn't be done, and what can be improved
in belgium or india or whatever (or what can be improved even if all
things were done, there are always things that can be better).

Daily meeting (india)
=====================

Should be informal, everybody standing, and should last no more than 5
or 10mn.

Goal is simply to know that everybody can work and that nobody is
blocked.

Everybody in team should answer 3 questions:

* what he worked on the day before

* what he's going to work on today

* if there is anything blocking him (either preventing from getting
 the tasks of the day before done, or something blocking for the
 current day).

What was said during the meeting should be encoded in a new "scrum
meeting" item, probably by noz.

When xmo starts his day, He'll try to check the meeting of the day and see
if he can help unblocking anything, or get information from other
people in belgium, or whatever.

Meeting should be done early in the morning, but after everybody has
arrived. Maybe around 30mn after everybody is there, so members of the
team can have a coffee and get their bearings (check the tasks
available and decide what they're going to work on, stuff like
that). Is really to get everybody started with the day, no pressure.

.. note:: The scrum meeting section of module is probably going to
   change quite a bit in the future (because qdp had lots of critics
   for it since he has many in team), so it's easier to fill and less
   messy, ideally it should work better soon.

Working with & on tasks (web team)
==================================

Unless there is only one person who can do the job, neither you nor me
should assign tasks to team member, it turns out: they should do that
themselves.

When a team member (us included) has "nothing" to do, he should:

* Go into "tasks", look for a task he wants to/can work on

* Assign the task to himself (so others know who's working on it, and
 not two persons working on same task)

* Mark task as open

* do work and log working hours (e.g. when starting work on an other
 task, or going for the day)

Web interface doesn't really work for tasks right now so I can't
check, but there might be task stage and state to play with.

Team mailing list (``openerp-dev-web@xxxxxxxxxxxxxxxxxxx``) can be
used to warn of problem or ask question or anything.

Also note that documentation should be written for new stuff & all,
ideally. We'll probably start doing this over time (also, tests).

Finishing & validating tasks
============================

Once task is done, team member should:

* mark task as done, status will be be checked through backlog

* push code in a personal branch on launchpad (note: can be done
 before, during work, if wants or if two working together on task)
 [#]_

* create a merge proposal to branch trunk-dev-web (not trunk), and ask
 review from ``openerp-dev-web`` (default is ``openerp``, is no good,
 with ``openerp-dev-web`` email should be sent to team mailing list
 that way everybody knows there is merge proposal to review and can
 keep track of things merged or not). Person to ask is in Extra
 Option, under box for description.

 Merge proposal should always have good description, based on task
 that was solved and explanations if decisions were taken. I think I
 already spoke about that in my previous mail.

* developer can start working on another task

Merge proposal will be used for discussion: team members should check
other people's merge proposals from time to time, set review (approve,
needs fixing, disapprove, abstain, ...) and say what they think if
needed.

If reviews are "needs fixing", developer should consider if they agree
with request, if they don't say why (not all needs fixing requests are
good, after all), if they do fix branch, push again and say it's
fixed.

Once needs-fixing are solved and 2-3 persons in team approve, branch
is merged into trunk-dev-web. Warning here: merge message should be
*very* clear or nobody will be able to understands in branch, and then
it's mess. If multiline merge message necessary, then do multiline
merge message, is ok. Because trunk-dev-web will be mostly merge
messages, so if only messages are ``[MERGE] merge`` then is useless.

Retrospective (india, mostly)
=============================

The last friday of the sprint, around early-mid afternoon (during
belgium morning or mid day) team should get together and consider how
ending sprint happened:

* What are the things that went well?

* Are there things that could be improved for next sprints?

Should be sent to me, so I can read and think about it it for sprint
planning meeting, and know what team thinks and what could be done
better.

If nothing to say, ok, but if things to say, it's important, I need to
know. Goal of this meeting is to make job easier and better for
everybody, so don't worry.

Outside of tasks
================

As said all above, I'll only be planning 75% full days. Developers
should have a bit of spare time so they can do stuff on the side:

* Keep up with news, read coding guidelines, write documentation,
 things like that.

* Plan and discuss stuff with one another, or with other teams

* Do code reviews, all team members should do a bit of code review so
 they see code of other members and say what they think and everybody
 can know a bit of everything and improve and know everybody is
 important

* Read, triage and fix bugs, bugs on launchpad are not always in
 backlog (but sometimes is), yet should still be fixed.

 Note that bug fix can be done (and pushed) directly in
 trunk-dev-web, unless very complex bug hard to solve, but all tasks
 (even small) should be done in branch, I think.

* Maybe other stuff that's needed and I haven't thought of.

.. [#] not really, don't call cops

.. [#] ideally, personal branch should be checked to merge easily with
      current team branch (trunk-dev-web), if personal branch was
      never pushed to, it can be rebased on trunk-dev-web and then
      pushed.

      Team members should remember to push with stacked or branches
      will take a long time to create, with stacked it's fast. There
      is also a way to use *bzr send*, but I think you need GPG key
      and a bit of setup. And Apple Mail doesn't do GPG keys well so
      I couldn't test plus I tried when still using old repository
      format so everything broken.

.. _rst2a: http://rst2a.com/create/type/