I have been developing software since long. Most of the projects I have worked on relied heavily on agile development processes. Over these years, I have always tried to learn refining agile methodologies to achieve more and more smooth and rapid development experience.
Let me take a moment to record my generic experiences here, at least for my reference.
Key guiding factors
There are some well known influencing factors, e. g. “requirements evolve over time” and we should respects them. However, some of those factors I have learned to respect a lot - to achieve more RAD, are
Trying to do thing right at one or two shots is much more painful than evolving with multiple iterations.
People give most output when they are given the work they like most. At early stages, people don’t like writing documentation and test cases
You may not be able to hire all genius developers. Project should succeed with people of mixed talent.
An average developer gives most output when the plumbing code and develompent patterns are already well set.
Keeping all these factors in mind, I see a normal project having these phases:
The Inception Phase
The objective of the inception phase is to arrive at an estimate and go/no-go decision with minimal effort. Inception phase aims to deliver the following.
One para summary about the product, its objective and the scope of the project
One or two page elaboration on the domain and project scope in plain English
System overview or broad architecture and deployment scenario. Should indicate volume and load.
Summary of user stories as themes. No need to elaborate.
Broad domain entity model (without attributes and complex associations)
List of non functional requirements like response time.
List of technology / legal risks, proof-of-concept tasks and mitigation plans. No need to mention common risks such as attrition.
List of cross cutting / non functional tasks.
List of third party tools and libraries needed.
Effort / Time / Cost estimation based on story points method.
For a medimu-sized project, these things are typically jotted following a one or two hour discussion among the customer, a functional analyst and a software architect. Many times, only either the functional analyst or the software architect takes the call and then explains the other one.
Note that all these happen before the project is signed off, and hence, no need to devote considerable effort into this. For a medium-sized project, typically, half-a-day to two days should be sufficient.
Agile methodologies suggest to add about 40%-50% contingency to the estimates, and RADLite respects that. However, many of the times the estimate is driven by budget constraint or competition. In that case, limiting the estimates to some feasible figure, keeping in mind feature trade-off is the only way. By the way, feature trade off is not a bad idea at all. Standish Group  research shows that on average only 20 percent of software features in existing applications are “always or “often” used, 16 percent are “sometimes” used, 19 percent are “rarely” used and 45 percent are never used. Great relieving information for we software estimators!
Note that in some projects there might be some uncertainities which may need investment in a feasibility study before the sign-off.
The Preparation Phase¶
Once the project is signed off, it enters the preparation phase. The preparation phase sets up the platform for the developers, arming them for action - i.e. to gobble up the user stories.
The following jobs are addressed in the preparation phase:
Development environment setup
Ensuring that there are no show stopper risks. Doing proof-of-concept of risky techincal features
Development framework and patterns setup. Includes designing UI Templates and patterns, establishing coding patterns, coding base classes for entity and service classes, coding utility classes, coding cross cutting concerns etc.
Skeleton entity model setup
Place holder classes which would be expanded later
User story expansion and elaboration. Division into must-have, should-have, could-have categories.
Coding convention establishment
The development phase¶
The development phase is sub-divided into three phases, namely must-have, should-have and could-have phase. Each of these phases address their own set of user stories.
Each of these is again sub-divided into these phases:
Development of working prototype, side-by-side elaboration of business rules: This phase is important whenever the requirements are not clear. It gives the customer a full cycle to revisit his requirements, business rules and stories. This is done in multiple iterations of fixed length, typically two weeks. Development of working prototype aims to develop all the UI and flow. but can skip time taking, changable business rules, security constraints etc. The objective of this phase is to demonostrate the customer the full functionality, so that he can re-visit the requirements, if any.
Development in multiple iterations of fixed length, typically two weeks.
Base test data and acceptance test case preparation: This is done by the onsite customer or functional analyst on spreadsheet format.
Development: Developers refer the base test data and acceptance test cases while coding.
Acceptance test automation: By looking at the base test data and the acceptance test case prepared by the onsite customer, developers record the test cases just after developing an user story. The recorded cases are coded in proper format and put into the automated test case repository.
Development of working prototype is more important in the must-have phase than the should-have and could-have phases. The rule of thumb is that, if the requirements are not clear to such an extent that it may need one of more cycles of revisit, we should have development of working prototype.
The transition phase¶
RADLite does not deviate here from well established standard methodologies.
RADLite is a methodology successfully followed by me in multiple projects. It’s uniqueness are:
More specific about estimation strategy on inception phase
A preparation phase to give the developers a solid platform before attacking user stories
A specific testing strategy different from TDD
Let me know your views!