Agile Rails Development Methodology


Agile Rails Development Methodology according to a developer is to use the following path for Ruby on Rails Application Development.

1. Write down a list of goals, roles, and features

  • Goals – what the goals of the whole project are – business and otherwise. This will help you decide what features are important

  • Roles – who is going to use the site – visitors, logged in members, admins? Do different people have different views of the same information on the site?

  • Features – what are the basic categories of interaction on the site? For example: Users: registration, using the forums, and blogging; Admins: moderating the user content

2. Write a list of stories

  • A story is different than a feature because it represents a single thread of interaction from a particular user’s perspective.

  • It’s common to express stories in form “As a ____ I want to ____ so that I can _____.” This forces you answer three important questions – Who is this for? What do they want to do? Why do they want to do it?

  • If you can’t complete a story in this form, it’s likely that you don’t have an answer to one of these three questions yet, so you’ll need to do some thinking to get the answers before the story is actionable.

  • Ex: “As an admin, I want to ban users from the forum, So that I can improve the quality of user-submitted content on the site.

  • Write these stories down on note cards. This will help you in estimation and prioritization.

3. Estimate the stories

  • Estimation is a huge topic in itself, but the basic idea is to associate a particular level of effort with each story.

  • The most common scales are 0/1/2/3/4, 0/1/2/4/8. I don’t think this is incredibly important, but pick something and stick with it.

  • Don’t get too hung up on the exactness of the estimates. Lots of things affect how long it takes you to finish a story, so small differences in story complexity tend to get lost in the noise.

  • Your goal here is to differentiate things that are low in effort, like stories that will result in you creating a simple model with a REST controller, from stories that are high in effort, like interfacing your application with a challenging third-party API, or a story that will require you to use a technology you aren’t very familiar with.

  • Write the estimate on each card.

4. Prioritize the stories

  • Rearrange the cards in the order that you’d like to tackle the stories.

  • Only the product owner can really make this decision. There are a lot of things that go into prioritization – deadlines, user testing, business value, etc. Estimation may have a lot to do with prioritization, because it illuminates opportunity cost. Maybe the product owner really wants that detailed Admin Dashboard, but if all the stories to make that work total 40 points, is it worth it to spend a month on just this feature. Maybe the product owner still wants the story

  • Are there any stories that don’t fit into the very minimum viable product to launch? If so, you should move them down. Try to complete a functioning app as quickly as possible so you can put it in front of users.

  • At this point, I usually move my cards into Pivotal Tracker, but I know lots of people who prefer pen and paper.

Read More : Railscarma.com

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s