Published at 23.01.2015
To create modern user experiences and products it is crucial to not only master the technological aspects but to establish a well organized development cycle transforming customer demands to integrated features of a software system. This article gives a short overview of our development process and methodologies.
Table of Contents
When we started the anynines project our team agreed on some basic guidelines. We decided to organize ourselves according to the “Lean Startup” principles which can be summarized to establishing a “Build, Measure, Learn”-loop and a strong focus on customer satisfaction while driving anynines forward. As we already worked with Kanban for Avarteq’s (our mother company) development projects it was a no brainer to also organize and visualize our anynines workflows using Kanban-boards, -policies and meetings.
Another rule: automate, automate, automate. This principle is based on the 5+ years of experience of our hosting department developing Enterprise-Rails and Railshoster. By enforcing automation we enable fast response times to customer demands and diminish ‘manual labor’ where possible, so we can focus on our product enhancement efforts.
We agreed on a soft separation into a development and operations team while many tasks might overlap. In those cases we form pairs between the teams. Especially for infrastructure automation development tasks it is crucial to bring together administrators and developers to find long lasting solutions. Here weekly team meetings form the basic organization while smaller groups/pairs schedule meetings on demand.
Inspired by the extreme programming and agile software development movements we decided to implement XP techniques into our workflow. Since Ruby is our main programming language and testing is a hot topic in the Ruby community we follow the concepts of test-driven development and iterative development cycles. Complex architectures are developed and elaborated within pairs or in challenging cases involving the whole team. Additionally we try to use pairing during development whenever possible.
It took a little while to adapt, but I now really enjoy the benefits of pair programming and finding solutions together.
The following diagram demonstrates the basic stages a ticket passes through during the development process:
A ticket starts in the backlog, followed by a preparation phase where basic information required for the ticket to be processed is added. When the preparation is finished the ticket is then positioned in the ready column so any team member can pull the ticket into the coding column. After implementing the ticket it is passed on to the testing section (e.g. integration tests, staging system deployments) followed by the approval process where another team member evaluates the work done (code review). If he/she decides that the ticket is solved it is passed on to the waiting for deployment column. Since some deployments require scheduled down times those tickets are saved in this column until the next maintenance window. After deploying the ticket moves to the done column and is considered fully processed.
We like to provide the best user experience possible to our customers, so we implemented a dedicated workflow to process user feedback into tasks and enforce system enhancements queried by user feedback:
Support tickets, emails and any other forms of user feedback (social networks, tweets, …) are processed to tickets on our user feedback board. Those feedback items are weighed by customer demand and the team’s time estimations before being processed to distinct tasks. Those tasks are then evaluated technically and form new tickets on the development board described above. This process ensures that valuable user feedback is integrated into our development pipeline.
And about that: please share your thoughts on how we can improve our service to fit your demands. We encourage you to contact our support, ping us on Twitter (@anynines), write us an email (firstname.lastname@example.org) or leave a comment below this article.