SCRUM and Agile Programming using Continuous Build System

Posted on 21-June-2008.

Introduction

            The traditional Software Development Life-cycle (SDLC) models such as the “water-fall” has evolved into a proven strategy for software development. However, there are several limitations to the conventional models such as lack of flexibility, poor requirements management resulting in extensive re-work at all stages of the SDLC. The drawbacks have resulted in the invention of agile software development strategies. Scrum is one if the widely followed agile software development methodologies which is discussed in detail in this article

Scrum

Scrum is an agile, lightweight process that can be used to manage and control software and product development using iterative, incremental practices. Wrapping existing engineering practices, including Extreme Programming and RUP, Scrum generates the benefits of agile development with the advantages of a simple implementation. Scrum significantly increases productivity and reduces time to benefits while facilitating adaptive, empirical systems development.

Tasks Involved in Planning a Sprint

A cycle in Scrum is called as “Sprint”; at the end of a sprint a set of production ready deliverables are created. The steps involved in the initiation of a Sprint are listed below,

1. Plan 30 day sprints
2. Before the beginning of every sprint, a meeting is planned
3. All the members taking part in the sprint take part in the meeting.
4. The availability of each member is recorded. Planned holidays, commitments on tasks not included in the sprint (such as support tasks) are all taken into account when recording the availability of each member.
5. A list of achievable tasks is selected. Tasks are chosen such that the completion of the task can produce a deliverable/ production component.
6. The tasks are listed on a white board; each task is chosen and further broken down into small units with the help of all the team members.
7. This facilitates each user to understand every tasks being executed and also provides inputs which results in an informal brain storming session.
8. When the tasks are broken down, each unit must not take less than 4 hours or more than 2 days (16 hours) to complete. If a sub unit of a task takes less than 4 hours it is logically combined with another unit or if a task takes than 2 days to complete, it is further broken down.
9. The members do the estimation of time; this makes it easier to achieve a realistic estimate in a transparent manner.
10. Finally, names are assigned against each subunit of a task for execution. The names are tentative and can be changed during anytime of the sprint. Pair programming can also be employed where appropriate.
11. The same process is repeated for all the identified tasks and all the data is recorded in the excel sheet.

Sprint Meeting

From the start of the sprint, a sprint meeting is conducted every day in the morning (before the start of work of the day). Each member answers the following question,

ü     What did you do since the last sprint meeting?

ü     Do you have any obstacles?

ü     What will you do before the next meeting?

At the end of every day, the excel sheet is updated with the amount of task that is completed (in hours) and the amount remaining (in hours) by each team member.

Any unexpected tasks not listed in the sprint that has taken a considerable amount of time for a member is recorded in the unexpected section of the excel sheet.

The members can re-estimate the time taken for completing a task at anytime.

The progress of the tasks are periodically monitored using the data in the excel sheet.

At the end of every sprint, the list of tasks completed is delivered/ moved into production.

Continuous Build System

The presence of a continuous build system plays a key role in the construction phase of agile software development. The continuous build system enforces test driven approach and facilitates rapid application development. A typical set-up of a continuous build system using open source products has been depicted below.

How it works

Cruise control continuously monitors the version control system (CVS), when it detects a change cruise control automatically takes the latest version of the source code into a configured location and invokes the ant scripts.

• The ant scripts compile the source code.

• Execute all the JUnit tests.

• Invoke jDepend, which records the package level dependencies and returns the results.

• Invoke emma when the JUnit test cases are executed which records the coverage of the test cases on the source code and returns the results.

• Invoke check style, which scans through the source code for Java coding standards and returns the results.

• Cruise control collates all the results and publishes it as a webpage into the Tomcat web server.

• Cruise control also sends an email to the user containing the details of the build results (Successful/ Failure) and the link to the published web page.