Development Process Management
| Languages: |
English | zh cn | Translate this article... |
Contents |
Introduction
What follows is an explanation about the Openbravo development process from a management perspective. The following are targeted goals for the development process:
- to be as efficient as possible while getting the best from our resources
- to make it easier for our community to collaborate with us
- to be transparent in order to manage what you can expect from our work
- to get feedback from you about how to improve the process
Openbravo has a growing development team formed by talented people is but still limited in terms of resources. Nevertheless, we have a pretty ambitious roadmap full of cool features. Also we understand that quality is a must in an ERP product so bug reporting and fixing is a critical task. Putting it all together results in a simple management rule: we have more to do than we can do so we have to PRIORITIZE. We have to be very organized and prioritize our efforts in order to deliver the most valuable benefits to our product. We believe in the "community driven" ideals as the best way to do that, so we have setup a set of tools -explained below- to get feedback from our community of developers and users. These tools also provide information about our activity: where our developers are allocated, what we will do next, when we plan to solve a specific issue, etc. We also want to continuously improve our development process so we are looking forward to your feedback about the management process itself.
Iterative Development
The Openbravo team does not strictly follow an Agile Methodology (such as XP or Scrum) but shares many of its principles. From a management perspective the most relevant principle is the iterative development in short iterations. Each iteration starts with the planning game where we define what features will be included and what bugs will be fixed. Then the development is carried out and tested. At the end of each iteration we package and release the software following the "release early and often" rule. The final step is a conclusion meeting to replan pending tasks and cover the lessons learned. This meeting usually overlaps the planning game of the next iteration.
Tracking Development Tasks
The Openbravo project is hosted on SourceForge.net and we use the great standard tools provided by this service to manage our development process. This section explains how to use the Trackers to create, monitor and query Development Tasks. A Development Task is an atomic -not divisible- activity that usually is done by just one developer. We use three different types of Development Tasks:
- Bugs: Errors that prevent Openbravo ERP from behaving as intended (eg. taxes are erroneously calculated, user interface does not follow guidelines, etc.).
- Feature Requests: Requests for new functionalities. Enhancement and modification of the current functionality is also managed as a feature request (eg. payroll management, enhancement of tax calculation, etc.)
- Other Tasks:Other activities not directly related to source code but still engineering tasks such as maintenance taks, documentation, etc. It is critical to manage all the tasks we have to do in order to properly planning our work.
For each type of Development Task there is a Tracker: a "Bug Tracker" (for Bugs), a "Feature Request Tracker" (for Feature Requests) and a "To Do Tracker" (for Other Tasks). Following the typical life cycle for a Development Task the actions performed on it through the Trackers are as follows:
Create
Task creation is done by Openbravo community -Openbravo team included, of course- whenever the need arises: a new bug is identified, a new feature is clearly described, etc. Although the life cycle of all Development Tasks is very similar, the description of the Task is different regarding the type. For bugs there is a Bug_Reporting_Guidelines document with a full description of how to report a bug. As a rule of thumb for all types, be as clear as possible (let say, be water ;-)
Use "Category", "Summary", "Detailed description" and "Attached files" to clearly describe what the Task consists of. We don't use private Tasks so leave the "Private" field unchecked. "Assigned To", "Group" and "Priority" are used to manage the Task during its life cycle and are explained below. When creating a Task leave them with default values, except the "Group" field that should be set as "To be planned".
Prioritize
Once the Task is created it is analyzed by our Tracker Manager -who is continuously monitoring the Trackers- and prioritized. For bugs we have a public rule of prioritization described in the Bug Reporting Guidelines. For feature requests we plan to prepare a voting mechanism to better understand what our community wants. For other Tasks prioritization usually does not work since they are "to do" tasks such as maintenance. We use this priority to plan our iterations as explained below.
Update
Sometimes the individual making the submission does not agree with the priority assigned by our Tracker Manager. Often, more info is requested to completely understand the tasks. In all these cases these individuals -who easily can monitor the Task- are able to update the Task adding new info that could help us in the next steps.
Plan
As explained previously Openbravo works in an iterative way, planning the work in iterations. We usually have between 8 to 12 iterations per year. As explained, when the iteration starts we decide what tasks will be done -of course using the priority- and who will do what within the iteration. We use the "Group" to define iterations. We create two Groups for each iteration: first Group is for Developers (what to develop) and second Group is for QA (what to test). For example, the iteration for release R2.30 beta has two Groups: "R2.30 beta" and "R2.30 beta - tested". The Tasks included in the iteration are assigned to the "Group" for Developers.
Many projects in SourceForge use the Group field in a different way. In those projects the Group is the code version where the bug is identified. We prefer to describe the whole environment (version code, operative system, database, browser) within the "Detailed description" field and use the Group for planning. The "Assigned To" field sets the developer responsible for completing the Task.
Within the iteration Openbravo developers work on their Tasks sorted by priority. Of course we try to complete all the planned tasks as well as the urgent ones that arises during the iteration such a critical bug. But some times we are not able to complete all of them. In those cases, if the Task is not essential for the iteration, we leave the task undone and assign it to the "None" Group. It will be planned in the next iteration.
Close
Once the Tasks is completed by the developer -including design, development, unit test and commit changes to SVN- he closes the Task by updating the "Status" field to "Closed" and the "Resolution" field to one of the next:
- Fixed: the bug is fixed, the new feature is done, etc. A comment is attached with explanations as needed about the resolution.
- Duplicate: the Task already exists or is a subset of an existing one. A comment is attached pointing to the existing Task.
- Works for me: just for bugs. Developer has not been able to repeat it. A comment is attached explaining that it works in the development environment (main Trunk of SVN).
- Rejected: the requested Task is rejected. A comment is attached with a CLEAR explanation about rejection reasons.
Test
Once a developer closes a Task, the QA team double checks to ensure that the Task is properly completed. If it is not they change the "Status" to Open and attach a comment with a CLEAR explanation about why the Task is reopened. If the check is ok they update the "Group" to the tested group for that iteration.
Monitor
Anyone can, at any time, actively monitor a Task. When you monitor a Task you receive an email for each change in the Task (Priority, Status, Group, ...) with an explanation about the change and a link to the Task management form. Typically all those making submissions should monitor the Tasks they submit. Also developers could monitor their assigned Tasks so they are aware of any update to them. Our QA team could monitor Tasks that does not pass the quality check and are returned to Development.
Conclusion
SourceForge is the tool used to manage tasks that are going to be performed by Openbravo team. So whenever anybody wants to tell the team to do anything he/she should first look if this task has been previously submitted. In case it has not, a new task should be reported trying to be as clear as possible in its description.
Working this way will make it possible to base the Openbravo Development team´s work on SF allowing the Community to know what we are currently working on, what we have already completed, and we have planned to be achieve next.