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

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

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

テスト駆動開発

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

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

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

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

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

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

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

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

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

No content

No content

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No content

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

モブワーク

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

No content

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

No content

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

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

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

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

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

ふりかえり

No content

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

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

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

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

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

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

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

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

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

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

No content

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

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

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

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

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

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

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

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