nDiki : 勉強会
勉強会 - study session
- 社内 Perl 勉強会
- 2006年4月21日から9月11日にかけて実施
2017年3月14日 (火)
第19回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の19回目。今日は第19章 スプリントプランニング。ここから「第IV部 スプリント」。スクラムチームにとって馴染みがあるパートです。
スプリントを回すにあたり第19章はすでに何度か先読みしているところですが、あらためて書籍にあたり気付きを得て実践していきたいところです。
タイミングと時間と参加者
スプリントプランニングはスプリントを開始するときに行います。2週間から1カ月のスプリントで4〜8時間ということなので、単純に計算すると1週間スプリントでは2時間程度でしょうか。
今は1週間/2週間スプリントのチームで賞味30分から45分ぐらいしかやっていません。実際時間不足を感じています。
もちろん長ければ良いというものでもありませんが、もし不足だとしたらこのあたりが適切な時間をかけられていない障壁かなと。前者はチームが成長することで解消される気がします。後者は LeSS (Large-Scale Scrum) の2段階のスプリントプランニングにしてチーム別のにはプロダクトオーナーは出ないという形式にするという解決案も思い浮かぶのですが、参加しないデメリットを考えると躊躇してしまいます。
プロダクトバックログアイテムにかけるキャパシティ
完成させる自信のある計画を行うにはキャパシティの把握が不可欠になります。
スプリントのキャパシティ = PBI にかけるキャパシティ + スプリントバッファ + それ以外
予定している休暇があるのにスプリントプランニングの際に宣言しないのは不誠実だということになるでしょう(休んではいけないということではなく、わかっているのに共有しないということが問題。体調不良等による突発的な休みももちろん別の話)。
今のところ自分たちのチームではベロシティ(ストーリーポイント)でなんとなくキャパシティがこれぐらいかなといった感じでしか考えられていませんが、次のスプリント期間をまず見通すことも必要だなと感じました。
作業時間を使ったキャパシティも紹介されていますが、実際ここまで精緻に管理したいと思うことはあまりないんじゃないかなという印象です。
プロダクトバックログアイテムの選択
基本優先順位順ですがスプリントゴールを示している場合はその限りではなく、またスキルの問題などでコミットできないプロダクトバックログアイテムはスキップするという選択も考える必要があります。
完成できそうにないプロダクトバックログアイテムを選択してはならない。プロダクトバックログアイテムが大きすぎて完成できそうにない場合は、顧客にとって価値のあるアイテムに分割するか、完成できそうな別のアイテムに着手する。(中略)未完成のアイテムを次のスプリントに繰り越していくと、スプリントの終了時に出荷判断可能なプロダクトインクリメントを手に入れるという目標がいつまで経っても達成できない。
ここがいつもスプリントプランニングでぶちあたるところです。プロダクトバックログリファインメントがしっかりできていないんですね。プロダクトバックログリファインメントは最重要レベルのアクティビティなんだなと。
タスク分解と作業時間見積もり
自信の獲得のためにタスク分解と作業時間の見積もりをまずしましょうとあるのですが、タスク分解と見積もりの方法については触れられていません。ここは自分たちで考えて頑張れという感じなんですかね。一般論にはできない部分だとは思いますが、ここは大ハマリするところなので参考になる話があると嬉しいなと思ってます。
スプリントプランニングでタスクを個人に割り当てるのは有害だというバッドプラクティスが挙げられていますが、ここは次の「スプリントの実施」で語られるところのようです。
2017年3月21日 (火)
第20回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の20回目。今日は第20章 スプリントの実施。すでに前の章で説明されていることもまた出てきて、そのあたりはおさらいとしてさらりと読むことができました。
誰がどの作業から始めてどの作業から完成させていくか
誰がどのタスクの作業をするのかはチームメンバの共同責任。どの作業から始めるか開発チームに選択する能力が必要。どの作業から完成させていくかはチームが決めること。開発チーム自身が考えてねという感じです。がんばれ開発チーム。
実際に作業を完成させていくにあたっては「スウォーミング」という聞きなれない言葉が出てきました。
新しいアイテムに着手する前にキャパシティのあるチームメンバが集まって、すでに誰かが着手したアイテムを完成させること。
ということで、動けるメンバで順にアイテムを完成させていきましょうと書かれています。ただ完全にシングルタスクで進めていけばいいかというとそうでもなく「すべてのチームメンバーが同時にひとつのアイテムに取り掛かるのは危険だ。」と書かれており、いい感じに絞ってやりましょうということでした。
ちなみに巻末でのスウォーミングの説明には
ある程度のゆとりと適切なスキルを持ったチームメンバーが集まって、ある項目に対して共同作業(スウォーミング)を行い、新しい項目に着手する前に、すでに進行中の作業を完了させること。
と一見 GNU 的な説明になってました。
デイリースクラム
デイリースクラムのところには
チームメンバーの最適な作業配分についてみんなで理解する
とありました。「昨日やったこと・今日やること・困っていること」という型ついなぞるだけになりがちですが、きちんとチームとして誰が何をどうやっていくかを共通のものにすることを意識していくことが大切ですね。
2017年3月28日 (火)
第21回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の21回目。第21章 スプリントレビュー。スプリントの中でいちばんうまく出来ていないスプリントレビューの話です。
スプリントレビュー
スプリントレビューは作業結果(出荷判断可能なプロダクトインクリメント)の検査と適応をするアクティビティです。
不都合な真実も含めて、現在のプロダクトの状況を透明に見せてくれる。
という、ちょっと最初は勇気が必要なアクティビティです。
この章によるとスプリントレビューはスクラムチームがスクラムチーム外の人に説明しフィードバックを得るための機会なのです。しかしながらついチーム内の確認の場になりがちで、チーム外の人からきちんとフィードバックを得られていないと反省しています。
スケジュールの調整
スクラムチーム外の参加者が最も多く、スクラムのアクティビティの中では最もスケジュールの調整が難しいと述べられています。たしかに。ステークホルダーのスケジュールに合わせてスプリントレビューのスケジュールを決め、それに合わせて他のアクティビティを合わせるのが現実的とのことでした。
スプリントレビューに参加してくれないようなら、それは開発する価値のないプロダクトということである。したがって、プロダクト開発を注視すべきだろう。
きちんと参加者が集まらない場合は同時並行の作業が多すぎないかも見直すべきなのかもしれません。
スプリントレビューのアウトプット
リファインメント(グルーミング)したプロダクトバックログと更新したリリースプランがスプリントレビューのアウトプットだと書かれています。
ほとんどのチームはスプリントレビューでグルーミングをしている。関係者全員が開発の現状と今後を理解して、新しいPBIを作成したり、既存のPBIの優先順位を変えたり、不要なものを削除したりする。
これも全然意識できていないところ。今はコメントをもらって終わりになっています。きちんと対話をしプロダクトの適応をするところまで実現できていないなと。
デモ
デモが難しいからといって、それはデモをしない理由にはならない。
プロダクトオーナー側でも「まぁいいか」と思ってしまうの良くないですね。反省。
2017年4月4日 (火)
第22回 エッセンシャル スクラムを読む会
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の22回目。第22章 スプリントレトロスペクティブ。
プロセスをスクラムチームが調査するためのものだ。
2月の第15章 さまざまなプランニング以来、4回目の発表担当です。
半年前に今のチームにスクラムを導入した当初に CSM に「まずはふりかえりをきちんとできるようにしたい」と言われてから、スプリントレトロスペクティブについては結構意識してきたので、あらためてふりかえりのふりかえりという気持ちで読みました。
事前準備
本章の中で事前準備についてけっこう書かれています。ふりかえのために全く事前準備していないので、その利点についてなるほどと感じました。ただ実際のところそこまで時間を費やさなくてもという思いもあります。大きな課題があってそれにフォーカスしたふりかえりをする場合は準備するというようになるかもしれません。
スプリントレトロスペクティブに使う時間
と書かれていますが、勉強会で皆の実態を聞いてみると1週間/2週間スプリントで30分から45分ぐらいというのが中心でした。プロセスの改善だけに時間を使いすぎるのに抵抗があるのかもしれません。
インサイトバックログ
付箋紙を使っているとインサイトバックログを残そうとあまり思わないなと。一方 Trello などのデジタルツールを使っている場合は残すという運用をするかもといったぐらい。
アクションの決定
ふりかえり時間・実行できるアクションのキャパシティを考えると、インサイトが多く集まった時は何について議論するかをきちんと絞る必要が出てきます。ここは結構ファシリテーターの腕の見せ所。紹介されているドット投票で機械的に決め手しまうのもさくっと進んで良さそうなので取り入れたいです。
アクションはスプリントバックログへ
改善アクションを扱う最も簡単な方法は、アクションに関連するタスクをスプリントバックログに追加して、新しい機能よりも優先順位を高くすることである。(中略) 改善アクションを実施したいのであれば、分離してはならない。統合すべきである!
なるほど。今は個人に委ねて次回確認ぐらいとなっているのですが、チームで可視化しフォローしていけるようにすべきですね。
2017年4月14日 (金)
第23回 エッセンシャル スクラムを読む会 (最終回)
社内で「エッセンシャル スクラム」を読みたい人が集まる勉強会の23回目。第23章 未来へ。ついに最後の章です。
スクラムは継続的な改善の一形態なのだからこれが最終形態というものは無いし、どのチームをとっても同じというものは無い。プラクティスはあってもベストプラクティスはチームによって違う。準備ができていないからスクラムを始められないというのはそもそも原則に反するので、まずやって学ぼう。現状を変えるよりもスクラムを無視したりスクラムを変更したりすることの方が簡単だけれど、組織を変革するために協力しあいながら確固たる信念をもって立ち向かおう。
そんなメッセージを本章から受け取りました。
第1章の「スクラムは役に立つか?」で出た通り全ての領域でスクラムが適しているわけではないので、盲目的に導入すれば良いというものではなく、領域が変わった場合はスクラムを続けるか続けないかの判断が必要になるのでしょう。もし取り組む領域が「複雑な領域」であるならばスクラムフレームワークはとても強力だということは間違いありません。
「エッセンシャル スクラム」と「エッセンシャル スクラムを読む会」そしてなによりこの半年のスクラム開発経験でスクラムについて多くを学ぶことができました。「エッセンシャル スクラム」は「スクラムガイド」を読んだだけでは得られない広範囲な知識やノウハウが詰まった良い一冊でした。
エッセンシャル スクラムを読む会のふりかえり
エッセンシャル スクラムを読む会を終えたあとは、オフィスのコラボスペースでビールを飲みながらお疲れさま会。参加の皆さんお疲れさまでした。この回を始めてくれたはらかち氏に感謝。休まず毎回参加してディスカッションしたことでいろいろな学びを得ることができました。嬉しい限りなので珍しく私もビールで乾杯しました。いっしょに全回参加した2人のうちの1人である RabbitFake 氏も特にお疲れさまでした。
ふりかえって出てきた話題としては
- 取り組む領域がクネビンフレームワーク(第1章)のどの領域なのかを見てスクラムを採用するかどうか考えたい。
- チームメンバでエッセンシャル スクラムを読むことで「PBI」などの同じ理解で使える言葉が増えた。チームの共通言語作りに貢献できた。
- 原則大事(第3章・第14章など)。
- WIP を下げる重要性をあらためて学んだ。
- 準備完了の定義・受け入れ条件が重要。
などが上がりました。
また実際に読む会と並行してスクラムを行ってきた中で
- プロダクトバックログリファインメントで1スプリントにおさまるように適切にプロダクトバックログアイテムを分割するの大変だよね。
- スクラムマスターと開発チームメンバ(エンジニア)との兼任が難しかった。
- スクラムマスターであると同時に組織図上のリーダーという立場でいると、自発的行動を促すのとある程度指示的に動かすのとの兼ね合いが悩ましかった。
- 困った状態であることにメンバが気がつくのを3カ月待った上で物理かんばんを導入してみた(すごい)。
などの話が出ました。
スクラム実践についての「検査と適応」をタイムリーに勉強会をしながら進められて学びの多い半年間でした。
全23回
- 2016年10月25日 第1回 第1章 イントロダクション
- 2016年11月01日 第2回 第2章 スクラムフレームワーク
- 2016年11月08日 第3回 第3章 アジャイルの原則
- 2016年11月15日 第4回 第4章 スプリント
- 2016年11月22日 第5回 第5章 要件とユーザーストーリー
- 2016年11月29日 第6回 第6章 プロダクトバックログ
- 2016年12月06日 第7回 第7章 見積もりとベロシティ
- 2016年12月13日 第8回 第8章 技術的負債
- 2016年12月20日 第9回 第9章 プロダクトオーナー
- 2017年01月10日 第10回 第10章 スクラムマスター
- 2017年01月17日 第11回 第11章 開発チーム
- 2017年01月24日 第12回 第12章 スクラムチームの構成
- 2017年01月31日 第13回 第13章 マネージャー
- 2017年02月07日 第14回 第14章 スクラムのプランニングの原則
- 2017年02月14日 第15回 第15章 さまざまなプランニング
- 2017年02月21日 第16回 第16章 ポートフォリオプランニング
- 2017年02月28日 第17回 第17章 エンビジョニング (プロダクトプランニング)
- 2017年03月07日 第18回 第18章 リリースプランニング (長期計画)
- 2017年03月14日 第19回 第19章 スプリントプランニング
- 2017年03月21日 第20回 第20章 スプリントの実施
- 2017年03月28日 第21回 第21章 スプリントレビュー
- 2017年04月04日 第22回 第22章 スプリントレトロスペクティブ
- 2017年04月14日 第23回 第23章 未来へ
2018年2月15日 (木)
今日のさえずり: ファシリテーターローテーションマーカーに AWS Cloud Ninja フィギュアが起用された
2018年02月15日
- 08:40 暖かくなるということで、さすがに今日からマスクをして外に出ることにした。
- 09:32 朝からすでに、ダウンジャケットでは暑かった。
- 09:39 “マイネットグループのゲームサービス事業会社4社が合併しマイネットゲームスに。「ゲームサービス圧倒的No.1」を目指す | 株式会社マイネット” http://bit.ly/2o1DYzP
- 09:42 ゲーム終了の経緯。 / “mobageで運営していたゲームを終了させた” http://bit.ly/2o1rJ6e
- 09:55 Trello に絵文字リアクション機能が追加されたので早速。選べるのは今は12絵文字だけっぽい。 http://bit.ly/2BZOTTa
- 13:15 朝のミーティングのファシリテーターローテーションマーカーに AWS Cloud Ninja フィギュアが起用された。
- 15:15 エンジニアが主役の Android カンファレンス。2日間で1000名以上が参加。 / “【DroidKaigi 2018】ミクシィグループのエンジニアが登壇しました｜ミクシル” http://bit.ly/2BuW0BW
- 17:15 DSC-RX0 はやはりビジュアル・ブックマーク機サイバーショットUの再来なのか。 / “子どもの日常記録に「RX0」を使い始めたらとても楽しい” http://bit.ly/2Buzjhg
- 17:18 Naney の日記: Buffer を Awesome Plan にアップグレードして予約投稿しておける数を10件から100件に増やした。これだけあればずいぶん先まで予約できちゃう(そこまでしないけれど)。… https://twitter.com/...
- 17:21 ミキサー車。 PowerShot G9 X Mark II https://t.co/vU69jFFNsA
- 19:50 Markdown でプレゼンテーションスライドを書ける Deckset for Mac を久しぶりに使った。社内勉強会のスライド作る時とかサクッと楽に書けて良い。
- 23:30 “[mixi] ベビースター×mixiコラボキャンペーン！” http://bit.ly/2Bt9zSm
2021年9月8日 (水)
第0回 『Hacking Growth グロースハック完全読本』を読む会 キックオフ
知識と共通言語をチームで獲得し事業推進につなげるのを目的に『Hacking Growth グロースハック完全読本』を輪読する勉強会を部内の関係者ですることにした。輪読形式の勉強会はエッセンシャル スクラムを読む会ぶり。
今日は参加者で集まってキックオフミーティング。顔合わせと勉強会の趣旨を確認したあと、進め方を打ち合わせた。各回担当者が事前にまとめたサマリーを発表し、事前に読んできている参加者全員で内容について話し合うオーソドックスなスタイルに決定。
初回は来週から。楽しみ。
ちなみに『Hacking Growth グロースハック完全読本』の新品単行本(紙)はいくつか通販サイトを見た限り品切れになっていた。増刷予定はないのかな?
2021年12月2日 (木)
第10回 『Hacking Growth グロースハック完全読本』を読む会 第8章 収益化をハックする
『Hacking Growth グロースハック完全読本』を読む会の第10回目。今日は「第8章 収益化をハックする」。前半部分の発表を担当。
収益化のグロースハックも基本は分析・ユーザー調査と実験。前半部分は収益化の観点でのおさらいである。
後半は価格の最適化や消費者心理の利用がトピック。価格の最適化についてはグロースハックというテクニカルな話以前にマーケティング戦略としてきちんと考えいく必要がある。消費者心理についてはちょうど今読んでいる『影響力の武器』に出てくる影響力の6つの原理が紹介されていた。収益化のハックにおいては、マーケティングやセールスで長年研究されてきた考えなどをしっかり学んでおく必要があるな。
『Hacking Growth グロースハック完全読本』を読む会もいよいよ次回が最終回の予定だ。参加者の一人が「自分のための勉強会だと思ってるんで」と言っていて、めちゃいい姿勢だなとテンションが高まった。「いやいや、自分も自分のための勉強会だと思ってるから」と負けじと返した。
2022年1月26日 (水)
今日のさえずり: 70:20:10 モデルのソース調査
- 08:41 Spirit #photography RICOH GR III #GR #GRIII #GR3 https://t.co/xD6m4FXrtZ
- 19:49 デザイン原則を参照しつつ、まずイラスト原則を定義。 みてねの「イラストガイドライン」をつくった話💡｜Miyu Matsumoto @miyumatsumoto https://note.com/.../n/n031372f5e718
- 24:19 2022年1月26日(水) やったこと - 花粉症の薬を手配 - 部内勉強会 (グロースハック) - 部内勉強会 (HTML と CSS) - 70:20:10 モデルのソース調査
Spirit#photography
— Naney (@Naney) January 25, 2022
RICOH GR III #GR #GRIII #GR3 pic.twitter.com/xD6m4FXrtZ
About
Naney (なにい) です。株式会社MIXIで SNS 事業の部長をしています。
※本サイトの内容は個人的見解であり所属組織とは関係ありません。