Skip to content
This repository has been archived by the owner on Mar 1, 2019. It is now read-only.

Development Process (old)

Jump to bottom
Matthias Benkort edited this page Feb 27, 2019 · 1 revision

Development Process

Meetings

The team meets weekly on a fixed hour. Weekly meetings have the following goals:

  • Review, discuss and refine new issues that have been proposed.
  • Share retrospective on closed issues.
  • Expose development / resolution plans and progresses for ongoing tickets.
  • Share updates or news affecting the team (e.g. holidays, trainings).

Reporting

After each weekly meeting, a snapshot of the current efforts is dumped into:

weekly reports

These collects issues closed and in progress and provides computed time estimates delivery for milestones.

Software Development

Software evolutions are recorded in the form of architectural decision records. Those decisions are discussed with the team and gives an efficient and minimal way of documenting decisions and organizing the work. They are made of several sections completed at different stages. Part of the development may also include bug fixing.

ADR

ADR Template

|************| |**********| |**********| |*************| |********| |**********|
| New Issues | | Proposed | | Accepted | | In Progress | |   QA   | |  Closed  |
|------------| |----------| |----------| |-------------| |--------| |----------|
|            | |          | |          | |             | |        | |          |
|    ...    ---->   ...  ---->   ...  ---->    ...    ---->  ... ---->   ...   |
|____________| |__________| |__________| |_____________| |________| |__________|
  1. ADR is created, Context, Decision and Acceptance Criterias sections are filled-in.
  2. When ready, ADR is moved to "Proposed", added.
  3. During weekly meetings, ADR is reviewed by the team.
  4. If accepted
    1. Context, Decision & Acceptance Criterias are adjusted as needed.
    2. Estimate is updated1 by the team.
    3. ADR is moved to "Accepted", removed, added.
    4. Once selected2, ADR is moved to "In Progress", Assignees is updated.
    5. Shortly after, Development Plan updated & Estimate adjusted1 (if necessary) by assignees.
    6. PR & QA sections are updated by assignees during development.
    7. Once requirements are covered, ADR is moved to "QA", Assignees is updated.
    8. If accepted (by QA)
      1. ADR is closed, added.
      2. Shortly after, Retrospective is completed by assignees.
      3. During weekly meetings, retrospectives are discussed, removed.
    9. If judged necessary (by QA)
      1. ADR is moved back to "In Progress", assignees are notified, back to 4.v
  5. If rejected
    1. ADR is closed, removed, added.

NOTE1
If estimate is greater than or equal to 21, the ADR is rejected and should be split across smaller ADRs.

NOTE2
Only issues figuring in a an ongoing milestone can be selected. Milestones are defined and filled according to product needs.

Bugs

Bugs Template

|**********| |*************| |********| |**********|
| Accepted | | In Progress | |   QA   | |  Closed  |
|----------| |-------------| |--------| |----------|
|          | |             | |        | |          |
|    ...  ---->    ...    ---->  ... ---->   ...   |
|__________| |_____________| |________| |__________|
  1. Bug is created, Context & Steps to Reproduce sections are filled-in.
  2. Bug is moved to "Accepted", added.
  3. Once selected1, bug is moved "In Progress", Assignees is updated.
  4. Shortly after, Resolution Plan & Estimate are updated.
  5. PR & QA sections are updated by assignee during development.
  6. Once fixed, bug is moved to "QA", Assignees is updated.
  7. If accepted (by QA)
    1. Bug is closed, added.
    2. Shortly after, Retrospective is completed by assignees.
    3. During weekly meetings, retrospectives are discussed, removed.
  8. If judged necessary (by QA)
    1. Bug is moved back to "In Progress", assignee is notified, back to 4

NOTE1
Only issues figuring in an ongoing milestone can be selected. Milestones are defined and filled according to product needs.

Note on Estimates

When discussing a proposal, engineers are expected to give an estimate for a ticket in terms of points. Points aren't equal to days. Instead, they represent a value upon which the team will build a common understanding. 8 points for a team might mean 25 days of work; it might mean 2 days for another.

So, instead of giving time estimates that are somewhat hard to come up with, the team is asked to give an estimate of the task difficulty. ZenHub then gives us tools to measure the team velocity and to give time estimates according to the past. Results should become more and more accurate as the team become better at breaking down tasks and assessing their difficulty.

In addition, the team is invited to use dedicated apps for point assignation to prevent members from influencing each others, for instance:

https://www.pointingpoker.com/

Clone this wiki locally