nDiki : 勉強会

勉強会 - study session

2017年3月14日 (火)

第19回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の19回目。今日は第19章 スプリントプランニング。ここから「第IV部 スプリント」。スクラムチームにとって馴染みがあるパートです。

スプリントを回すにあたり第19章はすでに何度か先読みしているところですが、あらためて書籍にあたり気付きを得て実践していきたいところです。

タイミングと時間と参加者

スプリントプランニングはスプリントを開始するときに行います。2週間から1カ月のスプリントで4〜8時間ということなので、単純に計算すると1週間スプリントでは2時間程度でしょうか。

今は1週間/2週間スプリントのチームで賞味30分から45分ぐらいしかやっていません。実際時間不足を感じています。

  • チームメンバが2時間のプランニングミーティングに耐えられない。きちんとスプリントプランニングするメリットを感じられていない。
  • 3チームのプロダクトオーナー(自分)が時間を確保できない。

もちろん長ければ良いというものでもありませんが、もし不足だとしたらこのあたりが適切な時間をかけられていない障壁かなと。前者はチームが成長することで解消される気がします。後者は LeSS (Large-Scale Scrum) の2段階のスプリントプランニングにしてチーム別のにはプロダクトオーナーは出ないという形式にするという解決案も思い浮かぶのですが、参加しないデメリットを考えると躊躇してしまいます。

プロダクトバックログアイテムにかけるキャパシティ

完成させる自信のある計画を行うにはキャパシティの把握が不可欠になります。 

 スプリントのキャパシティ
   = PBI にかけるキャパシティ + スプリントバッファ + それ以外

予定している休暇があるのにスプリントプランニングの際に宣言しないのは不誠実だということになるでしょう(休んではいけないということではなく、わかっているのに共有しないということが問題。体調不良等による突発的な休みももちろん別の話)。

今のところ自分たちのチームではベロシティ(ストーリーポイント)でなんとなくキャパシティがこれぐらいかなといった感じでしか考えられていませんが、次のスプリント期間をまず見通すことも必要だなと感じました。

作業時間を使ったキャパシティも紹介されていますが、実際ここまで精緻に管理したいと思うことはあまりないんじゃないかなという印象です。

プロダクトバックログアイテムの選択

基本優先順位順ですがスプリントゴールを示している場合はその限りではなく、またスキルの問題などでコミットできないプロダクトバックログアイテムはスキップするという選択も考える必要があります。

完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のあるアイテムに分割するか、完成できそうな別のアイテムに着手する。(中略)未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。

ここがいつもスプリントプランニングでぶちあたるところです。プロダクトバックログリファインメントがしっかりできていないんですね。プロダクトバックログリファインメントは最重要レベルのアクティビティなんだなと。

タスク分解と作業時間見積もり

自信の獲得のためにタスク分解と作業時間の見積もりをまずしましょうとあるのですが、タスク分解と見積もりの方法については触れられていません。ここは自分たちで考えて頑張れという感じなんですかね。一般論にはできない部分だとは思いますが、ここは大ハマリするところなので参考になる話があると嬉しいなと思ってます。

スプリントプランニングでタスクを個人に割り当てるのは有害だというバッドプラクティスが挙げられていますが、ここは次の「スプリントの実施」で語られるところのようです。

[ permalink ]
[ 3月14日全て ]

2017年3月21日 (火)

第20回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の20回目。今日は第20章 スプリントの実施。すでに前の章で説明されていることもまた出てきて、そのあたりはおさらいとしてさらりと読むことができました。

誰がどの作業から始めてどの作業から完成させていくか

誰がどのタスクの作業をするのかはチームメンバの共同責任。どの作業から始めるか開発チームに選択する能力が必要。どの作業から完成させていくかはチームが決めること。開発チーム自身が考えてねという感じです。がんばれ開発チーム。

実際に作業を完成させていくにあたっては「スウォーミング」という聞きなれない言葉が出てきました。

新しいアイテムに着手する前にキャパシティのあるチームメンバが集まって、すでに誰かが着手したアイテムを完成させること。

ということで、動けるメンバで順にアイテムを完成させていきましょうと書かれています。ただ完全にシングルタスクで進めていけばいいかというとそうでもなく「すべてのチームメンバーが同時にひとつのアイテムに取り掛かるのは危険だ。」と書かれており、いい感じに絞ってやりましょうということでした。

ちなみに巻末でのスウォーミングの説明には

ある程度のゆとりと適切なスキルを持ったチームメンバーが集まって、ある項目に対して共同作業(スウォーミング)を行い、新しい項目に着手する前に、すでに進行中の作業を完了させること。

と一見 GNU 的な説明になってました。

デイリースクラム

デイリースクラムのところには

チームメンバーの最適な作業配分についてみんなで理解する

とありました。「昨日やったこと・今日やること・困っていること」という型ついなぞるだけになりがちですが、きちんとチームとして誰が何をどうやっていくかを共通のものにすることを意識していくことが大切ですね。

[ permalink ]
[ 3月21日全て ]

2017年3月28日 (火)

第21回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の21回目。第21章 スプリントレビュー。スプリントの中でいちばんうまく出来ていないスプリントレビューの話です。

スプリントレビュー

スプリントレビューは作業結果(出荷判断可能なプロダクトインクリメント)の検査と適応をするアクティビティです。

不都合な真実も含めて、現在のプロダクトの状況を透明に見せてくれる。

という、ちょっと最初は勇気が必要なアクティビティです。

この章によるとスプリントレビューはスクラムチームがスクラムチーム外の人に説明しフィードバックを得るための機会なのです。しかしながらついチーム内の確認の場になりがちで、チーム外の人からきちんとフィードバックを得られていないと反省しています。

スケジュールの調整

スクラムチーム外の参加者が最も多く、スクラムのアクティビティの中では最もスケジュールの調整が難しいと述べられています。たしかに。ステークホルダーのスケジュールに合わせてスプリントレビューのスケジュールを決め、それに合わせて他のアクティビティを合わせるのが現実的とのことでした。

スプリントレビューに参加してくれないようなら、それは開発する価値のないプロダクトということである。したがって、プロダクト開発を注視すべきだろう。

きちんと参加者が集まらない場合は同時並行の作業が多すぎないかも見直すべきなのかもしれません。

スプリントレビューのアウトプット

リファインメント(グルーミング)したプロダクトバックログと更新したリリースプランがスプリントレビューのアウトプットだと書かれています。

ほとんどのチームはスプリントレビューでグルーミングをしている。関係者全員が開発の現状と今後を理解して、新しいPBIを作成したり、既存のPBIの優先順位を変えたり、不要なものを削除したりする。

これも全然意識できていないところ。今はコメントをもらって終わりになっています。きちんと対話をしプロダクトの適応をするところまで実現できていないなと。

デモ

デモが難しいからといって、それはデモをしない理由にはならない。

プロダクトオーナー側でも「まぁいいか」と思ってしまうの良くないですね。反省。

スプリントレビューはスクラムマスターと協力してきちんと設営していく必要があるなと感じました。

[ permalink ]
[ 3月28日全て ]

2017年4月4日 (火)

第22回 エッセンシャル スクラムを読む会

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の22回目。第22章 スプリントレトロスペクティブ。

プロセスをスクラムチームが調査するためのものだ。

2月の第15章 さまざまなプランニング以来、4回目の発表担当です。

半年前に今のチームにスクラムを導入した当初に CSM に「まずはふりかえりをきちんとできるようにしたい」と言われてから、スプリントレトロスペクティブについては結構意識してきたので、あらためてふりかえりのふりかえりという気持ちで読みました。

事前準備

本章の中で事前準備についてけっこう書かれています。ふりかえのために全く事前準備していないので、その利点についてなるほどと感じました。ただ実際のところそこまで時間を費やさなくてもという思いもあります。大きな課題があってそれにフォーカスしたふりかえりをする場合は準備するというようになるかもしれません。

スプリントレトロスペクティブに使う時間

と書かれていますが、勉強会で皆の実態を聞いてみると1週間/2週間スプリントで30分から45分ぐらいというのが中心でした。プロセスの改善だけに時間を使いすぎるのに抵抗があるのかもしれません。

インサイトバックログ

付箋紙を使っているとインサイトバックログを残そうとあまり思わないなと。一方 Trello などのデジタルツールを使っている場合は残すという運用をするかもといったぐらい。

アクションの決定

ふりかえり時間・実行できるアクションのキャパシティを考えると、インサイトが多く集まった時は何について議論するかをきちんと絞る必要が出てきます。ここは結構ファシリテーターの腕の見せ所。紹介されているドット投票で機械的に決め手しまうのもさくっと進んで良さそうなので取り入れたいです。

アクションはスプリントバックログへ

改善アクションを扱う最も簡単な方法は、アクションに関連するタスクをスプリントバックログに追加して、新しい機能よりも優先順位を高くすることである。(中略) 改善アクションを実施したいのであれば、分離してはならない。統合すべきである!

なるほど。今は個人に委ねて次回確認ぐらいとなっているのですが、チームで可視化しフォローしていけるようにすべきですね。

[ permalink ]
[ 4月4日全て ]

2017年4月14日 (金)

第23回 エッセンシャル スクラムを読む会 (最終回)

rimage:/nDiki/2017/04/14/2017-04-14-092915-nDiki-800x1200.jpg

社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。

スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変革するために協力しあいながら確固たる信念をもって立ち向かおう。

そんなメッセージを本章から受け取りました。

第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。

「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。

エッセンシャル スクラムを読む会のふりかえり

エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。

ふりかえって出てきた話題としては

  • 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
  • チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
  • 原則大事(第3章・第14章など)。
  • WIP を下げる重要性をあらためて学んだ。
  • 準備完了の定義・受け入れ条件が重要。

などが上がりました。

また実際に読む会と並行してスクラムを行ってきた中で

  • プロダクトバックログリファインメントで1スプリントにおさまるように適切にプロダクトバックログアイテムを分割するの大変だよね。
  • スクラムマスターと開発チームメンバ(エンジニア)との兼任が難しかった。
  • スクラムマスターであると同時に組織図上のリーダーという立場でいると、自発的行動を促すのとある程度指示的に動かすのとの兼ね合いが悩ましかった。
  • 困った状態であることにメンバが気がつくのを3カ月待った上で物理かんばんを導入してみた(すごい)。

などの話が出ました。

スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。

全23回

エッセンシャル スクラム: アジャイル開発に関わるすべての人のための完全攻略ガイド

[ permalink ]
[ 4月14日全て ]

2018年2月15日 (木)

今日のさえずり: ファシリテーターローテーションマーカーに AWS Cloud Ninja フィギュアが起用された

2018年02月15日

[ permalink ]
[ 2月15日全て ]

2019年10月30日 (水)

HTML・CSS についての勉強会【日記】

今年2回目の部内での HTML・CSS についての勉強会が今日あった。 複数人・複数チームでで開発保守する大規模サイトにおける共通部品化のデメリットの話など、なるほどと。

[ permalink ]
[ 10月30日全て ]

2021年9月8日 (水)

第0回 『Hacking Growth グロースハック完全読本』を読む会 キックオフ

rimage:ASIN:4822255824

知識と共通言語をチームで獲得し事業推進につなげるのを目的に『Hacking Growth グロースハック完全読本』を輪読する勉強会を部内の関係者ですることにした。輪読形式の勉強会はエッセンシャル スクラムを読む会ぶり。

今日は参加者で集まってキックオフミーティング。顔合わせと勉強会の趣旨を確認したあと、進め方を打ち合わせた。各回担当者が事前にまとめたサマリーを発表し、事前に読んできている参加者全員で内容について話し合うオーソドックスなスタイルに決定。

初回は来週から。楽しみ。

ちなみに『Hacking Growth グロースハック完全読本』の新品単行本(紙)はいくつか通販サイトを見た限り品切れになっていた。増刷予定はないのかな?

[ permalink ]
[ 9月8日全て ]

2021年12月2日 (木)

第10回 『Hacking Growth グロースハック完全読本』を読む会 第8章 収益化をハックする

rimage:ASIN:4822255824

『Hacking Growth グロースハック完全読本』を読む会の第10回目。今日は「第8章 収益化をハックする」。前半部分の発表を担当。

収益化のグロースハックも基本は分析・ユーザー調査と実験。前半部分は収益化の観点でのおさらいである。

後半は価格の最適化や消費者心理の利用がトピック。価格の最適化についてはグロースハックというテクニカルな話以前にマーケティング戦略としてきちんと考えいく必要がある。消費者心理についてはちょうど今読んでいる『影響力の武器』に出てくる影響力の6つの原理が紹介されていた。収益化のハックにおいては、マーケティングやセールスで長年研究されてきた考えなどをしっかり学んでおく必要があるな。

『Hacking Growth グロースハック完全読本』を読む会もいよいよ次回が最終回の予定だ。参加者の一人が「自分のための勉強会だと思ってるんで」と言っていて、めちゃいい姿勢だなとテンションが高まった。「いやいや、自分も自分のための勉強会だと思ってるから」と負けじと返した。

[ permalink ]
[ 12月2日全て ]

2022年1月26日 (水)

今日のさえずり: 70:20:10 モデルのソース調査

[ permalink ]
[ 1月26日全て ]
Naney の Web 日記 nDiki について・月別インデックス

About

Naney Naneymx

Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。

※本サイトの内容は個人的見解であり所属組織とは関係ありません。

Process Time: 0.025258s / load averages: 0.15, 0.20, 0.23