スクラム道 Full Boost 「青物横丁制圧作戦」#scrumdoに参加しました。
この記事では、選手として参加させていただいて感じたことと、自分が壇上で発言した質問や意見の補足をメインに書いています。
イベント自体については、他方々の記事にとてもわかりやすくまとめられていますので、そちらを参考にして頂ければと思います。
・ スクラム道フルブーストに参加してきた #scrumdo #nawoto_girls - Shinya’s Daily Report
・ スクラム道フルブーストに参加しました。 #scrumdo - k_0kamotoの日記
・ スクラム道フルブーストでひと試合してきました #scrumdo - 炸裂!情熱の右フック!!
スクラム道とは?
スクラム道HPより引用
スクラム道へは、2011/12/26に読み手@ryuzeeさんで行われたスクラム道場.08[「Doneの定義 虎の巻」](http://www.taoofscrum.org/contents/post/214)、2012/03/28に読み手@nawotoさんで行われた[「良く書けたインセプションデッキとは?」](http://www.taoofscrum.org/contents/post/220)の2度参加し、 今回のスクラム道 FullBoostが3度目の参加となりました。
今回のテーマ
今回はスクラム道10回記念ということで、過去に行われた5テーマから参加者の投票で再演を行う形式で、@imagireさんによる「プロダクトバックログ」の再演となりました。
まとめ その1 スクラム道 Full Boost 「青物横丁制圧作戦」 壮大な前座 #scrumdo - Yukarin’Note
読み手の@imagireさんによる発表の後、「議論に参加したい」「プロダクトバックログについて悩んでいる」人が選手として登壇。
選手として登壇した人には、マイクロソフトさんからプランニングポーカーがもらえる!とのことだったので、物欲に駆られて登壇してきました。
ステマ
おぉ!マイクロソフトさんからプランニングポーカーの差し入れだ!!
#scrumdo
— imae masatoshiさん (@modal_soul)
5月 11, 2012
いただいたポーカーはこちら 外箱がVisualStudioになっているという、さすがマイクロソフトさん!
ディスカッションRound1
ディスカッションRound1まとめ スクラム道 Full Boost 「青物横丁制圧作戦」Round1 #scrumdo - Yukarin’Note
プロダクトバックログに関して「ストーリーポイントを見積もる際の基準ストーリーが、後々基準として不適格だった場合どうするか?」と質問させていただきました。
あの場の発言だけでは説明しきれていいなかった部分も多々あるので、ここではこの質問の件を補足したいと思います。
前提として
1つのプロジェクトが開始されるにあたり、プロダクトバックログ(以下、PBL)が作成されます。
このPBLの各項目にストーリーポイント(以下、SP)を見積もる際、基準となる項目(以下、基準ストーリー)を選び、その他のPBLの各項目について見積もると思います。 私のチームの場合、ストーリーポイントが2と5に相当しそうな基準ストーリーを選び、見積もりを行っています
これ以降、新たにPBLに追加された項目についても同じ基準ストーリーを用いて見積もりを行えば、以前見積もった項目と大きさの比較が可能であると言えます。 例)10kgは1kgの10倍の重さです。なぜなら同じ基準(=単位、ここでいうkg)を用いているから
もしも基準が変わると?
基準ストーリーを実際に消化したところ、当初見積もっていたポイントよりもとても大きかったorとても小さかった、とします。
そうすると、その基準を用いた見積もりの結果の信頼性に疑問が出てきます。
例えば、SPが2と見積もっていた基準ストーリー「A」が実はSPが10に相当するボリュームで、SPが5と見積もっていた基準ストーリー「B」がSP2のボリュームだった場合
ある項目「X」の見積もりを、SP2の基準ストーリー「A」以上SP5の基準ストーリー「B」未満だからSP3と見積もった ここに基準ストーリーのSPの変化を適用すると、ある項目Xの見積もりは、SP10以上SP2未満となってしまい、この項目Xの見積もりが破綻してしまいます。
このような場合、新たに基準を設けて再見積もりを行えば問題は解消されると思います。
ただそうすると、各スプリントで計測したベロシティは、基準が異なるので単純な比較が行えなくなります。
ベロシティって重要ですか?
ベロシティを使う目的は様々あると思いますが、ざっと挙げると以下のような感じでしょうか。
・スプリントで消化するSPの見積もり
ベロシティはからないと、次のスプリントでどれぐらい積めるか基準値がわからなくなりません? RT @
kanu_
: 別にベロシティで測らなきゃいいんじゃないのかぁ。ってか誰が欲しがってるのかな?
#scrumdo
— SEO Naotoshiさん (@sonots)
5月 11, 2012
・チームの成長度合い
"ポイントの基準が更新されると、ベロシティによるチームの成長の測定が難しくなる。"
#scrumdo
— Tomohiro Hashidateさん (@joker1007)
5月 11, 2012
ディスカッションでの質問やツイートの反応にもありましたが、決して<h3>ベロシティを人事評価等に使いたい訳ではありません。</h3>この所は、特に強調しておきたいと思います。
ベロシティは「人事評価に使うべきではない」というのは大前提ではあるが、「自分達がどれくらい成長したの?」というのを測るための指標として「数値がぶれる」のはマズイのでは?
#scrumdo
— skowataさん (@skowata)
5月 11, 2012
ただ、現実問題としてアジャイルなプロセスを取り入れたことによる効果を、実際にプラクティスを実行する人以外に説明することを考えたときどうでしょう?
「アジャイルなプロセスを用いることで、どの程度生産性が向上した」、であるとか<h4>プラクティスの有用性を理解してもらえなければ、 今後アジャイルなプロセスを継続することが出来なくなってしまうかもしれません。</h4>
「価値判断で計測すればいい」という意見は正しいと思いますが、スプリント毎のROIを正しく計測するのは(そうできることが理想であり、その努力を惜しむべきではありませんが)難易度が高く早い段階での導入は難しいと思います。
実際にプラクティスを実行する人以外も、アジャイルなプロセスについて本質的な理解をすれば、ベロシティによる説得を行わなくても有用性を理解してもらえるかもしれませんが、 これもかなりハードルが高いと思います。
この質問で知りたかったこと
PBL見積もりの基準が同じであれば、ベロシティの増減がチームの生産性を表す指標として機能するのではないか?
ベロシティの向上によってアジャイルなプロセスの有用性の説明の裏づけになるのではいか?
基準が変化することで、ベロシティが(見かけ上)減少しているような場合、生産性の低下を指摘された時どのように説明することで、見かけ上の誤解を解くことができるか?
ということです。
今の話(ストーリーポイントと実際のタスクの相関)は「通貨(経済の話)」に似てる by @
kawaguti
#scrumdo
— skowataさん (@skowata)
5月 11, 2012
この質問に対するコメントのなかで、@kawagutiさんの通貨のたとえが、とても腹落ちしました。
ディスカッションRound2
ディスカッションRound2まとめ スクラム道 Full Boost 「青物横丁制圧作戦」Round2 #scrumdo - Yukarin’Note
1Rだけのつもりだったのですが、もたもたして残留してしまい、居残り組みとして2Rも選手として参戦と相成りました。
折角の機会なので、壇上から見た景色を写メってみました。
POの価値判断にチームが納得できない場合
POが初心者の場合、「これってホントに正しい優先順位なの?」という場合がある。その場合チームとしてどうするべき?
#scrumdo
— skowataさん (@skowata)
5月 11, 2012
POがPBLの各項目について優先順位付けした結果が必ずしもチームの意見と合致ばかりではないですね。
この話に対して私は「ビジネスとしての優先順位付けはPOの責任であり、チームが剥奪すべきではない」「チームが納得できないのであれば、その根拠をPOに説明必要はあるが、チームが優先順位決定するべきではない」とコメントしました。
これをもう少し補足すると、
- PBLの優先順位付け(≒事業判断)は、スクラムではPOというロールの責任(=権限)。
- POが決定した優先順位付けをチームが覆すことは、POから責任(=権限)を剥奪することになる。
- POから責任(=権限)を剥奪することは、スクラムでのロールが破綻しているのでは。
ということです。
#scrumdo
「POに責任がある」といって自分達の自主性を殺すのも危険なかおりじゃまいか
— atsumi shibataさん (@JibrielShibata)
5月 11, 2012
責任(=権限)はPOにあるから、チームは一切口出ししないと言いたい訳ではなく、あくまで「判断、決定」するのはPOであって、その判断のプロセスをチームが手伝うのアリはだという話でした。 ロールに拘らず、助け合うのがスクラムチームの有るべき姿だと思っています。
最後に
今回この様な有意義なイベントに参加させていただき、スクラム道スタッフの皆様、選手・参加者の皆様、バンダイナムコ様、マイクロソフト様、ありがとうございました。
今回は、@imagireさんの再演となりましたが、他方々の再演も是非是非お願いしたいところです!
Latest post:
- OpenWhiskのScala sbtプロジェクトのgiter8テンプレートを作った
- OpenWhisk+Scalaで作るServerless Architectureとっかかり
- BluemixにPlayframeworkアプリケーションをデプロイする
- sbt、Giter8を統合するってよ
- Scala 2.12.0でSAM型