Agile Development Methodology

Step 1: Specification

You, the customer, provide us with a specification for your project. This can be as sophisticated as a full-blow specification document or as simple as a short description and a set of user interface wireframes.

Step 2: Project Team

We form a project team composed of a project manager and one or more developers. If only one developer is assigned to the project then a second developer is added to the team to perform code reviews.We meet with you on Skype to break the project into agile “user stories”.

Step 3: User Stories

The user stories are entered into Pivotal Tracker. Stories describe the features of the plugin from the perspective of the user so that we remain focused on your requirements and not technical details of the implementation.

Step 4: Implementation

We “point” the stories by assigning them a value from one to three. Since developers are much better at estimating relative difficulty than man/hours or man/days, the point values are not associated with a specific timeframe. We tend to think of them as meaning “easy”, “medium” and “hard”. As with story writing, we point the stories together as a group that includes that project team and you, the customer.

We drag the stories from the “Icebox” into the “Backlog” in the order we want them completed. Pivotal Tracker automatically fills up the current sprint with stories. It uses the “velocity” of the team to decide how many points will fit in the sprint. The velocity always starts at ten, but over time it is refined by taking the average of the real velocity from the previous three sprints. You can always see exactly what we are working on by visiting the project in Pivotal Tracker.

We can discuss stories directly in Pivotal Tracker, but for longer discussions or discussions that aren’t related to a specific story, we use Basecamp.

Step 5: Testing

Wherever appropriate, the developer writes unit and/or functional tests to verify that the code works properly. We use the Jasmine testing framework for unit testing and Selenium for functional testing of web-based user interfaces.

Step 6: Code Reviews

When a story is completed, the developer submits the code for review by another member of the team. At Salsita, we use mandatory code reviews to reduce defects and ensure that our coding procedures and guidelines are followed. We use Review Board, an excellent open source application, for code reviews.

Before submitting the review, the developer ensures that all tests pass and then presses the “Finish” button in Pivotal Tracker. So you can see which stories are waiting for review since they have the “Deliver” button next to them.

Step 7: Delivery

Once the review is completed, the changes are pushed to our source control system and built automatically on Jenkins, our continuous integration server. Thanks to Jenkins you always have access to the very latest builds of your project. This also enables us to test on a variety of target platforms (different browsers, operating systems, etc.) every time we change something.

Once the build is on Jenkins, the developer presses the “Deliver” button in Pivotal Tracker. The “Accept” and “Reject” buttons are displayed. Now it’s your turn! Once you’ve downloaded the build and given it a try, you can press “Accept” to indicate that everything works fine (yay!) or “Reject” to indicate that some additional work is needed (boo!).