DevLove道場の感想 #agilesamurai #devlove

先日、DevLove関西でお会いした@papandaさんのご好意でアジャイルサムライDevLove道場に参加してきた。
「アジャイルサムライ」と同じく、ユーザストーリー洗い出し→バックログ作成→プラニングポーカーによる見積り→受入基準作成までのレシピで、とあるチームに途中参加させて頂いた。
感想を思いついたまま書く。

【参考】
ソフトウェア開発に特有な技術～ソフトウェア見積り: プログラマの思索

ソフトウェア開発の工数見積もりが混乱しやすい理由: プログラマの思索

Scrumの見積りと計画づくりは何故優れているのか？: プログラマの思索

チームは加速するのか～Velocityの使い方 #agilesamurai: プログラマの思索

【1】途中参加したチームは、Androidで緩いタスク管理のツールを作るのが目的だったらしい。
ユーザストーリー洗い出しで、メンバーから案があまり出なかったので、PostItで画面を書きながら紙芝居のように模造紙に貼り付けてみた。
そして、こうした方がいい、などと色々議論して、ユーザストーリーを書いていった。

個人的には、ユーザストーリーはユースケースや要件みたいなものだと思っている。
ユーザストーリーのフォーマットは決まっているものの、それほど細かくはない。
ユーザストーリーの書き方が難しいと言う声も聞いたが、顧客観点でユースケースを作ればいい。
そう思うと、従来のWF型開発のテクニックはそのまま流用出来る。

他チームでは、プロダクトオーナーがいないからユーザストーリーが書けなかった、という話をよく聞いた。
その話を聞いて、よく見かける光景だよなあ、と思った。

と言うのも、受託開発の要件定義では、設計チームが一生懸命資料を作って、やる気満々で顧客の会社に乗り込んだものの、顧客は諸事情でいなかったり、あまり時間が取れずに思ったような成果を上げれなかったりする。
そういういきさつを何度か経ると、要件定義がズルズルと遅れて開発やテストの期間が短くなって、作ったシステムも顧客が本来望んでいた仕様とは違っている、と後で言われたりする。
つまり、プロダクトオーナーが本来の役割を発揮していないのだ。

だが、僕らのチームは、自分たちが欲するアプリを作るためにユーザストーリーを洗い出していたから、自分たちがプロダクトオーナーであり、開発者だった。
だから、とてもやりやすかったし、ユーザストーリーをアジャイルっぽくどんどんブラッシュアップできた。

最近、SNSやゲーム、SaaS系企業がAgile開発に積極的に関わっているのは、自分たち自身がプロダクトオーナーゆえに深く議論できて、ユーザストーリーを作ったら実際に早めに作ってフィードバックする仕組みがあるからだろう。
つまり、要件定義もアジャイルの良さを持っている利点があるのだろうと思う。

【2】そして、ユーザストーリーに優先順位をつける時、データのCRUDに着目して優先順位をつけていった。
普通は、データ登録やデータ更新、そしてデータ表示の順番。
何故なら、まず、データが登録されなければ、データを表示することもできないから。

個人的には、DOAの観点で、データのライフサイクルで考えればいいと思っている。
画面のUIをある程度作れば、渡辺さんの本「業務システムモデリング練習帳 業務システムを効果的に設計するための精選45題」に従えば、テーブル設計はほぼ確定する。
そこで、テーブルのデータがどの機能でCRUDされるか、CRUDマトリクスを作ってもいい。
そうすれば、より明確になるから、優先順位が分かりやすくなる。

【3】一番やりたかったプラニングポーカーの見積りは興味深かった。
最初に@shirokappaさんから、基準となるユーザストーリーは1ptではなく2～3ptを基準にした方がいいよというアドバイスがあった。
実際に2Ptのユーザストーリーを見つけて、他のストーリーを見積もってみると、1ptにしたり、3ptや5ptになってくる。
つまり、相対的に開発規模を比較して見積もっている。

その利点は、三角測量ができるので、相対的に見積もりの精度が上がる点があるだろう。
1ptを基準にすると、全ての大きいストーリーが3倍、5倍のように見積もるしかないため、大きいストーリーほど見積りの誤差は大きくなる。
他のチームの話を聞くと、大・中・小のレベル感のような見積になってしまうみたい。

僕らのチームは最初はカードを出すものの、話しながらストーリーポイントを決めていた。
@shirokappaさんによれば、カードを故意に隠して、一斉に見せる方法もあるらしい。
つまり、最初に出した人のポイントに左右されず、議論が割れやすいので、議論がより深まる効果もあるらしい。
デルファイ法を自然にやっているような気がした。

プラニングポーカーによる見積りでは、過去のポイントを参考にして見積もっている時があった。
例えば、データのグラフ表示のストーリーが5Ptなので、かんばんによる表示のストーリーも5ptだろうと参考にして見積もった。
確かに、似たような機能のポイントはほぼ同等と見なせるから、ストーリーポイントのぶれは少なくなるだろう。

どうしても見積できないくらい大きいユーザストーリーは「Big」「？」というカードを皆で出した後、ストーリーを分割した。
実際にストーリーを三つに分割して、再見積もりしてみると、2pt + 5pt + 5ptになった。
この経験を考えると、例えば5ptを超える大きな見積もりは、ストーリーを更に分割して細かくした方が見積りの精度が上がるのではないか、という推測も成り立つ。

結局、僕らのチームは10個のユーザストーリーで合計30ptになった。
単純に1pt＝1.0MDと見なせば、30MD=1.5MMとなり、3人で開発すれば2週間で終わる規模感になる。
実際そううまく進むか分からないが、皆そんなイメージを浮かべたみたい。

最後の受入基準は結局作れなかったが、ユーザストーリーの受入テストケースを書けばいいだろうと大体イメージは湧いている。

【3】プラニングポーカーによる見積りは実際に試してみて楽しかった。
トランプのカードを出し合うので、ゲーム感覚。
見積りは難しい、という心理的な硬さを解きほぐしてくれる。

実際のストーリーポイントによる見積りは、概算見積りに近い。
つまり、不確実性コーンの一番最初辺りに相当するから、ブレは大きい。
ユーザストーリーからタスクカードへ分割していけば、タスクカードが思ったよりも増えたりして、見積り工数は増える可能性はある。
だが、ユーザストーリーを作った時点で概算見積りして、開発規模を共有できる利点は大きい。
また、見積もったストーリーポイントを1～4週間のスプリントで工数に換算できるから、見積りの評価にも使える。

WF型開発では、FP法で時間をかけて規模見積りするが、かなり一苦労だ。
そして、規模見積りから工数見積もりへ換算できる時期は、1年後の本番リリースだったりするから、規模見積りがあまり役立たない。

プラニングポーカーをやっていると、XPの計画ゲームは本来こんな感覚だったのだろうな、という気がしている。