Effective Retrospective

2017年3月18日に行われたProductivity Engineering − Forkwell Meetup #4での登壇資料です

Tidy First? ―個人で実践する経験主義的ソフトウェア設計
  • 著者／訳者：Kent Beck、 吉羽 龍太郎、 永瀬 美穂、 細澤 あゆみ
  • 出版社：オライリー・ジャパン
  • 発売日：2024-12-25
  • 単行本（ソフトカバー）：164ページ
  • ISBN-13：9784814400911
  • ASIN：4814400918
脳に収まるコードの書き方 ―複雑さを避け持続可能にするための経験則とテクニック
  • 著者／訳者：Mark Seemann、 吉羽 龍太郎、 原田 騎郎、 Robert C. Martin
  • 出版社：オライリー・ジャパン
  • 発売日：2024-06-18
  • 単行本（ソフトカバー）：312ページ
  • ISBN-13：9784814400799
  • ASIN：4814400799

Transcript

1. Effective Retrospective 2017/3/18 株式会社アトラクタ 吉羽龍太郎
2. 吉羽龍太郎 @ryuzee ✤ 株式会社アトラクタ取締役CTO/アジャイルコーチ ✤ アジャイル開発/DevOps/クラウドのコンサルティングとトレーニングを提供
3. 株式会社アトラクタのご紹介 ✤ 株式会社アトラクタ https://www.attractor.co.jp/ ✤ 開発プロセスに関するコンサルティングやトレーニングを提供 ✤ アジャイル開発 / DevOps / チーム育成 / クラウドコンピューティン グ / ドメインモデリングなどが専門領域
4. Retrospectiveとは？ ✤ 日本語では「ふりかえり」(このあとはこの用語を使います) ✤ アジャイル開発でよく使われるプラクティス ✤ ただし利用範囲はアジャイル開発には限定されない ✤ ソフトウェア開発でなくても使える
5. KPTが有名だが、ほかにもいろいろある http://www.flickr.com/photos/magnus_d/5121009259/
6. 大きな目的は2つ
7. 1. もっとうまくできるようにする
8. 定期的に検査してちょっとずつ良くする 50 37.5 25 12.5 0 #1 #2 #3 #4 #5
9. 2. 強制的に仕事を停止する
10. 車は急に止まれない
11. そう!! ✤ 人間も同じ ✤ 忙しいときほど止まれないが、止まらないと事故がおこる ✤ 強制的に立ち止まって本当にこのままでいいのか考える余裕を持つ
12. だから定期的な予定として組み込む
13. ふりかえりにおける大前提 = 心理的安全性
14. つまり… ✤ 役職や立場の上下関係、人事評価への恐怖などで、本当に思っていること が言えなければ、本当の「問題」にたどり着かない ✤ 安全性こそが透明性を生む ✤ まずはその場を「安全」にすること ✤ したがって必要に応じて参加者の選別やファシリテーターによる宣言が必 要にもなる(マネージャーやリーダーに参加を遠慮してもらったり) ✤ 「あなた VS. わたし」 => 「問題 VS. わたしたち」
15. 基本的な進め方の例 1. 場を設定する 2. データを収集する 3. アイデアを出す 4. 何をすべきか決定する 5. 終了する
16. 1. 場を設定する ✤ これから行う作業に集中できるように始め方に気をつける ✤ 参加者してくれることに感謝を示す ✤ まず全員に口を開いてもらう(抱負など)。全員参加が不可欠 ✤ 会議の冒頭に口を開くと主体的参加度があがる傾向 ✤ 進め方を説明する(タイムボックス、目標も含む) ✤ チームの約束を確認する ✤ この時間を端折ったりしない方がよい
17. おすすめの準備(道具編)
18. 2. データを収集する ✤ イベント、メトリクス、完成した成果などの客観的データを集める ✤ イベント＝ミーティング、意思決定、メンバーの変更、割り込み、障害、お祝い事など ✤ メトリクス＝バーンダウンチャート、ベロシティ、不具合数、課題数、完了した項目数、 ドキュメント数、障害数など ✤ 定性的な意見や感想もデータとなる ✤ ボードで見える化している場合はそれを使う。オンラインツールの場合はあらかじめダッ シュボード化しておいても良い ✤ データを共通理解や議論のための道具として使う ✤ 全部を集めないといけないわけではもちろんない
19. データの例(ほかにもたくさん) バーンダウンチャート テスト結果推移 ビルド結果 カンバン KeepやProblem 会議のログ 写真： https://www.flickr.com/photos/chrishuffman/2336990347/ https://www.flickr.com/photos/reevej/6334289004/
20. Opinion vs Fact (意見 vs 事実) Problem (問題) Solution (解決策) 計測 Fact (事実) デプロイ 仮説 Opinion (意見) 設計
21. 例えば？ ✤ 「品質が悪い」=> これは意見か事実か？ ✤ 「情報共有が不足している」=> これは意見か事実か？ ✤ 「お客様のテンションがあがりすぎている」=> これは意見か事実か？ ✤ 意見だけをもとにしてアクションを決めると本質的な問題が解決しない ✤ 解決策の欠如を問題として語るのは、場の安全性、チームの信頼の欠如を 示すシグナル
22. 3. アイデアを出す ✤ データを使って課題を抽出し、アイデアを出す ✤ アイデアにはリスクや副作用がある場合もある ✤ いきなり出した解決策が正しいことは多くないので、分析的に考える ✤ ✤ いま思いついた絶対イケてそうな機能のアイデアは1日経つとイケて ないことが多い 5 Whyや根本原因分析などのテクニックも利用する
23. 4. 何をすべきか決定する ✤ アイデアの中で妥当だと思えるもののうち、上位の課題を解決する項目を 少数選んで計画する ✤ 多すぎても行動できないので無駄になるので、数個に限定すること ✤ 必要であれば機能リストやプロダクトバックログに項目を追加したり、自 分たちの計画に組み込む ✤ 誰がいつまでにやるのかをはっきりさせないと完了しない
24. 拳から5本指 (Fist to Five) 0 この時点で決定を行なうこと自体に反対 1 重大な問題がある。そのまま決定したらアクションを起こす 2 問題がある。もっと話し合いをしたい 3 良いとは思わないが自分はそれでも構わない 4 良いので協力する 5 素晴らしいので自分が実行のリーダーになっても良い
25. 5. 終了する ✤ 決定事項や議論の内容などについて記録を残す ✤ ホワイトボードや模造紙などを写真にとっておいても良い ✤ フォローアップのアクションを決める ✤ ふりかえりの進め方がどうだったのかをふりかえる ✤ ふりかえりとそれまでの作業に感謝して終了する
26. よくある失敗と対策
27. ! 症状 ✤ 雰囲気が暗い ✤ 発言が特定の人に偏る ✤ 愚痴が多い ✤ 次のふりかえりでもプロセスが変わっていない ✤ 解決策がないことを主張する ✤ 手を打ったはずの問題が再現する
28. " 原因候補：安全性欠如 ✤ 安全でないと、失敗を認 めたり、問題を明らかに したり、新しいことに挑 戦しにくくなる ✤ 高い心理的安全性を持つ チームはそれぞれが同じ くらいの持ち時間で話す 傾向がある https://www.youtube.com/watch?v=KZlSq_Hf08M
29. " 原因候補：不明確なアクションアイテム ✤ どんなアクションをいつまでにやるのか決めていない ✤ アクションが実行されたか・定着したかをどう追跡するか決めていない ✤ 何をもってそのアクションが完了するのかの基準が明確でない ✤ 数が多すぎるアクションアイテム
30. # カイゼンボード ✤ カイゼンの取り組みを見える 化する ✤ 誰が着手しているかアバター を使って明らかにする ✤ 通常のカンバンと同様にアク ションに優先順位をつける ※アジャイルコーチの道具箱 – 見える化の実例集(Jimmy Janlén 著) より引用
31. " 原因候補：マンネリ… ✤ いつも同じやり方(KPTなど)をしている ✤ いつも同じ課題や不満がでる繰り返し ✤ 同じ観点ばかりで改善点を探すと見落とすことがある ✤ KPTでは全体の流れが把握しにくく散発的になる可能性も ✤ やり方を変える ✤ 日常の場所から離れる
32. タイムライン
33. # いろいろなふりかえり方法
34. # Token of Appreciation Timeline ※Fun Retrospectivesより いろいろなふりかえり方法 Happiness Radar Star Fish Story of Story WWW
35. http://bit.ly/2nLOyrV いろいろなふりかえり方法

Comment

No comments...