スクラム概論第1.1版 2018年08月02日この作品はクリエイティブコモンズ表示 - 継承 4.0 国際ライセンスの下に提供されていますスクラム概論 2018 TIS INC. クリエイティブコモンズライセンス表示-継承 4.0 国際

Size: px

Start display at page:

Download "スクラム概論第1.1版 2018年08月02日この作品はクリエイティブコモンズ表示 - 継承 4.0 国際ライセンスの下に提供されていますスクラム概論 2018 TIS INC. クリエイティブコモンズライセンス表示-継承 4.0 国際"

しらんさわまつ
4 years ago
Views:

1 スクラム概論第1.1版 2018年08月02日この作品はクリエイティブコモンズ表示 - 継承 4.0 国際ライセンスの下に提供されていますスクラム概論 2018 TIS INC. クリエイティブコモンズライセンス表示-継承 4.0 国際

2 なぜスクラムが求められているのか 2

3 企業を取り巻く環境の変化出せば売れる時代はどれだけ投資してどれだけ作れるかというシンプルな構造だった少々の欠陥があっても売れるので問題なかった予測可能予測困難価格競争付加価値競争何が売れるか分からない不確実なマーケットどれだけ投資してもどれだけのリターンが得られるか分からないビジネスモデルの賞味期限が短くなってきているマーケットの激しい変化に対応していかなければならない 3

4 スクラムの定義複雑で変化の激しい問題に対応するためのフレームワークであり可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである特徴軽量理解が容易習得は困難 19個の役割とルールしかない PMBOK V6には49個のプロセスが存在するスクラムは経験主義実際の経験と既知に基づく判断によって習得していくスクラムのルールについては以下のスクラムガイドに記載されている 4

5 アジャイルスクラムウォーターフォール 5

6 アジャイルとは Agile 形機敏な敏捷な名詞ではなく形容詞状態を表す Don t do agile, be agile アジャイル開発を行うのが目的ではなくアジャイルな状態にすることが重要その核となる考え方や原則がまとめられたものにアジャイルソフトウェア開発宣言とアジャイル宣言の背後にある原則がある 6

7 アジャイルソフトウェア開発宣言 2001年当時軽量ソフトウェア開発手法と呼ばれていた分野において著名な17名が集まりそれぞれが重視していた部分を統合し文書にまとめたもの日本で特に知られているのは以下の6名 Kent Beck (XPの考案者 JUnitの生みの親) Martin Fowler (PoEAAの著者マイクロサービスという言葉の生みの親) Dave Thomas (達人プログラマーなどの著者ボブおじさん) Robert C. Martin (Clean Code, Clean Coderなどの著者) Ken Schwaber (スクラムの生みの親) Jeff Sutherland (スクラムの生みの親) 7

8 アジャイルソフトウェア開発宣言私たちはソフトウェア開発の実践あるいは実践を手助けをする活動を通じてよりよい開発方法を見つけだそうとしているこの活動を通して私たちは以下の価値に至ったプロセスやツールよりも個人と対話を包括的なドキュメントよりも動くソフトウェアを契約交渉よりも顧客との協調を計画に従うことよりも変化への対応を価値とするすなわち左記のことがらに価値があることを認めながらも私たちは右記のことがらにより価値をおく 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 2001, 上記の著者たちこの宣言はこの注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい 8

9 アジャイル宣言の背後にある原則私たちは以下の原則に従う: 顧客満足を最優先し価値のあるソフトウェアを早く継続的に提供します要求の変更はたとえ開発の後期であっても歓迎します変化を味方につけることによってお客様の競争力を引き上げます動くソフトウェアを 2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースしますビジネス側の人と開発者はプロジェクトを通して日々一緒に働かなければなりません意欲に満ちた人々を集めてプロジェクトを構成します環境と支援を与え仕事が無事終わるまで彼らを信頼します情報を伝えるもっとも効率的で効果的な方法はフェイストゥフェイスで話をすることです 9

アジャイル宣言の背後にある原則(続き) 動くソフトウェアこそが進捗の最も重要な尺度ですアジャイルプロセスは持続可能な開発を促進します一定のペースを継続的に維持できるようにしなければなりません技術的卓越性と優れた設計に対する不断の注意が機敏さを高めますシンプルさ

10 アジャイル宣言の背後にある原則(続き) 動くソフトウェアこそが進捗の最も重要な尺度ですアジャイルプロセスは持続可能な開発を促進します一定のペースを継続的に維持できるようにしなければなりません技術的卓越性と優れた設計に対する不断の注意が機敏さを高めますシンプルさムダなく作れる量を最大限にすることが本質です最良のアーキテクチャ要求設計は自己組織的なチームから生み出されますチームがもっと効率を高めることができるかを定期的に振り返りそれに基づいて自分たちのやり方を最適に調整します 10

11 ウォーターフォールの進め方おなじみのV字モデル受け入れテスト要件定義外部設計内部設計システムテスト結合テスト実装単体テスト 11

12 アジャイルとウォーターフォールのプロセスの違いアジャイルウォーターフォール時間要件定義要件定義設計実装テスト設計要件定義設計実装テスト実装要件定義設計実装テストテスト要件定義設計実装テスト 12

13 アジャイルとウォーターフォールのプロセスの違いプロセスウォーターフォールアジャイル成功の測定計画通りに実行出来たか QCDによる測定変化への対応顧客満足競争力向上マネジメント指揮命令型トップダウンサーバントリーダーシップフラット計画範囲固定で工数を見積る期日固定で範囲を見積もる要求と設計最初に要求を洗い出す要求のすべてを設計する継続的に要求を受け入れる必要なタイミングで設計を行う実装全機能を同時に開発優先順位の高い機能から開発テストと品質保証終盤に実施早期から継続的にテストを実施出典: Scaling Software Agility 13

14 アジャイルとスクラムの関係スクラムはアジャイルに包含される他にもXPやLeanの流れを汲むKanbanなどがアジャイルに含まれる Agile Scrum Crystal Lean XP Kanban 14

15 アジャイルの中でのスクラムの採用率ハイブリッドを合わせると 70%がスクラムを採用 VersionOne 12th Annual State of Agile Report 15

16 スクラムとは 16

スクラムの起源スクラム自体は1995年にJeff SutherlandとKen Schwaberによって発表されているがスクラムの原点となっている野中郁次郎竹内弘高の研究論文 The New New Product Development Game は1986年に発表されている論文の中で柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて Scrum

17 スクラムの起源スクラム自体は1995年にJeff SutherlandとKen Schwaberによって発表されているがスクラムの原点となっている野中郁次郎竹内弘高の研究論文 The New New Product Development Game は1986年に発表されている論文の中で柔軟で自由度の高い日本発の開発手法をラグビーのスクラムに喩えて Scrum スクラムとして紹介した実はアジャイルよりスクラムの方が歴史は長い Luke Burgess introduces the ball into the scrum. 17

18 スクラムの定義(再掲) 複雑で変化の激しい問題に対応するためのフレームワークであり可能な限り価値の高いプロダクトを生産的かつ創造的に届けるためのものである特徴軽量理解が容易習得は困難 19個の役割とルールしかない PMBOK V6には49個のプロセスが存在するスクラムは経験主義実際の経験と既知に基づく判断によって習得していくスクラムのルールについては以下のスクラムガイドに記載されている 18

19 スクラムに向かないプロジェクトプロジェクトの状態が単純決まりきったモノを作るチームの生存期間が短い３ヶ月より短いと技術やプロセスに習熟しない要件不明確スクラムが得意とする領域カオス単純固定技術枯れている不確か 19

20 スクラムの理論スクラムは経験的プロセス制御の理論(経験主義)を基本にしている判断し行動したことが経験になる実際の経験判断行動反復的かつ漸進的な手法で予測可能性の最適化とリスクの管理を行う知識判断し行動した結果新たな知識を獲得する 20

21 スクラムを支える3本柱経験的プロセス制御の実現は以下の3つによって支えられている透明性 (Transparency) 結果責任を持つ人に対して見える化されていること標準化され見ている人が共通理解を持てること検査 (Inspect) 作成物や進捗を頻繁に検査し変化を検知する検査を頻繁にやりすぎて作業の妨げになってはいけない適応 (Adapt) プロセスに不備がある場合その構成要素を調整するプロセスの調整を出来る限り早く行い逸脱を防ぐスクラムのイベント作成物ロールには必ず何れかが当てはまる 21

22 スクラムの5つの価値基準 5つの価値基準を取り入れ実践することで透明性検査適応が実現可能となる確約 (Commitment) 個人はスクラムチームのゴールの達成を確約しなければいけない無理をして絶対に終わらせるということではない勇気 (Courage) スクラムチームのメンバーは正しいことをする勇気を持ち困難な問題に取り組まなければいけない集中 (Focus) スクラムチーム全員がスプリントの作業とゴールに集中しなければいけない公開 (Openness) スクラムチームとステークホルダーは仕事や課題とその遂行の様子を公開することに合意しなければいけない尊敬 (Respect) スクラムチームのメンバーはお互いを能力のある独立した個人として尊敬しなければいけない 22

23 スクラムにおける19のルール透明性検査適応プロダクトバックログリファインメント(5 10%) スプリント(1-4週間) デイリースクラムデイリースクラムスプリントプランニング第一部スプリントバックログスプリントプランニング第二部出荷可能な製品スプリントレビュープロダクトオーナー Doneの定義デイリースクラムスプリントレトロスペクティブデイリースクラム障害リスト開発チーム(7±2) デイリースクラムデイリースクラムプロダクトバックログスプリントの中止スクラムマスター 23

24 スクラムにおける3つのロール 24

25 スクラムにおける3つのロール透明性検査適応プロダクトバックログリファインメント(5 10%) スプリント(1-4週間) デイリースクラムデイリースクラムスプリントプランニング第一部スプリントバックログスプリントプランニング第二部出荷可能な製品スプリントレビュープロダクトオーナー Doneの定義デイリースクラムスプリントレトロスペクティブデイリースクラム障害リスト開発チーム(7±2) デイリースクラムデイリースクラムプロダクトバックログスプリントの中止スクラムマスター 25

26 スクラムチームプロダクトオーナー開発チームスクラムマスターで構成される自己組織化されており機能横断的ゴールを達成するための最善策を自分たちで選択するスクラムチーム説明責任要求ステークホルダー作業依頼説明成果質問プロダクトオーナー開発チーム(7±2) 支援支援スクラムマスター 26

プロダクトオーナー(PO) 求められる能力コスト感覚ネゴシエーション力説明力決断力一貫性戦略性役割開発チームの作業とプロダクトの価値の最大化に責任を持つリリース日リリース内容を決めるプロダクトバックログの管理に責任を持つ1人の人間プロダクトバックログの優先順位の決定(委員会があっても構わないが決定はPOの責任)

27 プロダクトオーナー(PO) 求められる能力コスト感覚ネゴシエーション力説明力決断力一貫性戦略性役割開発チームの作業とプロダクトの価値の最大化に責任を持つリリース日リリース内容を決めるプロダクトバックログの管理に責任を持つ1人の人間プロダクトバックログの優先順位の決定(委員会があっても構わないが決定はPOの責任) 開発チームへの作業依頼(PO以外が開発チームに作業依頼をしてはいけない) 作業結果の受入拒否仕事プロダクトバックログアイテム(PBI)を明確に表現するゴールとミッションを達成できるようにPBIを並べ替える開発チームが行う作業の価値を最適化する PBIを全員に見える化透明化明確化しスクラムチームが次に行う作業を示す必要とされるレベルでPBIを開発チームに理解してもらう 27

28 開発チーム求められる能力開発力自己組織化見積力職能横断的スキル(全員揃えばプロダクトを作れる) 役割リリース可能なモノを作成する自分たちの作業の管理(1番良いやり方を自分たちで考え決める) 生産性を向上するために努力する責任仕事スプリントプランニングで約束したことを実現する生産性向上のための行動を常に考え行う 28

29 スクラムマスター求められる能力サーバントリーダーシップティーチング力ファシリテーション力コーチング力スクラム以外のプロセスの理解集団心理の理解事実(数字)を示す役割スクラムの理解と成立に責任を持つプロダクトオーナーの支援開発チームの支援仕事スクラムの説明を行い理解してもらう効果的なプロダクトバックログの管理方法の検討 (必要に応じて) イベントのファシリテート開発チームの進捗を阻害する要因の排除 29

30 スクラムチームアンチパターン兼任スクラムマスタープロダクトオーナー開発チーム(7±2) スクラムマスター兼開発チーム課題スクラムマスターとして開発チームに対して厳しく接する場面もあるがその際にスクラムマスターとしての発言なのか開発チームの一員としての発言なのか受け取る側が混乱しやすい特に従来の開発でチームリーダーを担当していたような人は技術的にも優れている場合が多いためアーキテクチャの検討や設計開発とスクラムマスターとしての役割を両立することになり負担が大きい解決策スクラムマスターの経験がある場合チーム内でスクラムマスターや技術的に頼れる人を育て手放していく経験が無いのであれば開発チームからスクラムマスターを選び自身は開発者に専念する 30

31 スクラムチームアンチパターン PO委員会プロダクトオーナー委員会開発チーム(7±2) スクラムマスター課題プロダクトオーナーが複数人いるため意見が統一されず開発チームが混乱するプロダクトオーナー委員会内で意見が衝突する場合があるため判断スピードが遅くなる開発チームが仕様を問い合わせる際に誰に連絡を取れば良いかわからない解決策委員会があっても良いが必ずプロダクトオーナーを1人決めるスクラムマスターはプロダクトオーナー以外からの作業依頼はブロックする 31

32 スクラムチームアンチパターン意欲に満ちたステークホルダーステークホルダー開発チーム(7±2) 課題積極的に協力しようと開発チームにアドバイスや情報を提供してくれるがプロダクトオーナーとすり合わせられていないまたプロダクトバックログに反映するための調査作業などを直接開発チームに依頼してしまうプロダクトオーナーが把握していない作業や情報が増えベロシティの低下や本来優先すべきタスクが後回しにされる事態を招く解決策スクラムマスターはステークホルダーからの直接の依頼をブロックしプロダクトオーナーを必ず通すように説明するプロダクトオーナーはステークホルダーに対して情報収集と説明を行う 32

33 スクラムの3つの作成物 33

34 スクラムの3つの作成物透明性検査適応プロダクトバックログリファインメント(5 10%) スプリント(1-4週間) デイリースクラムデイリースクラムスプリントプランニング第一部スプリントバックログスプリントプランニング第二部出荷可能な製品スプリントレビュープロダクトオーナー Doneの定義デイリースクラムスプリントレトロスペクティブデイリースクラム障害リスト開発チーム(7±2) デイリースクラムデイリースクラムプロダクトバックログスプリントの中止スクラムマスター 34

35 プロダクトバックログプロダクトに必要なものが全て優先順位で並んだ一覧プロダクトに対する変更要求の唯一の情報源となるプロダクトバックログの1要素をプロダクトバックログアイテム(PBI)と呼ぶプロダクトバックログはビジネス要求市場の状態技術の変化などにより常に変化し続ける PBIに内容の詳細や見積り並び順の変更などを加えることをプロダクトバックログリファインメントと呼ぶリファインメントのタイミングはスクラムチームが決定する一般的に開発チームの作業の10%以下にすることが多い見積りは相対見積りで行う値はフィボナッチ数列やS,M,Lなどなんでも良い明確リファインメントによって明確にしていく不正確で粗い優先順位ストーリー見積 1 AとしてXXが出来る 2 2 BとしてYYを一覧形式で参照できる 3 3 C処理の性能改善 Dとしてレポートを作成できる 8 35

36 不確実性コーンプロジェクトが進行するにつれて見積もりのバラツキがどのように推移していくのかを表している最初期においては見積りの最大値と最小値に 16倍もの開きがあるスプリントを繰り返すうちに不確実性が小さくなる間違っていても早期にアジャストすれば良い 36

37 ゴールへの進捗の確認リリースバーンダウンチャートなどを用いて希望している内容が希望しているタイミングでリリースできるかを追跡確認するスプリントレビュー時に確認するとプロダクトオーナーにスコープの調整の材料を与えることができるリリースに必要なポイント数とタイミングが分かれば１スプリント実施するだけで遅れの有無がわかる理想 40 実際 Sprint 1 Sprint 2 Sprint 3 Sprint 4 Sprint 5 Sprint 6 Sprint 7 Sprint 8 Sprint 9 Sprint 10 Sprint 11 37

38 スプリントバックログスプリントで選択したプロダクトバックログアイテムとそれらを出荷可能な製品として届けるための計画を合わせたもの開発チームがスプリントゴールを達成するのに必要な作業の一覧十分に詳細化されておりスプリント中は変更される可能性があるスプリントバックログを変更できるのは開発チームだけ見積りは理想時間で行うタスクの粒度は小さい方が見積り精度が上がるため小さい方が良い大きくても１日のうち開発作業にあてられる時間程度を上限とすることストーリータスク見積 AとしてXXが出来る UIのコーディング 3.0h データモデル設計変更 Entityの作成 3.0h Actionのコーディング 2.0h UIのコーディング 4.0h Actionのコーディング 2.0h BとしてYYを一覧形式で参照できる 38

39 スプリントの進捗の確認スプリントバックログの残作業量を追跡し進捗を確認するデイリースクラムでバーンダウンチャートを確認することが多い理想 15 実際水曜日木曜日金曜日月曜日火曜日水曜日木曜日金曜日月曜日火曜日 39

40 出荷可能な製品これまで作成してきた製品と今回のスプリントで完成したプロダクトバックログアイテムを合わせたものスプリントの終わりには出荷可能な製品が完成していなければならない出荷可能とはスクラムチームの完成の定義に合っていることを意味する部品だけでは出荷できない小さくても使えるものを作る 40

41 作成物の透明性 41

42 Done(完成)の定義出荷可能な製品の完成の定義作業が完了したかどうかの評価に使われるリリースするためにやらなければならないこと Done Undone 毎スプリント完了しているもの毎スプリント実施できていないもの開発 UT カバレッジ80%以上 IT リグレッションテストドキュメント作成静的解析シナリオテスト負荷テストセキュリティテストリリース UndoneをDoneにしていくことが重要 42

43 スクラムにおける5つのイベント 43

44 スクラムにおける5つのイベント透明性検査適応プロダクトバックログリファインメント(5 10%) スプリント(1-4週間) デイリースクラムデイリースクラムスプリントプランニング第一部スプリントバックログスプリントプランニング第二部出荷可能な製品スプリントレビュープロダクトオーナー Doneの定義デイリースクラムスプリントレトロスペクティブデイリースクラム障害リスト開発チーム(7±2) デイリースクラムデイリースクラムプロダクトバックログスプリントの中止スクラムマスター 44

45 スプリントプランニングタイムボックス: 4時間 / 2週間スプリントプランニング第一部スプリントの成果である出荷可能な製品の増分として何を届けることができるかという問いに答えるインプットはプロダクトバックログ最新の製品開発チームの予想キャパシティと実績これを元にどのプロダクトバックログアイテムまで選択するのかを決定するこのアイテム数については開発チームが責任を持つスプリントで届けるプロダクトバックログを予想したあとにスプリントゴールを設定するスプリントゴールはプロダクトバックログを実装することで実現するスプリントの目的優先順位ストーリー見積 1 AとしてXXが出来る 2 2 BとしてYYを一覧形式で参照できる 3 3 C処理の性能改善 Dとしてレポートを作成できる 8 スプリントで実施するPBIを選択 45

46 スプリントプランニングスプリントプランニング第二部出荷可能な製品の増分を届けるために必要な作業をどのように成し遂げるかという問に答える第一部で実施すると決めたプロダクトバックログアイテムをスプリントバックログに落とし込むスプリントの最初の数日間分のタスクについてはこの段階で作業レベルまでタスクを分解するタスクの分解は必要に応じてスプリント期間中も実施するプロダクトオーナーはプロダクトバックログの明確化やトレードオフを支援するタスクを分解した結果作業が多すぎたり少なすぎたりする場合はプロダクトオーナーと話し合い調整する開発チームはどのようにスプリントゴールを達成するかを説明できなければならないストーリー AとしてXXが出来る BとしてYYを一覧形式で参照できる具体的なタスクに分解するタスク見積 UIのコーディング 3.0h データモデル設計変更 Entityの作成 3.0h Actionのコーディング 2.0h UIのコーディング 4.0h Actionのコーディング 2.0h 46

学習が進むにつれてスコープが明確化されプロダクトオーナーと開発チームの交渉が必要になる可能性があるスプリントの中止スプリントはタイムボックスの終了前に中止することができるが

47 スプリントタイムボックス: 1ヶ月以下出荷可能な製品を作成するための1ヶ月以下のタイムボックスであり開発作業を行う連続した期間スプリントはスプリントプランニングデイリースクラム開発作業スプリントレビュースプリントレトロスペクティブで構成される注意スプリントゴールに悪影響を及ぼすような変更は加えない品質目標は下げない学習が進むにつれてスコープが明確化されプロダクトオーナーと開発チームの交渉が必要になる可能性があるスプリントの中止スプリントはタイムボックスの終了前に中止することができるがスプリントの中止の権限があるのはプロダクトオーナーだけ中止した場合はプロダクトバックログの完成したアイテムをレビューする未完成のプロダクトバックログアイテムは再見積りを行ってからプロダクトバックログに戻す 47

デイリースクラムタイムボックス: 15分 / 1日前回のデイリースクラムから行った作業の検査と次回のデイリースクラムまでに行う作業の計画を立てるこの場でスプリントバックログの作業進捗を検査するデイリースクラムは毎回同じ時間場所で開催するデイリースクラムでは開発チームのメンバーが以下のことを説明する

48 デイリースクラムタイムボックス: 15分 / 1日前回のデイリースクラムから行った作業の検査と次回のデイリースクラムまでに行う作業の計画を立てるこの場でスプリントバックログの作業進捗を検査するデイリースクラムは毎回同じ時間場所で開催するデイリースクラムでは開発チームのメンバーが以下のことを説明する開発チームがスプリントゴールを達成するために私が昨日やったことは何か開発チームがスプリントゴールを達成するために私が今日やることは何か私や開発チームがスプリントゴールを達成するときの障害物を目撃したかデイリースクラムで詳細な内容に踏み込みそうな場合はデイリースクラム終了後に開発チームまたは一部のチームメンバーで集まり詳細な議論適応再計画を行う 48

プロダクトオーナーがPBIの完成したものと完成していないものについて説明する開発チームはスプリントでうまくいったこと直面した課題それをどう解決したかを議論する開発チームは完成したものをデモして

49 スプリントレビュータイムボックス: 2時間 / 2週間スプリントの終わりに出荷可能な製品の増分の検査と必要であればプロダクトバックログの適応を行うスプリントレビューではスクラムチームと関係者がスプリントの成果をレビューする進捗確認の場ではなくフィードバックや更なる協力を引き出すことが目的スプリントレビューには以下が含まれる参加者はプロダクトオーナーが招待するプロダクトオーナーがPBIの完成したものと完成していないものについて説明する開発チームはスプリントでうまくいったこと直面した課題それをどう解決したかを議論する開発チームは完成したものをデモして質問に答えるプロダクトオーナーは現在のプロダクトバックログを確認し完了日を予測するグループ全体で次に何をするか議論し次のスプリントプランニングのインプットにするプロダクトの次のリリースに対するスケジュール予算性能市場をレビューする 49

50 スプリントレトロスペクティブタイムボックス: 1.5時間 / 2週間スクラムチームの検査と次のスプリントの改善計画を作成する機会スプリントレビューが終わり次のスプリントプランニングが始まる前に実施する人関係プロセスツールの観点から今回のスプリントを検査するうまくいった項目や今後の改善が必要な項目を特定整理する次のスプリントで実施する改善策を特定するスクラムチームの作業の改善実施計画を作成する完成の定義を適切に調整する方法は特に規定されていないがよくKPTが用いられる KPTの実践的な進め方についてはプロジェクトファシリテーション実践編ふりかえりガイド[1]が参考になるその他の方法についてはアジャイルレトロスペクティブズ強いチームを育てるふりかえりの手引き [2]などを参照 [1]: [2]: 50

51 会議体及び出席者 51

52 スクラムと品質 52

53 ウォーターフォールでの品質課題フェーズゲートにより内部品質は担保されるが作成した製品が本当に欲しいモノだったのかわかるのは受入テストのタイミング大きなリスクが後半に待っている要件定義設計実装結合テスト受入テスト 53

54 スクラムではスプリントレビューでビジネス要件との適合性を確認時間要件定義設計実装テスト要件定義設計実装テスト要件定義設計実装テスト要件定義設計実装テスト 54

55 狩野モデル顧客満足度満足気に入る魅力品質仕方ない物理的な充足度充足不充足一元的品質 (性能品質) 当たり前当たり前品質 (基本品質) 気に入らない不満足 55

56 狩野モデルスクラムは魅力品質一元的品質を高めやすい仕方ない顧客満足度満足気に入る他に無い機能デザインユーザビリティなど物理的な充足度充足不充足スループットレスポンスタイム稼働率など当たり前機能が正常に動作すること想像通りに動作すること気に入らない不満足当たり前品質はウォーターフォールと変わらない 56

57 QCD + S Delivery Quality(品質) 固定 Cost(コスト体制) 固定 Delivery(価値提供までの時間) 固定 Scope(スコープ) 調整可能 Scope Quality Cost 57

58 テスト自動化繰り返し開発していくことになるのでテストを行う回数がウォーターフォールより多い前のスプリントで追加した機能のリグレッションテストなどを考えると自動化は必須時間要件定義設計実装テスト要件定義設計実装テスト要件定義設計実装テスト要件定義設計実装テスト自動化するテスト種別などはコンテキストに依存するのでスクラムチームで検討する 58

59 継続的インテグレーション/デリバリーテスト自動化と同様に頻繁にビルドデプロイを行うことになるため自動化を推奨する 59

60 スクラムとメトリクス 60

61 ベロシティ 1スプリントで完了したストーリーポイントの合計開発チームの生産量を表すスプリントプランニングでキャパシティを決める際に参考にする Sprint 1 Sprint 2 Sprint 3 Sprint 完了したストーリーベロシティ 61

62 ベロシティの利用リリース予定に対して遅延しているかどうかリリースポイント (期待 or 実績) ベロシティ残スプリント数例ポイント 10スプリントオンスケジュール 100 9ポイント 10スプリント遅延キャパシティの求め方キャパシティ = 5スプリント分の有効ベロシティの平均有効ベロシティは初出のベロシティ今までの最大最小を除外したもの有効ベロシティが5スプリント分ない場合は直近のベロシティを採用する 62

63 アジャイルプロジェクトでの成功の測定方法ビジネス価値が 23%(2016年)から43%(2017年)に増加顧客満足度が28%(2016年)から46%(2017年)に増加する一方ベロシティが67%(2016年)から42%(2017年)に減少顧客満足度ビジネス価値予算と実際のコストの差計画と実際に消化したストーリーの差異計画と実際のリリース日の差製品の欠陥見積精度累積フロー図 VersionOne 12th Annual State of Agile Report 63

64 スクラムアジャイルに対するよくある誤解 64

65 スクラムは生産性が高い決まりきったモノを作るのであればウォーターフォールの方が生産性は高い複雑で変化が激しく市場やユーザの反応を見なければ正解がわからない場合などはスクラムが向いている市場投入までのリードタイムはスクラムの方が早い市場投入までのリードタイム = P + (S + Q + W) 要素定義システム開発セットアップタイム(準備) 準備時間計画設計に掛かる時間プロセスタイム加工時間移動時間実装に掛かる時間デリバリーに掛かる時間キュータイムリソースの制約から待っている時間全員が作業中でタスクが着手されていない時間ウェイトタイム依存するタスクの待ち時間依存モジュールの完成待ちテスト対象のデリバリー待ちなどをしている時間 65

66 リソース効率とフロー効率リソース効率稼働率良い稼働率良いリードタイム長いリードタイム短いリードタイム長いリードタイム短い稼働率悪い稼働率悪い高低フロー効率低高 66

67 リソース効率とフロー効率リソースリソース 1つのリソースを稼働率が 100%になるまで配分フローユニットフローユニットフローユニット例マルチタスクリソースリソースリソースフローユニットが享受できるリソースを最大化するフローユニットフローユニット例ペアプログラミング 67

68 リソース効率とフロー効率リソース効率高 Water Fall Scrum 低 Lean Chaos フロー効率低高 68

69 スクラムは大規模に向かない 2-8チームでの開発向け 1人のスクラムマスターは1-3チーム担当できる 1つのプロダクトに対して1つのプロダクトバックログ 1人のプロダクトオーナー各チームのスプリント周期は同一 8チーム以上はLeSS Hugeというフレームワークがある企業規模でアジャイルを実現するためのもの 8-12週のサイクルで反復する 1リリースに対して5-15チーム(50-125人)が存在する 69

70 スクラムはドキュメントを作らない包括的なドキュメントよりも動くソフトウェアに価値を置いている必要なドキュメントは当然作成する 70

71 スクラムは品質がウォーターフォールに劣る開発プロセスによってテスト種別テストケースは変わらないよって基本品質に差が出ることは無い 71

72 Appendix 72

アジャイルの採用理由製品のデリバリーの加速が更に重視されるように 1. 2. 3. 4. 5.

73 アジャイルの採用理由製品のデリバリーの加速が更に重視されるように製品のデリバリーの加速優先順位の変更管理能力を高める生産性を高めるビジネスとITの連携の改善ソフトウェアの品質を高める VersionOne 12th Annual State of Agile Report 73

74 アジャイルを導入するメリット優先順位の変更管理プロジェクトの可視性ビジネスとITの連携デリバリー速度/市場投入までの時間チームの生産性向上プロジェクトのコスト削減と答えている数は意外と少ない VersionOne 12th Annual State of Agile Report 74

75 アジャイルの成熟度 80%以上がまだ成熟しきっていないと回答簡単には習得できない VersionOne 12th Annual State of Agile Report 75

76 構成管理及びリリース管理の成熟度モデルプラクティスビルド管理および継続的インテグレーション環境およびデプロイメントリリース管理およびコンプライアンステストデータ管理構成管理レベル3 - 最適化プロセスの改善に注力するチームで定期的に話し合いの場を持ち変更管理ポリシーを常に検証し効率全ての環境がうまく管理されている本番環境への変更の取り消しはめったにリリースのたびにデータベースのパフォー統合時の問題やその自動化による解決運用チームとデリバリーチームが協力し的な共同作業や素早いデプロイができてプロビジョニングは完全に自動化発生しない問題があればすぐに見つかマンスやデプロイメントプロセス自体につい素早いフィードバックそしてよりよい可視リスク管理やサイクルタイム削減を行ういるかを確かめるまた変更管理プロセ仮想化を適切に活用するりすぐに修正されるてのフィードバックを得る化について議論するスの可監査性もチェックするレベル2 - 定量的な管理プロセスが計測可能で制御されているビルドメトリクスを収集して可視化しそ統合したデプロイ管理リリースやリ環境はアプリケーションの健康状態を監データベースの更新やロールバックはデプ開発者は少なくとも一日一度はメイン品質のメトリクスとその傾向を追跡するれに基づいて作業するビルドを壊れたまリース取り消しの手順もテストして視し能動的に管理しているサイクルタロイのたびにテストされるデータベースのラインにチェックインするブランチはリリー非機能要件を定義し計測するまにしないいるイムを監視しているパフォーマンスを監視最適化するス作業の時にだけ使う自動ビルドと自動テストのサイクルを変ソフトウェアのデプロイは完全に自レベル1 - 一貫しているユニットテストや受け入れテストを自動化ライブラリや依存関係を管理するバー更がコミットされるたびに実行する依存動化されボタンを押すだけで完結変更管理とその承認プロセスが定義されデータベースへの変更はデプロイメントプ自動化されたプロセスがアプリケーションのする受け入れテストはテスターが書くジョン管理システムの利用ポリシーは変関係を管理するスクリプトやツールを再するすべての環境に対して同じ手それを守っている規約を順守しているロセスの一環として自動的に行うライフサイクル全体に適用されるテストが開発プロセスに組み込まれる更管理プロセスで定義する利用する順でデプロイするバージョン管理システムを使ってソフト一部の環境ではデプロイを自動化レベル0 - 繰り返し可能普段のビルドやテストを自動化するすべ面倒で頻度も低く信頼できないリリースデータベースへの変更は自動化したスクリウェアの作成に必要なものをすべて管理する新しい環境を手軽に作成すストーリーの開発の一環として自動テストプロセスは文書化され一部は自動化されてのビルドはソース管理システムを使っリリース要件に関するトレーサビリティも限プトで行いスクリプトはアプリケーションとするソースコードや設定ファイルビルドるすべての構成管理情報を外にを書くているて自動化された手順で再現できる定的ともにバージョン管理するやデプロイ用スクリプトデータのマイグ出してバージョン管理するレーションなどレベル-1 - リグレッションエラー多発ソフトウェアのデプロイ手順が手動バージョン管理システムを使っていないソフトウェアのビルド手順が手動である開発をした後に手作業でのテストを実施データのマイグレーションはバージョン管プロセスは繰り返せず管理も貧弱そして対であるバイナリが環境に依存するリリース頻度が低くしかも信頼できないあるいは使っていても滅多にチェックインし成果物やビルド結果の管理をしていないする理されておらず手動で操作する処療法を行っている環境の配布が手動であるない David,Farley ; Jez,Humble. 継続的デリバリー:信頼できるソフトウェアリリースのためのビルドテストデプロイメントの自動化. 和智右桂訳 ; 高木正弘訳. KADOKAWA/アスキーメディアワークス

77 拙速と巧遅巧さ巧巧遅巧速拙拙遅拙速速さ遅速 77

78 拙速と巧遅巧さ巧 Water Fall Scrum 拙 Lean Chaos 速さ遅速 78

79 アジャイルをスケールさせるには内部のアジャイルコーチチーム間での同じプラクティスとプロセスチーム間での共通のツールの実装外部のアジャイルコンサルタント/トレーナー経営陣の後援 VersionOne 12th Annual State of Agile Report 79

スクラムと監査についての一考システム監査人協会近畿支部近藤博則

スクラムと監査についての一考システム監査人協会近畿支部近藤博則スクラムと監査についての一考システム監査人協会近畿支部近藤博則自己紹介近藤博則 ( こんどうひろのり ) 昭和 54 年 11 月 4 日生まれ平成 27 年システム監査技術者試験合格関西支部報告 2 本支部メルマガ巻頭言寄稿など支部活動に参加アンケートスクラムを知っていますか? スクラムを使ったとがありますか? スクラムを監査した事がありますか? スクラムが生まれた背景ビジネスの不果実性の増大

スクラム概論 第1.1版 2018年08月02日 この 作品 は クリエイティブ コモンズ 表示 - 継承 4.0 国際 ライセンス の下に提供されています スクラム概論 2018 TIS INC. クリエイティブ コモンズ ライセンス 表示-継承 4.0 国際

スクラム概論第1.1版 2018年08月02日この作品はクリエイティブコモンズ表示 - 継承 4.0 国際ライセンスの下に提供されていますスクラム概論 2018 TIS INC. クリエイティブコモンズライセンス表示-継承 4.0 国際