[音楽]成功する味ある開発第5回目今回はこの見積もりについて説明をしたいと思います皆さん見積もりはされてますでしょうかちょっとですね計画堂の中でも見積もりというのは非常に重要なフェーズと置かれて
いると思いますし見積もりにたくさんの時間を割いていると思いますしかしその見積もりですけれども果たして同様に役に立てているでしょうかアジャイル開発においては役に立つかどうかというのは非常に重要です
役に立たないものであればやる必要ありませんし逆に役に立つように使うべきですですからこの見積もりは従来の太田ホール会ウォーターフォールモデル低角度開発では
役に立たないどころか害をなすものだったりしますので今から説明するこのアジャイル開発における見積もりというのは実はその使い道も使い方もまったく違いますですのでこの役に立つ見積もりというのは一体どういうものなのかというのを今から説明していきたいとおもいます
まず見積もりについてですけれども時間で見積もっているというプロジェクトが多いと思いますし今までの習慣上3時間見積りというのは多く使われてきました
しかしアジャイル開発においてはこの時間見積もるという概念はいったんストップしてくださいなぜかと言いますと人間はこの進退的感覚認知と私ちょっと書いてますけれども時間という概念を体の感覚進退的感覚でとらえるというのは苦手です
例えば親しい友人と楽しいおしゃべりをしているとき時間はあっという間に過ぎますそう感じます真夏の暑い中外で待たされていた場合
非常に長く感じると思います両者がともに終わった後に何分くらい経ったと思いますかと時計を用いずに質問された場合
果たして正確に答えることができるでしょうか時間というのはそれぐらい人間にとってみてトライ所ない難しい感覚なんですねですので人間にとってみると時間という感覚時間という単位で物事を見積もるというのは実は苦手ですから
その苦手な感覚苦手な能力に頼るのはやめてこの特異である進退的感覚というのを用いることにしてみたいと思いますまず人間が認知しやすいものというのはまず1つが空間に対する
認知というのは認知しやすいです例えば距離高さあれ広さこういったものはある空間に対してこの空間は何倍ぐらいのサイズですかとかですね
高さに関してもうこの高さに大対してこれはどれぐらいの高さでしょうかな何倍の高さでしょうか何倍の距離でしょうかっというのは比較的正確に信頼できる感覚として用いていますますもう一つが出漁
重さあるいは濃さこういったものも比較をする場合に心体的認知としては感覚として例えばどちらの方が重いのかどちらか悪いのかというのは
言い当てられることができますってこれは比較するという方法で用いてますけれどももし比較をしなかった場合はやはり苦手です持ったバッグの重さこれを今何キロかを当ててくださいって言われるとなかなか正確に言い当てることは難しいと思います
2つのバッグを持ってどちらのバックの方が重いですか言われるとかなり正確に答えることができると思いますその差が大きければ大きいほど明白にその違いを言い当てることができると思いますけれどもかなり近い5必要重さであったとしてもどちらが重いかというのを言い当てることはそんなに難しく
ないと思いますソフトウェア開発で機能を見積もる際に時間という単位でみつも郎とするのではなくてこの進退的感覚に置き換えるようアナロジーですね置き換えることで見積もってみましょう基準となるにこれをまず
キーもの中で決めます例えばへ業務アプリを業務用のシステムアプリケーションを作ろうとするプロジェクトであればがあるとてもデータのメンテナンス画面マスタメンテナンス画面を
せまず基準におこうと決めてそれを2としてそして今からみつも郎としている機能がそれに対してどれくらいの規模なのかどれぐらいのa
重さなのかふぐザストなのかといったことをこの見積もりの時に比較と比較の対象としておくといいと思いますここで決してマスタメンテナンス元あの希望ドアのままマスタメンテナンス画面基準に
おいたものだったら2時間で作れるから今回のものを8時間で作れるだろうといった形で時間という概念をそこに取り込まないようにしてください時間と意外にはそこに取り入れた瞬間に認知は歪みます先ほども申し上げましたとおり人間は時間という感覚を認識するのが苦手です
友達と楽しく喋った時間と外で暑い中まだされた時間これらを後にがて比較してもどっちの方が長かった短かったかというのも正確に把握できないのと同じで
この基準に対して対象を用いるときであっても単位を時間という単位で見積もらないように注意をしてくださいこれはスクラムマスターがもしチームメンバー開発メンバーが時間という単位で考えようとしているなを着替えようとしているなと感じたら積極的に介入してください
介入をして決して時間ではありませんよとそして付け加えるべきはその3つ持った結果はにに対して8だったというこの8という数字にも実は大してにはありませんこれはこの後説明しますけれども3つ持った結果として出てきた数字が重要なのではなくて
3つもぷロードするそのプロセスの中に役に立つ価値がありますなので見積もりというのはこの出てきた結果を正しく予測しようとかこの数字を足し算したいがために見積もりを出そうという目的で使うと見積もりというこの行為は役に立たないものになります
むしろ有害なものになりますこの3つ守ろうとするプロセスの中で得られる様々なそのプロセスの中で見出せる情報あるいは共有あるいはイメージの鮮明化
そういったものに価値がありますのでですので基準を置いたらそれに対して今から作ろうと思うものがどれくらいのサイズなのか複雑どうなのか規模なのかといった形でどんどん見積もっていくというのがアジャイルに開発する際下の見積もりの
スタートですねこれをまず念頭においておいてくださいこの見積もりをどのようにすれば役に立つものとして使えるのか見積もりというのはこの
書きました2つのために用いるのではないというふうに前半いましたスケジューリングするためどれぐらいで作れるのかというのを決めるためではありませんそしてコミットメントのためでもありませんこれ以内に作りなさいと迫るものでもあり
ませんじゃあどういうのが見積もりの役に立つ使い方なのかといいますと日ノー分割を素早く行う判断をするためですねここにこの見積もりというプロセスこれが
役に立ちます見積もった昨日が8という見積もりが出た場合いい今のチームにとってみて8は大きすぎるとなると者小さく分割しましょうという風にすぐに判断をすることができます判断して分割をしてみた結果
た幸せたら急になった元の8よりも大きくなってしまったとしてもですねこれらを分割して1つずつ確実に作ってその一つずつにフォーカスをするという形で作り終わった場合振り返ると分割をせず
8のまま作った時よりも実は分割をした方が早く終わるということが起こります時間と考えると8と9だと8の方が時間がかかってしまうと矛盾しますよねなのでこれは時間ではないんですね時間で置き換えるのではなくて規模あるいは複雑道これがでこの数字が見積もられています
ただこれがこの鉢がチームのベロシティに対して十分なまで小さいのであればわざわざ分割する必要はありませんその場合であればこのまま作ったほうが早いということになりますこの8という数字自体に意味があるのではなくてチームのベロシティに対してどうなの
かという比較が必要になります春チームでは8だったら分割しようですけどあるチームであれば16でも分割しないということが起こりえますそれはそのチームが何の基準を基にしてそもそも
見積もりをスタートさせたかによって変わってきますのでこの数字が大きいた小さいかというのはそのチームのその状況velocity 布状態に打って変わってきますそして見積もり自体は開発メンバーのみで見積もってください
開発メンバーがある基準に対してその2頭いた場合今回作ろうと思っている機能作る対象の機能はその2に対してどれくらいなのかという形でそれぞれが同時にですね
出しますこれはプランニングポーカーといわれるフィボナッチ数列を用いたカードこういったものが一般的にも普及してますけれども私はフィボナッチ数列だけじゃなくてもそれこそ何でもいいと思います数字が判断しやすいわかりやすいので数字を用いるというの良いと思いますけれども
開発者がまず自分たちで見積もるということが重要ですでそれによって非常に大きく見積もった開発者と小さく見積もった開発者これが本当に大きな差が開いてしまった場合に入っ
なぜという形でその大きく見積もった理由を確認します逆では小さく見積もった理由も確認します見積もり大きな開きが出たということは開発者の頭の中のイメージが実は食い違っているということがここで発見できる発見できるきっかけになりますすると
大きく見積もった開発者に意見を聞くとこういう間が出たりした場合例えば今回使おうとしてるアーキテクチャは大私にとってあるいはチームにとって過去に例のない過去に作ったことがない architecture なので
もしかすると全然わからないところでハマるかもしれないあるいは小さく見積もった開発者が今回のシステムに関してはこのテープとこのテーブルを作る使うということですけれどもこれは非常に簡単な操作なので私はそんなに難しくないと思いますしかしそれに対して大きな見積もりをしたかいましたがいやいやこのテーブル床の
テーブルとこのテーブルもこのテーブルを使う必要があるしこのテーブルワークしかも外部のあるシステムに依存してますよなのでそこも含めて今回は開発しないといけないのでその複雑度を考慮してますかとなれば小さな見積もりを出して発射はあなるほどそれはコールしてなかった
じゃあそれをコールするともう少し見積もり大きいかもという形でそれぞれが見積もりに差異があることこれはまずきっかけとしてなぜそういう妻があるのかというのをチーム内で共有をして話し合うと実は詳細な部分が描けてなかったあるいは分からないことが多かった
あるいは不確実なところが多かったということが炙り出せますさらにもう大きいのであればより詳細なところをイメージするが難しくなりますのでそこを十分に議論するよりも先に分割してしまって分割をした結果に対してさらに議論をしていく方がいい
より早くスピーディーに目的を果たせますですので開発メンバー以外の人がもし見積もっていた数字を開発メンバーに押し付けていた場合であればそれらはスケジューリングのためであったりコミットメントのためであったりします見積もりの
使い方としては役に立たない使い方ですねユーザーが見つ持っていたりあるいはチームのメンバー以外の例えば上流行というあるコンサルタントなんかが見積もっていた場合それがをそのまま導入してチームメンバーにこれがもう見積もりですからと渡してしまうとその見積もりはコミット面倒になってしまいます
その時間内に作りなさいということになるわけですねその見積もり自体は逆に立たないばかりかが異様なしますその納期に間に合わせおとしてその見積もりに間に合わせようとして6をします品質を下げたりあるいは不確かなまま作らざるを得ない残業してしまう時間をオーバーしてしまう
そしてそれがコミットメントになってしまった場合にユーザーはそのタイミングで機能がリリースされるものだと思っているのにリリースされなかったとなるとユーザーが失望します衝突しますといった形でこの見積もりをきっかけにしてさまざまな問題が生まれてしまうわけですね
これらのためにならないように見積もりの使い方をこれらのために使わないように役に立たない使い方をしないようにあくまでも見積もりは開発メンバーのみで見積もってそしてあくまでも機能分化と素早くを行う判断をするためと割り切って見積もりを素早く素早く行っていくようにしてください
後から振り返るとそれらの見積もりの方がはるかに役に立つ見積もりを数字だったりしますのでこの後ですねその数字を者実際にこのスケジューリングがコメットミントのために使ってはいけないんですけれど
も結果的にスケジューリングに使えるものになったりすることがあるという風になりますのでじゃあどうやってこの子のように行った見積もりをスケジューリング生かせばいいのかというのは
リリースプランニングを説明する動画の中ねーまたベッドを紹介していきたいとおもいます