Upgrade to Pro — share decks privately, control downloads, hide ads and more …

アジャイルの風味をお持ち帰り

yattom
December 13, 2020

 アジャイルの風味をお持ち帰り

Agile Japan 2020の某所サテライトでお話しさせてもらった資料です

yattom

December 13, 2020
Tweet

More Decks by yattom

Other Decks in Programming

Transcript

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

    View Slide

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

    View Slide

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

    View Slide

  4. テスト駆動開発

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  12. テスト駆動開発の効果
    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

    View Slide

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

    View Slide

  14. View Slide

  15. View Slide

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


    View Slide

  17. テスト駆動開発を始めるには…
    • 書籍『テスト駆動開発』
    • コミュニティイベント 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で参加してます

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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


    View Slide

  31. View Slide

  32. アジャイルな見積りと計画づくりを始めるには…
    • 書籍『アジャイルな見積りと計画づくり』
    • 認定スクラムマスター研修
    • 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/

    View Slide

  33. モブワーク

    View Slide

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

    View Slide

  35. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  58. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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


    View Slide

  63. モブワークを始めるには…
    • 書籍『モブプログラミング・ベストプラクティス ソフトウェアの品質と
    生産性をチームで高める』
    • セミナー資料など
    • モブプログラミング スタートアップマニュアル
    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 及部さんとやっとむ

    View Slide

  64. ふりかえり

    View Slide

  65. View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

  72. ※コミットメントベースの人事活動(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

    View Slide

  73. いろいろなふりかえり手法・ツール
    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ブランチ
    (問題構造ツリー)

    View Slide

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

    View Slide

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

    View Slide

  76. View Slide

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

    View Slide

  78. ファンダンラーンふりかえり
    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

    View Slide

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

    View Slide

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


    View Slide

  81. ふりかえりを始めるには…
    • 書籍『アジャイルレトロスペクティブズ 強いチームを育てる「ふりか
    えり」の手引き』
    • 書籍 ふりかえり読本シリーズ ふりかえり実践会
    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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide