はじめに
みなさんは、タスク管理は何を使っていますか?
個人的にはTrelloを使って、チームのタスク管理はBacklogを使ってと、ツールを分けて使っている方も多いのでは無いでしょうか。
私もかつてはそのようにタスクを管理していたことが多かったのですが、企画はタスクとして管理して、開発タスクはGithubで管理、デザインはまた別のGithubのリポジトリで管理(これ自体やっていないところも多いかも)といったようにバラバラに管理している(あるいは管理していない)ことによって、
テストは誰がやるの?そもそも今は、タスクの完了率はどのくらいなのだろう?誰が何のタスクを持っているの?といった、全体感が見えなくなりがちでとても困っていました。
そんなこともあって、私は最近はもっぱらzenhubを使っています。
zenhubとは、
Githubにない(弱い)アジャイル開発らしさを補ってくれるGithubの拡張のようなものです。
zenhubを使うと具体的に何ができるようになるのかは
以下の記事で詳しく説明してくれているのでご参考程度に
ZenHubとは - Qiita
この記事では主に、
- 導入
- (zenhubを使って)プロジェクトのタスクがどう管理されているか
- メリット
- デメリット
の3つを説明しようと思います。
あくまでも私の関わっているプロジェクトと、個人的に運用したことを元にzenhubが最適だと思ったので、みなさんのプロジェクトには使いづらいこともあるかと思いますが、この記事を参考にプロジェクトに組み込むか判断に使って頂けたらと思います。
導入
とりわけ説明することも少ないですが、zenhubは、Google Chromeや、firefoxのブラウザ拡張として導入することが可能です。
以下のURLにアクセスして、「CHROMEに追加」を押して追加することができます。
ZenHub for GitHub - Chrome ウェブストア
プロジェクトのタスクがどう管理されているか
プロジェクトで例えば追加機能を作るとなった場合、まずepic
を作成します。
epicとは
この機能を活用するとGitHubの情報の構造は次のようにすることが出来ます。
プロジェクト (repository) > リリース (milestone) > 機能 (label) > エピック (Epic) > ストーリー (issue) > タスク (tasklist)
Issueを最小作業単位、ユーザーに価値を提供する単位として利用します。
今までは、大きな作業群であるエピックはユーザーストーリーとは別のIssueとして管理しなければなりませんでした。(チームそれぞれでやり方は違ったと思います)
GitHubに革命が起きる?ZenHubに追加された新機能”エピック”とは - Qiita
まあ簡単に言うと、複数のIssueをまとめたIssueのようなものです。
zenhubを使うことのメリットの一つはEpicが使えるようになることであります。
epicの作り方は、zenhubのboard
からnew issue
を押し、issue title
を入力し、任意でcommentを入力し、create an epic
のボタンを押すと、epicが作成画面が開きます。
先程epicはIssueをまとめるIssueだと説明しましたが、企画がepicの一つとして作成されるイメージです。
例えば、質問投稿画面に新しく、プレビュー機能を追加するという、タスクであれば
これが、epicにあたる大元のタスクになります。
次にそれにともなう、小タスクを作成していきます。
このような画面になったかと思います。ここで、新しくepicに紐付ける作業単位のIssueを発行していきます。
(また、先にissueがある場合は後からこちらのチェックボックスで選択し、紐付することが可能です。)
ここでいう作業単位のIssueとは、例えば開発、デザイン、テスト、デプロイなどプロジェクトごとにことなりますが、ここで作成するIssueを全て一通り終わらせることができたら、このepicを完了とする。ということを念頭に細分化してください。
(プロジェクトによっては例えばここに、効果検証などを含めることもあるかと思います。)
ある程度Issueを作成することができたら、先程作成したepicに紐付けて完了です。
プロジェクトによって運用方法が異なってくるかと思いますが、私のチームでは以下の事に気をつけて運用しています。
-
小タスク(issue)には必ず担当者をアサインして、誰がそのタスクを持っているのかを明示的にする
-
できるかぎり、Estimateをつけることによって工数を管理する
小タスクにEstimateを付けることによって、合計値がepicにも反映されるので、できるのであれば付ける -
タスクの詳細はEpicにだけ記載して、小タスクとなるissueには一切何も書かない
それぞれのタスクにアサインされた人は必ずepicを見るようにすることで情報が分散しにくくなるのを防ぐことが可能 -
Epic作成にもレビューを設け、やるやらの判断を行った上で、実行する
Epicを作成する段階で、一旦リーダーなどの目を通すことによってタスクの優先度ややらなくていいタスクを排除することができる。その際に、Epicに記載する内容をフォーマットとしてまとめていれば、タスクを作りやすく、精査もしやすくなる -
Pull RequestはEpicに紐付けることで、PRとEpicを連携させる
-
出来る限り、子タスクを実行した人が、ボードを動かし進捗の管理をする
このように、zenhubを利用し、ボードでタスクを管理する為にも運用フローが重要になってきます。
メリット
zenhubを導入することによるメリットはいくつかあると思いますが、
- カンバン方式を利用することによって、誰が、何のタスクを、どのくらいの進捗で進めているのかが一目瞭然である
- (Epicに記載するべき内容の、フォーマットを定めて)企画のチェックを予めおこなうことによって不必要なタスクが実行されることを防ぐ
- 一つのEpicに対して全ての小タスクが紐付いているので確認が容易である
などのメリットが得られます。
デメリット
- 運用フローが複雑になると、(とくに企画を立てる人)は理解し参画するコストがかかる
- 作業者が進捗を管理しないと、結局全体で把握することができなくなる
- 企画の精査や、(とくにデプロイ時など)どのタスクがテスト可能かなどの管理をする人が大変
それぞれ現状では上記の様なデメリットはありますが、それぞれドキュメントを残したり、自動化をしたりすることによって解決できるような問題ではあります。
まとめ
運用フローを整え、タスクの管理を一元化することによって、
- カンバン方式を利用することによって、誰が、何のタスクを、どのくらいの進捗で進めているのかが一目瞭然である
- (Epicに記載するべき内容の、フォーマットを定めて)企画のチェックを予めおこなうことによって不必要なタスクが実行されることを防ぐ
- 一つのEpicに対して全ての小タスクが紐付いているので確認が容易である
しかしデメリットも少なからず存在するので、それぞれのプロジェクトに導入するには検討が必要。
いかがだったでしょうか。記事を読んで同じような境遇にあるかたは一度検討してみて下さい。