-
Notifications
You must be signed in to change notification settings - Fork 252
Busy Workflow Guideline v1.1 May 2018
Moved to https://github.com/busyorg/workflow/wiki/Workflow-guideline-v1.1-(05-2018)
A lot of attention gets paid to the importance of workflow, especially in Development. But a tested and well-implemented workflow plan isn’t just process for process’s sake. A well-tuned workflow improves productivity, aligns team expectations and helps to define company culture. Improving our development workflow has the business impact of saving time and money by reducing wasted attention and keeping the focus on building the Busy project.
The goal of this document is to walk you through the concepts and specifics that should be understood in our workflow while contributing to Busy.org projects. Prior to contributing to Busy a few steps need to be completed, starting from specifications, to designs.
By defining it properly in a Guideline, it will allow every contributor to be on the same page using this as a global development methodology and improve our workflow. Our goal is to manage Busy processes according to the defined rules. The rules, which we call a workflow process definition, include the activities and steps that occur in the process and the relationship between those steps. SaaS tools we’re using will be mentioned as well.
Developers should not have to make any guesses that lead to errors and lose time. On the other hand, creating detailed specs manually is tedious and takes a lot of the team members and designer’s time but might be mandatory in our approach. The most appealing software applications developed today are produced by a close collaboration of designers and developers. The minimum specs should be written on a document using “User Stories” by team founders & members (called “Product Owner”) allowing the designer to work on wireframe and UI/UX design and the developers to code in two weeks Sprints (called “Team Members”). The workflow will be controlled by the management team / scrum Master (called “Managers”)
We start using tools that help us to create design specs with a minimum of hassle. Such tools save time for both designers and developers and will lead to better designer-developer workflows.
In the last few years we’ve seen a crush of workflow software hit the market, and with the right tools we can better manage and automate the development process. A well-curated suite of tools helps our team to sharpen and track communication, manage clear expectations and responsibilities, and allow any one team member to pick up where someone else has left off.
We rely heavily on tools like Google suite, Slack, Trello, Zeplin, Github, to make sure Vision, Design and Development are always in communication and able to understand where the project stands.
We’re always observing, tracking and implementing ways to improve development workflow, working in a collaborative approach with open-decision making. Busy adopt its own workflow model based on a hybrid Agile/Scrum method. This document is open to any inputs/suggestion.
Within software projects, there are inevitably problems that are difficult to predict ahead of time. The more sophisticated the project, the more unknowns there will be. Research and development, Q&A, Ideas and specifications (User stories) are necessary to resolve those unknowns, this phase should be done up front so the resolutions are clear, rather than later as part of the development process when this could cause major delays.
With clean specs and good Q&A, the team can then move forward quickly, with everyone feeling confident about technical decisions that have been made.
Busy has been a virtual organization since it was founded, and we’re now adopting Agile methods–especially Scrum–for all projects. Trello as our go-to solution for managing virtual, Scrum projects.
We love the way that Trello lets you see the big picture. This concept is at the centre of Scrum: if team members don’t understand the big picture goals of a Sprint or a release, they don’t own their respective tasks in the same ways. If they don’t understand their work in relation to what other team members are doing, then they don’t collaborate as much, don’t cross-skill, and the team doesn’t improve.
This new version removes Trello from the process and centralize everything on GitHub Projects Boards. (test asked by @fabien). We will use two GitHub Projects Boards to improve our workflow and global vision.
User stories are part of an agile approach that helps shift the focus from writing about requirements to talking about them. All agile user stories include a written sentence or two and, more importantly, a series of conversations about the desired functionality.
What is a user story? User stories are short, simple descriptions of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template: As a < type of user >, I want < some goal > so that < some reason >.
- As a user, I want to vote for a witness
- As a new user, I want to be able to sign-up so that I can start using the platform
- As a witness, I want to see who voted for me
User stories will be defined as Cards in the Product Backlog (Trello)
For each user story (or issue at a later stage), we have a common structure, the problem/motivation + proposed resolution approach.
Here is the structure:
- Problem / Motivation
- Proposed resolution
- Remaining tasks
- User interface changes
- API changes
- Data model change
Each issue is a GitHub card, so everyone that takes part to the project can comment it. We can also use the GitHub Projects cards checklist to get a clear overview of remaining tasks.
Trello is great for the big picture view of things, since everything is on the same page. We used it in our Workflow v1, but @fabien advocate all-in-one tool for this current Workflow, and centralizing it on GitHub Projects. We will give it a try for Workflow v1.1 starting from May 2018.
There are potential downsides to use only one board (one big picture) for a project:
- as a Team member trying to focus on a task, sometimes you can’t see the tree for the forest. important stuff can get changed way too easily boards can get too wide, with too much horizontal scrolling.
- as a Product Owner, there’s all this tempting stuff in the Sprint Candidate list that keeps frustrating you about it not being in the sprint. Part of the goal is to prevent distraction during an active sprint.
Since in Scrum we have two distinct modes–ideas/specs/review/ (the Specs) and active and planned development (the Sprints) –we suggest using one board for the Product Backlog specifications, and another board for Sprint planning and details. When we approve a card, we move it from the Product Backlog board to a Sprint Backlog on a separate Sprint board.
We’re organizing our Product Backlog board into the following lists of cards:
- Ideas. To develop ideas
- Requirements Gathering. A list to flesh out User stories and desired functionality.
- Specs in Progress. Specs/Definition/User Stories
- Specs Done. Designer can start wireframe/design phase
- Wireframe/Design in Progress
- Wireframe/Design Done. When Producer Owner are satisfied, card is ready for Sprint Candidate
- Sprint Candidates. For tickets that have been estimated. Ready to Dev
On this board, the Product Owner is responsible for prioritization of cards within each list, with the highest priority cards always on top.
The team moves cards to Sprint Candidates during a Sprint Planning meeting. If User Stories are not complete or missing Specs/Designs, cards get moved back to Requirements Gathering.
Cards should only appear on this board if they have been approved for a specific sprint by the Product Owner.
- Sprint Backlog This is ordered according to priority determined by Product Owner. Directly shipped from the Sprint Candidates
- Current Sprint: date Two week sprint
- Dev in Progress Developers pick cards from Sprint backlog to Dev in Progress and start to code
- Dev Done When Dev is finished and Ready-to-verify (Review/Test/QA bug reports)
- Functional review Done (Product Owner + Designer + Tester)
- Code review Done Need 2 devs
- Ready-to-ship
- Blocked
Sketch-Wireframe-Design-Prototype-Integration
Sketching from Ideas in the Product Backlog Board.
Activity Flow as well (+ other tools like UXPin)
Sketch + Invision Invision comment system
Zeplin allow collaboration between designers and developers
Collaboration between designers and developers is essential to the success of a web project, and it’s a measure of a team’s success. Whilst sharing the same workspace is invaluable, having an online source of truth that helps with this collaboration is incredibly helpful
This is where Zeplin enters the scene.
Zeplin is a collaboration tool for UI designers and front end developers. It goes beyond the design workflow and helps teams with the design hand-off.
It allows designers to upload their wireframes or visual designs straight from Sketch and add them to project folders in Zeplin. Annotations will automatically be added to the designs (sizes, colours, margins and even CSS suggestions for certain elements) which will leave you with an online repository that the whole team can contribute to.
Working with Zeplin has many advantages, here are some examples:
- Avoid building long spec document; something which is neither agile nor easy to update. Work on ideas and user stories to start sketching
- Create instant annotated designs with all the relevant information for developers and other designers.
- Can create exportable designs, so developers gain quick access to individual assets.
- Create style guides that will help the design team stay consistent.
- Take advantage of Slack integration, instantly notifying the team every time there’s an update.
Many development teams are turning to Agile project methodology to organize goals for their product teams, which allows them to be more flexible in making changes to the process over time. A main component of Agile is the Sprint, which makes the work of a large-scale project more manageable by dividing it into smaller tasks, usually tackle-able inside of two weeks. Breaking tasks down to fit into two-week cycles makes it easier to prioritize and plan, rather than trying to stick to a long-term plan even as priorities change.
Estimating time requirements for software development is extremely challenging, as it’s next to impossible to predict when or how a ticket will cause project delays. Developers tend to estimate less time than is required, which often leads to projects going over time and budget. When working with short sprints the impact of unforeseen hiccups can easily be contained and managed.
At Busy.org, we start each sprint by prioritizing the project tasks to work on. Once tasks are chosen, then we begin the collaboration between design and development to build out the feature or improvements.
As teams change, either with new hires or moving responsibilities, it is important to bring new members up to speed as quickly as possible. This reduces gaps in productivity and means sprints can keep rolling forward.
About GitHub Workflow … ... Later on, in the next version of Busy Workflow, we will apply GitFlow Workflow ….
Copywriters, for example, use proofreading and editing as process tools to ensure that what they write is as close to flawless as possible. Developers have code reviews. Code reviews can be automated, done by peers, or both. The goal is to identify bugs early, ensure that coding standards are maintained, and generally keep the codebase healthy. Code reviews also provide a venue for providing valuable feedback to junior developers.
At Busy, all code is peer-reviewed by at least two other developer. The reviews take place after the code and tests have been written and committed to source control. Ultimately the code a developer is writing, needs to be crafted not just for the machine running it, but also the future developer who is going to have to read it and make a change to it. We use the Pull request process of GitHub.
Pull requests let you tell others about changes you've pushed to a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before the changes are merged into the repository.
After initializing a pull request, you'll see a review page that shows a high-level overview of the changes between your branch (the compare branch) and the repository's base branch. You can add a summary of the proposed changes, review the changes made by commits, add labels, milestones, and assignees, and @mention individual contributors or teams.
Once you've created a pull request, you can push commits from your topic branch to add them to your existing pull request. These commits will appear in chronological order within your pull request and the changes will be visible in the "Files changed" tab. Other contributors can review your proposed changes, add review comments, contribute to the pull request discussion, and even add commits to the pull request. After you're happy with the proposed changes, you can merge the pull request. If you're working in a shared repository model, the proposed changes will be merged from the head branch to the base branch that was specified in the pull request.
to-be defined
As we've been using GitHub Issues to collect bug reports and feature requests, we will now attach Issues to specific GitHub Project Board cards related to that feature. This makes it easy to see why something hasn’t been merged, as well as to follow up with the person assigned to see if that bug is being worked on (or feature request)
New ideas can be added as GitHub Issues with Suggestion label as well.