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

ScrumTraining2020

Cybozu
PRO
August 19, 2020

 ScrumTraining2020

Cybozu
PRO

August 19, 2020
Tweet

More Decks by Cybozu

Other Decks in Technology

Transcript

  1. Scrum Training 2020

    View Slide

  2. グループ決め
    Breakout room割り当て

    View Slide

  3. About me
    • Yusuke Amano @ama_ch
    • kintone Dev -> ScrumMaster

    View Slide

  4. About me
    • Toshiyuki Otomo @toshiotm
    • 週2日サイボウズ勤務

    View Slide

  5. Agile Coach Team

    View Slide

  6. 本日のゴール
    • スクラムで定義されている役割・イベント・
    成果物を理解する
    • なぜ、スクラムで開発するのかを理解する

    View Slide

  7. タイムテーブル
    • 13:00-14:00 説明
    • 14:15-14:45 各チーム議論
    • 15:00-15:30 エクササイズ
    • 15:45-16:00 Q&A
    適宜休憩とQ&Aを挟みます

    View Slide

  8. なぜスクラム?

    View Slide

  9. ソフトウェア開発は不確実性が
    高い
    • コストと納期の見積もりは難しい
    • 顧客自身も何がほしいのかわからない
    • マーケットを先読みすることはできない
    • 作る前に大きな意思決定をすることはリスク
    が大きい(情報はあとから追加される)

    View Slide

  10. Cynefin Framework
    https://en.wikipedia.org/wiki/Cynefin_framework
    ΫωϏϯϑϨʔϜϫʔΫ
    https://www.slideshare.net/kiroh/ss-14929935

    View Slide

  11. スクラムの概要

    View Slide

  12. スクラムについて
    • スクラムは、複雑なプロダクトを開発・提供・保守するため
    のフレームワークである。
    • 3つの役割、5つのイベント、3つの成果物
    • スクラムの特徴:
    • 軽量
    • 理解が容易
    • 習得は困難

    View Slide

  13. プロジェクトマネージメントト
    ライアングル
    https://en.wikipedia.org/wiki/Project_management_triangle

    View Slide

  14. View Slide

  15. ϓϩμΫτΦʔφʔ
    ։ൃνʔϜ
    εΫϥϜϚελʔ
    ϓϩμΫτ
    όοΫϩά
    εϓϦϯτ
    όοΫϩά
    ੡඼૿෼
    σΠϦʔεΫϥϜ
    ;Γ͔͑Γ
    εϓϦϯτ
    ϓϥϯχϯά
    εϓϦϯτ
    ϨϏϡʔ
    εϓϦϯτ

    View Slide

  16. スクラムの価値基準

    View Slide

  17. スクラムの3本柱
    • 透明性
    • 検査
    • 適応
    経験的プロセス制御の実現は、透明性・検査・適応の3本柱に
    支えられている。

    View Slide

  18. 5つ価値基準
    • 確約(Commitment)
    • 勇気(Courage)
    • 集中(Focus)
    • 公開(Openness)
    • 尊敬(Respect)
    これらを実践するとき、スクラムの柱(透明性・検査・適
    応)は現実のものとなり、あらゆる人に対する信頼が築かれ
    る。

    View Slide

  19. ス ク ラ ム を 活 用 す る に は 、 こ れ ら の 5 つ の 価 値 基
    準 を 上 手 に 実 践 し な け れ ば い け な い 。 個 人 は 、 ス
    ク ラ ム チ ー ム の ゴ ー ル の 達 成 を 確 約 し な け れ ば い
    け な い 。 ス ク ラ ム チ ー ム の メ ン バ ー は 、 正 し い こ
    と を す る 勇 気 を 持 ち 、 困 難 な 問 題 に 取 り 組 ま な
    け れ ば い け な い 。 全 員 が 、 ス プ リ ン ト の 作 業 と ス
    ク ラ ム チ ー ム の ゴ ー ル に 集 中 し な け れ ば い け な
    い 。 ス ク ラ ム チ ー ム と ス テ ー ク ホ ル ダ ー は 、 す べ
    て の 仕 事 と そ れ ら を 遂 行 す る 上 で の 課 題 を 公 開
    す る こ と に 合 意 し な け れ ば い け な い 。 ス ク ラ ム
    チ ー ム の メ ン バ ー は 、 お 互 い を 能 力 の あ る 独 立
    し た 個 人 と し て 尊 敬 し な け れ ば い け な い 。
    スクラムの価値基準

    View Slide

  20. 5つの価値基準
    https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
    • スクラムの理論(p.4)、スクラムの価値基準の
    項目(p.5)を読んでください
    • スクラムチーム内に5つの価値基準がないとき、
    何が起こりますか?
    • 各チームで議論してください

    View Slide

  21. 役割・イベント・成果物

    View Slide

  22. プロダクトオーナー

    View Slide

  23. 役割1: プロダクトオーナー
    • 開発チームから生み出されるプロダクトの価値の最大化に責任を持つ
    • プロダクトバックログの管理に責任を持つ 1 人の人間である
    • プロダクトバ ックログの管理には、以下のようなものがある:
    • プロダクトバックログアイテムを明確に表現する
    • ゴールとミッションを達成できるようにプロダクトバックログアイテムを並
    び替える
    • 開発チームが行う作業の価値を最適化する
    • プロダクトバックログを全員に見える化・透明化・明確化し、スクラムチー
    ムが次に行う作業を示す
    • 必要とされるレベルでプロダクトバックログアイテムを開発チームに理解し
    てもらう

    View Slide

  24. プロダクトオーナー
    • プロダクトオーナーの項目(p.5)を読んでくだ
    さい
    • POがプロダクトバックログマネジメントをし
    ないと何が起こりますか?
    • 各チームで議論してください
    https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

    View Slide

  25. 開発チーム

    View Slide

  26. 役割2: 開発チーム
    • 各スプリントの終了時にリリース判断可能な「完成」したプロダクトインクリメントを届け
    ることのできる専門家で構成されている
    • 自分たちの作業を構成・管理するために、組織から体制と権限を与えられている
    • その相乗効果によって、開発チーム全体の効率と効果が最適化される
    • 開発チームには、以下のような特徴がある:
    • 自己組織化されている。プロダクトバックログをリリース判断可能な機能のインクリメ
    ントに変える方法は、誰も(スクラムマスターでさえも)教えてくれない。
    • 機能横断的である。インクリメントを作成するスキルをチームとしてすべて備えている。
    • ある人にしかできない作業があったとしても、スクラムにおける開発チームのメンバー
    に肩書きはない。
    • テスティング、アーキテクチャ、運用、ビジネス分析のような専門領域であっても、ス
    クラムは開発チームのサブチームを認めていない。
    • 開発チームのメンバーに専門能力や専門分野があったとしても、最終的な責任は開発
    チーム全体が持つ。

    View Slide

  27. 開発チーム
    • 開発チームの項目(p.6)を読んでください
    • 自己組織化されていない開発チームはどうな
    りますか?
    • 職能横断的でない開発チームはどうなります
    か?
    • 各チームで議論してください
    https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

    View Slide

  28. スクラムマスター

    View Slide

  29. 役割3: スクラムマスター
    • スクラムガイドで定義されたスクラムの促進と支援に責任を
    持つ
    • スクラムの理論・プラクティス・ルール・価値基準を全員に
    理解してもらえるように支援することで、その責任を果たす
    • スクラムチームのサーバントリーダーである
    • さまざまな形でプロダクトオーナーを支援する
    • さまざまな形で開発チームを支援する
    • さまざまな形で組織を支援する

    View Slide

  30. 参考動画:
    https://youtu.be/NcWDx-XXISY

    View Slide

  31. 成果物1: プロダクトバックログ
    • プロダクトに必要だと把握しているも
    のをすべて順番に並べた一覧
    • 価値が高いものから順番に並べる
    • プロダクトバックログは決して完成し
    ない(リファインメントを通じて絶え
    ず手入れする)
    • 並び順が上のアイテムほど明確で詳細
    ϑΟʔνϟʔ"
    ϑΟʔνϟʔ#
    ϑΟʔνϟʔ$
    όά
    ϦϑΝΫλ9
    ϑΟʔνϟʔ%
    όά
    ϦϑΝΫλ:
    ʜ
    ʜ

    View Slide

  32. プロダクトバックログリファイ
    ンメント
    • プロダクトバックログアイテムに対して、詳細の追加、見
    積り、並び替えをする活動
    • いつどのようにリファインメントをするかは、スクラム
    チームが決定する
    • 開発チームは見積りに対して責任を持つ
    • プロダクトオーナーがトレードオフの理解や選択などにつ
    いて開発チームに影響を及ぼすこともあるが、最終的な見
    積りは実際に作業をする人が行う

    View Slide

  33. プロダクトバックログ
    https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
    • プロダクトバックログの項目(p.12)を読んでく
    ださい
    • プロダクトバックログを作るのは何のためで
    すか?ないとどうなりますか?
    • 各チームで議論してください

    View Slide

  34. イベント1: スプリント
    • スクラムの中心はスプリント
    • 「完成」した、利用可能な、リリース判断可
    能なプロダクトインクリメントを作るための、
    1 か月以下のタイムボックス
    • スプリントの長さは常に一定

    View Slide

  35. イベント2: スプリントプランニング
    • スプリントの作業はスプリントプランニングで計画する
    • プランニングはスクラムチーム全体の共同作業
    • トピック1: スプリントで何ができるか?
    • PBL + インクリメント + キャパシティ + ベロシティ -> 選択したPBI
    • トピック2: 選択した作業をどのように成し遂げるか?
    • 選択したPBI -> スプリントバックログ
    • 通常はシステムの設計から始める

    View Slide

  36. 成果物2: スプリントバックログ
    ϑΟʔνϟʔ" λεΫ λεΫ λεΫ λεΫ
    λεΫ λεΫ λεΫ λεΫ
    • 開発チームがスプリントで行う作業がリアルタイムに
    反映される
    • 新しい作業が必要になれば、開発チームがスプリント
    バックログに作業を追加する
    • 計画の要素が不要になれば削除する
    • スプリントバックログアイテムのサイズは1日未満を
    推奨
    • 前回のレトロスペクティブで特定した優先順位の高い
    プロセスの改善策を少なくとも1つは含める

    View Slide

  37. スプリントバックログ
    https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
    • スプリントバックログの項目(p.13)を読んでく
    ださい
    • スプリントバックログを作らずに実装を開始
    すると何が起きますか?
    • 各チームで議論してください

    View Slide

  38. イベント3: デイリースクラム
    • 前回のデイリースクラムから行なった作業の検査と今後のスプリント作業の予想をする
    ことで、チームのコラボレーションやパフォーマンスを最適化する
    • デイリースクラムは、開発チームがスプリントゴールを達成する可能性を最適化する
    • たとえ ば、以下のような例を使用する:
    • 開発チームがスプリントゴールを達成するために、私が昨日やったことは何か?
    • 開発チームがスプリントゴールを達成するために、私が今日やることは何か?
    • 私や開発チームがスプリントゴールを達成する上で、障害となる物を目撃したか?
    開発チームやチームメンバーは、デイリースクラムの終了直後に集まり、スプリントの残
    作業につい て、詳細な議論・適応・再計画を行うこともある。

    View Slide

  39. デイリースクラム
    • デイリースクラムの項目(p.10)を読んでくださ

    • デイリースクラムをしないと何が起きます
    か?
    • 各チームで議論してください
    https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

    View Slide

  40. 成果物3: インクリメント
    • これまでのインクリメントの価値と今回のスプリント
    で完成したプロダクトバックログアイテムを合わせた
    もの
    • スプリントの終了時には、新しいインクリメントが
    「完成」していなければいけない。つまり、インクリ
    メントが動作する状態であり、スクラムチームの「完
    成」の定義に合っていることを意味する。
    • プロダクトオーナーがリリースを決定する/しないに
    かかわらず、インクリメントは常に動作する状態にし
    ておかなければいけない

    View Slide

  41. インクリメント
    https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
    • インクリメントの項目(p.14)を読んでください
    • スプリント終了時に「完成」したインクリメ
    ントを用意するのは何のためですか?インク
    リメントが未完成だとどうなりますか?
    • 各チームで議論してください

    View Slide

  42. イベント4: スプリントレビュー
    • スプリントの終了時にインクリメントの検査と、必要であれば
    プロダクトバックログの適応を行う
    • スクラムチームとステークホルダーがスプリントの成果をレ
    ビューする。スプリントの成果とプロダクトバックログの変更
    を参考にして、価値を最適化するために次に何ができるかを参
    加者全員で話し合う。
    • 次にリリースするプロダクトの機能や性能のスケジュール・予
    算・可能性・市場をレビューする
    • 新たな機会に見合うように、プロダクトバックログを全体的に
    調整することもある

    View Slide

  43. スプリントレビュー
    • スプリントレビューの項目(p.11)を読んでくだ
    さい
    • スプリントレビューを開催するのは何のため
    ですか?なくなるとどうなりますか?
    • チーム内で議論してください
    https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

    View Slide

  44. イベント5: スプリントレトロス
    ペクティブ
    • スクラムチームの検査と次のスプリントの改善計画を作成する機会
    • スプリントレトロスペクティブには、以下の目的がある:
    • 人・関係・プロセス・ツールの観点から今回のスプリントを検査する
    • うまくいった項目や今後の改善が必要な項目を特定・整理する
    • スクラムチームの作業の改善実施計画を作成する
    • スクラムマスターは、次のスプリントが効果的で楽しいものになるように、ス
    クラムチームにスクラムプロセスフレームワークの範囲内で開発プロセスやプ
    ラクティスを改善してもらう

    View Slide

  45. スプリントレトロスペクティブ
    https://scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf
    • スプリントレトロスペクティブの項目(p.12)を
    読んでください
    • スプリントレトロスペクティブをするのは何
    のためですか?なくなるとどうなりますか?
    • 各チームで議論してください

    View Slide

  46. その他補足

    View Slide

  47. 学習リソース
    https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-Japanese.pdf

    View Slide

  48. 各現場の実装と大規模スクラム
    • それぞれの現場はフレームワークをもとに現
    場の事情にあわせた実装をしています
    • スクラムのフレームワークと完全に一致しな
    い部分もあります
    • 特にkintone,Garoonは大規模スクラム(LeSS)
    の仕組みが入っています

    View Slide

  49. エクササイズ

    View Slide

  50. こんなときどうする? #1
    • スプリント中にPOに質問したいことが出てきまし
    た。どうしますか?
    • PBIを開発中に、PBIとは関係ない箇所で不具合を
    見つけた。どうしますか?
    • リリース後の不具合が多発しています。チームと
    して何をすることができますか?
    • レトロスペクティブで出た改善アクションは、い
    つ・どこで・誰が実施しますか?

    View Slide

  51. こんなときどうする? #2
    • スプリントプランニングで計画していた実装方法
    が、スプリント中にうまくいかないことがわかり
    ました。どうしますか?
    • チームがコミットメントした3つのPBIのうち2つ
    終わった時に、3つ目に着手してもスプリント内
    で終わりそうにないことがわかりました。チーム
    としてどうしますか?
    • チームがコミットメントしたPBIがスプリント中
    にすべて終わりました。チームとしてどうします
    か?

    View Slide

  52. Reflection
    Q&A

    View Slide