by Ryan Walker •

Rails web application development process

Here is the process I am presently using, from high-level planning down through actual BDD-style coding.

Brain Dump

Using notecards, high-level brain dump of stories:

  • roles
  • action/tasks

When complete, organize content and transfer to digital doc, toss cards.

Modeling & User Stories

Develop “ubiquitous language”–Words that work for both the technical implementation and with conversations with users or customers. This language is also important for the screens, which should have include clear direction on how the system works. This would be in contrast to typical programmer-generated screens, which will often have usability issues.

To each story, add a few sentences to describe it; just enough information to serve as a token for a conversation that will take place closer to implementation.

Minimum viable product

In true “Lean Startup” style, development of the app should be treated as an ongoing series of experiments to test hypothesis on what success may look like.

So an important step is to ask what is the first validatable theory to begin with, preferably an important one. Then choose only those stories that directly help create an experiment to learn from.

Continuous delivery

Continuous integration should be setup to continously deploy the app. There should be no such thing as “releases” and “iterations”.

UI-First Development

Screens

  • Which screens - REST conventions can do a lot of work - what is the logical name of the noun-verb combination?
  • What’s on them - design from the inside out. Just the content without the outer frame of navigation. What matters to the user of the screen. What are they trying to do? Put in words what things they are trying to do on the screen, including the various paths they may take. (Don’t just assume the page should be a standard REST-template form.)
  • Be completely rational, “don’t make me think” - when I see the screen, I instantly know what to do with it, it’s easy to complete the task.
  • Least effective difference - give things visual priority, doing just enough to create the hierarchy.

Flows

Think with actions, every action has 3 screens…

  • How you get to it
  • How do you do it
  • What happens afterwards - how do i know it worked. What do i want to do next?

HTML & Coding

1. HTML mockup

Explore UI options on paper, in Photoshop, or in HTML to get to a happy design for the feature. It’s best to explore this in as lightweight a form as possible to avoid wasted effort.

2. Write new feature/scenario

Guard runs the features and outputs pending steps, copy and paste them, and write simple code to define them (using code semantics you wish you already had.)

3. Pick a red step & write failing spec @ the rspec level

Using Rspec, specify the missing functionality. Guard will now see red at the rspec level.

4. Write as little code as possible to make the spec pass

Get the spec green, as quickly as possible. Guard pops the stack and reruns the scenarios you’re working on. Once green, refactor anything that’s needs it.

5. Repeat until your steps are all green.

Filed under Product Management Ruby on Rails Software Development