In Shipyard we try to minimise as much project management as possible. This is how we keep our team lean and nimble.
GitHub is our base of operations in which we've integrated some apps to help us run lean whilst delivering high quality code. Here are our integrations:
- Circle CI for continuous development and deployment
- Heroku for hosting (automatic deployments from master to staging - US & EU)
- Code Climate to spot security issues and to track code quality & test coverage
We also use a number of tools such as Rubocop to ensure code quality is maintaned at a high level before it hits GitHub.
Discussions happen in two places; Issues and Pull Requests. Issues are for discussing how feature works prior to creating a branch for the feature. Pull requests are for discussing how to implement the feature after committing code.
The product manager is responsible for syncing the issues backlog and sprint milestones with the product roadmap. We manage our weekly sprints (Tuesday to Tuesday) using GitHub Issues. Typically we overload the sprints by ~50%.
We always make quality the highest priority. Features have to solve their related problem completely in a considered manner, with high quality code and comprehensive testing & QA. We don't rush deployments or features and don't set time deadlines either.
Everything should have someone assigned (unless the issue isn't in the current sprint or a pull request is waiting review).
Everything should also have labels attached. Labels are explained below:
-
Size labels should be assigned by the person who picks up the issue. All PRs and Issues should have one size label.
-
Type labels indicates what the issue is related to. All PRs and Issues should have at least one type label.
-
Action labels indicate if someone has to do something and where appropriate should have that person assigned to the the PR.
-
Emergency labels must be done immediately. Drop what you're doing and close out this issue immediately.
-
Blocked labels represent that someone or something is blocking this issue from being resolved. Anything with this label cannot be merged in master.
-
In progress label indicated the issue/PR is currently being worked on and should always have someone assigned.
-
QA needed label indicates that if this feature is not done correctly, the firm's brand reputation could be at risk. Anything with this label needs explicit approval from the product manager or product owner before it's merged into master, and again before it is deployed.
There are two milestones - "Current sprint dd/mm" and "Current release". The product manager will manage the issues within current sprint, with the exception of anyone within the team who spots a bug or hotfix. All other issues (can be created by anyone) sit in the backlog without a milestone.
The Current sprint dd/mm milestone includes all issues that have been earmarked for completion with in the current sprint. Just before someone merges a PR they assign it to the Current release milestone to help the CTO identify pending migrations and the "QA needed" PRs. If there are things that need to be done in the deploy for each milestone, place that in the milestone's description.
The CTO is in charge of deployments to production. We aim to do a deploy every time someone's feature is merged into master. Unless the "QA needed" is applied, the developer that wrote the feature should do a quick QA on staging to make sure it works as expected, let the CTO know the feature is ready for deployment. The CTO will deploy 2-5 times a day and monitor New Relic after each deployment.