WARNING: This is a wiki used as a scratch-book. This version of the development process is being worked on actively, and are considered to be a draft. The authoritative documentation for Kolab Groupware lives at https://docs.kolab.org.
The purpose of this document is to describe the processes related to product development at Kolab systems. This includes the following three parts:
# Pre-Production (Sales, Product Management and Architecture & Design)
# Production (Development)
# Post-Production (QA, Release Management and Service)
The description will be detailed to a certain extent, but more details will be written out in appendix or in specific documents.
NOTE: See also the clarification on the terminology [[Product, Project and Teams]] and their use in Phabricator.
The Pre-Production process is an interaction between (corporate) Sales, #product_owners, and #architecture_design. #product_owners collect input from all stakeholders, and describe the incoming requests from consumers of the //Kolab Groupware product// as user-stories, in //Maniphest Tasks// and make sure that they are associated with the #product_owners workboard. The workflow of the #product_owners workboard help the #product_owners facilitating the conversation with #architecture_design and #qa. It consist of Incoming, In_Triage, Ready, and Done:
* **Incoming** When tasks has only just been created, and no other action has been taken yet, they are in this state.
* **In_Triage** This state is holding tasks in the process of clarification and prioritizing (Triage). This is where tasks are being exploded and separated into smaller more workable tasks. The actual **Software Projects** are determined and associated, technical details are added by #architecture_design, and user-stories and test-cases are defined and approved by #qa.
* **Ready** Tasks in this state are ready to be associated with a sprint.
* **Done** Tasks has been through a sprint, they have been build and packaged, and the resulting packages are available to #release_management.
NOTE: Phabricator is set up with **Software Projects**, most of which relate to one or more source code management repositories. The Maniphest tasks are entered and associated with these software projects.
The #architecture_design team evaluates the tasks technically during the triage, clarify the requirements with the #product_owners and separate them into workable sub-tasks. Every task must hold at least one test-case for a verifiable user story. These test-cases will be following the task all the way through the process and are a vital part of the deliverable measurement and documentation of the task and in the end release. To ensure the testability, #qa will evaluate the test-cases. If a test-case is not useful, #qa will require the task to be re-evaluated.
This evaluation is normally a part of the backlog grooming by sprint participants, but in such normal situations, the sprint participants are usually also involved with a mere one software project.
The evaluation is best done by a team in a single room. The Kolab development teams however are not in a single location, so the backlog grooming will have to happen on-line. Such grooming is done in preparation for sprints, so focussed on the future sprint backlogs, and not taking place as a general activity for the ~112 software project backlogs normally referred to as "product backlog" in Scrum terminology.
NOTE: in the beginning, @petersen is coaching the process. Focus is on the following perceived challenges:
* The #product_owners must ensure to keep collaboration with all stakeholders.
* The #product_owners must facilitate, that that views from #architecture_design, #qa and where needed others, are included in each task during triage.
* Every task must contain a test-case or a verifiable user-story before it can be accepted as "Ready" from the #product_owner.
* During triage it is determined for each task if:
# it could be decided the feature is a small task and needs no review (it is ready to be included into a sprint)
# the feature is an epic (involves many components, complexity, ... etc.),
# the user-stories are problem-descriptions and not just a desired solution, but they are complete, and understandable for developers and #qa.
The #product_owners prioritize the tasks, and associates the tasks with the next sprint (by adding the next sprint to the task using hash-tags `#sprint_desktop_next` or `#sprint_server_next`).
This lists the tasks in a **sprint** backlog based on priority. It is then up to the sprint participants (currently still occupied with the current sprint, while the backlog for the next sprint is being filled) to ensure the backlog for the next sprint is appropriately groomed.
Production starts with sprint planning. The team get together on-line, and look at the sprint backlog (the backlog for the `#sprint_desktop_next` or `#sprint_server_next`).
NOTE: The former two sprint links are dynamic -- they refer to the actual next sprint tags, such as: #sprint_desktop_next and #sprint_server_next.
The #scrum_masters facilitate an evaluation of the tasks in the backlog in the order of priority. The needed effort is discussed. This evaluation results in the assignment of story points, and the tasks are assigned to a developer (if possible).
An amount of effort in every sprint should be reserved for interruptions.
In the beginning, the team will have difficulty figuring out exactly how to assign story points, and how many story points they can do in a sprint, but after just 2 sprints, it will improve considerably.
During the sprint, the #scrum_masters facilitate the daily standup call. In this call team members inform the rest of the team about the status of their work and which obstacles they encounter ("What did I do yesterday?" and "What do I plan to do today?"). It is the job of the #scrum_masters to work on and eliminate any obstacles if possible.
The sprint projects are configured with the sprint workflow; the states of: Backlog, Doing, Review, Done:
* **Backlog** is holding tasks that are selected for this sprint, but not being worked on yet.
* **Doing** is holding tasks that is actively being worked on by a developer (the assignee).
* **Review** is holding tasks where coding is done, but test case needs to be run [..and code review?].
* **Done** is holding tasks where the resulting code has been committed, and included test-cases has been successfully run.
As developers are working on tasks, these are being moved across the workflow columns in the sprint workboard.
In the end of a sprint, the #scrum_masters facilitate the sprint retrospective. The team get together on-line and show as much of the working software written during the sprint as possible by running through the included test cases [screen sharing facility or similar would be really good]. The status of the sprint documentation (burndown/burnup charts) is recognized and the velocity (the number of story points done in the sprint) is decided for the coming sprint.
When tasks are exiting a sprint in the status Done, there are one or more commits connected to each task, which resolve the issue (and successfully run through the included test-case) described in the task. These tasks are forwarded to #quality_assurance, by adding #quality_assurance to the task.
The relevant components are packaged, and packages are made available to #quality_assurance. If the packages pass #quality_assurance [simple workflow], they are handed over to #release_management, who will label them as releasable. They are however not released until all stakeholders (needs to be determined) agree to the release. The #product_owners facilitate this decision, and must
#support is added to the tasks for access to the test-cases. This makes it possible for #support to create and improve HowTo and FAQ documentation.
[?? maintain working VM from the latest releasable versions]
**Epic**: The top umbrella item in the backlog. Is covering several stories and tasks. Epics can not be estimated as a complete entity. Only after estimating the smaller pieces together an estimation can be done.
**Product Owner**: The role responsible for the link between the customer and development. The product owner is creating the product backlog and prioritizing it.
**The definition of Done**: When the test-case for a certain task is being executed successfully, and the code resulting in the "fix" has been committed to git, the task can be moved to **Done**.
**Project (in Phabricator)**: "Everything" is a project in the phabricator terminology. The projects are assigned to tasks (rather than the other way around) by adding the project hash tag to the task. We operate with the following types,
* **Software Projects**: One per software component or git repository (such as #copenhagen). They are associated with tasks related to this component. The software projects has no workflow. They lanes in the workboard describes the available versions in a forward directed manner.
* **Role Projects**: One per role in the process (such as #product_owners). When a person is given a role, they are added as members of the Role Project. Role projects has a workflow which is custom to the needs of the role.
* **Sprint Projects**: One per sprint (such as #sprint_server_201513). Tasks added to the Sprint Project is work that is planned for execution. Therefore the Sprint Projects has a workflow (described elsewhere in this documentation).
**Story points**: A number of points that describes the amount of effort needed to complete a certain task. The effort of a task is measured against the effort of the other tasks.