Development workflow

Our development workflow represents a series of iterations that are outlined in the project commencement phase. Each iteration includes planning, requirements analysis, design, coding, testing and stable release (optional). After each iteration we review the project with the customer, reassign its priorities and plan the next iteration.

An iteration would include several consecutive stages that would involve constant feedback to and from the client.

Specification discussion

Development workflow diagram

A business analyst discusses initial specification outline with the customer and then submits the draft to the shared Wiki environment. This is where the spec will be reviewed and finalised by developers, business analysts and the client.

Wiki is a collaborative environment of structured web-pages where all issues related to a project can be discussed using simple mark-up language.

A separate, 100% secure Wiki instance is set up for each project to facilitate development and discussion process. Our preferred tools are TWiki and JSPWiki (both have an excellent track-record), though any other option is possible, including project discussions in customer’s environment.

Another option for specification and project discussion is establishing a Drupal environment. Drupal is a powerful content management platform best suited for complicated analysis with advanced features (polls, forms etc.), where large number of people are involved.

Task assignment and monitoring

Developers break the specifications into separate tasks and register them in a secure issue tracker tool (Trac) specifically set up for the project and shared by all project team members. All tasks are categorised by milestones (iterations) and priority (to handle more important tasks before less important ones).

Tasks are checked and assigned to developers in the order of correct priority. After a task is fulfilled, the responsible developer marks it as ‘done’ and submits it for acceptance testing. Tested issues are marked as ‘checked’, and then stored, where they can be reopened if required.

Iteration planning

After a list of tasks is outlined, we compose the iteration plan. This is a list of most urgent and/or basic tasks that must be implemented in the nearest time. At the start of the project we usually plan one or two first iterations and then go on making iteration plans one by one, since each new iteration is usually affected by the previous one.

In the beginning of each iteration, developers schedule tasks on this iteration starting from those of higher priority and based on implementation risks. Developers re-check tickets importance and order them with a business analyst during iteration planning. Scheduled tasks are registered in our planning and tracking environment (we currently use XPlanner tool).

Our approach to iteration planning is to start with core functions to have a working solution prototype rolled out at the end of a first iteration. A customer in this case can check the prototype and feel their solution from the earliest development stages. They are encouraged to provide ‘on-the-fly’ feedback that is easily included into further iterations to ensure that the customer gets precisely what is required.

A typical iteration would last around 2 weeks — we believe it to be the best choice to implement a set of features allowing for close enough monitoring of development progress. Iteration length can be adjusted depending on the project’s nature, availability of time, and/or customer expectations. It is not uncommon to have longer iterations (1 month or even more).

Coding

Developers implement scheduled tasks and commit their code to source control repository. Committed tasks are marked as fixed/done in issue tracker to be checked by the testing team.

Mandatory unit tests are established both for features newly developed and for defects fixed.

Continuous integration

Committed code is subject to automatic build process at the build server that continuously monitors source control repository. As soon as it detects any new commit into a particular project codebase, the build server automatically triggers build process for this project: it compiles the code, runs unit tests and assembles build distribution. This process never stops, so every fragment of code is automatically tested and included into project build. Continuous integration is performed by CruiseControl environment built around Apache Ant or Apache Maven tool.

If a build fails, development team gets notified immediately and it’s a top priority task to fix the build.

Acceptance testing

A compiled build is deployed on a test server and thoroughly tested both manually and automatically (apart from integration and functional testing performed in continuous integration stage).

There are four types of testing we employ in every project:

After an iteration is over, the build is deployed (rolled out) and developers start working on the next iteration. At the same time we receive customer’s feedback to check if we’ve implemented the requirements correctly and to make adjustments if needed.