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 methodology 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. Unlike classical development processes, such as Waterfall or RUP, iterative approach makes it possible to make changes to functionality at any time. If something needs to be changed, we update wireframes firstly. Then we check what milestones will be affected by this change. If functionality that is already implemented needs to be modified, we create a new milestone to make the necessary changes. If the milestone has not been implemented yet, we will make changes to it at once and then keep them in mind when we start development of the functionality in this milestone.