rails product planning
Last updated 16 April 2013
This article from the RailsApps project suggests how entrepreneurs can plan development of Rails applications for startups and personal projects. It describes product planning with “user stories” and introduces the concept of behavior-driven development as part of the software development process.
If you’re new to Rails, see What is Ruby? And Rails?, recommendations for a Rails tutorial, and a list of top resources for Ruby and Rails.
The RailsApps project provides example applications that developers use as starter apps. Hundreds of developers use the apps, report problems as they arise, and propose solutions. Rails changes frequently; each application is known to work and serves as your personal “reference implementation” so you can stay up to date. Each is accompanied by a tutorial so there is no mystery code. Maintenance and development of the RailsApps applications is supported by subscriptions to the RailsApps tutorials.
You might think that software development begins with writing code. But in fact, product planning is the first stage of the software development process. Product planning, which is at the heart of going from “concept to code,” is critical in getting a project off to a good start.
Arguably, for a simple application, you don’t need a lot of “ceremony.” There’s no need for a written specification. Just write some code. But though your application may seem simple, software projects have a tendency to grow complex and take longer than planned. At a minimum, product planning will help you focus your ideas before you begin coding. If the application grows complex, it will help you track progress and stay on course.
For ambitious projects, when you are part of a team, or when other people’s time and money are at risk, product planning is a key element of a robust software development process that also includes project management and testing. See an article on Rails and Project Management for more on the topic.
If you’re a solo operator, product planning can be helpful; if you plan on growing a company, it is fundamental. It’s up to you to decide how much time you will spend in product planning. But consider some of the benefits:
- It helps you discover the functionality you need to implement.
- It helps you describe and discuss features with your business partners.
- It serves as a “to-do list” to help you track progress.
- It is the basis for acceptance testing or integration testing.
User stories (definition: user stories) are a way to discuss and describe the requirements for a software application. The process of writing user stories will help you identify all the features that are needed for your application. Breaking down the application’s functionality into discrete user stories will help you organize your work and track progress toward completion.
User stories are often expressed in the following format:
As a <role> I want <goal> so that <benefit>
As an example, here are user stories for the rails-prelaunch-signup application from the RailsApps project.
*Request Invitation* As a visitor to the website I want to request an invitation so I can be notified when the site is launched *See Invitation Requests* As the owner of the site I want to view a list of visitors who have requested invitations so I can know if my offer is popular *Send Invitations* As the owner of the site I want to send invitations to visitors who have requested invitations so users can try the site *Collect Email Addresses* As the owner of the site I want to collect email addresses for a mailing list so I can send announcements before I launch the site *Social Network Sharing After Sign Up* As a user I want an option to post to a social network after I sign up so my followers will learn about the site
We can use this list of user stories as our task list in implementing the application. The article Rails and Project Management shows how you can track progress implementing user stories with a simple to-do list or more complex project management tools.
Behavior-driven development (BDD) is an effective methodology for software development that turns user stories into a test suite for acceptance testing or integration testing.
Here’s how user stories can be the basis for behavior-driven development using Cucumber:
- write user stories
- user stories become Cucumber scenarios
- create acceptance tests based on Cucumber scenarios
- code each feature
- run acceptance tests as each feature is completed
This process of “concept to code” is a good way to manage software development. It’s a good way to build complex applications, either as a solo operator or part of a team.
Cucumber scenarios turn user stories into plain-English descriptions of a series of steps to execute a product feature. Cucumber is appropriate when a team includes nonprogrammers who are involved in defining product requirements or there is a need for a specification and acceptance tests to be maintained independently of implementation (for example, when implementation is outsourced).
There are alternatives to Cucumber that may be more appropriate for smaller projects or teams of people who are comfortable reading software code.
Many Rails developers create integration tests using Capybara in combination with RSpec as described in Ryan Bates’s How I Test Railscast.
User stories can still be the basis of product planning using the RSpec and Capybara approach; instead of using Cucumber, features are tested with RSpec and Capybara but the features are still based on user stories.