We use Design by Contract (DbC) approach to develop our projects. In simple words means that the project is a split into several parts (milestones) and every milestone represents as an independent functional block. It is close by meaning to potentially shippable increment term used in Scrum.
Once we have a complete project structure and very detailed wireframes we split project into milestones. Each milestone is estimated separately in hours needed for its development and can take around 2 weeks to be implemented. In the end client gets the complete functional block.
In the first week of the current milestone designer develops mockups, lead developer writes documentation in RAML format for that part of REST API which we are going to build in this milestone and QA engineer writes test cases which cover functionality from this milestone. After mockups was approved by client frontend developer starts with slicing mockups into HTML/CSS. In the second week a group of backend/frontend developers starts implementing functionality from the milestone. At this moment they already have RAML documentation for the REST API which regulates client-server communications and HTML/CSS for the UI. After server side and client side code was finished QA engineer starts verification of the functionality from the milestone using previously written test cases. If there are any bugs found by QA engineer, backend and/or frontend developers immediately fix them. When all test cases passed successfully milestone is considered to be finished.
In the second week the first group starts already working on the next milestone. In this way we ensure iterable parallelized development process which is easy to control and allows to detect flaws in 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.
It is in general much more flexible. Unlike classical Waterfall or RUP methodologies it allows changes during the development, but to be able to ship a reliable system every change needs to be carefully evaluated. This normally means additional work for us. If we find the common ground on the change that needs to be done, we document it, change wireframes, mockups, then wait for client’s approval and give our estimate. Then we either create a new milestone and extend the initial project estimation or include it in one of the following milestones. It is a strict process that cannot be bypassed and underestimated.