How we work
Every project starts with a requirements workshop. This workshop allow s us to define the problem statement and an initial list of use cases (or User Stories) that will be developed during the life of the project. With the Use Case list we perform an effort estimation based on Use Case Points. This technique, derived from Function Point estimation, drives the effort (in hours) required for a software project, considering the number and complexity of use cases and actors, non-functional requirements and the development environment.
The problem statement and use case list are used as the starting point for the functional specifications.
Once the estimated duration of the project is known, the use cases in the list are prioritized in order to define the project planning.
As the project evolves, the problem statement and use case list are updated to keep track of changes and modifications to the project scope.
At the beginning of a project, a new directory is created on our internal version control system (Subversion). This directory contains three sub-directories: trunk, tags and branches. The trunk will contain the main development line. Tags, holds the tags that are created at the end of every iteration. Branches, is used to create code branches for bug fixing or to experiment with architectural changes when necessary.
If the customer has a subversion server, the synchronization of both servers can be arranged.
A new project is then created in our issue tracker (Redmine). The defined use cases are created as new tasks and assigned to the project leader. Milestones for the project are defined, and the use cases are assigned to milestones.
Three environments are created for every project:
• A development environment, which integrates the work from all the team
• A test environment, where the automated and manual test are performed
• A demo environment, which is updated at the end of each iteration, so that acceptance testing can be performed.
Once the project structure is defined continuous integration server (Jenkins) is configured for the project.
Based on the initial scope definition, a site/application navigation map is created and a non-functional prototype too. This prototype has two goals: to validate the application concept to ensure we understood what the customer wants and to be a starting point to work the look & feel and usability aspects of the application.
Depending on the project size, 2 to 3 weeks iterations are defined.
At the beginning of every iteration a planning meeting is held to define the goals in terms of code and functional specifications.
Use case priorities are reviewed. If additional use cases where created while writing the specifications, the affected documents are updated and the use cases are added to the issue tracker. The use cases a divided into tasks that can be performed in less than one day and assigned to team members.
At the beginning of each day, after the stand-up meeting, developers update their working copy of the code and start working on their assigned tasks. When a task is finished the developer has one of his peers to review his code.
At the end of the iteration the team verifies the quality of what they have built, a tag and branch is created in the control version system, and the new functionality is deployed in the demo environment so that the customer can start the acceptance testing.
The customer reports defects in the issue tracker and after discussing priorities with the development team, defects are scheduled for their resolution.