We use a Design by Contract (DbC) approach to develop our projects. In plain English, this means that the project is divided into several parts (milestones) and every milestone represents an independent functional block. It’s close to the meaning to the potentially shippable product increment term used in Scrum.
Once we have a comprehensive project structure and precisely detailed wireframes we split the project into milestones. Each milestone is estimated separately in the hours needed for its development and can take around 2 weeks to be implemented. In the end, the client gets a complete functional block.
In the first week of the current milestone the designer develops mockups, the lead developer writes the documentation in RAML format for that part of the REST API which we’re going to build in this milestone and the QA engineer writes test cases which cover the functionality from this milestone. After the mockups have been approved by the client the frontend developer starts slicing mockups into HTML/CSS.
In the second week a group of backend/frontend developers starts implementing the functionality from this milestone. At this moment, they already have RAML documentation for the REST of the API which regulates client-server communications and HTML/CSS for the UI. After the server side and client side code was finished the QA engineer starts verification of the functionality from the milestone using the previously written test cases. If there are any bugs found by the QA engineer, backend and/or frontend developers immediately fix them. When all test cases have passed successfully, the milestone is considered to be finished.
In the second week, the first group immediately starts working on the next milestone. In this way, we ensure an iterable parallelized development process which is easy to control and allows to detect flaws in the initial design on the earliest stage of development.
We used this approach on different projects, both smaller ones (3-4 months) and bigger ones (>12 months). It proved to be efficient for all sizes of projects. This approach allows everyone to stay focused on a small functional block and to keep in mind all the tiniest details related to this block.
In general, it’s much more flexible. Unlike the classic Waterfall or RUP methodologies, it allows for changes during development, but to be able to ship a reliable system every change needs to be carefully evaluated. Normally this entails additional work. If we find common ground on the changes that need to be done, we document it, change wireframes, mockups, then await the client’s approval and provide our updated estimate. Then we either create a new milestone, and extend the initial project estimation or include it in one of the following milestones. It’s a rigid process that cannot be bypassed and underestimated.