アジャイルとスクラムとは ～価値、原則、プラクティス～

アジャイルとスクラムの入門、基本的な講義の資料です

Transcript

1. Agile and Scrum – values, principles, practices アジャイルとスクラムとは ～価値、原則、プラクティス～ やっとむ こと 安井 力 アジャイルコーチ 合同会社やっとむ屋 代表 Copyright© 2021 by 安井力、合同会社やっとむ屋 yattom@yattom.jp スライド公開URL https://is.gd/BMNP2P
2. 2001年ごろアジャイルと出会い、開発者、チームリーダー、トレー ナー、導入支援と多様な立場で関わってきた。(株)永和システム マネジメントにて2010年頃からアジャイルコーチを主軸として 活動。2014年独立。 プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム 著書・訳書 tsutomu.yasui@gmail.com twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ やっとむ / 安井力(やすいつとむ)
3. 今日の内容 • アジャイルな企業の例 • アジャイルとはなんなのか？ • アジャイルの価値・原則・プラクティスとは？ • アジャイルに向き不向きはあるの？ • アジャイルをやってみるには？ 質問歓迎します！
4. アンケート: アジャイルやスクラムのイメージ • www.menti.com をアクセスして、番号を入力してください • ご自分のアジャイルやスクラムのイメージと近いものを3つ選んでく ださい • 録画視聴の方も手元で書き出してみてください
5. ある 変わった企業 の話
7. どこが変わってるの？ • 顧客が毎週やってきて、開発チームと一緒に成果について話す • プログラマーは全員ペアを組んで仕事をする • 毎週納期、でも残業はぜんぜんない • ハイテク人類学者がユーザーを研究する • 地下の広大なオフィス(駐車場を改装)で、座席・デスクが移動自由 • 赤ん坊や動物がいる • 喜びがある (※基本的に2016年時点の話になります)
9. 他の写真？なにか適当なやつ？ https://www.flickr.com/photos/kitlvcollections/5497319028/ ハイテク人類学者 High-Tech Anthropologists
10. 顧客による計画おりがみ
12. 自律的な進捗管理
15. ペアプログラミング
16. 顧客を巻き込んだデモ ショウ＆テル
17. すなわち…… 要件定義 プロジェクト 計画 実装 受入テスト ハイテク 人類学者 顧客と 計画おりがみ ペア作業 タスクボード ショウ＆テル 1週間
18. MAKE MISTEAKS FASTER 失敗をはやくたさくんしよう
19. 2021年のアップデート • 2020年はファイナンスの危機 • 収益60％ダウン • 一時的な給与カット • 手元資金とPPPローンで乗り切った • 全員リモートワーク • 「リモートで上手くやれる方法を探究するのが楽しみだ！」 • リモートペアプロ • リモートでハイテク人類学 • 紙やホワイトボードの仕組みをデジタル化 • オフィスツアーはバーチャルツアー • 採用インタビューもバーチャルで実施(2021年2月) https://menloinnovations.com/stories/culture/culture-storytelling-joy
20. またある 変わった企業 の話
21. https://www.sonicgarden.jp/201407_family_trip 株式会社 ソニックガーデン
22. どこが変わってるの？ • 家族旅行をする • 全社員リモートワーク • オフィスをなくした • 顧客には顧問プログラマが１人で専任する • 企画から設計、コーディング、運用まですべて • マネージャがいない • 業務ハッカー募集中 • 納品しない受託開発 • プログラマを一生の仕事に
24. http://getnews.jp/archives/1510240 全社員リモートワーク(2016年から)
25. https://www.flickr.com/photos/124247024@N07/13903385550/ 顧問プログラマ
26. https://www.slideshare.net/rootmoon/ss-48797871
27. https://www.slideshare.net/rootmoon/ss-48797871
28. https://kuranuki.sonicgarden.jp/2014/11/innoswdev_fse.html
30. 1人ひとりがセルフマネジメント チーム全体がみんなで協力
31. 小さな組織で個人の価 値を尊重すること 中間に入る無駄をなく して直接つなぐこと 判断に理解と納得を持 ち思考停止しないこと 動くサービスを常に最 高品質で提供すること 小口化し繰り返すこと で持続可能にすること 日々学びを続けて自ら 変化に取り組むこと 情報をオープンにし常 に公明正大であること 価値観を共有 https://www.sonicgarden.jp/company
32. 「こうした問題を何とかできないか、一 体何が原因なのかを考え尽くしたとこ ろ…ビジネスモデルそのものに問題が あると分かった」 「もともと私たちはリモートチームを… 目的にしてきたわけではありません。… ビジネスモデルを追究した結果として、 リモートチームで仕事ができるように」 「変化を受け入れる 変化を恐れない 自らの変化を広げる」 変化 試行錯誤 https://www.sonicgarden.jp/company
33. アジャイルな ソフトウェア開発 とは
40. アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 http://agilemanifesto.org/iso/ja/ 2001年
41. アジャイル宣言の背後にある原則 私たちは以下の原則に従う: 顧客満足を最優先し、 価値のあるソフトウェアを早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、お客様の競争力を引き上げます。 動くソフトウェアを、2-3週間から2-3ヶ月という できるだけ短い時間間隔でリリースします。 (続く) http://agilemanifesto.org/iso/ja/principles.html
42. ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで彼らを信頼します。 情報を伝えるもっとも効率的で効果的な方法は フェイス・トゥ・フェイスで話をすることです。 動くソフトウェアこそが進捗の最も重要な尺度です。 (続く) http://agilemanifesto.org/iso/ja/principles.html
43. アジャイル･プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるようにしなければなりません。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます。 シンプルさ（ムダなく作れる量を最大限にすること）が本質です。 最良のアーキテクチャ・要求・設計は、 自己組織的なチームから生み出されます。 チームがもっと効率を高めることができるかを定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 http://agilemanifesto.org/iso/ja/principles.html
44. http://agilemanifesto.org/iso/ja/ Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
45. アジャイルとは
46. アジャイルソフトウェア開発宣言 私たちは、ソフトウェア開発の実践 あるいは実践を手助けをする活動を通じて、 よりよい開発方法を見つけだそうとしている。 この活動を通して、私たちは以下の価値に至った。 プロセスやツールよりも個人と対話を、 包括的なドキュメントよりも動くソフトウェアを、 契約交渉よりも顧客との協調を、 計画に従うことよりも変化への対応を、 価値とする。すなわち、左記のことがらに価値があることを 認めながらも、私たちは右記のことがらにより価値をおく。 http://agilemanifesto.org/iso/ja/ 2001年
47. Alistair Cockburn “Heart of Agile” http://alistair.cockburn.us/HeartOfAgile 2014年
48. https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/ Joshua Kerievsky “Modern Agile” 2016年
49. 安全を必須条件にする • よい仕事の前提条件 • 心理的安全性 • アンゼニアリング (Anzen-eering)
50. 高速に実験＆学習する • よりよいやり方をつねに模索する • 現状が上手くいっていたら、それを壊す • 自分の経験から、相互の知識から、外のリソースから学ぶ • 実験から新たな情報を獲得する
54. モブプロの実験と改善の例
55. 雑談 • クリエーションライン社の取り組み • https://www.creationline.com/blog/tadahiro-yasuda/31156 • なお講師がアジャイルコーチとして支援しています • Weekly朝会で全社員がお互いに雑談する • たくさんの実験 • 時間設定 • 人数 • メンバー • 雑談テーマ • 効果 →
56. 継続的に価値を届ける • ユーザー価値に集中する • 継続的に、頻繁にデリバーする • 毎週～毎日程度 • サービス内容にもよる • 届けた結果を見る • フィードバックを得る • 新たな実験の材料とする
57. 人々を最高に輝かせる • 成果を得るために最も大切なのは人 • 個人と人々 • 最高に輝いている個人・チームが最高の結果を出せる
58. 従来型 ウォーターフォール アジャイル
59. 従来型 ウォーターフォール アジャイル プロセスや ツール 個人と対話
60. アジャイルなソフトウェア開発の4側面
61. https://speakerdeck.com/kawaguti/kanban-and-scrum
62. 1999 1995 2003 2001 参考: 1991 - Linux 1996 - Java 1.0 2001 – Windows XP 2002 - .NET Framework 1.0 1986 1994 (GoF)
63. アジャイルとは？ • 「アジャイルな開発」を実現できるような 人、組織、環境、ビジネスを作ること？ • アジャイルな開発から得た知見を 人、組織、環境、ビジネスに応用すること？ どちらにしても、 開発だけ 運用だけ ビジネスだけ 。。。の話ではない！ 経営だけ 人事だけ
64. アジャイルな開発の特徴 • ビジョンや目標を共有し、全体がそこに向かっている • ルール、プロセス、手法が常に変わり続けている • アウトカム(結果)を重視している • 「そこにいる人びと」ならでは、になっている • 顧客やステークホルダーの信頼を得ている • 市場競争力を維持している • 自主性があり、いきいきして、学び続けている こうした観点からKPI・KGIを選ぶ
65. アジャイルな人や組織の特徴 • ビジョンや目標を共有し、全体がそこに向かっている • ルール、プロセス、手法が常に変わり続けている • アウトカム(結果)を重視している • 「そこにいる人びと」ならでは、になっている • 顧客やステークホルダーの信頼を得ている • 市場競争力を維持している • 自主性があり、いきいきして、学び続けている こうした観点からKPI・KGIを選ぶ
66. アジャイルの指標例 • 実験の頻度、健全な割合で失敗しているか • ビジョンの認知と腹落ち度 • 顧客やユーザーからのNPS(ネットプロモータースコア) • 価値提供の頻度 • メンバーの成長と流動性 • ソフトウェア開発の場合 • リリースと測定の頻度 • CI、CDの頻度と所要時間 • テストの自動化カバレッジ ※コードカバレッジではなく、テストの自動化カバレッジ • ソースコードの変更頻度(既存コードをちゃんと直しているか)
67. アジャイルは形容詞 agi・le [形] 素早い、敏捷、しなやかな • Be Agile, not Do Agile • アジャイル「を」やる ⇒ できない！ • アジャイル「を」使う ⇒ 誤り • アジャイル「に」開発する • アジャイル「な」態度 • 「もっと」アジャイル
68. 形容詞「アジャい」 • アジャい開発 • 「うちのチーム、結構アジャいんですよ」 • 我が社でもアジャイルを導入する → 我が社もアジャいくなる • 「アジャイルをやるのに必須のツールです」 → 「今よりアジャいくなるのに、お勧めツールです」 ※誰も言ってません。流行ったらいいな
69. 開発 運用 ビジネス 経営 人事 ビジョン プロダクトの 価値 プロダクトの 価値 長期 世界・世間 組織文化 変化 能力を発揮 するチャンス 能力を発揮 するチャンス 差をつける チャンス 常に・あたり まえ スキルアッ プ・チェンジ アウトカム ユーザーに とっての価値 ユーザーに とっての価値 新たな展開 コアバリュー の不変 現場の声 信頼と実績 フィードバッ クを生かす フィードバッ クを生かす 三方良し 現場を信頼 採用より成 長重視 いきいき 個々の強み、チームの力、モチベーション、誇り
70. マインドセットの違い ガチガチマインドセット • 能力 – 不変、背の高さなど • ゴール – 良く見られる • 挑戦 – 避ける • 失敗 - 個人的な問題 • 努力 - 能力がない人がやる • 困難に直面すると – 無力 アジャイルマインドセット • 能力 – 成長、筋肉など • ゴール – 学ぶ • 挑戦 – 受け入れる • 失敗 – 情報を得られる • 努力 – 熟達への道 • 困難に直面すると – 回復力(レジリエント)
71. アンケート: 自分にとってアジャイルとは？ • ここまでの話から、アジャイルという考え方が自分にどう関わるか、 自分ならどんなところにアジャイルをあてはめたいか、思いついた ことを書いてください。 • 複数回答可です(送信した後で追加できます) • 時間が余ったらおすすめのランチやおやつについて書いてください • 録画視聴の方も手元で書き出してみてください
72. アジャイル への たどり着き方
74. 価値、原則、プラクティス • 価値 = 究極の目的 • プラクティス = 実際の具体的なやり方 • 原則 = プラクティスがなぜ価値につながるかの説明
75. 価値、原則、プラクティス • メンローイノベーションズ • 価値 = 喜び • 原則 = 個人を生かす、学び合う、仕事を楽しむ • プラクティス = ペアプログラミング • ソニックガーデン • 価値 = 個人を尊重、試行錯誤 • 原則 = 一生プログラマ、納品しない、やってみる • プラクティス = リモートワーク、顧問プログラマ、定額契約、師弟制度 • 数えると、おおむね 価値 < 原則 < プラクティス
77. お仕事 頑張ってますか？
78. 何のために お仕事 頑張ってますか？
80. 何のため＝価値 • 価値とは ほしいもの • ただでは手に入らない
81. プログラム 機能 フィーチャ 価値 コスト
82. C B どれを選ぶ？ A D 価値 コスト
83. B A D 価値が大きく 早くできるものから C 1 2 3 4
84. コスト≒時間 B A D C コスト
85. 価値は時間累積 B A D C 時間 価値 累積価値
86. 価値は時間累積 B A D C 時間 価値 累積価値
87. B A D 大価値短期間＝高ROI C 1 2 3 4
88. A A A A A
89. 価値とはほしいもの • 顧客価値 • 情報、リスク対策 • 生産性
90. 早いほうがいい 細かいほうがいい 先のことも考えたほうがいい
91. 簡単 ですね♪
92. 簡単な わけがない 💀
94. お仕事 頑張ってますか？
95. 誰のために お仕事 頑張ってますか？
96. 誰が 誰のために お仕事 頑張ってますか？
97. コミュニケーション
98. 情報帯域
99. コミュニケーションパス パス＝3本 1人2本 パス＝10本 1人4本 パス＝66本 1人11本
100. 伝言ゲームと 情報劣化
101. 価値を提供するすべてのスキルを一緒に ビジネスも技術もマネジメントも一緒に ユーザーも顧客も開発も一緒に できるだけ少人数で
102. 簡単な わけがない 💀
103. 手戻り
104. 技術的負債
105. 機能追加とコスト 時間 価値
106. 価値 コスト 時間 圧 縮 技 術 的 負 債 利 子 コスト 時間 圧 縮 技 術 的 負 債 技術的 負債
107. 技術的負債 • 一時的なメリットを与える(レバレッジ) • 開発したソフトウェアに内在する • 開発の作業効率を悪化させる • 除去作業をしないと取り除けない • 放置すると増殖する
108. 技術的負債 • 不適切なエンジニアリングで発生する • 能力不足 • 圧力、プレッシャー • 考慮不足 • 将来は本質的に予測できない • 「考慮不足」は不可避 • 「キレイ」な状態を… 最初にちゃんとする → 不可能 or どこかで破綻する 維持する → 常時リファクタリングを続ける • 負債をためすぎないうちに返済する • 将来予測 → 変更容易
109. 変更容易性 • 設計がシンプル • 変更箇所と内容が自明 • 依存関係が少ない • 特に隠れた依存関係 • 実装もシンプル • 誰でも安心して変更できる • 自動化したテスト • リグレッション • 常にこの状態を維持する • 厳しい規律 • だんだん難しくなる
110. 品質と規律
111. 簡単な わけがない 💀
112. 人
113. こんなに難しいことを実現する 仕組みを作るのは困難 こんなに難しいことを実現する 工夫を作れる人
114. https://anagileway.wordpress.com/2016/10/07/modern-agile-jp/ Joshua Kerievsky “Modern Agile”
115. モチベーション3.0 • 自律 • 熟達 • 目的 自分のやり方で集中することで より上手になり、できることも広がり そうして大きな目標を目指せれば モチベーションが上がる
116. チームによる学習
117. 責 任 大 ← → 小 能力 →高 低← 学習 パニック 快適
118. 責 任 大 ← → 小 能力 →高 低← 学習 パニック 快適
119. 「チームの心理的安全とは、対人のリスクを取っても 安全であるという、チーム全員の信念である」 “Psychological Safety and Learning Behavior in Work Teams” Amy Edmondson, 1999 Amy C. Edmondson https://twitter.com/amycedmondson 心理的安全 (Psychological Safety) 「「心理的安全」とは、関連のある考 えや感情について人びとが気兼ね なく発言できる雰囲気をさす。」
120. 図3. グルー プレベルで 研究した心 理的安全性 の関係
121. 集団的学習を促す行動 • 質問する • 情報を共有する • 支援を求める • 証明されていない行動を試みる • 失敗について話す • 意見を求める
122. イノベーションを産み出し続ける組織 SECIモデル http://www.atmarkit.co.jp/aig/04biz/seci.html http://current.ndl.go.jp/ca1518
123. 学習する組織 • システム思考 – 全体を考える • メンタルモデルへ意識を向け見直す • 共有ビジョン ― 「自分たちはなにを創造したいのか？」 • チーム学習とアラインメント(合致) • 経営者を含むマネジメント全体の意識変革 『学習する組織』ピーター・M・センゲ
124. •価値 •コミュニケーション •技術 •人
125. 簡単な わけがない 💀
127. 価値とは…… • 製品のユーザーが何を 望んでいるか知りたい • ワクチンの効率的配送 サービスを実現する • 会社の資金が底をつきそう • 製品が遅い • 開発スピードが遅い • 猫の画像でにっこりさせたい → 情報 → 人命 → 会社存続 → 実行速度 → 開発速度 → しあわせ
130. プラクティス •Practice = 練習 実践 • HOW •なぜやるのか、なんのためにやるのか • ノウハウではない • 必須でもない 必要性から要請される •実験の対象 • うまくいくかどうか やってみて改善 • 実際のやり方はみな違う
131. 超基本プラクティス • 朝会 / デイリースタンドアップ / デイリースクラム • 短期間サイクル / イテレーション / スプリント • タスクボード / スプリントバックログ • ふりかえり / レトロスペクティブ
132. 朝会 / デイリースタンドアップ • チーム全員 • 毎日、同じ場所、同じ時間で • 状況と問題を共有する • 立ったまま、15分以内 • 現状を踏まえて計画を見直す https://www.slideshare.net/yattom/project-facilitation-from-hiranabe
133. イテレーション • 1～4週間程度をサイクルとして、仕事を完成する • 仕事を完成する • 1機能の要件定義、設計、実装、テストまで • できるように仕事を小さく分割する • イテレーション冒頭で計画づくりをし、終わりでふりかえりをする • イテレーションの成果から毎回フィードバックを得る
134. ふりかえり / レトロスペクティブ • チーム全員 • 仕事のやりかたを見直す • 改善アクションを出す • チームが自分自身で実験する
135. タスクボード • チーム全員のタスクを見える化 • 状況を日々アップデート • 見れば誰でも全体の様子がわかる • 順調でなければ誰でもアクションできる
136. 朝会、ふりかえりを学ぶ • プロジェクトファシリテーション http://objectclub.jp/community/pf/ • 朝会ガイド http://objectclub.jp/download/files/pf/MorningMeetingGuide.pdf • ふりかえりガイド http://objectclub.jp/download/files/pf/RetrospectiveMeetingGuide.pdf • 見える化ガイド (タスクボード) http://objectclub.jp/download/files/pf/ManagementBySeeingGuide.pdf • ふりかえりの書籍 • 『アジャイルレトロスペクティブズ』 https://www.amazon.co.jp/dp/4274066983 • 『アジャイルなチームをつくる ふりかえりガイドブック』 https://www.amazon.co.jp/dp/4798168793
137. 朝会 イテレーション タスクボード ふりかえり 作る 現状 更新 見直し リズム 思い出す 見返す 次回に 生かす プラクティス同士の相互作用
138. アンケート • 質問として、詳しく聞きたいプラクティスを書いてください • 具体的に導入を検討していたり、やっているけれど困っているなど • 資料で触れていないものでもOKです
139. XP(Extreme Programming)の プラクティス 主要プラクティス • 全員同席 • チーム全体 • 情報満載のワークスペース • いきいきとした仕事 • ペアプログラミング • ストーリー • 週次サイクル • 四半期サイクル • ゆとり • 10分ビルド • 継続的インテグレーション • テストファーストプログラミング • インクリメンタルな設計 導出プラクティス • 本物の顧客参加 • インクリメンタルなデプロイ • チームの継続 • チームの縮小 • 根本原因分析 • コードの共有 • コードとテスト • 単一のコードベース • デイリーデプロイ • 交渉によるスコープ契約 • 利用都度課金
140. XP(Extreme Programming)の プラクティス
141. https://speakerdeck.com/kakutani/xpmatsuri2019-keynote
142. スクラムのプラクティス •3つの役割 • プロダクトオーナー、開発者、スクラムマスター •スプリント、プロダクトゴール、スプリントゴール •5つのイベント • スプリントプランニング、スプリントレビュー、 デイリースクラム、レトロスペクティブ、リファインメント •3つの作成物 • プロダクトバックログ、スプリントバックログ、 プロダクトインクリメント
143. https://www.servantworks.co.jp/resources/scrum_overview_figures/
144. アンケート • 質問として、詳しく聞きたいプラクティスを書いてください • 具体的に導入を検討していたり、やっているけれど困っているなど • 資料で触れていないものでもOKです
147. プラクティスの難しさ: マニュアルではない • 実際にやるのはプラクティス • プラクティスをやるだけでは価値に近づかない • 「なんのため？」と「なぜ？」を意識し続ける • 自分たちがねらっている価値を共有し、理解を深める • 価値に到達する原則について全員で勉強する
148. • ただやろうとしても、なかなか上手くいかない • 我流になってしまって効果が上がりにくい • 実践(=プラクティス)の中で、繰り返し練習(=プラクティス)する • 繰り返しながら、自分たちで常に見直し続ける × やれているか △ 型通り・お手本通りか ◦ 価値に近づいているか • お手本、ガイド、指導者などを活用する プラクティスの難しさ: 練習しないと上達しない
149. 守破離 • 能、茶道、剣道などの教え • 守 • 師匠につき、言われたとおりのことが完璧にできるよう修練する • 基礎を身につける • 破 • 自分なりの試行錯誤をしたり、他流のやり方を取り込んだりする • 精神、メカニズム、理論を身につける • 離 • 自分自身が独立し、流派を作る、自らが師匠になる • 新たな価値を生み出す
150. • プラクティス同士の相互作用がある • 単体では効果が上がりにくい • 同時にたくさん導入すると失敗する、難易度が高くなる • やりやすい、導入しやすい順序がある • ひとつずつ導入する • ちゃんとできるようになるまで、他のことに手を出さない プラクティスの難しさ: 独立したテクニックではない
151. https://www.amazon.co.jp/dp/B08711ZCPY
152. • 期待したようにも、予定通りにも進まない • 予想外の出来事や結果は、自分たちについての新たな発見 • 試行錯誤しながら自分たちについて理解を深めていく • 計画通りに進まないことを計画する • 全員で計画づくりをする • 計画変更を計画に含める • 計画変更につながる情報収集を計画する • 計画変更の工数が小さくなるよう、計画の詳細度をコントロールする • 計画変更の量や回数を指標とする(少なかったら問題) プラクティスの難しさ: 計画通りには進まない
153. アジャイルな見積りと計画づくり • アジャイルで計画はたいへん重要 • 必要なだけ計画する • 変化を前提として計画する • 出来上がった計画 よりも 計画づくり を重視する • プランニング・オニオン EMZERO Vol.3.1(マナスリンク)より引用 http://www.manaslink.com/articles/75 参考： 「アジャイルな見積りと計画づくり」 マイク・コーン著 角谷信太郎、安井力訳 https://www.amazon.co.jp/dp/4839924023
154. • 難しいので、あきらめがち • 難しいので、簡単な方法を探しがち • 難しいので、自分はいいやと思いがち • 難しいので、非難されがち • 信念と熱意のある人が必要(知識もあるとよい) プラクティスの難しさ: 難しい
155. 新しいことに取り組むのは常に難しい • 信念と情熱のある人が必要 (1 エバンジェリスト) • 小さく試して小さく成功させる (2 小さな成功) • 大きな理想を一歩ずつ実現する (3 ステップバイステップ) • 自分の不足を認めて助けを請う (6 協力を求める) • 先見性のある人を集める (11 アーリーアダプター) • とにかく試してみる (17 やってみる) • 権限ある人に認められる (28 経営層の支持者) • やるといいことがあるという気配で人を引き寄せる (40 成功のにおい) https://www.amazon.co.jp/dp/462108786X
156. アジャイルと 向き 不向き
157. アジャイルの向き不向き • 効果が期待できるプロジェクト、プロダクト • 能力を発揮する個人の性向 • チームや組織の、ルールや文化
158. カオス 複雑 込み入った シンプル
159. https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba Stacey Matrix 要求、スコープ、市場 技術、テクノロジー 不明確 明確 不明確 明確
160. Stacey Matrix https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba 要求、スコープ、市場 技術、テクノロジー 不明確 明確 不明確 明確
161. Stacey Matrix https://www.linkedin.com/pulse/why-stacey-matrix-model-can-help-understand-agile-baf-kurtulaj-mba 要求、スコープ、市場 技術、テクノロジー 不明確 明確 不明確 明確
162. On Pioneers, Settlers, Town Planners and Theft. by Simon Wardley http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html
163. よくある障害 • 上司が理解してくれない • 部下、現場が理解してくれない • 他部門、顧客が理解してくれない • 契約やコンプライアンスの壁がある • 開発スキルが足りない • 既存のコード、システム、サービスがある • 時間がない • 予算がない • 人材が足りない
164. よくある障害 • 上司が理解してくれない • 部下、現場が理解してくれない • 他部門、顧客が理解してくれない • 契約やコンプライアンスの壁がある • 開発スキルが足りない • 既存のコード、システム、サービスがある • 時間がない • 予算がない • 人材が足りない よくある！ 対処し乗り越える対象 障害を発見する のがスクラム
165. マインドセットの違い ガチガチマインドセット • 能力 – 不変、背の高さと同じ • ゴール – 人から良く見られる • 挑戦 – 避ける • 失敗 - 個人的な問題 • 努力 - 能力がない人がやる • 困難に直面すると – 無力 アジャイルマインドセット • 能力 – 成長、筋肉などと同じ • ゴール – 学ぶ • 挑戦 – 受け入れる • 失敗 – 情報を得られる • 努力 – 熟達への道 • 困難に直面すると – 回復力(レジリエント)
166. アジャイルマインドセット • 実験： 「ガチガチ」と「アジャイル」マインドの2グループ • 簡単な試験を受けてもらう • 次の試験を選ばせる • ガチガチ → 簡単なものを選ぶ • アジャイル → 難しいものを選ぶ • 他の人にアドバイス • ガチガチ → アドバイスしない、嘘をつく • アジャイル → アドバイスする • 2つのグループの違いは？ • ランダムに分けただけ • ガチガチ → 結果をほめられた • アジャイル → 努力をほめられた https://www.slideshare.net/agiledays/linda-rising-the-power-of-an-agile-mindset
167. アジャイルマインドセット • 実験： 「ガチガチ」と「アジャイル」マインドの2グループ • 簡単な試験を受けてもらう • 次の試験を選ばせる • ガチガチ → 簡単なものを選ぶ • アジャイル → 難しいものを選ぶ • 他の人にアドバイス • ガチガチ → アドバイスしない、嘘をつく • アジャイル → アドバイスする • 2つのグループの違いは？ • ランダムに分けただけ • ガチガチ → 結果をほめられた • アジャイル → 努力をほめられた https://www.slideshare.net/agiledays/linda-rising-the-power-of-an-agile-mindset
168. 障害を乗り越えるアジャイルマインド • 結果を出すのが大事 → 努力するのが大事 • 「頑張ります！」では大雑把 → プロセスや経過、判断や行動を細かく識別、把握する • 小さな失敗をたくさん見つけて情報を得る • 個人の責任、自分の作業を完遂する → チームの責任、全体で価値を完成する • 人は人、仕方ない → 人はつながり、変化する
169. アジャイルを “やってみる”
170. Unlearn 脱学習
171. Unlearn / 脱学習 / まなびほぐし • アジャイルに限らず、今までのやり方を変えるときに必要 • 今までのやり方＝今までに学んだことを、いったん脱ぎ捨てる • うまくいくかわからなくても、やってみる • うまくいかないとわかっていても、やってみる • 過程を精緻に分析し、知見を得る • 結果はあまり気にしない • 結果の良し悪しより、予想とのズレに注目する • 新たな学びに向け、今までの知識を壁にしない
172. 超基本プラクティス • 朝会 / デイリースタンドアップ / デイリースクラム • 短期間サイクル / イテレーション / スプリント • タスクボード / スプリントバックログ • ふりかえり / レトロスペクティブ • 「プラクティスは難しい」を忘れずに
173. チームに任せる • 環境を与える • 場所、空間、オフィス • 機材、インフラ • 支援を与える • 他からの介入を防ぐ • 問題・課題を解消する • 信頼する • 放っておく！
174. 組織を変えるか 組織を作るか • 既存の組織、ルール、人の考え方、文化を変えるのは大変 • 新たに組織を作る方が簡単(な場合もある) • 出島的な部署 • 別会社 • オフィスも別にする • ゼロベースで新しいやり方に取り組めるような環境 • フルタイム • 十分な権限 • 報告させない、マイクロマネジメントしない、我慢して任せる
175. 組織を変えるか 組織を作るか • いまある組織を変えたい • 小さく始めて育てる • 1つのプラクティスを小規模に始める • チーム単位(3～10名程度) • 1人では続かない • 周囲が邪魔しないよう守り育てる • あなたも邪魔しないように • 成果が上がってから少しずつ広げる • 『Fearless Change』を参考に
176. メンローイノベーションズに学ぶ • 社長が最強のビジョンを持つ • XPとデザイン思考(IDEO)をベースとする • やるべきことを決め、できる人を集め、徹底的にやる • そこから新たな工夫、実験、失敗からの学びを繰り返す • 何年もかけて上手になっていく • 情熱 • 権限 • 時間
177. ユーザー価値に集中する • プロダクトの価値とエンドユーザーが得る価値を整える • 自分たちの行動、ルール、プロセスを再検討する • ユーザー価値の観点から • 「その仕事はユーザーにどう役立つの？」 • ユーザーを理解する • 観察(ハイテク人類学) • 直接会って話を聞く • ペルソナ
178. フィードバック • エンドユーザーの反応、要望、ニーズを最優先する • それ以外は調整すべき利害関係者(ステークホルダー) • エンドユーザーからチームが直接情報を得る • 行動分析 • インタビュー • ベータテスター • 情報を持ったチーム自身が決断し行動する • 自身が判断し、行動し、結果を見て、改善する • 上司・マネージャ・他部門・アナリストなどのせいにしない
179. 開発技術の更改 • アジャイル20年の歴史は開発技術の進歩と表裏一体 • アジャイルなソフトウェア開発に最低限必須な技術を導入する • イテレーション単位で開発ができるスキルとテクノロジーを修得する
180. すでに常識の開発定番技法 • バージョン管理システム • ビルド自動化 • コードの共同所有 • テストの自動化 • 継続的インテグレーション(CI) • 開発環境の標準化 • コンテナ • DevOps
181. すでに常識の開発定番技法 • バージョン管理システム – 1982年(昭和57年) RCS • ビルド自動化 – 1976年(昭和51年) Make • コードの共同所有 – 1960年代(昭和40年頃) 『プログラミングの心理学』のエピソード • テストの自動化 – 1989年(平成元年) SUnit • 継続的インテグレーション(CI) – 1997年(平成9年) XP • 開発環境の標準化 – 2010年(平成22年) Vagrant • コンテナ – 2000年(平成12年) FreeBSD Jail • DevOps – 2009年(平成21年)
182. (ちょっとだけ)新しめの当たり前の技術たち • 分散バージョン管理システム – 2005年 Git • ビルド自動化システム – 2011年 Jenkins • コードの共同所有 – 2008年 GitHub • E2Eテストの自動化 – 2004年 Selenium • 継続的デリバリー(CD) – 2010年 書籍”Continuous Delivery” • 開発環境の標準化 – 2010年 Vagrant • コンテナ – 2013年 Docker • DevOps – 2009年
183. 変更可能な設計 • イテレーション単位で機能を完成する • ほぼすべての開発は改修・変更 • 包括的な設計・アーキテクチャ → 変更容易な設計・アーキテクチャ • 要素技術 • オブジェクト指向設計 • ドメインドリブンデザイン(DDD) • クリーンアーキテクチャ • マイクロサービス(MSA)
184. テスト自動化 • 常に変更するコードの品質を担保し続ける • 手動テストでは早期に破綻する • ソフトウェアの正しさを動作で検証する • レビューなどの手法も併用すべき • 自動化すべき領域を識別する 詳しくはこちらも（宣伝) 講演動画もあります https://youtu.be/vrbMKbdV6xY https://speakerdeck.com/yattom/tesutofalsezi-dong-hua-totesutoqu-dong-kai-fa
185. 継続的デリバリー • 開発作業から本番リリースまでの過程を自動化し、継続実行する • 属人性(人の作業や確認)を減らす • 手順書 → 自動化する • チェックシート → 自動化する • レビュー → 機械的チェックや正しさの確認は自動化する • テスト → 手順で進めるテストは自動化する • リリース作業 → ワンタッチで完結するよう自動化する • 人間性を生かす作業に時間を使う • 議論する • もっとよいアイデア、設計、手法を見つける • 不要な機能、手順、プロセスを削減する • 思いもよらない問題、バグを探索する https://www.amazon.co.jp/dp/B074BQQ96X
186. 技術やツールの権限を与える • チーム自身が、ユーザー価値に最適な技術やツールを選定する • 会社ルール、取引先都合、新しもの好きの誰かなどに振り回されない • 新しい技術やツールに工数を確保する • 調査、学習、実験する時間 • 既存コードを適合させる時間 • うまくいかなかったとき切り戻す時間 • チームの挑戦と成長に価値をおく • 長い目でユーザー価値につながる
187. いきいきと働く • ユーザー価値に集中する • 大局的プロダクト価値を目標とする • ツール、プロセス、プラクティスに挑戦し、習熟する • 個々人が自律的に能動的に働く • チームとして個人の能力の総和以上の結果を出す • 他からの介入は最低限 • 仕事に「Joy」があふれる
189. individuals and interactions
190. 2001年ごろアジャイルと出会い、開発者、チームリー ダー、トレーナー、導入支援と多様な立場で関わってき た。(株)永和システムマネジメントにて2010年頃からア ジャイルコーチを主軸として活動。2014年独立。 プログラマー Python JavaScript Java C/C++ アジャイルコーチ (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム tsutomu.yasui@gmail.com twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ やっとむ / 安井力(やすいつとむ) アジャイルコーチに手伝ってもらう
191. 質問への回答 • Mentimeterのほうに書き込んでください
192. おすすめ書籍など • 『アジャイル開発とスクラム 第2版』平鍋健児 野中郁次郎 及部 敬雄 https://is.gd/qOh1f5 • アジャイル開発やスクラムの概要や全体像、 企業から見てどういうメリットがあるのか • 『アジャイルサムライ』Jonathan Rasmusson https://is.gd/K9zZf4 • アジャイル開発を実際に始める方法 • 『スクラムブートキャンプTHE BOOK』西村、永瀬、吉羽 https://is.gd/zmKM7q • スクラムの実際のやりかたについて気軽に学べる • 『アジャイルな見積りと計画づくり』Mike Cohn https://is.gd/lBZ6aN • 価値を生み出す計画をアジャイルに作り、進める方法 • 『レガシーコードからの脱却』 David Scott Bernstein https://is.gd/6vAgjt • 技術的側面からアジャイルに必須の技法を解説
193. アンケート: なにをやりたくなりましたか？ • 以上の話を踏まえて、いまやりたいこと、やってみたくなったことを自 由に書いてください。複数回答できます(送信したあと追加で回答で きます) • 時間が余ったら好きな音楽や動画、テレビや映画について書いてくだ さい • 録画視聴の方も、手元に書き出してみてください