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 (``[email protected]``) 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/
_______________________________________________ Mailing list: https://launchpad.net/~openerp-dev-web Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-dev-web More help : https://help.launchpad.net/ListHelp
