[音楽]背コースラージある開発第3回目今回は版ダウンチャートについてお話をしたいと思いますburn down チャートは皆さん司会入る所においてますでしょうか恨ま第二回目の時と同じ
表現になってしまいますけれどもスクラムボードについてもその晩ダウンチャートについてもなるべくですね普段メンバーの視界に入るところに置くようにしておいてくださいこれはですねスクエアのボードはお子様に
ポストイットふせんを移動させるという意味でも視界に入る必要がありますけれどもこの版ダウンチャートもう実は視覚的に何かを訴えるために利用するということですので今日はこのその何かというは何なのかというのをご説明していきたいとおもいます
まずはこの burn down チャートまあこの場合は1週間のスプリント5営業日後稼動日というのを考えた場合にとりあえずはこういった形式になると思います鳥阿絵図今仮にですねこのチームの
今回のスプリントで作るサイズをちょっと仮にちょっと決めてみますって諸々の機能膜ぜ今回このスクランボーダーこれあの burn down チャート一致してませんのでこれはまあ一旦無視していただきて結構なんですけれども
もしですね仮にこのスプリントで作ろうと思っているもののサイズがまあ仮にですけれどもねに15.8ポイントこのスプリントの中で作ろうと思っているとなった場合に大体こんなものは半分半分と
だいたい狩りで大雑把におけば大丈夫です半分玉13そして上釜17.5でまぁその下が6.5とかですねだいたい半分に近いもので
わかりやすい数字で半分半分半分とやっていけばいいと思いますそれにたいそれで江李双曲線を引いてもしうまく順調にいけばこんな風になりますようと目安のラインですねこれが聞かれますでその下に日付を書けばいいかなと思いますので
こういうふうにですね実際の日付を買いですねどれぐらいで作り切らないといけないかといった目安の日付を書いておきますでまでは実際にこのスプリントを動かしていてですね官僚に持って行ったとします
それによってday one がですねちょっと下がったといった場合に例えばですけれども21.3にあったとちょっと下がったとそして
次の日米3ではまったく触れなかった21.3のまま横ばいだとかデイ方ではですね
ちょっと下がって15.1ぐらいになったとしますそして day 5でかなり下がった5.8まで佐賀とか少し残った今回のスプリントで作り切ろうと思っていた
すべては作りきれなくて少し残ってしまったまあこういった状態の版ダウンチャードが出来上がったとしますでこの場合この横ばいの箇所ですねこういったどうすればよかったのかこれをあぶり出すためにこの burn down チャートというのは実は機能さ
せることができますこの版弾チャートを見えるところに張り出す効果というのは日々下げていくということをチームの中で意識させることにありますチームメンバーがいかにして日々確実に
下げられるかというプレッシャーこれをチームメンバーの中で共有するためですねスクランマスターはその中でも横ばいになってるなあるいはよく by なりそうじゃないかということに対してアテンションをかけるんですね横ばいになっているなぜ大畑になってるんだ
これをチームメンバーに意識させることによって会議が長すぎるんじゃないかとか割り込みタスクが多すぎて開発に集中できてないんじゃないかとか一番多いのはユーザーストーリーが大きすぎるんじゃないかという問題ですね
この burn down チャートを下げようと思いますとこのトゥー秒からブーイングに持っていくだけではダメでそのルール員からさらにダーンになったこの瞬間に触るわけですからもしこんな風になっていたらその日の
burn down チャート下がりませんそういったことがこの burn down チャートを用いることによって見つけられたりしますこの付箋一つのサイズです不正1つの単位ですけれどもこれはタスク単位ではありません
これはの第2回目で説明しましたあくまでもユーザーストーリータイガーあるいは機能単位ですからこれらをだーに持っていくと出荷できるとあるいは
プロダクトオーナーのレビューが受けられるという状態ですからこれらはタスク単位ではなくてユーザーストーリー化機能単位であると友好度を狙いますとこれが下がっていないということはユーザーストーリー機能として分割をする小さくするということを考えないといけません
これはなぜなのかあるいはそもそも分割を指定してどうすればいいのかということを考える必要があるんですけれども
これよく受ける質問なんですけれども例えばにスプリントでエジスプリント2週間で開発をしているチームがあったとしますこのチームが2週間で大したものは作れないなかなか出ればできる機能がすっないんだぞ
それでチームとしては3週間で作りたいあるいは4週間にしたいとこういった相談を受けた場合大抵は
1スプリント2週間で作れないから3週間にしたところで実は大したものは作れません4週間にしたところで実は大して生産性を上がらないんですね重要なのは1スプリント2週間と決めたことによって何をしているのかの方が重要でそのチームが
取り組もうとしているユーザーストーリーのサイズユーザーストーリーそのものがそのチームにとっておっきすぎるとそのチームの生産性に対してユーザーストーリーが大きいということですねなのでユーザーそのチームは消化しきれないという現象が起こっている
これがむしろ問題だったりしますですのでそのチームの生産性がどれぐらいなのかというのをまず理解する必要があるんですけれどもチームが生産性を上げるというひとつの目標があった見せよう現状のチームの能力を考えるのであれば
もっと小さいユーザーストーリーに分割をしていく絞り込んでいくと言う必要がありなので1スプリント2週間出るで大したものは作れないんですと思ってるんであればそもそものユーザーストーリーをもっとちっちゃくしましょうと考える必要があるのでむしろ私はそういった状況にあるチームに関してはむしろ逆の
アプローチを取ります1スプリント2週間ではなくてむしろ1週間でありませんかとこっちの選択肢を私は提示しますなぜそんなことをするのかといいますと1週間の中で作ろうと思うとかなりユーザーストーリーを小さくしないとリリースでいきたい
それこそ1日で作れるサイズこれをまずチームがどれぐらいのサイズであれば1日で作れるサイズなのかというのをチームメンバーが正しく把握する必要があります1日単位で作ろうと思うとかなり小さなさてサイズにしないと作れないということが実感できると思います
ですのでチームメンバーが2週間で機能を作ろうという意識から1日でどれぐらいの機能を作らないといけないのか1日で自分たちが作れる機能のサイズというのはどれくらいのものなのかユーザーストーリーするとどれくらいのサイズなのかというのをまずは意識させる
理解させるということをやるためにもむしろ期間を短くするというアプローチを私は取ったりしますこれは本当ケースバイケースですので必ずしもじゃあそういった状況のチームが1週間にすればうまくいくかというわけではないんですけれども
ユーザーストーリーのサイズを見てそのチームが甘くっうまく消化しきれないというのを見焙り出す必要があるのでその前にこの burn down チャートを用いるとずーっと横ばい
あるいは最後にまとめて下がってくるみたいな状態にもチームがあったとすればそれはユーザーストーリーが大きすぎるということになりますですからこの横ばいが起こった時点でもしこんな風になっているのであればこれを
戻しましょうで全員でこれらを取り込みましょう確実に一つずつだーに持っていきましょうと促す場合もありますしもしそうでなくて初めからこの状態で
全然落ちないんだとすればそのチームにとってこの3ポイントというのは大きすぎるんですもっと小さいものに分割しましょうというのを促しますですのでこの3ポイントとかにポイントというのは
チームメンバーが見積もっている必要がありますこれが外部の誰かが3つ持ったものがなぜかチームに押し付けられた形でチームメンバーが作ろうと思う時にはもうすでに見積もりが終わっている状態で渡されるというのはダメですたまりですけれども
ブルー沢東オーナーが初めにも3詰まってしまったものこれをチームメンバーに対してこの見積もりでいきましょうと私の場合これはダメですあくまでもチームメンバーが自分たちの頭の中で自分たちが過去に作ったもののこれと比較をした上で何ポイントナム彼をチームメンバーが導き出すというのは重要です
出なければここに割り振られているポイントは全くの意味のない数字になりますしこれが下がらなかったことの原因がユーザーストーリーポイントが大きすぎるんじゃないかと議論そのものをまた無意味になってしまいますので見積もりはそもそもプチのメンバーでやるものそして
このポイントそのものがメンバーにとって大きなは小さいのかというのも重要になってきますはいでこの場合であればじゃあどう計算すればいいか
といいますとそのチームが作れるサイズというのをまずthat ですけども計算した方がいいと思いますこの場合だと1スプリントが5日間ですから
いつかなわけですねそこに対してチームが今回のスープ通常ですねそれまでの何スプリントが回してきたところで安定した velocity のポイントがわかると思います今回の場合は例えばスプリント8だとした場合に
その8より前のスプリントの中である程度高いところで安定してきた状態にあったとしたらその安定してきた状態でのポイント持ってくると思ってくると20ポイントだったとした場合にいつか他に落とそうと思う1日当たり4ポイントですね
で落としていかないとダメだぞとなるともしですねまあこれはさんとさんとになので4よりも小さいから大丈夫ですけれどももし今読ん以上のものがユーザーストーリーとしてあった場合それはそのチームにとって大きすぎるということですね
ですのでもし見積もりで4以上のいざストーリーっぽポイントの方がこのユーザーストーリーとしてあるんだとしたらそれは積極的に分割をしましょう小さくしましょうという風にチームメンバーに促してですねもっとこのユーザー須藤力は別の形として版分割はできないのかという風にしてより小さなユーザーストーリーにしていくということを促します
そして細密も利用してい文化としては小さなもう開発を2として取り組んでいくということをしていきます分割した結果もともとのサイズよりもトータルが大きくなるということもあります例えば3ポイントのものを分割して
1.81.8でたしたら3.6になるみたいなこともありえますそれは当然オーバーヘッドが発生しますからもともとのユーザーストーリーポイントも分割したことによってさらに大きくなるということは通常あり得ます
ありえますけれどもそうでもして小さくした方が最終的な消化するスピードが上がりますこれ何が一見矛盾してるように思うんですけれどもトータルとしての効率性を求めるのではなくて目の前にある
えっ業務タスクを確実にこなしていくそして確実に機能としてリリースしていくということもチームメンバーとしてはまず第9線として意識できるように持っていくこれが
この開発で味わえるに開発する上では非常に重要になってくるし姿勢になりますという意味でこのチームにとってみると4ポイント以下にしましょうとしていくとこの burn down チャートが確実に落ちるんじゃないか
という風になりますのではじめにこのユーザーストーリーを見積もるタイプないときにですねもし4本4ポイント以上の見積もりがを出してしまった場合にチームメンバーをそのタイミングであれ待てよこれはちょっと大きいんじゃないがという風にして
抱えその機能をどうすればいいかというのを考え直すということをその場ですぐにできればいいと思います一つずつでもいいんでだーに持っていきましょうという風に考えるそのきっかけがこのburn down チャートの使い方になります