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.
Theis Kolab instance of Phabricator is holding the following types of projects:
* **Software Projects**: most projects of this type is related to one or more source code management repositories. The Maniphest tasks are entered and associated with these software projects. Example: #copenhagen
* **Role Projects**: This type of project is providing workboards and workflow for a group of users with the specific role (members of the project). Example: #product_owners
* **Sprint Projects**: These projects provide workboards and workflow for the development team working the timeboxed sprint. Example: #sprint_process_201516
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 #product_owners, #architecture_design and consumers of the //Kolab Groupware product// (stakeholders).
Stakeholders can be:
* Community members
* Kolab employees
* Paying customers
* Partners of Kolab Systems
* Subject Matter Experts
* Any other person or group with interests in Kolab
* A mix of all of the above
The Pre-Production process is an interaction between (corporate) Sales, #product_ownNOTE: See also the clarification of [[Community Collaboration]] about the interaction of community members in Phabricator.
#product_owners collect input from all stakeholders, and together with #architecture_designn the //Product Vision// is compiled. #product_owners collect input from all stakeholdersThis results in a list of (high-level) activities, and describe the incoming requests from consumers ofwhich are the //Kolab Groupware product//n formulated as user-stories, inentered as //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: See also [[Guidelines for creation of Tasks]].
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: iIn the beginning, @petersen is coaching the process. Finning 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_owners.
-* 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 in the top of his prioritized list 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: These 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 #sprint_xxx_next backlog in the order of priority. The needed effort is discussed. This evaluation results in the assignment of storypoints, and the tasks are assigned to a developer (if possible). Although the task can be assigned to a specific developer, the sprint backlog and all the tasks therein is the responsibility of the complete sprint team.
NOTE: "Storypoints" is a method of describing the measure of the effort needed to resolve a given task. Rather than estimating the amount of time expected to be needed, a storypoint measure is taking the complexity, the collected knowledge and the effort needed for other tasks in the stack. During the sprint preparation, the team select a reference task from the stack (usually the simplest) and give that e.g. 3 points. Then pPoints are then given to the rest of the tasks in the stack following the Fibonacci sequence (1,2,3,5,8,13,21..) and relating these to the reference task.
NOTE: An amount of effort in every sprint should be reserved for interruptions.
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 impediments 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 impediment 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 steps in the sprint workboard.
In the end of a sprint, the #scrum_masters facilitate the sprint retrospective. The development 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. 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 (if it is not already there).
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.
#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.
**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.
* **Architecture & Design**:
* **Scrum master**:
* **Process Managers**:
**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 in the stack.