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

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

yattom
June 24, 2021

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

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

yattom

June 24, 2021
Tweet

More Decks by yattom

Other Decks in Technology

Transcript

  1. Agile and Scrum – values, principles, practices アジャイルとスクラムとは ~価値、原則、プラクティス~ やっとむ

    こと 安井 力 アジャイルコーチ 合同会社やっとむ屋 代表 Copyright© 2021 by 安井力、合同会社やっとむ屋 [email protected] スライド公開URL https://is.gd/BMNP2P
  2. 2001年ごろアジャイルと出会い、開発者、チームリーダー、トレー ナー、導入支援と多様な立場で関わってきた。(株)永和システム マネジメントにて2010年頃からアジャイルコーチを主軸として 活動。2014年独立。 プログラマー Python JavaScript Java C/C++ アジャイルコーチ

    (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム 著書・訳書 [email protected] twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ やっとむ / 安井力(やすいつとむ)
  3. 2021年のアップデート • 2020年はファイナンスの危機 • 収益60%ダウン • 一時的な給与カット • 手元資金とPPPローンで乗り切った •

    全員リモートワーク • 「リモートで上手くやれる方法を探究するのが楽しみだ!」 • リモートペアプロ • リモートでハイテク人類学 • 紙やホワイトボードの仕組みをデジタル化 • オフィスツアーはバーチャルツアー • 採用インタビューもバーチャルで実施(2021年2月) https://menloinnovations.com/stories/culture/culture-storytelling-joy
  4. どこが変わってるの? • 家族旅行をする • 全社員リモートワーク • オフィスをなくした • 顧客には顧問プログラマが1人で専任する •

    企画から設計、コーディング、運用まですべて • マネージャがいない • 業務ハッカー募集中 • 納品しない受託開発 • プログラマを一生の仕事に
  5. 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
  6. 1999 1995 2003 2001 参考: 1991 - Linux 1996 -

    Java 1.0 2001 – Windows XP 2002 - .NET Framework 1.0 1986 1994 (GoF)
  7. アジャイルな開発の特徴 • ビジョンや目標を共有し、全体がそこに向かっている • ルール、プロセス、手法が常に変わり続けている • アウトカム(結果)を重視している • 「そこにいる人びと」ならでは、になっている •

    顧客やステークホルダーの信頼を得ている • 市場競争力を維持している • 自主性があり、いきいきして、学び続けている こうした観点からKPI・KGIを選ぶ
  8. アジャイルな人や組織の特徴 • ビジョンや目標を共有し、全体がそこに向かっている • ルール、プロセス、手法が常に変わり続けている • アウトカム(結果)を重視している • 「そこにいる人びと」ならでは、になっている •

    顧客やステークホルダーの信頼を得ている • 市場競争力を維持している • 自主性があり、いきいきして、学び続けている こうした観点からKPI・KGIを選ぶ
  9. アジャイルの指標例 • 実験の頻度、健全な割合で失敗しているか • ビジョンの認知と腹落ち度 • 顧客やユーザーからのNPS(ネットプロモータースコア) • 価値提供の頻度 •

    メンバーの成長と流動性 • ソフトウェア開発の場合 • リリースと測定の頻度 • CI、CDの頻度と所要時間 • テストの自動化カバレッジ ※コードカバレッジではなく、テストの自動化カバレッジ • ソースコードの変更頻度(既存コードをちゃんと直しているか)
  10. アジャイルは形容詞 agi・le [形] 素早い、敏捷、しなやかな • Be Agile, not Do Agile

    • アジャイル「を」やる ⇒ できない! • アジャイル「を」使う ⇒ 誤り • アジャイル「に」開発する • アジャイル「な」態度 • 「もっと」アジャイル
  11. 形容詞「アジャい」 • アジャい開発 • 「うちのチーム、結構アジャいんですよ」 • 我が社でもアジャイルを導入する → 我が社もアジャいくなる •

    「アジャイルをやるのに必須のツールです」 → 「今よりアジャいくなるのに、お勧めツールです」 ※誰も言ってません。流行ったらいいな
  12. 開発 運用 ビジネス 経営 人事 ビジョン プロダクトの 価値 プロダクトの 価値

    長期 世界・世間 組織文化 変化 能力を発揮 するチャンス 能力を発揮 するチャンス 差をつける チャンス 常に・あたり まえ スキルアッ プ・チェンジ アウトカム ユーザーに とっての価値 ユーザーに とっての価値 新たな展開 コアバリュー の不変 現場の声 信頼と実績 フィードバッ クを生かす フィードバッ クを生かす 三方良し 現場を信頼 採用より成 長重視 いきいき 個々の強み、チームの力、モチベーション、誇り
  13. マインドセットの違い ガチガチマインドセット • 能力 – 不変、背の高さなど • ゴール – 良く見られる

    • 挑戦 – 避ける • 失敗 - 個人的な問題 • 努力 - 能力がない人がやる • 困難に直面すると – 無力 アジャイルマインドセット • 能力 – 成長、筋肉など • ゴール – 学ぶ • 挑戦 – 受け入れる • 失敗 – 情報を得られる • 努力 – 熟達への道 • 困難に直面すると – 回復力(レジリエント)
  14. 価値、原則、プラクティス • メンローイノベーションズ • 価値 = 喜び • 原則 =

    個人を生かす、学び合う、仕事を楽しむ • プラクティス = ペアプログラミング • ソニックガーデン • 価値 = 個人を尊重、試行錯誤 • 原則 = 一生プログラマ、納品しない、やってみる • プラクティス = リモートワーク、顧問プログラマ、定額契約、師弟制度 • 数えると、おおむね 価値 < 原則 < プラクティス
  15. 価値 コスト 時間 圧 縮 技 術 的 負 債

    利 子 コスト 時間 圧 縮 技 術 的 負 債 技術的 負債
  16. 技術的負債 • 不適切なエンジニアリングで発生する • 能力不足 • 圧力、プレッシャー • 考慮不足 •

    将来は本質的に予測できない • 「考慮不足」は不可避 • 「キレイ」な状態を… 最初にちゃんとする → 不可能 or どこかで破綻する 維持する → 常時リファクタリングを続ける • 負債をためすぎないうちに返済する • 将来予測 → 変更容易
  17. 変更容易性 • 設計がシンプル • 変更箇所と内容が自明 • 依存関係が少ない • 特に隠れた依存関係 •

    実装もシンプル • 誰でも安心して変更できる • 自動化したテスト • リグレッション • 常にこの状態を維持する • 厳しい規律 • だんだん難しくなる
  18. 「チームの心理的安全とは、対人のリスクを取っても 安全であるという、チーム全員の信念である」 “Psychological Safety and Learning Behavior in Work Teams”

    Amy Edmondson, 1999 Amy C. Edmondson https://twitter.com/amycedmondson 心理的安全 (Psychological Safety) 「「心理的安全」とは、関連のある考 えや感情について人びとが気兼ね なく発言できる雰囲気をさす。」
  19. 学習する組織 • システム思考 – 全体を考える • メンタルモデルへ意識を向け見直す • 共有ビジョン ―

    「自分たちはなにを創造したいのか?」 • チーム学習とアラインメント(合致) • 経営者を含むマネジメント全体の意識変革 『学習する組織』ピーター・M・センゲ
  20. 価値とは…… • 製品のユーザーが何を 望んでいるか知りたい • ワクチンの効率的配送 サービスを実現する • 会社の資金が底をつきそう •

    製品が遅い • 開発スピードが遅い • 猫の画像でにっこりさせたい → 情報 → 人命 → 会社存続 → 実行速度 → 開発速度 → しあわせ
  21. プラクティス •Practice = 練習 実践 • HOW •なぜやるのか、なんのためにやるのか • ノウハウではない

    • 必須でもない 必要性から要請される •実験の対象 • うまくいくかどうか やってみて改善 • 実際のやり方はみな違う
  22. 超基本プラクティス • 朝会 / デイリースタンドアップ / デイリースクラム • 短期間サイクル /

    イテレーション / スプリント • タスクボード / スプリントバックログ • ふりかえり / レトロスペクティブ
  23. 朝会 / デイリースタンドアップ • チーム全員 • 毎日、同じ場所、同じ時間で • 状況と問題を共有する •

    立ったまま、15分以内 • 現状を踏まえて計画を見直す https://www.slideshare.net/yattom/project-facilitation-from-hiranabe
  24. イテレーション • 1~4週間程度をサイクルとして、仕事を完成する • 仕事を完成する • 1機能の要件定義、設計、実装、テストまで • できるように仕事を小さく分割する •

    イテレーション冒頭で計画づくりをし、終わりでふりかえりをする • イテレーションの成果から毎回フィードバックを得る
  25. 朝会、ふりかえりを学ぶ • プロジェクトファシリテーション 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
  26. XP(Extreme Programming)の プラクティス 主要プラクティス • 全員同席 • チーム全体 • 情報満載のワークスペース

    • いきいきとした仕事 • ペアプログラミング • ストーリー • 週次サイクル • 四半期サイクル • ゆとり • 10分ビルド • 継続的インテグレーション • テストファーストプログラミング • インクリメンタルな設計 導出プラクティス • 本物の顧客参加 • インクリメンタルなデプロイ • チームの継続 • チームの縮小 • 根本原因分析 • コードの共有 • コードとテスト • 単一のコードベース • デイリーデプロイ • 交渉によるスコープ契約 • 利用都度課金
  27. 守破離 • 能、茶道、剣道などの教え • 守 • 師匠につき、言われたとおりのことが完璧にできるよう修練する • 基礎を身につける •

    破 • 自分なりの試行錯誤をしたり、他流のやり方を取り込んだりする • 精神、メカニズム、理論を身につける • 離 • 自分自身が独立し、流派を作る、自らが師匠になる • 新たな価値を生み出す
  28. • 期待したようにも、予定通りにも進まない • 予想外の出来事や結果は、自分たちについての新たな発見 • 試行錯誤しながら自分たちについて理解を深めていく • 計画通りに進まないことを計画する • 全員で計画づくりをする

    • 計画変更を計画に含める • 計画変更につながる情報収集を計画する • 計画変更の工数が小さくなるよう、計画の詳細度をコントロールする • 計画変更の量や回数を指標とする(少なかったら問題) プラクティスの難しさ: 計画通りには進まない
  29. アジャイルな見積りと計画づくり • アジャイルで計画はたいへん重要 • 必要なだけ計画する • 変化を前提として計画する • 出来上がった計画 よりも

    計画づくり を重視する • プランニング・オニオン EMZERO Vol.3.1(マナスリンク)より引用 http://www.manaslink.com/articles/75 参考: 「アジャイルな見積りと計画づくり」 マイク・コーン著 角谷信太郎、安井力訳 https://www.amazon.co.jp/dp/4839924023
  30. 新しいことに取り組むのは常に難しい • 信念と情熱のある人が必要 (1 エバンジェリスト) • 小さく試して小さく成功させる (2 小さな成功) •

    大きな理想を一歩ずつ実現する (3 ステップバイステップ) • 自分の不足を認めて助けを請う (6 協力を求める) • 先見性のある人を集める (11 アーリーアダプター) • とにかく試してみる (17 やってみる) • 権限ある人に認められる (28 経営層の支持者) • やるといいことがあるという気配で人を引き寄せる (40 成功のにおい) https://www.amazon.co.jp/dp/462108786X
  31. On Pioneers, Settlers, Town Planners and Theft. by Simon Wardley

    http://blog.gardeviance.org/2015/03/on-pioneers-settlers-town-planners-and.html
  32. よくある障害 • 上司が理解してくれない • 部下、現場が理解してくれない • 他部門、顧客が理解してくれない • 契約やコンプライアンスの壁がある •

    開発スキルが足りない • 既存のコード、システム、サービスがある • 時間がない • 予算がない • 人材が足りない
  33. よくある障害 • 上司が理解してくれない • 部下、現場が理解してくれない • 他部門、顧客が理解してくれない • 契約やコンプライアンスの壁がある •

    開発スキルが足りない • 既存のコード、システム、サービスがある • 時間がない • 予算がない • 人材が足りない よくある! 対処し乗り越える対象 障害を発見する のがスクラム
  34. マインドセットの違い ガチガチマインドセット • 能力 – 不変、背の高さと同じ • ゴール – 人から良く見られる

    • 挑戦 – 避ける • 失敗 - 個人的な問題 • 努力 - 能力がない人がやる • 困難に直面すると – 無力 アジャイルマインドセット • 能力 – 成長、筋肉などと同じ • ゴール – 学ぶ • 挑戦 – 受け入れる • 失敗 – 情報を得られる • 努力 – 熟達への道 • 困難に直面すると – 回復力(レジリエント)
  35. アジャイルマインドセット • 実験: 「ガチガチ」と「アジャイル」マインドの2グループ • 簡単な試験を受けてもらう • 次の試験を選ばせる • ガチガチ

    → 簡単なものを選ぶ • アジャイル → 難しいものを選ぶ • 他の人にアドバイス • ガチガチ → アドバイスしない、嘘をつく • アジャイル → アドバイスする • 2つのグループの違いは? • ランダムに分けただけ • ガチガチ → 結果をほめられた • アジャイル → 努力をほめられた https://www.slideshare.net/agiledays/linda-rising-the-power-of-an-agile-mindset
  36. アジャイルマインドセット • 実験: 「ガチガチ」と「アジャイル」マインドの2グループ • 簡単な試験を受けてもらう • 次の試験を選ばせる • ガチガチ

    → 簡単なものを選ぶ • アジャイル → 難しいものを選ぶ • 他の人にアドバイス • ガチガチ → アドバイスしない、嘘をつく • アジャイル → アドバイスする • 2つのグループの違いは? • ランダムに分けただけ • ガチガチ → 結果をほめられた • アジャイル → 努力をほめられた https://www.slideshare.net/agiledays/linda-rising-the-power-of-an-agile-mindset
  37. 障害を乗り越えるアジャイルマインド • 結果を出すのが大事 → 努力するのが大事 • 「頑張ります!」では大雑把 → プロセスや経過、判断や行動を細かく識別、把握する •

    小さな失敗をたくさん見つけて情報を得る • 個人の責任、自分の作業を完遂する → チームの責任、全体で価値を完成する • 人は人、仕方ない → 人はつながり、変化する
  38. Unlearn / 脱学習 / まなびほぐし • アジャイルに限らず、今までのやり方を変えるときに必要 • 今までのやり方=今までに学んだことを、いったん脱ぎ捨てる •

    うまくいくかわからなくても、やってみる • うまくいかないとわかっていても、やってみる • 過程を精緻に分析し、知見を得る • 結果はあまり気にしない • 結果の良し悪しより、予想とのズレに注目する • 新たな学びに向け、今までの知識を壁にしない
  39. 超基本プラクティス • 朝会 / デイリースタンドアップ / デイリースクラム • 短期間サイクル /

    イテレーション / スプリント • タスクボード / スプリントバックログ • ふりかえり / レトロスペクティブ • 「プラクティスは難しい」を忘れずに
  40. チームに任せる • 環境を与える • 場所、空間、オフィス • 機材、インフラ • 支援を与える •

    他からの介入を防ぐ • 問題・課題を解消する • 信頼する • 放っておく!
  41. 組織を変えるか 組織を作るか • 既存の組織、ルール、人の考え方、文化を変えるのは大変 • 新たに組織を作る方が簡単(な場合もある) • 出島的な部署 • 別会社

    • オフィスも別にする • ゼロベースで新しいやり方に取り組めるような環境 • フルタイム • 十分な権限 • 報告させない、マイクロマネジメントしない、我慢して任せる
  42. 組織を変えるか 組織を作るか • いまある組織を変えたい • 小さく始めて育てる • 1つのプラクティスを小規模に始める • チーム単位(3~10名程度)

    • 1人では続かない • 周囲が邪魔しないよう守り育てる • あなたも邪魔しないように • 成果が上がってから少しずつ広げる • 『Fearless Change』を参考に
  43. フィードバック • エンドユーザーの反応、要望、ニーズを最優先する • それ以外は調整すべき利害関係者(ステークホルダー) • エンドユーザーからチームが直接情報を得る • 行動分析 •

    インタビュー • ベータテスター • 情報を持ったチーム自身が決断し行動する • 自身が判断し、行動し、結果を見て、改善する • 上司・マネージャ・他部門・アナリストなどのせいにしない
  44. すでに常識の開発定番技法 • バージョン管理システム – 1982年(昭和57年) RCS • ビルド自動化 – 1976年(昭和51年)

    Make • コードの共同所有 – 1960年代(昭和40年頃) 『プログラミングの心理学』のエピソード • テストの自動化 – 1989年(平成元年) SUnit • 継続的インテグレーション(CI) – 1997年(平成9年) XP • 開発環境の標準化 – 2010年(平成22年) Vagrant • コンテナ – 2000年(平成12年) FreeBSD Jail • DevOps – 2009年(平成21年)
  45. (ちょっとだけ)新しめの当たり前の技術たち • 分散バージョン管理システム – 2005年 Git • ビルド自動化システム – 2011年

    Jenkins • コードの共同所有 – 2008年 GitHub • E2Eテストの自動化 – 2004年 Selenium • 継続的デリバリー(CD) – 2010年 書籍”Continuous Delivery” • 開発環境の標準化 – 2010年 Vagrant • コンテナ – 2013年 Docker • DevOps – 2009年
  46. 変更可能な設計 • イテレーション単位で機能を完成する • ほぼすべての開発は改修・変更 • 包括的な設計・アーキテクチャ → 変更容易な設計・アーキテクチャ •

    要素技術 • オブジェクト指向設計 • ドメインドリブンデザイン(DDD) • クリーンアーキテクチャ • マイクロサービス(MSA)
  47. テスト自動化 • 常に変更するコードの品質を担保し続ける • 手動テストでは早期に破綻する • ソフトウェアの正しさを動作で検証する • レビューなどの手法も併用すべき •

    自動化すべき領域を識別する 詳しくはこちらも(宣伝) 講演動画もあります https://youtu.be/vrbMKbdV6xY https://speakerdeck.com/yattom/tesutofalsezi-dong-hua-totesutoqu-dong-kai-fa
  48. 継続的デリバリー • 開発作業から本番リリースまでの過程を自動化し、継続実行する • 属人性(人の作業や確認)を減らす • 手順書 → 自動化する •

    チェックシート → 自動化する • レビュー → 機械的チェックや正しさの確認は自動化する • テスト → 手順で進めるテストは自動化する • リリース作業 → ワンタッチで完結するよう自動化する • 人間性を生かす作業に時間を使う • 議論する • もっとよいアイデア、設計、手法を見つける • 不要な機能、手順、プロセスを削減する • 思いもよらない問題、バグを探索する https://www.amazon.co.jp/dp/B074BQQ96X
  49. 2001年ごろアジャイルと出会い、開発者、チームリー ダー、トレーナー、導入支援と多様な立場で関わってき た。(株)永和システムマネジメントにて2010年頃からア ジャイルコーチを主軸として活動。2014年独立。 プログラマー Python JavaScript Java C/C++ アジャイルコーチ

    (プロセス面) チームビルディング 現場導入支援 スクラムマスター支援 ふりかえり アジャイルコーチ (ものづくり面) モブプログラミング テスト駆動開発 テスト自動化 学びのゲームをデザイン、製作、デリバリー 宝探しアジャイルゲーム カンバンゲーム 心理的安全性ゲーム [email protected] twitter:@yattom https://www.facebook.com/yattom https://www.linkedin.com/in/yattom/ やっとむ / 安井力(やすいつとむ) アジャイルコーチに手伝ってもらう
  50. おすすめ書籍など • 『アジャイル開発とスクラム 第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 • 技術的側面からアジャイルに必須の技法を解説