チームとコーディングのワークフロー
チームで分散バージョン管理 (DVCS) と ITS (Issue Tracking System) のワークフローを扱っていると困ったことがいくつかあります。
ITS によるチームのワークフローと DVCS によるコーディングのワークフローが同期しない
これは、結構問題です。
例えば、以下のような課題として顕在化してきます。
チームのワークフロー上では、「作業中」になっているけど、ブランチ作ったの？コード書いてるの？プルリクエストだしたの？
要するに、チームのワークフロー上では表現しきれないけれど、「作業中」の中で、開発者は、DVCS でいろいろな作業を行っており、そこにも確かにワークフローが存在しているのです。
「作業中」に行うコーディング上のワークフローの例:
Git リモートリポジトリをクローン
↓
フィーチャー ブランチを作成
↓
ローカル リポジトリへチェックアウト
↓
ローカルでコード変更
↓ ↑
ローカルで add & commit
↓
リモートに push
↓
プルリクエスト発行
↓ ↑
プルリクエスト承認可否（他者によって）
↓
コードのマージ
これが「作業中」というステータスの中で行われていたとしたらどうでしょうか？それはワークフローと言えるでしょうか？開発者が何を行っているのかがわからないということになるならば、チームメンバーやマネージャは適切なフォローを行うことができないということになります。また残念ながらマルチタスクで仕事をこなさなければならないメンバーにとってはワークフローが二つあることによる混乱でコーディングよりも情報収集や更新に気を配らなければならなくなります。本末転倒になるワークフローはゴミのようなものです。
ここで、ワークフローを構築する上での原則の一つをおさらいしておきましょう。
ワークフローのステータスは、一人で行える作業単位に抑えるべきである
これは絶対のルールではありませんが、指針としては十分に尊重されるべきものです。この原則に基づけば、上記のコーディング上のワークフローを「作業中」に収めるのは適切ではなく、少なくともプルリクエストのあたりはステータスを分けた方がいいことがわかります。
「作業中」→「レビュー中」
さらには実施しているかどうかも重要なチームで共有すべき事柄ですから以下のようにすると良いでしょう
「準備完了」→「作業中」→「レビュー中」
これでだいぶ見通しが立つようになるはずです。ちなみに、これ以上細かくしてしまうことはチームのワークフローとしては不適切なことが多いです。チームのワークフローとコーディングのワークフローの二つが存在していてそれらはパラレルであり、同期されなければならないことを常に頭に入れておきましょう。
要するに、チームのワークフローとコーディングのワークフローの二つを念頭に置きながら、いかにシンプルなワークフローと低い作業コストで開発者がクリエイティブなことに専念できるかが勝負です。クリエイティブなことよりも、自分の作業の情報収集や更新、チームの状況の情報収集に注意を払わなければならないならばそれはよいワークフローとは言えません。
2つのワークフローの同期
最近のツールは進化しているので、チームのワークフローとコーディングのワークフローを同期する手立ても提供してくれています。ここでは、以下のツールの連携を紹介します。
- チームのワークフロー: JIRA Software
- コーディングのワークフロー: GitHub / Bitbucket
JIRA Software は、DVCS のリポジトリサービスとの連携をサポートしていますので、GitHub, Bitbucket, Bitbucket Server, GitHub Enterprise と簡単な設定を行うだけで連携することができます。
設定は、こちらも参考にしてください:
JIRA Software ワークフロー トリガーによるステータス遷移の自動化
JIRA Software には、チームのワークフローをグラフィカルに定義する機能がありますが、そこでトリガーを設定することで DVCS の操作に応じてスタータス遷移を行わせることが可能です。これは、JIRA Software と GitHub や Bitbucket を連携させている場合に使えるようになります。
JIRA Software でのチームのワークフローは、「ステータス」とそれらを遷移させる「トランジション」で構成されます。
任意の「トランジッション」に対して DVCS のアクションと連動する「トリガー」を設置できます。
例えば、ステータス「作業中」から「レビュー中」に遷移する「レビューに回す」トランジッションのトリガーとしては、「プルリクエストが作成」と「プルリクエストが再オープン」を設定しておけば、プルリクエストしたときに「作業中」から「レビュー中」に自動で遷移してくれるようになります。
トリガーを追加/設定するのはとても簡単です。[トリガーを追加] ボタンをクリックしてウィザードに従えばいいだけです。
私のデモ環境では、以下のように設定しています。
遷移前ステータス 遷移後ステータス 設定しているトリガー
作業前（準備完了） 作業中 「ブランチが作成されました」
作業中 レビュー中 「プルリクエストが作成されました」
「プルリクエストが再オープンされました」
レビュー中 作業中 「プルリクエストが却下されました」
レビュー中 完了（または検証中） 「プルリクエストがマージされました」
n/a n/a 「コミットが作成されました」
「コミットが作成されました」は使用していません。理由は上述した通りですが、プルリクエストを伴わないカジュアルなコードレビューを行うなどする場合や、継続的インテグレーションのレビューや細かい単位での手動テストを行うなど、他者の作業を伴う場合は、チームのワークフローにステータスを追加し、このトリガーを設定してもいいでしょう。
メリット
この連携機能のメリットはいくつもあります。
- チームのワークフローとコーディングのワークフローの乖離を防ぐ
- チームでよりシンプルなワークフローを形成する
- バックログ項目やタスクと作業した成果(物)を結びつける効果を低コストで実現する
- チームのワークフローからコーディングの操作を実行できる
- 開発者は、コーディングのワークフローに専念するだけでチームのワークフローにも伝達・貢献する
- チームやマネージャは、チームのワークフローで開発者のコーディング作業の経過（マイルストーン）をリアルタイムに知ることができる
「チームのワークフローからコーディングの操作を実行できる」と「作業と成果を結びつける」はもう少し解説しておきます。
JIRA Software では、DVCS と連携設定をすることで、課題（バックログ項目やタスクなど）の単位で成果を自動追跡、レポートする機能が付いてきます。これらは課題単位で「開発パネル」で確認できます。
「開発パネル」では、追跡とレポートだけでなく、ここから DVCS の操作を実行することもできるのです。例えば、「ブランチを作成」をクリックしたらその課題専用のフィーチャブランチを作成できます（Bitbucket のみ）。また、ブランチから「プルリクスエストの作成」を行うこともできます。継続的インテグレーションとの連携もしていれば、デプロイも実行できるようになります。
「開発パネル」の成長度合いを画面ショットで見てみましょう。
デメリット
もちろん、デメリットもあります。もっとも懸念しなければならないことは、開発者がチームのワークフローやリズムを無視してしまうことでしょう。コーディングのワークフローは、チームがビジネス価値を提供する過程の一部に過ぎません（重要な一部です。ないがしろにできるものではありません）。チームのリズムを乱すことに繋がるならば、もう少し、チームのワークフローを意識してもらうよう、例えば、JIRA Software のカンバンやタスクボードを見るようにしてもらうといいでしょう。JIRA Software のカンバンやタスクボードには、成果物も含めて正しい情報が集まっているはずなので、開発者個人にとっても、チームにとってもマネージャにとってもコンセンサスをとるための材料が揃っていることになります。
また、コードレビューなど自分のコーディング以外の仕事を遂行する上で、優先順位などはチームの状況を見ながら行う必要があります。その意味でも JIRA Software のカンバンやタスクボードを見る癖をつけるのは決して悪くありません。DVCS の操作も行えるようになっているのも開発者のシンプルなワークフローを徹底する（＝忘れないようにする＆同じやり方をとる）ことにつながります。
参考資料
JIRA Software と GitHub, Bitbucket の連携やトリガーについてはオンラインドキュメントをご覧ください。特に DVCS サービスによって実施できる操作が異なる場合がありますので、最新情報のチェックもしていただければと思います。
JIRA Software による連携を無料で試す
Atlassian 製品は、無料で試すことができます。いますぐ試せるクラウド版と、自社サーバーに構築するダウンロード版のどちらも無料で試せるので、この設定を試してみてください。その上でチームにフィットするかを確かめましょう。
Atlassian 製品を試す（クラウド版）
Atlassian 製品を試す（サーバー版）
※ 本投稿は、個人ブログに掲載したものを転載しています。