モチベーション
スクラム開発をする際に各タスクにはストーリーポイントを決めてタスクを見積もります。
このストーリーポイントはチームで合意を取り決定しますが「なぜこのストーリーポイントなのか」を共有するのは事前に取り決めをしていても難しいです。
これを正しくチーム内で共有し、共通の認識のもとストーリーポイントを決定できるようにするようにします。
脱却するために何をしたか
以下の様にストーリーポイントを影響する要因に分解し、各要素から決定し、タスクボードに反映するツールを作成しました。
簡単に説明するとJQLを元にJIRAからIssueを取得し、それらに対してストーリーポイントに影響する要素をスライダーでチーム全員で決定し、それらの値からストーリーポイントを計算するツールです。
細かな話
ストーリーポイントそもそもとはなんなのか
『More Effective Agile ー"ソフトウェアリーダー"になるための28の道標』 によると以下。
ストーリーポイントは作業アイテムの大きさと複雑さの目安となる基準である。
よくありがちな失敗として、ウォーターフォールなどの工数ベースの開発からスクラムに移行した場合、「ストーリーポイント＝工数」という誤った認識のもと、「これは担当者が3日くらいかかると言っているのでストーリーポイントは3pt」といった言葉を変えただけの運用になり、ストーリーポイント本来の役割を十分果たすことができません。
ストーリーポイントはいくつかの要因によって決定される複合的な値であり、複合的な値であるがゆえにいきなり「ストーリーポイントはいくつか」と決定しようとすると、各チームメンバーの中では様々な考えがよぎり、結果、自分が一番重きをおいている要因を重視したストーリーポイントが口をついて出てきます。
スクラムに関して十分に知識が浸透しているチームであればこれらを口頭で話し合い決定することも可能ですが、そうでないとチームメンバー感の力関係により、特定の人が考えたストーリーポイントが採用されたり、人日などのよく知りパラメーターでの置き換えに繋がります。
そこで、ストーリーポイントはいきなり直接決定せず、ストーリーポイントマトリックスを作成し、ストーリーポイントが影響を与えるか、その各値が上がるとストーリーポイントはどの程度上がるのか、を決定します。
ストーリーポイントはストーリーポイントマトリックスによって決定する
ストーリーポイントは各要素の複合的な値なので、ストーリーポイントは何によって決定されるかを決定します。
あまり多くの要素を定義しても検討しきれないので3～5個の要素に絞るのが良いでしょう。
例としては以下のようなものです。
- 知識
- そのタスクに関して知識をチームがどの程度保持しているか（担当者個人ではなく）
- チームに知識があればそれは誰にでも実施可能であり、チームにとって小さなタスクといえる
- 特定の人物にしか知識が無いものであればこのタスクはボトルネックになる可能性があり、チームにとって大きなタスクと言える。また知識の明文化などの副次的な作業が発生する
- プロジェクト完遂後、ストーリーポイントの消化が多いメンバーに知識が属人化していると判断でき、これを解消するための指標となる
- 複雑度
- このタスクに関連する要素の大小
- このタスク関連するコンポーネントや関数、あるいは関係者などは多ければ多いほど、影響範囲の検討や調整などの作業が発生する
- 作業量
- このタスクを完遂するために必要な作業の大小
- 開発作業の場合、ソースコードにどの程度のソースコードの実装が必要か
- テストの場合、どの程度のテスト項目消化が必要か
- 作業量が多いほどチームとしてもレビュー量、確認量が増える
- 不確実性
- このタスクを完遂することはチーム以外にどの程度依存しているか
- チーム外の経営陣やユーザーの意思決定が必要な場合、このタスクは完了できるか不明確であり、バッファを確保しておくほうが望ましい
これらの要素をマトリックス化し、それぞれに指標を設けておきます。
このとき、「高い」「低い」などの値ではなく、ある程度具体的な値を据えておいたほうがプロジェクト全体でストーリーポイントを相対的につけやすいです。
例としては以下のような感じです。
| ストーリーポイントへの影響 | 知識 | 複雑度 | 作業量 | 不確実性 |
|---|---|---|---|---|
| 小さい | チーム全員が知識を持っている | 単一の関数のみ | 100行未満の修正 | 担当者で決定可能 |
| やや小さい | チームの75%以上が知識を持っている | 複数の関数に影響 | 200行未満の修正 | チーム内で決定が必要 |
| やや大きい | チームの半分以上が知識を持っている | 複数のコンポーネントに影響 | 300行未満の修正 | チーム外との社内合意が必要 |
| 大きい | チームの半分以下しか知識を持っていない | 影響する範囲が不明 | 400行未満の修正 | 社外との合意が必要 |
上記のようなマトリックスができたら、ここからストーリーポイントを計算する方法を決定します。
流石に全パターン256通りのそれぞれに対してストーリーポイントを決定するのは面倒なので、何かしらの計算式で出すのが良いでしょう。
例えば、「小さい=1」、「やや小さい=2」、「やや大きい=3」、「やや大きい=4」として平均値を取り、範囲でストーリーポイントに割り当てる、といった形です。
すべての値が同じ重みをつける必要はありません。チームとして影響の大小を考え、荷重平均を取るのも良いです。
ただ、ストーリーポイントは1+1=2の世界なので相乗平均を取るのはおすすめしません。
ツールを作って自動連携
上記のストーリーポイントマトリックスを利用してストーリーポイント計算するのは良いですが、これらをExcelなどで管理するのは面倒なので、ツールを作って自動でタスクボードに連携します。
今回のPJではJIRAをタスクボードに使用しているので以下のような構成で作成します。
ストーリーポイントの各要素はJIRAに直接保存しても良かったのですが、自分にJIRAのタスクボードの定義変更の権限がなかったり、JIRAのAPIの実行回数の制限が思ったよりも少なかったりでJIRAへの書き込み回数を最小限にするために、ストーリーポイントの書き込みはDynamoDBを使用しました。
また、フロントエンドの部分についてはCloudFrontにしてLambda Edgeを使う案もありましたが、今回は社内ツールであり、社外アクセスをIPで制限する必要がありました。
この場合、WAFを使う必要があり、WAFを使うならAPI GatewayのリソースポリシーでIP制限をしたほうが安価だったのでAPI Gatewayを採用しています。
API Gatewayの構築についてはこちら、Lambdaの構築についてはこちらに記事を記載しているので参考にしてください。