This week in class, we started our capstone projects. It’s hard to believe that it will all be over in four weeks, but I’m grateful for what I’ve learned and it’s been an incredible journey so far. And I can’t wait for the topics we’ll cover in the coming weeks to make our projects even better. So far, we’ve covered the fundamentals of building a Rails app including using Git, coding in Ruby, Agile development, employing TDD techniques, the plethora of Ruby gems, and of course, Rails.
I’ve signed up to be a part of two projects that I think are interesting and will challenge me to be a better Rails developer. On one project team, our goal is to develop a scheduling application that will allow managers and employees to interact easily over scheduling shifts. It will contain some very useful features such as being able to request time off, switch shifts, set default availability, and set overtime.
On the other team, we are building an app that will integrate GitHub and Pivotal Tracker into one system. The goal is to be able to modify Tracker stories and merge Pull Requests all from one dashboard. We will be using the GitHub and Pivotal tracker APIs to accomplish this and I’m excited to see how this project develops over the next few weeks.
Inception – starting a new project
Once we formed our project teams, we used Agile development techniques to take the first steps toward building our apps. Before discussing any aspect of the code, we framed the big picture of our project using a whiteboard discussion. By having an open discussion with managers, developers, and clients, it is easier to envision to ultimate design and use of an application and turns a daunting task into smaller, more manageable stories. As is custom in Agile development, stories can be generated during weekly meetings and developers can work on turning those stories into code during a sprint, or iteration.
So we started our projects with a discussion of the vision we had for each application, our goals and anti-goals, and who we thought might use the software. In this way, we started to have a clear understanding of how to start building our app and it no longer seemed like a daunting task. We also broke down the design into personas, roles, and activities. Personas are people who would use the app, roles are the positions they might fill in using the app, and activities are the functions they want to be able to use.
The foundation of our development plan lies in ‘user stories.’ A user story is a brief description of how someone might use the app and reveals the functionalities that need to be incorporated into it. For example, a user story for a scheduling app might read like, “As an employee, I want to be able to request time off, so my manager can find a replacement for my shift.” I’ll go over each aspect of a project development plan and how it plays an important role in keeping a team focused and motivated.
Goals, Risks, and Anti-Goals
Create a list of goals you want to accomplish while developing your new product. This seems obvious, but you can use this opportunity to talk goals for your team instead of just features you want to enable in the software. For example, what deadlines do you want to meet and how can you align yourselves to the values of the client or your own company?
This list is equally important to the goals you set. It outlines things you might tackle in the future, but should NOT be a priority for the time being because it could detract from your team’s progress. Perhaps you don’t want to worry about compatibility on mobile devices so you can steamroll ahead toward an MVP.
Outlining potential obstacles and pitfalls can help your team focus on problems before they arise. Perhaps your software will need to use new (buggy) technologies to be implemented properly.
Personas, Roles, Activities
Personas are a list of people who will be using your software. In my shift scheduling project, our list of personas would look like visitors, users, administrators.
Once you define the list of personas, you can dive into the roles they might fall into when they start using the software. For the shift scheduler, users might fall out into various categories such as employees, managers, and payroll issuers. Each role will have certain capabilities based on their role; for example, payroll issuers should be able to see how many hours an employee worked, but not be able to modify their schedule.
At this point in the process, you should start listing out the specific details of how a user might interact with the software. This is important in starting to develop user stories. Activities could be as simple as ‘log in to the home page’ or as complex as ‘generate a list of employees scheduled to work on a certain day.’
Writing good user stories is an art in and of itself. The goal is to create a scenario that is detailed enough that it can be broken down into a development task with acceptance criteria and relevant tests. The first step is to look at your list of activities and roles to generate a very broad user story using this template:
As a <user-type>, I want <functionality>, for <benefit>.
As a visitor, I want to create a new profile, so that I can start using the application.
Once you have a basic user story, the goal is to generate a story for whatever project management tool your team uses (e.g. Pivotal Tracker). Since A tracker story needs to be tangible in a way that any software developer can start working on it, it’s important to start developing a set of acceptance criteria to test if the story is complete. In our class, we write a list of steps that a user might take to accomplish the user story.
Acceptance Criteria: Visit the home page Click on 'Sign Up' link Fill in my first name Fill in my last name Fill in my email address Fill in my phone number Fill in my birthday Click on 'Complete Sign Up' Link Redirect to 'My Profile' with a banner that says, 'Thank you for signing up!'
Those steps eventually become a
capybara test that we can implement in Rails.
require 'rails_helper' feature 'New user sign up' do scenario 'should let a user create a new profile' do visit '/' click_link 'Sign Up' fill_in 'First Name', :with => 'Bob' fill_in 'Last Name', :with => 'Smith' fill_in 'Email', :with => 'firstname.lastname@example.org' fill_in 'Phone Number', :with => '1234567890' fill_in 'Birthday', :with => '01/01/01' click_link 'Complete Sign Up' expect(page).to have_content('Thank you for signing up!') end end
Once you’ve created one user story, repeat the process until you have enough work that can be digested during one sprint. Don’t forget to keep your project on track by reflecting on your goals, risks, and anti-goals often. It’s important to have a clear, open discussion at project inception to ensure your team’s success!