View source | Discuss this page | Page history | Printable version   

Development Process Management



What follows is an explanation about the Openbravo development process from a management perspective. The following are targeted goals for the development 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

Task life cycle

The Openbravo project is hosted on 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:

  1. Bugs: Errors that prevent Openbravo ERP from behaving as intended (eg. taxes are erroneously calculated, user interface does not follow guidelines, etc.).
  2. 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.)
  3. 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:


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".


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.


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.


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.


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:


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.


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.


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.

Retrieved from ""

This page has been accessed 30,306 times. This page was last modified on 2 February 2010, at 07:52. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.