anitsh
commented
3 years ago Release Early, Release Often
Release early, release often (or Ship Early, Ship Often, time-based releases, RERO) is a software development philosophy that emphasizes the importance of early and frequent releases in creating a tight feedback loop between developers and testers or users, contrary to a feature-based release strategy. Advocates argue that this allows the software development to progress faster, enables the user to help define what the software will become, better conforms to the users' requirements for the software, and ultimately results in higher quality software. The development philosophy attempts to eliminate the risk of creating software that no one will use.
This philosophy was popularized by Eric S. Raymond in his 1997 essay The Cathedral and the Bazaar, where Raymond stated "Release early. Release often. And listen to your customers".
This philosophy was originally applied to the development of the Linux kernel and other open-source software, but has also been applied to closed source, commercial software development.
The alternative to the release early, release often philosophy is aiming to provide only polished, bug-free releases. Advocates of RERO question that this would in fact result in higher-quality releases.
Release Plan
A Release plan is not a static plan. It will change during the whole project while we know more about the project. New, removed, modified user stories, and the respective changes of their estimates will influence the release plans as well. Therefore, the release plan should be revisited and refreshed at regular intervals.
Based on the release process, source code branching are created and maintained.
Patterns for Managing Source Code Branches
Scrum Release Plans:
Feature-Based Release Planning What we know: Velocity of the Scrum Team, Features we want to deliver. What we don't know: How long do we need to deliver these features?
Date-Based Release Planning What we know: Velocity of the Scrum Team, The Date we want to deliver. What we don't know: What features can we deliver until the deadline?
Feature-Based and Date-Based Release Planning What we know: Velocity of the Scrum Team, Features we want to deliver, The Date we want to deliver these features. What we don't know: Can the Scrum Team deliver the requested features until the given deadline?
Resource