Maximizing our productivity is key to meeting goals and releasing on time. We use all sorts of project management tools,
but we also have a series of informal guidelines as to how we use
Slack, Phabricator, and Google Docs among our developer squads.
Specifically, how we integrated into their API, follow informal internal
guidelines of conversation, and how the tools themselves work great to
make our work great.
Slack
Slack is a great
marriage of one-on-one and group discussion tools. Slack channels can
contain a group of people, where you can still call out individual
people with @ mentions by name, or via “@channel” to notify everyone in
the channel. We organized our channels by topics and teams, which can
cover project-related items or even our next engineering outing.
The true power of this tool is in its API. We’ve integrated things
like Jenkins build failures, production system alerts, link-generator
bots—where, for example, I type in a ticket number, and the bot
generates a link to that ticket in our tracking system. (Of course we
added some bots to provide comic relief throughout the day.) We can also
upload files, post URLs (which automatically display the metadata –
works really well with Google Drive links), and organize our contacts
and channels very neatly in the nav.
Not only has Slack reduced our email volume, it reduced the amount of
info that can be lost in a one-on-one conversation. We now encourage
majority of conversations to happen in a group setting unless it’s truly
a private matter. And since you have the ability to subscribe just to
channels relevant to you, as well as get notified when you’re
specifically mentioned, the signal-to-noise ratio is very good.
It’s really opened up our communication channels tremendously. Email
is an “offline” communication channel, whereas chat is “online.” An
email thread also puts the burden on the original author to know off the
bat who include in the thread. More often than not, people are added to
that thread later on. So when a group of stakeholders are having a
discussion in a chat room, and they need a manager to weigh in, it only
takes a simple mention to bring them up to speed. “Hey @michael, you had
this issue last week, can you paste the solution?”
Phabricator
We’re also switching our ticket/sprint/bug tracking system to Phabricator,
a suite of dev tools coming from Facebook. It does ticketing with
agile/kanban style boards has good vcc integration, a code review app
that’s very nicely integrated into our git flow, and lots of other
goodies. Compared to others, we found Phabricator to be light-weight,
easier to administer, and—best of all—it’s free. It’s certainly not as
mature of a product, but there’s a wonderful community behind it. In
fact, our own Chris Burroughs has contributed to the project.
We recently made all of our old subversion repositories read-only,
and are fully on git now. Adding Phabricator into the mix has also been a
game changer. It allows for pre- and post-commit code reviews and
audits, letting teams decide what works best for them. A majority of our
groups use both approaches, and we trust the devs to use their
judgement. If someone is working on a significant change, they do so on a
branch and continuously commit there.
Once they’re ready for a review, the dev runs git rebase master to
get their feature branch up to date with the main tree and submit the
code for review. We do so with a Phabricator cli tool called archanist. Run a simple
arc diff
command, and the branch is uploaded into Phabricator where you can
specify who needs to review the code. Reviewers can add comments right
on there, and easily see any new changes since the last review. When the
review is accepted, the dev runs arc land, and the branch is
automatically merged back into master and pushed to remote. Small
changes are allowed to bypass this process, and teams are required to do
post-commit audits of all changes. It takes only a few minutes to audit
changes from the day, but it keeps more people in tune with ongoing
work without being disruptive.
If you’re not running a code review process internally, even if
manually, you really should be. I’ve lost count on how many defects were
avoided as a result.
Google Docs
Though Google Docs isn’t the full-featured Microsoft Word software,
it’s not that far from it and makes us crazy productive. My two favorite
features are Comments and the ability for multiple editors at once.
Forget the nightmare that comes with version control when docs are sent
via email. Google Docs allows the author to grant certain permissions to
editors—some can only view, comment, or edit. And no matter how many
edits you go through, Google keeps the versions saved and all the
comments so you can go back to it if you really need to. You can also
get more than one person editing the doc, really allowing for multiple
contributors. We jam on new ideas quite often, and it’s a lot better to
leisurely work on a document together than scheduling a meeting to
discuss the topic, assigning someone to start the doc, emailing a group
of people, and then . . . well, you get the point.
These are three tools and the guidelines we follow to help make our productivity insanely better. Does your developer team do any of these things? Any other project management tricks your team uses that you’d like to share? www.addthis.com
No comments:
Post a Comment
Komentar