天の月

ソフトウェア開発をしていく上での悩み, 考えたこと, 学びを書いてきます(たまに関係ない雑記も)

アジャイルカフェ@オンライン 第72回に参加してきた

agile-studio.connpass.com

こちらのイベントに参加してきたので、会の様子と感想を書いていこうと思います。

会の概要

家永さん天野さんじょうさんの3人のアジャイルコーチが、アジャイル実践者から寄せられた質問に答えていくイベントです。今日のテーマは「アジャイルにおける見積もりのやり方は?」でした。

会の様子

前提

契約のために行う見積もりの話はしないという前提がありました。

見積もりの目的

チームの認識を合わせることや集合知を活用することが挙げられると言う話がありました。

また、ターゲットとコミットメントは混同しないようにする必要があるということで、このあたりまでに完了させるぞ、というターゲットを決めた後にコミットメントしていく(=約束ではない)というのが重要だそうです。

見積もりのやり方

ユーザーストーリーやバグなどが見積もり対象で開発者が見積もりをすると仮定した場合、どういう見積もりをするかという話をしていきました。

見積もりは継続的にしていくものであり、前提を多数入れて緻密にするのではないという話や、相対見積もりをしないといけないとは決められていないし相対見積もりの方が人気があるのだけれども時間見積もりでもいいということです。

また、手法としては、アフィニティ見積もりやミュートマッピングを実施するといったものも代表的なものとしてはあるということでした。

No Estimate

実践経験はないものの、同じくらいのレベルでチケットを切ることができるのであればNo Estimateも選択肢としては出てくるんじゃないか?という話がありました。

Q&A

タスクも相対見積もりするのが人気か?

タスクの見積もりに関しては言及されていないものの、立ち上がりのチームが練習的な意味合いも込めて見積もりするのは良いのではないかということでした。

実装を始めてから見積もりよりも大変なことが分かったらどうする?その逆は?

一旦チケットを置いといて次以降の見積もりの参考とするパターンや、見積もりをし直すパターンがあるということでした。

逆に見積もりよりも早く終わった場合は、機能をより多く作るのが良いということです。

プロダクトリリースまでの見積もりに対して進捗状況を知る方法はバーンダウンチャート以外にあるか?

質問に直接回答できていないですが、母数が変わることがあるので、リリースバーンダウンチャート自体もいまいちだと思っているという回答がありました。

あくまでも状況がどうなっているかだけを見るのが大切だということです。

会全体を通した感想

質問がめちゃくちゃ活発で、みなさんが見積もりに対して興味がかなりあることが分かったのが良かったです。

自分がスクラムとかの研修をやるときも見積もりの部分に関しては活発に質問が来るのですが、これは自分の職種によるものだと思っていたので、あんまり職種によらない傾向なのかもしれないなと感じました。