User:Soulsonic~enwiki/RIP (Rapid Iterative Prototyping)

Rapid Iterative Prototyping (RIP) is a software development methodology that evolved from Agile development approaches, most notably RAD. In resource stressed development environments, overtaxed developers and project managers felt the need for a more streamlined approach to development.

RIP methodology stresses developing against a constantly evolving prototype. Development is the continual evolution and fleshing out of the prototype. The prototype is repeatedly reviewed, both within the team, and with the customer. At all times RIP offers the customer the application in its most realized form, prompting immediate, reasoned, and nuanced feedback.

RIP teams (cells) typically consist of only 2 or 3 members, and operate with a high degree of autonomy within larger IT organizations. A team typically consists of one or more programmers, and a systems generalist. A guiding principle of RIP is that members of a cell should be highly skilled and experienced, because RIP relies much more heavily on quick decision making and team autonomy than more traditional approaches. The developer(s) are selected from the most capable available, and are chosen for their complimentary skill sets and ability to work well together. The generalist is typically an experienced systems analyst or project manager. The generalist guides the project, manages the customer interactions, and does the vast majority of non-programming work for the project.

Much of RIP is evolved directly from earlier Agile methodologies, with their emphasis on short feedback loops, close cooperation with the customer, and nimble response to changing requirements. Where RIP differs is in its

• emphasis on the ephemeral nature of software
• lack of reliance on consistent customer interaction
• software re-usability limited to frameworks
• low or non-existent component re-usability

The RIP approach rejects the idea of component re-usability, arguing that probability of a component being re-used is extremely low, any attempt to create a reusable component extends development time and creates unnecessary dependencies that complicate future functionality extension.
The RIP approach rejects the idea of software re-usability, arguing that well designed, purpose-built applications are by nature scalable and extensible

"Create the fastest possible solution to your need, using the best currently available tools and thoughtful design...Documentation should support, not supplant good design."

The RIP approach:

• thoughtful, meaningful feedback
• responsive to change
• small teams (typically 2 or 3 people)
• limited documentation
• limited re-usability
• crispy
• team driven
• minimal resource utilization
• fast
• multitasking
• phased development
• constant re-prioritization

Business Assumptions:

• priorities change
• attention spans are short
• the customer is lying (always)
• software is not forever

Why Developers Love it:

• less documentation
• developers are protected
• freedom

Advantages:

• Rapid development
• Nimble
• High level of customer awareness
• Works well if little customer involvement
• excellent utilization of high-cost talent

Criticisms:

• Too reliant on experts
• Not a viable methodology for inexperienced teams
• Little applicability to most development work
• not easily applicable to large scale projects
• Error prone
• ignores corporate development standards