How we do

I wanted to document the lifecycle of a project at Novoda, using an app I wrote as an example. This would include explanations about how we use tools for source code management, project discussions and project tasking/reporting to keep everyone involved and invested throughout the project, and even more importantly, how we’ve changed the way we use these tools over time.

Wutson is a series-tracker for TV, a guide to what’s on. It’s similar to SeriesGuide or SeriesAddict, in that you should be able to track the shows that you’re watching (and which episodes you’ve seen).

I chose to work on Wutson because I wasn’t fond of any of the existing series trackers (“it’s not you… it’s me”). It should be quite a visual, image-heavy app, so it’ll be perfect to serve as both a testbed for improving accessibility in Android apps and also a great opportunity to apply project tools at a professional level on a personal project.

This is how we do!

Tools

This year, Paul and Xavi have been delivering their Software Craftsmanship talk, Y U NO CRAFTSMAN, describing how we work at Novoda, and how we try to encompass the principles of software craftsmanship in our day-to-day work.

But where would a craftsperson be without their set of tools? At Novoda, we use a base set of tools on all projects. The way we use them evolves from project to project as we understand our process better. Our toolbox includes:

  • JIRA
  • BaseCamp, Google Drive
  • GitHub, Jenkins
  • Android Studio, Genymotion

JIRA

alternatives: Pivotal Tracker, Trello, Mingle

For Wutson, I’ll be using JIRA to keep track of the priority and status of tasks. I want to use JIRA instead of a less powerful (but simpler) app to understand how it works to greater extent (I think JIRA is misunderstood) and feed that back into our process at Novoda.

We use JIRA to organise our time – it provides visibility to all the tasks that we have indicated that we want to achieve in the current sprint and the current status of each of those tasks.

We only add a task (/bug/story) to a sprint when all the dependencies for that task have been met – we shouldn’t start a sprint where tasks cannot be completed due to being dependent on another unfinished task.

For example, if there is task to “Update the buttons on Screen X to match the design” then before this task can be added to the sprint:

  • the design mockup
  • the design spec (paddings, colors, typefaces)
  • all required assets (9 patches in all the relevant densities)

should be available as attachments to the task in JIRA; a random developer should be able to jump onto the project and have all the things needed to complete the task, without having to hunt things down in various places/chase up designers for missing assets.

JIRA is used not only as a tool to help us organise our time – it’s used to track our progress and promotes accountability (both of the development team and the product owner).

It’s important to remember you are a team (never clients vs. development). With this in mind, create tasks with clear and unambiguous acceptance criteria. If during a sprint review, the acceptance criteria is met, but the product owner isn’t happy, we still mark the task as complete, and create a new one. What time is it? EXAMPLE TIME!

In order to be assured my data is up to date, as Finn, I want manually refresh my data

Given I am on the data screen,
When I press the “Fetch data” button,
The app should present the most up-to-date data


App implementing acceptance criteria as-is

PO: “Hmm, this is a bit jarring. You click the button, nothing happens, then BOOM new data? Why is there no loading indicator? We can’t ship this.”

You: “The current implementation matches the existing acceptance criteria so this story should be accepted as complete. You’re right though, this is jarring – let’s add a new story, with acceptance criteria that covers the missing aspects.”

In order to be assured my data is up to date, as Finn, I want to see feedback when I refresh my data manually

Given I am on the data the data screen,
When I trigger a manual refresh,
The app should display a loading indicator that disappears when the data loads


App implementing new, more specific acceptance criteria

PO: nice.

Basecamp, Google Drive

alternatives to Basecamp: Freedcamp
alternatives to Google Drive: Dropbox, SugarSync, Box.com

We attach final assets to JIRA tickets so that developers have what they need to implement a feature. What about discussion and iteration, and WIP/original PSDs and stuff?

At Novoda, we use Basecamp for discussion. Often, our designers will show designs here for discussion with the client. This can include anything from sketches to mock ups, but the point is that the discussion is open and focused (want to talk about something else? Start a new thread). Once a design has been okayed, the final assets will be added to the relevant JIRA tickets.

PSDs, AI and other original files will be handled by the design team. We’ve got a shared Google Drive (for the project) but the design team (as of writing) also use Dropbox internally because it handles syncing of large files a lot quicker than Drive right now.

GitHub, Jenkins

alternatives to GitHub: BitBucket, Beanstalk
alternatives to Jenkins: Travis CI, AnthillPro, Go

All our projects are version controlled using git and we’ve grown our process to accommodate some of the features available in GitHub, namely Pull Requests (code review) and GitHub wiki.

Anything that hits our main branch (master/develop) has gone through the pull request process. We’ve also setup Jenkins, a continuous integration server, to trigger a build whenever something has been merged into the main branch.

Android Studio, Genymotion

alternatives to Android Studio: IntelliJ IDEA, Eclipse
alternatives to Genymotion: Intel-powered Android emulator, real devices

We’ve been using Android Studio since it was released at Novoda. It’s approaching a 1.0 release and we consider it stable enough for development.

On client projects, we’ve generally stuck to the stable versions, and only the team lead can give the OK to update so as not to waste time with broken tools.

Since Genymotion v2, I can’t develop on Android without it. It starts quickly, and I can deploy relatively quickly. The downside is that you need to buy the pro version for screen recording capabilities (we always add screenshots/gifs to pull requests when the UI changes) but I’m happy to switch to a real device when I need to.

Other tools

  • A physical whiteboard and dry-erase markers to plan things out/draw diagrams
  • Google Keep (or a whiteboard) for the day’s TODO list
  • I find SourceTree is invaluable for breaking up changes into small chunks when you’ve gone too far between commits. When I’m on a Linux box, I use gitg.

For Wutson, here’s the setup I’ll be using:

  • JIRA: I’ll be using a private JIRA board to keep track of my tasks.
  • Basecamp/Google Drive: I won’t be using Basecamp or Google Drive as I don’t need to discuss things with myself. I’ll keep WIPs and original files locally, and attach final assets to the relevant JIRA tickets.
  • GitHub: Wutson will be developed on a public repo using GitHub but I won’t be relying on code-review before merging my feature branches back to dev.
  • CI: Wutson has a job running on Travis CI which should run whenever something is merged to dev or master
  • Android Studio/Genymotion: I’ll be using the latest version of Android Studio and Android build tools, as well as Genymotion 2.3+. Though we stick to stable(-ish) versions of AS when working on client projects so we don’t waste paid-for development time, I’m happy to risk downtime in my personal projects to try out the latest features and fixes.

I’ll document the process throughout work on Wutson, to better explain how I use the tools listed above and to help describe the (ever-evolving) process at Novoda. Stay tuned!

Leave a Reply

Your email address will not be published. Required fields are marked *

To create code blocks or other preformatted text, indent by four spaces:

    This will be displayed in a monospaced font. The first four 
    spaces will be stripped off, but all other whitespace
    will be preserved.
    
    Markdown is turned off in code blocks:
     [This is not a link](http://example.com)

To create not a block, but an inline code span, use backticks:

Here is some inline `code`.

For more help see http://daringfireball.net/projects/markdown/syntax

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>