[音楽]成功するアジャイル開発第7回目はリリースプランニングについて説明したいと思いますリリースプランニングはスクラムはまジェル開発においては
どういうスケジューリングで機能を追加していくかリリースしていくかということをプランニングスケジューリングしていくためのプロセスとして置かれているチームもあるかと思いますけれども私が考えるこのリリースプランニングというフェーズはスケジューリングをするためというよりも
プロダクトバックログをディファイ面と洗い直すという作業をするという位置付けで捉えたほうがより効果の固定価値の高いイベントになるかなと思いますでこのディリースプランニングを以下にはて早く早くやるか特にプロダクトバックログにたくさんユーザーストーリーなり佑也がう
山の擁立と積み上がってくるとこれを毎回毎回に見積もりをし直して優先事業月直してというはリファイン綿と麻それだけの労力かなり負荷がかかっていますですのでいかに手早くいかにいい効果のある方法でに背面とを継続してやれるか
この的に行こうちょっと今回は紹介してみたいと思いますでもすでに aos ml と区画を切ってありますけれどもこれはのチームのベロシティに準じてこの sml を区切る
ポイントを設定してもらえればと思いますこのリリースプランニングはスクラムであればまだスプリントを始めていないチームがいきなり4一番初めにあるというのはあまり意味がないと思っています
できれば4スプリントから8スプリントを回した後でようやくやる涼香ようやくこのリリースプランニングに取り掛かるということでも遅くはないんじゃないかなと思いますしその方がより確実に効率よくやれると思いますといいますのも
チームにとってどういったポイントがこの s ショーですね小さいサイズとみなせるのかというこのs と m の間のこの境界線がどのポイントになるのかそして
この m と l の間のこの境界線がだいたいどれぐらいのサイズだったらちょっと大きすぎるとなるのかというのはそのチームのベロシティによりますから何度も何度も見積もりをするという作業をスプリントプランニングの中でおこなっていくうちにチームの感覚として身についてくると思いますですので
ある程度チームがスプリントを回してスプリントプランニングを何度か経験して見積もるという作業を何度か経験した後にこのリリースプランニングの中でポイントを決めていけばいいんじゃないかなと思います一旦ここではまあ仮にですけれどもチームが s とみなせるのは5ポイントいいかm とみなせるのは13ポイントいいか
ll とみなせるのは13ポイント以上こういった形で一旦仮においてみましたなのでここの境界線はまあチーム日本の状況に応じていれば良いと思います一旦別れておいていますそしてもうすでに付箋が貼ってをありますけれどもまずは後付箋を全部生え剥がした状態
プロダクトバックログの中にあるこれがユーザーストーリーを一気に書き出してみて今はこのスペースの関係上かなり少ないものに絞ってますけれども実際はもっとかなりあると思います特に大規模システム業務システムレガシーシステムの作り替えそういったものになると本当に膨大になると思いますので
それらを書き出したものを開発者何人かで手分けをして一気に入っ張り出していくと担当を変えてですねそれぞれやっていくという形でいいと思いますでまぁ迷った場合にメンバー間でこれどっちだっけ
須田ゲームだっけみたいなことを相談するのも ok ですしここにプロダクトオーナーも参加してどれかなと決めるのもありかと思いますけれどもここもやはり見積もりですから開発者で貼っていってくださいそしてこの
貼っていった結果だいたいこのような形になったちょっとした場合に次にプロが不当なあるいはユーザーに優先順位順に張り替えてもらいます上にある方が優先順位が高く下にある方がいい1000人が低いという形に一度並び
書いてもらえます一応この状況はですね s が9万 m が5枚 l が3枚貼られた状態になってますから一旦ここで
これが全てでいったいどれぐらいのユーザーストーリーポイントが必要になるのかというのを計算してみますでアオジで書いたものが最小で赤字で書いたものが最大とおいてますけれども最小の場合はこの小さい方の数字をこの枚数出かけてみますなので0.5
が9枚45ポイントそしてこちら m の場合は最初が5ポイントですから5ポイントに5枚で25ポイントl の場合は13ポイントが最初ですから
13ポイントに3倍かけて39ポイントこれで私合わせたものがこのサンプルの場合であれば68.5ポイントになったというのがこの最小の見積もりになります正しい
これは最小ですからこの68.5ポイントで実際に実装ができるとみなすのはこれは危険ですこれは可能性としては限りなくゼロに近い最小の見積もりですこれはあの
0%ではないので限りなくゼロに近いと言う意味で7パーセントと言って家へマイクロ%とかいう呼び名で呼んでみてもいいかと思います実際にこの65ポイントで作れるということはまずありえないんだけれどもただしこの65ポイントをさらに下回ることもないと
いう意味でこう65ポイント以上は絶対にかかるとみなせる加減ですねなのでチーム内でもあるいはチームが員に対してもそうですけれどもこの68.5ポイントで作れると思ったへと思わせてはダメです68.5ポイントで作れるわけではないと
ただし規模としてシステム規模としてはこれぐらいは最低かかるのでもしこれをこのシステム欲しいと言っているユーザーが実はもっと小さいもっと短い期間でほしいと言われた場合はそもそももうこれを削るしかないんですよそういった指標の角栄コミュニケーションのきっかけとしてこの数字は用いてください
最大の場合はその子の最大の部分で掛け算して最後l はですね最大はもう無限大と見なしますけれどもこれも軽いですね無限大だと計算ができないので入ったは50ポイントを置いて
すべてを足し合わせると260ポイントになるとただこれも最大と言いながら無限大を借り50磨いてますからもっと大きくなる可能性がありますなのでこの際症に関してはこれを下回ることはないしかし最大に関してはこれを上回ることがある
そしてこの2つの数字を見るとかなり開きがありますね68.5ポイントと260ポイントですからかなりの大きな幅があります見積もりに関してはそれぐらい幅があるということをまずはチーム間で認識をする人がありますけれどもじゃあそもそもなんで3つこういった形で見積もるんだと言いますと
プライオリティをつける際にこれよりも小さいものをユーザーが望んの望んでいたりあるいはチームが無理なコミットメントをしないためにもこれよりももっと早く作りたいあるいはこの最大があまりにも非現実的すぎるっていうのであればどれか築きましょう
この絵の中でもさらにこれをもっと小さくですね具体的なユーザーストーリーに分解しませんかといった形の考える切り口を生み出すためですねその後これらを再度プロダクトバックログに入れなおすんですけれどもその際にこの優先順位の高い順からどんどん入り直していく
そうしていくとその上から順番にですねポイントを立ち上げていくと今のチームの平均 velocity で1スプリント目で次の1スプリントでここまで次の1スプリントとここまで次の1スプリングでここまでといった形で
を大まかにこう切り分けられていくと思いますのでそうなると大大会初の期間がこれぐらいリリースできる期間これぐらいといったのが見えてくると思いますそういった形でいつどのタイミングでどんな機能をリリースできるのかという現実的な
数字というのをここで導き出すただこれは導き出すのが目的なのではなくてチーム感がチームのメンバーがユーザーを含めた各ステークホルダーに対して今自分たちが作ろうとしているシステム
がこれから先どの機能が重要でどの機能をを作るのにはこのシステムを完成するのには最低でもこれくらいの
ポイントが必要なんだということを見ていくプロセスになりますなのでできる限りたくさんコミュニケーションをとってそしてこの張り出したものに対してじゃあどっ2010いく重要なのかというのを開発者含め議論をする場にしてくださいなのでリヴァイ面とする際に
プロダクトバックログを出してきて出してきてですねひとつ歳見積もりをかけて順番を入れ替えてなんてやってるとすごく時間がかかりますのでこのテクニックを使って見積作業という先人をつけるという作業がこれでかなり簡略化でできて時間を短縮できますので
それを元にしてスケジュールをside a 上から順番にプロダクトバックログを並べたそれらをスプリントで区切ってプランニングするという形で時間短縮をしてみてください
この場合今からここには models ユーザーストーリーマップだとかストラクチャーズあれビヘイビアマップそういったものをここには置いてませんけれども実際には壁に張り出した状態でそれでは見ながらこの機能とこの機能はこの箇所だから
まず先につく必要があるねとかですねあるいはもしこれを削るんだとしたらこのモデル頭の中の子が抜け落ちてしまうのでシステムとして不安定になるあるいは不完全なってしまうそういったものを議論しながらこれは削れるあるいは削れない単にユーザー視点として別に欲しくないかなとか入らないかなって
いう議論で削るのではなくてシステムとしての完全体を考える上でそれは削っても大丈夫なのかあるいは系するといっても丸解けずのではなくてやれる機能としての適用範囲を絞ったものも機能としてでえーっ
その知っても何組み込みませんかあるいは別の機能として置き換えませんかそういった話をこのリーズプランニングの中で変えようとして発生させてみてください常に ry という観点で開発をする機関に対して提供できる機能の勝ちこれらを常にプロダクトオーナーは意識しながら海を進める必要がありますけれども
プロダクトバックログの全てに於いてその意識を持ち続けながらやる際にはできる限り短く早くのに負荷をかけない状態でやれるそれが味わえるに開発を進めるうえでは非常に重要になります私たちの脳のリソースは限りがありますからあまりにも大量の作業を長時間やると
正しい判断ができなくなりますですのでその時間も短縮しながら我々が包括しないといけないところになるべくリソースへのリソースを割いてあげるそういった形で日々のこのリリースプランニングだけに限らず日々のデイリーサーブミーティングなり
モデルモデリングなりを負荷をかけずに簡略化して本質を突いた作業に特化して集中できるようにするそしてなるべくコミュニケーションも本質を突いたコミュニケーションをするオープンなコミュニケーションするっといった形で進められるようにしてみてください