効果的なスプリントプランニングのトライ

効果的なスプリントプランニングのトライ  Retty株式会社  今井貴明  Scrum Fest Osaka 2021   2021/06/26  

自己紹介  • TK (Imai Takaaki)  • エンジニア  ◦ 2015~ SIer 
◦ 2021~ Retty株式会社  • @t_k_redman 

今日のお話 

スプリントプランニングについて話します  • スプリントプランニングってどんなことするイメージ？ 

スクラムガイドによると・・・  https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf スプリントプランニングは次のトピックに対応する：トピック 1：このスプリントはなぜ価値があるのか？トピック 2：このスプリントで何ができるのか？トピック 3：選択した作業をどのように成し遂げるのか？

スクラムガイドによると・・・  https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf スプリントプランニングは次のトピックに対応する：トピック 1：このスプリントはなぜ価値があるのか？トピック 2：このスプリントで何ができるのか？トピック 3：選択した作業をどのように成し遂げるのか？端的に言えば
「やることを決めてタスク分解」・・・かな？

スクラムガイドによると・・・  https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Japanese.pdf スプリントプランニングは次のトピックに対応する：トピック 1：このスプリントはなぜ価値があるのか？トピック 2：このスプリントで何ができるのか？トピック 3：選択した作業をどのように成し遂げるのか？今日は特にこの部分について

スプリントプランニングで実現できると思ってること  • スプリントゴールまでの道のりをクリアにする  • デイリースクラムの効果を上げる  • 開発チーム内の文化ができる 

きっかけ 

スクラム学び始めのスプリントプランニング理解  スクラムマスター兼開発者の私   スプリントの計画を立てるんだな〜〜〜タスク分解な〜完全理解  ガイド読んだ 
トレーニング受けた  • スクラムガイドとかの説明を読むと一応理解できる  • スクラムイベントの中では比較的イメージしやすいイベントではあると思う 

やってみると難しい①  • タスクが大きくなりすぎたりふわっとしてしまう  ◦ やってみないと、調べてみないとわからないからざっくりタスク化  ◦ タスクボリュームが読めなくてバッファを積んでしまう  調査確認

やってみると難しい②  • タスクが属人化してしまう  ◦ 詳しい人しか取れないタスクができる  ◦ スキル的に取れるタスクが限られる 

やってみると難しい③  • 時間がかかりすぎてしまう  ◦ 半日とか1日とかかかってしまってもっと短くしたい  ◦ 作業に費やす時間の割合が減ってしまう 

昔々あるところのチーム  • チームメンバーは自分を含む4人  • 結成3ヶ月くらい  • スクラムビギナーズ  • 自力でコーディングできるメンバーは半分 

チームの抱えるスプリントプランニングの悩み  タスクが大きすぎるタスクによって特定の人に偏ってしまうスプリントプランニングに時間がかかる

一番の課題はスキル差  • 一人では取れないタスクも多くありパフォーマンスに影響が出ていた  • コーディング経験が浅いメンバーを常にフォローしながら進めている状態 

自力で書ける・書けないの違いは何？  • コーディング経験が浅いメンバーも、基本的な文法理解はあるし一緒に処理を追えば読むこともできる  • ヒアリングしていくと「何から手をつけたらいいかわからない」という課題がありそう 

• コーディングって何から始めてどうやって進めてたっけ？  無意識でやっていることを言語化してみる  処理の大枠の流れから•••    データ取り回しに必要な処理を  洗い出し•••    モデルクラス•••関数••• 

それをみんなでやってみれば良いのでは  • 普段は頭の中で無意識にやっている手順を会話で確認しながらスプリントプランニングでみんなでやってみることにした 

トライと結果 

スプリントプランニングでやったこと①  • 処理順を会話で確認しながら実装内容をコメントで書いていく  ◦ 最初は「ここでこの配列をループさせてこの変数に値を入れていく」くらいまで  ◦ 基準は「みんなが自力でコーディングできる」こと  • コメントをキリのいい範囲で切って一つのタスクにする 

スプリントプランニングでやったこと②  • わからないことがあった場合は調査  ◦ 細かくタスクを切っていくためには不確実なことをなくしていくことが必然  ◦ APIの仕様、データ構造の検討、既存処理把握など今まで調査タスクにしていたものは全てスプリントプランニング内で消化した 

細かくタスク分解していった結果  タスクが大きすぎるタスクによって特定の人に偏ってしまうスプリントプランニングに時間がかかる • 誰が見てもやることが明白な状態になり誰でもタスクが取れる  •
経験が浅いメンバーに対してレクチャーもできた 

細かくタスク分解していった結果  • 属人化排除のためのタスク細分化でやることがクリアに  • 不確定要素が減ってバッファを積む必要がなくなった  • メンバー間での仕様の認識乖離がスプリント序盤で解消した  タスクが大きすぎるタスクによって特定の
人に偏ってしまうスプリントプランニングに時間がかかる

細かいタスク分解でチームの文化ができてきた  • スキルの高い人に引っ張られてレベルが底上げされる  • レベルが上がると必要なタスク粒度や表現方法も変わる  • 思想が揃ってくる  ◦ クラスやコンポーネントの設計、関数の切り方、モデル化などのルールが確立されていく 

未解決の課題  • 調査事項も消化しながらタスク細分化までやるので当然さらに時間はかかる  タスクが大きすぎるタスクによって特定の人に偏ってしまうスプリントプランニングに時間がかかる

時間かかってもいいんじゃない？  • むしろこれくらいやらないとスプリントゴールまでの道なんて見通せない  ＝タスク粒度が粗いと検査の精度が上がらない  • なぜ「調べないと分からない」ことが残ってるのにスプリントゴールが達成できると思っていたのか・・・ 

そうは言ってもMTGに時間をかけたくない・・・  • 手を動かしてない時間が増えると不安が募る  ◦ 当時スプリントプランニングに1.5日くらいかけてた  ◦ 1週間スプリントなので手を動かせるのは60％くらい 

そもそもMTGとして捉えない方がいい  • WFでいうところの詳細設計をしている  • 設計工程をモブワークしているのだと思えばこれも必要な時間 

でもそんなに細かくして大丈夫？  • タスク間の依存度上がらない？  ◦ 時間にして15分とか30分のタスクになる  ◦ きれいに疎結合のタスクにするのは難しい  • 結局一連のタスクを同じ人がとることにならない？  ◦
それスクラム的にどうなの？  ◦ それなら細分化しなくても一緒じゃない？ 

目的は「透明性を上げる」こと  • 全てのタスクを疎結合にすることが目的ではない  半日見込みのタスクに昨日から着手してます。多分昼過ぎくらいに終わります。例えばデイリースクラムで・・・  30分見込みのタスクが半分くらい仕掛かってます。次はこの30分タスク取って、午前中は
3つくらい消化できそうです。スプリントゴールに向けた検査がしやすいのはどっち？ 

ブラックボックスこわい  • 半日で終わる根拠がわからない  • 当人が気付いていない問題が眠っているかも  • 「このタスク思ったより時間かかった」というときに振れ幅が大きい 

「依存関係になりにくい設計にする」という考え方も  • 「必要な関数は何か」という視点で分解していくなど  ◦ 依存関係のあるタスクを少なくできる  • タスク細分化のためだけにそうするわけでもない  ◦ リファクタリングしながら計画するイメージ  •
関数ごとに実装するならついでにテストも書いちゃったり  ◦ どこかで聞いたような設計方法論がハマりそう 

まとめ 

スプリントプランニングで実現できると思ってること  • スプリントゴールまでの道のりをクリアにする  • デイリースクラムの効果を上げる  • 開発チーム内の文化ができる 

スプリントプランニングで実現できると思ってること  • スプリントゴールまでの道のりをクリアにする  • デイリースクラムの効果を上げる  • 開発チーム内の文化ができる  • 不確実なことはクリアにしてしまってやることを明白にする •
タスク細分化の過程で実現内容（仕様）の認識をすり合わせる

スプリントプランニングで実現できると思ってること  • スプリントゴールまでの道のりをクリアにする  • デイリースクラムの効果を上げる  • 開発チーム内の文化ができる  • タスクが細かい方が透明性が高まる（ブラックボックスになりにくい） •
スプリントゴールに向けた進捗の検査精度が高まる • 日々の、もっと言えば毎時のステータスが見える

スプリントプランニングで実現できると思ってること  • スプリントゴールまでの道のりをクリアにする  • デイリースクラムの効果を上げる  • 開発チーム内の文化ができる  • スキルが高い人に引っ張られる •
タスク粒度の基準を「誰でも一人でできる」にすることでチームのレベルにあったタスク粒度になっていく • 設計や実装の思想が揃う

言いたいこと  スプリントプランニングでは  スプリントゴールを見通せる細かいタスク分解が良さそう！ 

おまけ  • CSMとかCSPOのトレーニングで言われて今になって分かった気がすること  ◦ 「設計はスプリントプランニング内で行うんです」  ▪ →そうだね  ◦ 「スプリントの成功はプランニングで８割決まります（トレーナー調べ）」  ▪
→そうかも  ◦ 「スプリントプランニングで立てる計画は一つでなければいけないとは決まってません」  ▪ →どうしてもプランニング内でクリアにしきれない不明事項は条件分岐後の計画もしっかり立ててスプリントゴールを見通せってことかな？ 

ご清聴ありがとうございました！ 

効果的なスプリントプランニングのトライ

効果的なスプリントプランニングのトライ

TK

More Decks by TK

Other Decks in Technology

Featured

Transcript