Slide 1

Slide 1 text

アジャイルの 風味を お持ち帰り やっとむ こと 安井力 Agile Japan 2020 サテライト

Slide 2

Slide 2 text

2001年ごろアジャイルと出会い、開発者、チームリーダー、トレー ナー、導入支援と多様な立場で関わってきた。(株)永和システム マネジメントにて2010年頃からアジャイルコーチを主軸として 活動。2014年独立。 プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム 著書・訳書 [email protected] twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ やっとむ / 安井力(やすいつとむ)

Slide 3

Slide 3 text

アジャイルの風味をお持ち帰り • 「チームならではの活動を増やしていくための気づき、 ヒントを持ち帰ってもらう」(サテライト実行委員のみなさん) • チームで取り組めるプラクティスを紹介します • テスト駆動開発 • アジャイルな見積りと計画作り • モブワーク • ファンダンラーンふりかえり • 「風味」だけ? • 実践できるレベルの説明は無理なので……

Slide 4

Slide 4 text

テスト駆動開発

Slide 5

Slide 5 text

(C)2012 株式会社永和システムマネジメント

Slide 6

Slide 6 text

テスト駆動開発とは • プログラミングの手法 (テスト手法ではない) • プロダクトコードと自動化したテストを一緒に書く • 自分の作業が上手くいってるか、テストを通じて把握する テスト駆動開発は ふつうの開発

Slide 7

Slide 7 text

『テスト駆動開発』ケント・ベック、オーム社 https://honto.jp/netstore/pd-book_28393266.html

Slide 8

Slide 8 text

テスト駆動開発とは 1. 期待する結果(外部仕様)をテストで表現する 2. 正しい結果になるようコードを記述する 3. コードを改善し、きれいにする(リファクタリング) 4. 1~3を短期間(数分~数時間)で繰り返す

Slide 9

Slide 9 text

テスト駆動開発とは 1. 期待する結果(外部仕様)をテストで表現する 正解を定める 2. 正しい結果になるようコードを記述する 正解と一致させる 3. コードを改善し、きれいにする(リファクタリング) 保守性を守る 4. 1~3を短期間(数分~数時間)で繰り返す 不安を減らす

Slide 10

Slide 10 text

きれい 汚い (すぐには)動かない 動作する Green Refactoring TDDと黄金の回転

Slide 11

Slide 11 text

テスト駆動開発のメリット • 書きながら設計が改善する • 変更時にテストを安全ネットにできる • 単体レベルのバグが減る • さらなるテスト自動化の足がかりになる • 小規模に始めても効果がある • 自信を持って作業できる → 自信を持てるレベルがより高度になる

Slide 12

Slide 12 text

テスト駆動開発の効果 IBM ドライバ Microsoft Windows Microsoft MSN Microsoft VisualStudio チーム人数 9 6 5-7 7 コード量(KLOC) 41.0 6.0 26.0 155.2 開発規模(人月) 119 24 46 20 欠陥数 (TDD未使用に対 する) 61% 38% 24% 9% 開発時間の増加 (管理者の見積) 15~20% 25~35% 15% 20~25% Nachiappan Nagappan, E. Michael Maximilien, Thirumalesh Bhat, Laurie Williams “Realizing quality improvement through test driven development: results and experiences of four industrial teams” 2008 http://research.microsoft.com/en-us/groups/ese/nagappan_tdd.pdf

Slide 13

Slide 13 text

Why TDD? ― 変更容易性の問題 • 設計が複雑化する • ドキュメントが陳腐化する • 全体を把握しきれなくなる • どこを直せばいいか自信がなくなる • 全体を理解していないので、つぎはぎで直す • 直した場所と関係なさそうなところが壊れる • ますます設計が複雑化する

Slide 14

Slide 14 text

No content

Slide 15

Slide 15 text

No content

Slide 16

Slide 16 text

ここでアジャイル風味! やってみないと どうなるか わかりません 「 」

Slide 17

Slide 17 text

テスト駆動開発を始めるには… • 書籍『テスト駆動開発』 • コミュニティイベント TDDBC(ブートキャンプ) https://tddbc.connpass.com/ • 和田卓人さんの動画 • 基調講演/ライブコーディング https://youtu.be/Q-FJ3XmFlT8 • 解説動画(全20回) https://gihyo.jp/dev/serial/01/tdd • 和田さんの有償セミナー • https://event.shoeisha.jp/cza/tdd 私もTAで参加してます

Slide 18

Slide 18 text

アジャイルな 見積りと計画づくり

Slide 19

Slide 19 text

『アジャイルな見積りと計画作り』 マイク・コーン、マイナビ出版 https://honto.jp/netstore/pd-book_03083348.html

Slide 20

Slide 20 text

• 計画づくりとは価値の探究なのだ • 計画づくりがすべてだ 立てた計画はどうでもいい 大モルトケ • アジャイルな「計画づくり」だ 「アジャイルな計画」ではない • よい計画とは、ステークホルダーが信頼できる計画だ • 「アジャイルは計画しない」… これほど実情とかけはなれた言葉もない • アジャイルではフィーチャー単位 • やっとむ「スクラムの話だ」 角谷さん「XPだと思ってた」 両方正しい プランニング プラン

Slide 21

Slide 21 text

• 計画は必要だし重要 • 以前に立てた計画より、現在の状況のほうが偉い 計画に従うことよりも 変化への対応を 価値とする アジャイルソフトウェア開発宣言 https://agilemanifesto.org/iso/ja/manifesto.html

Slide 22

Slide 22 text

計画のジレンマ • 計画がなければ何をすればよいか判断できない • いちばん情報が少ないのは、いま。 いまする判断が、いちばん悪い • 情報が増えれば、より良い判断ができる • 計画時点では情報不足なことを認める • 情報を収集して計画を変更することを計画する • VUCA=不安定、不確実、複雑、曖昧

Slide 23

Slide 23 text

「計画づくり」をアジャイルにする • 計画は最初に立てる • 計画を守るほうが偉い • 計画は決定事項 • 達成することを約束する • 約束を守ることが仕事 • 常に計画づくりを続ける • 目の前の現状に合わせるのが偉い • 計画はつくった時点での見通し • 全力を尽くすことと学ぶことを約束する • 最大の価値を提供するのが仕事

Slide 24

Slide 24 text

変更しやすい計画 • 最終的に達成したい目標が明確 • 不確実性を表現する • 作業項目が成果物ベース • 作業項目間の依存関係が少ない • 進捗や状況が客観的で透明 • 直近は詳細に、先の方はおおまかに

Slide 25

Slide 25 text

成果物ベースの作業項目: ユーザーストーリー https://www2.slideshare.net/kdmsnr/20111022-userstoryfirstgeneration

Slide 26

Slide 26 text

スクラムでの計画 • ストーリーを順序づけて並べる • 上から1つずつ完成する • 完成時期を幅で表現する • 自信の度合いを表示する • 常に更新し、関係者と共有、説明する • 上の方のストーリーは1~2日で 完成する大きさ、下の方は週~月 『スクラム現場ガイド スクラムを始めてみたけどうまくい かない時に読む本』ミッチ・レイシー、マイナビ出版 https://honto.jp/netstore/pd-book_27671286.html

Slide 27

Slide 27 text

変更しやすい計画づくり • 全員が参加する • 最終的に達成したい目標が明確 • わからないことを わからないと言う • 経験から学び、計画を変更したくなる • よいアイデアを探して、計画を変更したくなる • 計画づくりの機会をふんだんに組み込む プランニング

Slide 28

Slide 28 text

多段の計画づくり • 計画は段階的につくる • リリース • イテレーション(スプリント) • デイリー

Slide 29

Slide 29 text

プランニングポーカー • 相対見積もり • 10倍までのスケール • 過去の情報を利用 • 当事者・専門家の見解を収集する • 対話と情報共有を引き出す • 集合知は優秀な個人より正確 • 楽しい

Slide 30

Slide 30 text

ここでアジャイル風味! うまくいけば こんなふうになってる はずです! 「 」

Slide 31

Slide 31 text

No content

Slide 32

Slide 32 text

アジャイルな見積りと計画づくりを始めるには… • 書籍『アジャイルな見積りと計画づくり』 • 認定スクラムマスター研修 • Scrum inc. https://scruminc.jp/training/master/ • アギレルゴ https://www.jp.agilergo.com/training • アトラクタ https://www.attractor.co.jp/service/public/ • ユーザーストーリー • 書籍『ユーザーストーリーマッピング』https://honto.jp/netstore/pd- book_27209896.html • プランニングポーカー • https://www.planitpoker.com/quickplay/

Slide 33

Slide 33 text

モブワーク

Slide 34

Slide 34 text

https://speakerdeck.com/yattom/mob-programming-to-build-teams

Slide 35

Slide 35 text

No content

Slide 36

Slide 36 text

はじめてのモブプロあるある • 誰かが「モブプロやってみよう!」と声をかけて集まる • 言い出しっぺがなんとなくドライバーになる • 「じゃあまずこれやろうか」と、なんとなく作業開始 • 他メンバーは、いまいちどうしたらいいかわからず、眺めている • ドライバーがなぜか焦りを感じて、一区切りつくまで書き続ける • 交代しても、1人の人がナビし続けて、他メンバーは眺めてる • 終わりになって、もやもやが残ったまま流れで解散

Slide 37

Slide 37 text

『モブプログラミング・ベストプラクティス ソ フトウェアの品質と生産性をチームで高める』 マーク・パール、日経BP https://honto.jp/netstore/pd-book_29475322.html

Slide 38

Slide 38 text

ベストプラクティスの例 • モビングを実験として位置づける • 行番号ON • モビングインターバル…10分ごとに ドライバーを交代する • 経験からの学習…セッション後には毎回、ふりかえりをする • 最初は共感から • 協調的なマインドセットの獲得 • スペースは重要だ

Slide 39

Slide 39 text

始めるとき気をつけるとよいこと •目的とゴールを定める •進み方を表明する •議論と実験のバランスを取る •その場でフィードバックを得る •ふりかえりをする •個々人のペースとやり方で復習する

Slide 40

Slide 40 text

目的とゴールを定める • 目的: なにを目指すか、現在の優先事項、方向性 • 例: X機能の開発を全力で進める Yライブラリの使い方を共有する AさんがZモジュールの現状を把握する • ゴール: セッション終了時に到達したい点 • 例: X機能の正常系2パターンを実装してテストする Yライブラリを納得するまで動かして結果を残す AさんがZモジュールのシーケンスを図に描ける 目的や 方向性 ゴールと 進み方

Slide 41

Slide 41 text

「目的はこれ。いいですか?」ではダメ 「目的はこれこれです。いいですか?」 A) 「いいです(よくない)」 B) 「いいです(と思ったけど違った)」 C) 「いいです(聞いてない)」 • 少し議論や質問をして認識違いや 理解の差異を埋める • 進めながら揃う部分もあるので 深入りしすぎない • セッション途中でも確認する https://www.oreilly.com/library/view/user-story-mapping/9781491904893/

Slide 42

Slide 42 text

進み方を表明する • モブプロ中、現在地がわからなくなったり、迷子になったりする • いまどこにいるのか、次は何をするのか、ゴールに近づいているかを 常に共有する • ゴールに向かう手順は? • いまなにしてる? 次の作業はどれ? • やろうとしていることの全体像は? どのくらい終わった?

Slide 43

Slide 43 text

進み方を表明するツール TODOリスト 作業の区切り ここまでできたね 快調! このTODOは☑ね 次はどれだっけ こっちのTODO? あれ先にしない? それがいいかも! ドライバーがしゃべる さてABCメソッド 書くぞ あれ、DEFだっけ 正常系はこうで 変数名 どうしよっかな FOOBARは? FOOBAR…と 戻り値の型int? intでよかった

Slide 44

Slide 44 text

進み方を表明するツール TODOリスト 作業の区切り ここまでできたね 快調! このTODOは☑ね 次はどれだっけ こっちのTODO? あれ先にしない? それがいいかも! さてABCメソッド 書くぞ あれ、DEFだっけ 正常系はこうで 変数名 どうしよっかな FOOBARは? FOOBAR…と 戻り値の型int? intでよかった intだとダメじゃね そう? いい気がする 結果ゼロどうする? 例外かと思った 例外でいいね なにしてたっけ コメント忘れてた 条件書き換えて テストしたい テストあるよ テスト変更し いやケース追加 このケースある テスト足らんじ あとにしよう えー…はーい できた気がする 処理がこうで、 チェックがあっ 引数のバリデー ンは…しなくて ので、ループの もいいし、フェ ポストエラーは ドライバーがしゃべる 注意: ナビゲーターがもうちょっと仕事したほうがよい あーうー…あー あーーー!おけ これでよさげ わからん…

Slide 45

Slide 45 text

議論と実験のバランスを取る • モブでの議論は大事 • 知見を出しあってお互いから学べる • 創造的な騒々しい議論ができる • 知識が組み合わさって新しいアイデアが得られる • 話すだけではなく、試してみる • いいアイデアが出たら、書いてみる • 複数のアイデアは、書いて見比べる • 議論が平行線になったら、実際に動かしてみて比べる • 最初は議論 << 実験くらいの気持ちで • 結論が出るまで話す < 試してから結論を出す • 書く時間がもったいない < 書けば判明する・共有できる情報がもったいない

Slide 46

Slide 46 text

その場でフィードバックを得る コードを 書く レビュー OK 動く (ユニット テスト)

Slide 47

Slide 47 text

その場でフィードバックを得る コードを 書く レビュー OK 動く (ユニット テスト) ビルドパイプ ライン通る デプロイ できる 動く (E2E)

Slide 48

Slide 48 text

その場でフィードバックを得る コードを 書く レビュー OK 動く (ユニット テスト) ビルドパイプ ライン通る デプロイ できる 動く (E2E) 仕様漏れ がない (品 質テスト) よい設計 (リファクタ リング) モブ外の 人の評価 外部 システムと つながる

Slide 49

Slide 49 text

その場でフィードバックを得る コードを 書く レビュー OK 動く (ユニット テスト) 仕様漏れ がない (品 質テスト) ビルドパイプ ライン通る デプロイ できる 動く (E2E) よい設計 (リファクタ リング) モブ外の 人の評価 外部 システムと つながる 楽しい! 学びが多い! 品質向上!

Slide 50

Slide 50 text

その場でフィードバックを得る • 作業が“ちゃんと”進んでいるかどうか、モブの中でわかるように • 後で問題がわかっても、モブに伝わらない • 全員が正しい理解や学びを、できるだけたくさん得る • 動いたほうが楽しい!

Slide 51

Slide 51 text

ふりかえりをする • モブ作業を終えるとき • 全員で一緒に • やりかたはいろいろ • モブの延長として、みんな声を出すスタイルがおすすめ https://www.ogis-ri.co.jp/otc/hiroba/others/ActivityPocket/FunDoneLearn.html マインドマップでふりかえり して共有(リモート) ファンダンラーン 参考書籍

Slide 52

Slide 52 text

ふりかえりのねらいは2つ • よりよいプロダクトを目指す • よりよいモブプログラミングを目指す

Slide 53

Slide 53 text

学びを積み上げる • ふりかえりの結果を再利用できる形で残していく

Slide 54

Slide 54 text

個々人のペースとやり方で復習する • 復習 ― モブの中で得た新しい知識を定着させる • セッション後に一定の時間を確保する • スタイルは個々人の自由 • ひとりで復習してもよい • モブ体制を維持しながら、個人作業としてもよい • モブとして復習するのもよい ※復習に限らず、モブへの参加・離脱は各自の判断でゆるくてもよい

Slide 55

Slide 55 text

どんな仕事でも使える コードを 書く レビュー OK 動く (ユニット テスト) 仕様漏れ がない (品 質テスト) ビルドパイプ ライン通る デプロイ できる 動く (E2E) よい設計 (リファクタ リング) モブ外の 人の評価 外部 システムと つながる 楽しい! 学びが多い! 品質向上!

Slide 56

Slide 56 text

モブプロが生きる仕事 仕事に生かす モブプロの強み 仕事に生かせない 高度な知識を 組み合わせる 全員の知識を生かせる 形式的に定義された知識 均一な知識 解くべき問題が複雑 個々人の総和以上の 成果が出る 容易な問題の積み重ね 創造性が求められる エンゲージメントが 引き出される 単純作業 密な連携が必要 オーバーヘッドが 最小になる 明確に切り分け、 定義された作業 ルーチンワーク

Slide 57

Slide 57 text

モブプロが生きる仕事 最近の経験だと… ✓スクラッチ開発2ヶ月弱 ✓メンバーはいるけどパートタイム ✓知らんサービスいろいろ試す ✓どレガシーな既存システムと結合 ✓もやっとしたイメージだけで 何を実現したらいいかわからない ✓でも本番でユーザーに見せる (マジで?) • 新しいことを試す • 未知のものを使う • 全体的な設計 • 問題が複雑 • 正解がわからない • いろいろ起きて、どんどん対処する • 曳光弾開発 (『達人プログラマー』) • 顧客も一緒 • メンバーのスキルが高い • みんな乗り気 • 一部屋占拠して部室化

Slide 58

Slide 58 text

No content

Slide 59

Slide 59 text

必死にデプロイ中 なんかあったら すぐ参加できる

Slide 60

Slide 60 text

必死にデプロイ中 なんかあったら すぐ参加できる 全体がモブ

Slide 61

Slide 61 text

仕事に生かすかチームに生かすか? 仕事に生かす モブプロの強み チームに生かす 高度な知識を 組み合わせる 全員の知識を生かせる メンバーどうしで学びあう 解くべき問題が複雑 個々人の総和以上の 成果が出る 自分の力の出し方を学ぶ 協力が上手になる 創造性が求められる エンゲージメントが 引き出される モチベーションが上がる 障害物が見つかる 密な連携が必要 オーバーヘッドが 最小になる 文化を醸成、維持する

Slide 62

Slide 62 text

ここでアジャイル風味! うまくいったかどうか ここを見て 判定します 「 」

Slide 63

Slide 63 text

モブワークを始めるには… • 書籍『モブプログラミング・ベストプラクティス ソフトウェアの品質と 生産性をチームで高める』 • セミナー資料など • モブプログラミング スタートアップマニュアル https://speakerdeck.com/takaking22/mob-programming-startup- manual-number-mobprogramming-number-mobupuro • チームをブーストし、仕事をドライブするモブプログラミング【デブサミ2020】 https://codezine.jp/article/detail/12166 • オンラインモブプロの動画 https://takaking22.com/2020/online-mob- programming/ • 有償セミナー • https://event.shoeisha.jp/cza/remote-mob 及部さんとやっとむ

Slide 64

Slide 64 text

ふりかえり

Slide 65

Slide 65 text

No content

Slide 66

Slide 66 text

ふりかえり 次の一歩を よりよく踏み出すため 立ち止まる 時間

Slide 67

Slide 67 text

https://speakerdeck.com/viva_tweet_x/effective-retrospective-tonikakule-siihurikaeri?slide=61

Slide 68

Slide 68 text

『アジャイルレトロスペクティブズ 強いチームを育てる「ふりかえり」の手引き』 エスター・ダービー、ダイアナ・ラーセン、オーム社 https://honto.jp/netstore/pd-book_02923224.html ふりかえり読本シリーズ ふりかえり実践会 https://hurikaeri.booth.pm/

Slide 69

Slide 69 text

ふりかえりとは • すぐ先の未来のためにやる • 自分たちのためにやる • 自分たちでやる • 事実と経験を踏まえる • 楽しい • 頻繁にやったほうがいい

Slide 70

Slide 70 text

ふりかえりの構造 https://speakerdeck.com/viva_tweet_x/effective-retrospective-tonikakule-siihurikaeri?slide=108

Slide 71

Slide 71 text

「チームの心理的安全とは、対人のリスクを取っても 安全であるという、チーム全員の信念である」 “Psychological Safety and Learning Behavior in Work Teams” Amy Edmondson, 1999 Amy C. Edmondson https://twitter.com/amycedmondson 心理的安全 (Psychological Safety) 「「心理的安全」とは、関連のある考 えや感情について人びとが気兼ね なく発言できる雰囲気をさす。」

Slide 72

Slide 72 text

※コミットメントベースの人事活動(CBHRP)は 双方向の、長期的な人間関係に着目し、HR活 動のシステムとして従業員のスキルレベル、モ チベーション、情報、エンパワーメントを強化す る。CBHRPは個々の従業員の定着率を改善す る。 https://www.sciencedirect.com/science/article/pii/S0970389 615000968 心理的安全性 (および全体的な信頼 関係/全体的な自主性) 組織学習 組織のパフォーマンス 知識の交換/ 組み合わせ コミットメントベースの HR活動※ 高品質な人間関係、 ソーシャルキャピタル プロセスの革新 Figure 2を訳したもの “Psychological Safety: The History, Renaissance, and Future of an Interpersonal Construct” Amy C. Edmondson and Zhike Lei, 2014 https://www.annualreviews.org/doi/pdf/10.1146/annurev-orgpsych-031413-091305 図2. 組織レベルの心理的安全に関する研究の対象となった関係。HR=Human Relationship (人事) コミットメントベースという、従業員に対する新しいアプローチは、従来よりも幅広く 設計した職種を定義し、計画と実施を統合し、オペレーションを維持するのみでな く更新する施策を含んでいる。個人の責任は状況の変化に応じて変化し、組織が 成果を求める単位は個人からグループに移行する。マネジメントの組織構造はフ ラットで立場の差異は最小限になり、コントロールと協調は共有されたゴールに依 存し、肩書きではなく専門性が影響力を持つ。(“From Control to Commitment in the Workplace”, Richard E. Walton, Harvard Business Review 1985) https://hbr.org/1985/03/from-control-to-commitment-in-the-workplace

Slide 73

Slide 73 text

いろいろなふりかえり手法・ツール KPT プロジェクトファシリテーション実践編:ふりかえりガイド http://objectclub.jp/community/pf/ https://www.techagilist.com/agile/scrum/sailboat-or-speedboat-sprint-retrospective/ Speedboat https://qiita.com/radiocat/items/5639ae676ce3b52b3a3f https://nuworks.jp/ja/2016/10/26/moving-motivators/ ムービング・ モチベーターズ https://www2.slideshare.net/tocfe/ss-11267504 https://hiiiiiiihikaru.hatenadiary.com/entry/2018/01/31/143520 http://takubon.hatenablog.com/entry/2015/08/28/165524 TOCfEブランチ (問題構造ツリー)

Slide 74

Slide 74 text

いろいろなふりかえり手法・ツール ふりかえりチートシート https://qiita.com/viva_tweet_x/items/b06f56ce83038fc2bb8f Retromat https://retromat.org

Slide 75

Slide 75 text

ファンダンラーンふりかえり • ファクトを掘り起こして共有する • 楽しい(Fun)・やり遂げた(Done)・学びがあった(Learn)で分類する • ファクトに対する感じ方をチームで話す • 場の形成とチームの強化が主なねらい • アクションアイテムを出すには、これだけでは足らないかも

Slide 76

Slide 76 text

No content

Slide 77

Slide 77 text

楽し かった 楽しく 学びも 完了した 達成した 楽 完 学 学び あった

Slide 78

Slide 78 text

ファンダンラーンふりかえり 1.まずホワイトボードや模造紙に、上のFun/Done/Learnの図を描く。重なり合う領域が狭 くなりすぎないよう気をつけること 2.メンバー1人ひとりで、やったことを付箋に書き出す 3.付箋の内容を共有して会話しながら、図上の当てはまる領域に付箋を貼っていく。 1. 付箋を書いた人ではなく、他のメンバーが貼り付ける領域を選ぶようにすると面白いです 2. 例: 「みんなでゲームで遊んだ」→ 楽しかったのでFunの円の上半分(他と重ならない部分)に貼る 3. 例: 「モブプロでスキルを共有したが進みは遅かった」 → モブプロでモチベーションが上がったのでFun、ス キル共有したのでLearn、Doneにはつながらなかったので、FunとLearnの重なる右中央の領域に貼る 4. 例: 「新たにVue.jsで機能を実現できた」→ やって楽しかったし、Vue.jsを学べたし、機能をリリース(提供)でき たので、Fun/Deliver/Learnの重なる中央部分に貼る 4.次にスプリントやプロジェクト全体としてどうだったか、当てはまると思う領域に1人ずつ 選ぶ(シールを貼ったり、ペンで印をつけたりするとよい)。スプリントならスプリント全体、 プロジェクトならプロジェクト全体についての評価をする 5.ボードを眺めながら、次のスプリントやプロジェクトではどの領域を狙いたいか話をする ファン・ダン・ラーン(FDL)ふりかえりボード https://qiita.com/yattom/items/90ac533d993d3a2d2d0f

Slide 79

Slide 79 text

ファンダンラーンふりかえり 1.図を描く。大きく、特に重なる領域が広くなるように 2.個々人で、やったこと、出来事、事実を付箋に書く 3.話しながら付箋をファンダンラーンの当てはまる領域に貼っていく 4.楽しく会話する

Slide 80

Slide 80 text

ここでアジャイル風味! なんだかんだ言っても 要するに やりたい! 「 」

Slide 81

Slide 81 text

ふりかえりを始めるには… • 書籍『アジャイルレトロスペクティブズ 強いチームを育てる「ふりか えり」の手引き』 • 書籍 ふりかえり読本シリーズ ふりかえり実践会 https://hurikaeri.booth.pm/ • KPT/KPTA https://www2.slideshare.net/esmsec/kpta- 55354492 • ふりかえりam https://anchor.fm/furikaerisuruo/episodes/ep-1- amPodcast---viva_tweet_xhiguyume-Podcast-ea1lk9

Slide 82

Slide 82 text

アジャイル風味 やってみる やったらこうなる やったら測る やりたい

Slide 83

Slide 83 text

アジャイル風味 やってみる勇気を持つ 目標をコミュニケーションする フィードバックから学ぶ やりたい気持ちを尊重する

Slide 84

Slide 84 text

おしまい Copyright©2020 安井力、合同会社やっとむ屋