zube.ioとタスク管理 — アジャイルサムライを読んでみて

「アジャイルサムライ」という本を読みました。
開発手法のひとつであるアジャイル開発について解説された本です。

今参加させてもらっているベンチャーでもアジャイルを取り入れており、必要に駆られたので読んでみました。

だいぶ前にこんな記事を書きましたが、それの振り返りなども踏まえてまとめました。
↑この記事にはポモドーロ法などについても書かれてあります。

アジャイルサムライ――達人開発者への道

「アジャイル開発」の全体的な概念や、ストーリーの回し方などはもちろんのこと、僕はプログラマとしての立場なので、この本の中のプログラマの信念に関する部分を注意的に読みつつも、いつかはなり得るかもしれない他のメンバーの立場についての部分も理解しようと思いながら読み進めました。

「アジャイルサムライ」に関することの概要

この本には、ざっくり以下のようなことが紹介されています。
挿絵も多く、とても読みやすい本で、楽しみながら読了できました。
全ては、「お客さんに価値のあるものを最適な形で提供する」という考えが念頭にあります。

  • アジャイルなチームとはどんなものか
  • どんなメンバーが必要か
  • メンバーのベクトルを合わせるためにどうすればいいか
  • 必要なストーリーはどのように出すか
  • それらのストーリーをどのように消化していくか
  • リファクタ、テスト、CIなどについて

タスク管理に関して

今回はこの本の中で、僕が最も関心のあった部分であるタスク管理について少しまとめます。
アジャイルやスクラム開発に便利なツールに「zube.io」というのがあるので、これを使っていきます。
この本自体は、チーム開発のためのものですが、個人的なタスク管理にも使える部分があるように感じました。

ちなみにチームでのアジャイル開発では、各々個人の生産性のみを計測するのは、ナンセンスだと書いてありました。
あくまでもチーム同士で考え方を共有し、助け合うことが重要ですよと。
それを頭の片隅に置いた上で進めていきます。

また、普段僕らが「タスク」と呼んでいる単位は、アジャイル的には「ストーリー」と呼ぶそうなので、今回はそれに倣って以下では「ストーリー」と呼びます。

工数見積りについて

この本では、工数の見積もりについて以下のようなスタンスを取っています。

  • 正確に見積もるなんて無理
  • このプロジェクトをやり遂げられるのか?が欲しい答え

では、どのようにして見積もっていくかですが、

  • ストーリーそれぞれを互いに相対的なサイズで見積もる
  • ポイントを元にして進捗を追跡する
  • ベロシティを見積もる

詳しく書いていきます。

見積もりの手順

細かい日数で見積もるのは無理なので、ストーリーの相対的な大きさで比較する手法を取ります。

まず最初に、今からゴールに向けて必要なチームのストーリーを思いつく限り洗い出します。
次に、それらの中から比較に使えそうな軸になるストーリーを大、中、小のサイズで3つ抜き出します。
そして残っているストーリー一覧をこれら大、中、小に割り振っていきます。
「ストーリーA」は大変そうだから「大」だな、「ストーリーB」は一瞬で終わりそうだから「小」だな、という感じに。
これをチームメンバー全員で簡単な話し合いも交えて分けていきます。

最後に、これらを5pts、3pts、1ptと、ポイント付けをします。
ここでいう「ポイント」というのは、日数のことでもなければポモドーロの単位でもありません。
単位なんてどうでもいい、相対的なストーリーの大きさを示します。

ここで適当に割り振った3種類のポイントに対して、明らかなミスがあることに途中で気づけば、その都度見積もりなおします。
例えば、「ストーリーC」は3ptsだと思ってたけど、やり始めてみたけっこう大変だということに気付いて実は5ptsだった的な。

これらのポイントをストーリーごとに割り振ることで、チーム全体(今回は個人)で1スプリントの中でできるストーリーの量や、ゴールまでにいくら時間がかかるかを把握することができます。
この「1スプリントの中でできるストーリーの数」のことを「ベロシティ」と呼びます。
つまり、このような式になります。

  • ベロシティ = 今までに完了したストーリーポイントの合計 / 全てのイテレーション数

ちなみに、「スプリント」というのはアジャイル開発で頻出する重要なワードで、サイクルを回す周期のことです。
大体は1週間から2週間の間のどこかに固定されます。

zube.ioを使う

説明も途中ですが、ストーリー管理を進めていくためにzube.ioというサービスを使っていきます。

zube.ioとは

スクラムやアジャイル向けのストーリー管理ツールです。
動作が快適でUIも綺麗です。
それとGitHubとの強い連携ができるので、それもすごく便利です。
Trelloからストーリーのインポートもできます。

ただし、多機能なので、慣れるまでは少しずつ使っていったほうが良いかもしれません。

Trelloと比べて、残念なところはモバイルアプリがないところですね。
現状はブラウザ上でしか見れないっぽいです。

ですので、外にいるときになにかストーリーを思いついたらとりあえず女子高生AIりんなちゃんにLINEを送って、瞬時に閉じることでラインの通知をつけさせてリマインドさせてます。

準備をしていく

適当にアカウントを作成し、最初に「Epics」に思いつくプロジェクトのグループを作成していきます。

何度か言ってますが、今回は個人のストーリー管理ですので、僕の場合は例えば「勉強会用の勉強とまとめ」とか「練習用の○○アプリを作成する」とか、「Go言語の勉強」とか、「読書」などになります。
サイドバーのProject>Epicsからページへ行き、右上の「New epic」から作成できます。

Epicsカラーも自由に選べるのも良いですね。

作っていて検討の必要性を感じたのは、このEpicsの粒度ですね。
例えば、読書を例に取るなら、「読書」そのものを一つのEpicsにするべきか、「アジャイルサムライ」など一冊の本を一つのEpicsにするべきか悩みました。

これはやっていきながら自分好みにすると良いと思いますが、明確なゴールがないようなものはできるだけ大きくグルーピングしました。

スプリントの期間を決める

次にスプリントを回す期間を決めていきます。
1週間にするのか、2週間にするのか、はたまた10日間にするのか、どんなサイクルで回すのかなどを考えます。
僕はバイト先と合わせて、「水曜始まり火曜終わりの7日間単位」でスプリントを作成することにしました。

記念すべき一発目のスプリントを作成します。
Sprintsのページで、右上の「New Sprint」から作成し、タイトルや期日を設定していきます。
タイトルは何でも良いと思いますが、2018年8月の1週目だから「201808#1」などとしました。

ラベルの作成

Project>Labelsから、ラベルを変更します。
ここはデフォルトでGithubのものになっていて使いにくいので、自分用に変えていきます。
僕は時間の管理にtogglというサービスを使っていますが、このtoggl上のプロジェクト名に合わせました。
あとでもう少し詳しく書きますが、zube.ioはtogglと連携することができます。
このときに、このラベルごとに割り振っていると管理が便利になります。

カラムの設定

Settings>Workspaceからカラムを変更します。
デフォルトではアジャイル開発向けのものになっていますが、今回は個人管理なので、自分好みに少し変更しました。

  • Inbox
    思いつきリスト。
    スプリント関係なく何かやることを思いついたら全部ここにぶち込む。
    あとで分割するので単位もどうでもいい。大きすぎても良い。
    後で見て意味がわかればOK。

  • Free space
    予備欄。
    一時的なストーリー置き場や、明日やることなどを突っ込む。
    できるだけ開けておく。

  • In this Sprint
    今回のスプリントでやろうと思っていることリスト。
    Inboxからここに持ってくると時にサイズを小さく分割すると良い。

  • Today
    今日やることリスト。
    In tihs Sprintから持ってくる。
    同じく持ってくるときに分割できそうならしたほうが良い。

  • In Progress
    今やっていること。
    やりかけていること。
    一つ一つのストーリーの粒度を小さくすれば、ほとんど使わないかも知れないので、もしかしたらいずれここは廃止するかも。

  • Done
    今回のスプリントで終わったものをここに移動させる。

ところどころ「分割」とか言っているのは、Inboxに入れるようなストーリーは大きな粒度になりがちだからです。
例えば「アジャイルサムライを読む」など。

このままでは1日や1週間で終わらないこともあり、管理が難しいです。
ですので、移動させたりするたびに分解しながら突っ込むと良いかと思います。
例えば「アジャイルサムライの”1章を”読む」などです。

ストーリーを突っ込んでいく

「Sprint Board」のページに行き、右上の「New Card」からストーリーを突っ込んでいきます。
このときに以下のような設定ができるので、必要に応じて設定します。

priority

優先順位です。
0~5の6段階で設定できます。
5が最も優先順位が高いものになります。

point

ここは先ほど紹介した、相対的なストーリーの重さを測るために使うポイントです。
最初は当てずっぽうで、徐々に精度を高めながら感覚でポイントを定めていきます。
0から100まで適度な尺度で設定できるようになっていますが、1、3、5の3種類などのようにして、あまり選択肢を広げすぎないほうが管理しやすいかと思います。

ラベルやEpic

同時に先ほど作成したラベルやEpicやAssginers(自分)などや、ストーリーに対するMarkdownの説明も設定できます。

実行する

いつやるか決める

Inboxに入っているたくさんのストーリーの中から、

  • 今週やらないといけないこと
  • 今週やりたいこと

を選んで、In this Sprintなどのカラムに移動させます。
難しいですが、ここでは欲張りすぎたり保険をかけすぎたりせずに「一週間で終わらせられそうな量」を移動させます。

togglと連携する

先ほどもちらっと書きましたが、toggleを使っている場合は連携することをおすすめします。
Chromeを使っている場合は、このページから拡張機能を入れることで連携できます。

入れた後に、ストーリーを見てみると、togglのボタンが表示されているかと思いますので、そこからプロジェクトを選んでタイマーをスタートできます。
togglのデスクトップアプリも入れておけば、ポモドーロ法を使い25分でタイマーが切れるような設定も可能です。

振り返り

スプリントの最終日に振り返りをしましょう。
項目としては、以下のようなものになります。

  • 最初に設定したストーリーを全て完了することができたか
  • もっとうまくやれたこと、改善点はあるか
  • 次のスプリントで何をするか→SprintBoardにセット

Analyticsを使う

左のリストに「Analytics」という項目がありますが、このページから分析ができます。
ここでは3つを紹介します。

しかし、これらはあくまでもチーム開発のものであって、個人のストーリー管理には時間制限がないものも多くあるので、どこまでうまく活用できるかは謎です。

バーンダウンチャート

バーンダウンチャートを見ることで以下のようなことが一目瞭然になります。

  • どれだけストーリーを完了させたのか
  • どれだけストーリーが残っているのか
  • ベロシティはいくらか
  • いつごろ全てを完了させられそうか

残っているストーリーの量と、それに対する理想的な残りのストーリー数がチャートで表示されています。
スプリントの初日が一番多く、そこから徐々に減らしていき最終日に0になるのが理想です。

バーンアップチャート

バーンダウンチャートの逆で、処理したストーリーを積み上げていきます。
残っているストーリーの量、理想のグラフ、現実のグラフの3線でチャートが表現されます。
必ず0からスタートし、最終日に設定したストーリー数のところまでグラフが伸びているのが理想です。

バウンダウンチャートに比べて、新しくストーリーが追加されたことがわかりやすいのが特徴です。

ベロシティ

カードもしくは、ポイントでチームまたは自分の1スプリントに対するベロシティを確認できます。
この値を知ることで、適切な工数見積りができるようになります。

例えば「僕は1週間で15ポイント分のストーリーをこなすことができる」と知っていれば、次のスプリントにぶち込むストーリー数を合計で15ポイントにしておけば、大体うまく終わらすことができそうだということがわかります。

さいごに

こんな感じで、タスク管理をし始めました。
togglはポモドーロタイマーも使えるので便利なのでぜひzube.ioと組み合わせて使ってみてください。
それでは、プロダクティビティのある日常を。

アジャイルサムライ――達人開発者への道

コメントを残す