アジャイルソフトウェア開発とは

Slide 1

Slide 1 text

アジャイル開発で素早く価値を創造し社会の課題解決へつなげる

Slide 2

Slide 2 text

アジャイルソフトウェア開発とは

Slide 3

Slide 3 text

はじめに

Slide 4

Slide 4 text

1. なぜアジャイルなのかを知る 2. アジャイル開発と非アジャイル開発を知る 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる今日のゴール

Slide 5

Slide 5 text

1. なぜアジャイルなのかを知る 2. アジャイル開発と非アジャイル開発を知る 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる今日のゴール

Slide 6

Slide 6 text

今の世の中って？

Slide 7

Slide 7 text

出典：Society5.0 －ともに創造する未来一般社団法人日本経済団体連合会 http://www.keidanren.or.jp/policy/2018/095.html Society 5.0

Slide 8

Slide 8 text

Society 5.0 1. 変化が激しい 2. 物事の予測が困難 3. 複雑かつ不確実な世の中

Slide 9

Slide 9 text

デジタル革新と多様な人々の想像・創造力の融合によって、社会の課題を解決し、価値を創造する社会 Society 5.0 1. 変化が激しい 2. 物事の予測が困難 3. 複雑かつ不確実な世の中

Slide 10

Slide 10 text

ただ

Slide 11

Slide 11 text

出典：なぜ、今アジャイルが必要か？独立行政法人情報処理推進機構 IPA https://www.ipa.go.jp/files/000073019.pdf 従来のソフトウェア開発だとこれに追随できない

Slide 12

Slide 12 text

出典：なぜ、今アジャイルが必要か？独立行政法人情報処理推進機構 IPA https://www.ipa.go.jp/files/000073019.pdf ので、こうする必要がある

Slide 13

Slide 13 text

出典：なぜ、今アジャイルが必要か？独立行政法人情報処理推進機構 IPA https://www.ipa.go.jp/files/000073019.pdf ソフトウェアの価値も高め続ける必要がある

Slide 14

Slide 14 text

今求められている開発

Slide 15

Slide 15 text

1. 変化するビジネス要件に迅速に追従できる 2. 事業と開発が密にコミュニケーションをとり一体となる今求められている開発

Slide 16

Slide 16 text

これらを解決するために生まれたのが

Slide 17

Slide 17 text

アジャイル開発

Slide 18

Slide 18 text

アジャイル開発って何？

Slide 19

Slide 19 text

アジャイル開発はどんなイメージかチャットに書き込んでみましょう！

Slide 20

Slide 20 text

柔軟で効率的なシステム開発によって、迅速なシステム提供を目ざすというソフトウェア開発手法の総称。アジャイルは英語で、「素早い・機敏な・（頭の回転が）速い」などの意味をもつ。ソフトウェア開発の課題であった、開発期間の短縮化や低コスト化、柔軟で迅速な対応などを実現するための取り組みで、プログラマーなどの開発サイドから提唱された手法である。 2001 年アメリカのスノーバードにソフトウェア開発手法の分野のエキスパートが集まりアジャイルソフトウェア開発宣言（アジャイル・マニフェスト）という文書がまとめられた。さらに、組織としてアジャイル・アライアンス Agile Aliance が結成され、本格的な取り組みがスタートした。途中経過の成果を早い段階から継続的に顧客に引き渡すことで、開発途中での確認や仕様変更などに対応する。また仕様書だけに頼るのではなく、顧客や開発チーム内でのコミュニケーションを重視することを原則としている。アジャイル開発とは参考：https://kotobank.jp/word/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB-348

Slide 21

Slide 21 text

アジャイル開発とは柔軟で効率的なシステム開発によって、迅速なシステム提供を目ざすというソフトウェア開発手法の総称。アジャイルは英語で、「素早い・機敏な・（頭の回転が）速い」などの意味をもつ。ソフトウェア開発の課題であった、開発期間の短縮化や低コスト化、柔軟で迅速な対応などを実現するための取り組みで、プログラマーなどの開発サイドから提唱された手法である。 2001 年アメリカのスノーバードにソフトウェア開発手法の分野のエキスパートが集まりアジャイルソフトウェア開発宣言（アジャイル・マニフェスト）という文書がまとめられた。さらに、組織としてアジャイル・アライアンス Agile Aliance が結成され、本格的な取り組みがスタートした。途中経過の成果を早い段階から継続的に顧客に引き渡すことで、開発途中での確認や仕様変更などに対応する。また仕様書だけに頼るのではなく、顧客や開発チーム内でのコミュニケーションを重視することを原則としている。参考：https://kotobank.jp/word/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB-348

Slide 22

Slide 22 text

アジャイル開発とはアジャイルソフトウェア開発宣言 ↓に則って途中経過の成果を早い段階から継続的に顧客に引き渡す

Slide 23

Slide 23 text

アジャイル開発とはアジャイルソフトウェア開発宣言 ↓に則って途中経過の成果を早い段階から継続的に顧客に引き渡す

Slide 24

Slide 24 text

アジャイルソフトウェア開発宣言

Slide 25

Slide 25 text

アジャイルソフトウェア開発宣言

Slide 26

Slide 26 text

アジャイルソフトウェア開発宣言完全に理解した

Slide 27

Slide 27 text

アジャイルソフトウェア開発宣言やり方とか知らんが関係者と話して、ドキュメントを作らず実装して、計画せずに顧客要求を飲み続ける開発手法ね！

Slide 28

Slide 28 text

Slide 29

Slide 29 text

アジャイルソフトウェア開発宣言

Slide 30

Slide 30 text

アジャイルソフトウェア開発宣言

Slide 31

Slide 31 text

このことから

Slide 32

Slide 32 text

アジャイル ≠ 開発手法

Slide 33

Slide 33 text

アジャイル = 価値観

Slide 34

Slide 34 text

❌：Do Agile. ⭕：Be Agile.

Slide 35

Slide 35 text

❌：アジャイルをする ⭕：アジャイルになる

Slide 36

Slide 36 text

以上

Slide 37

Slide 37 text

ウソです、続けます💦 すいません許してください!何でもしますから! ん？今なんでm

Slide 38

Slide 38 text

アジャイルソフトウェア開発宣言もし Do の観点で具体的にするなら実態はこれくらいの認識がいいかも要求から動くソフトウェアを作りリリースした成果物をレビューして肉付けしながら完成形を目指す

Slide 39

Slide 39 text

今日のゴール 1. なぜアジャイルなのかを知る a. 従来の開発手法だと世の中の変化についていけない 2. アジャイル開発と非アジャイル開発を知る 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる

Slide 40

Slide 40 text

Slide 41

Slide 41 text

アジャイル以外の開発

Slide 42

Slide 42 text

アジャイルの価値個人と対話動くソフトウェア顧客との協調変化への対応非アジャイルとアジャイル（以下のように定義）非アジャイルの価値プロセスやツール包括的なドキュメント契約交渉計画に従うこと

Slide 43

Slide 43 text

非アジャイル開発の進め方

Slide 44

Slide 44 text

非アジャイル開発の進め方って何が思い浮かびますか？チャットに書き込んでみよう！

Slide 45

Slide 45 text

アジャイルの価値個人と対話動くソフトウェア顧客との協調変化への対応非アジャイルとアジャイル非アジャイルの価値プロセスやツール包括的なドキュメント契約交渉計画に従うこと

Slide 46

Slide 46 text

非アジャイルとアジャイル非アジャイルの価値プロセスやツール　　　　　 →　　不確定要素の排除、 WBS ガントチャート包括的なドキュメント　　　 →　　認識相違をなくす契約交渉　　　　　　　　　 →　　金銭・責任（他）計画に従うこと　　　　　　 →　　期日までの確実な履行

Slide 47

Slide 47 text

非アジャイル開発の進め方　例：ウォーターフォール参考：https://it-trend.jp/process_management/article/464-0012

Slide 48

Slide 48 text

なぜアジャイルになりにくいのか？

Slide 49

Slide 49 text

要求定義要件定義基本設計詳細設計実装単体テスト結合テスト総合テスト受入テストリリースなぜアジャイルになりにくいのか？

Slide 50

Slide 50 text

要求定義要件定義基本設計詳細設計実装単体テスト結合テスト総合テスト受入テストリリースなぜアジャイルになりにくいのか？ここで最終ゴールが決まる！

Slide 51

Slide 51 text

登場人物顧客 PM 開発者

Slide 52

Slide 52 text

なぜアジャイルになりにくいのか？早く移動したい！

Slide 53

Slide 53 text

なぜアジャイルになりにくいのか？早く移動したい！要求ヒアリング ● 時速100km出る ● 乗ってる人は安全に ● 何らかのエネルギーで動く

Slide 54

Slide 54 text

なぜアジャイルになりにくいのか？要件定義 ● 時速100km出る ● 乗ってる人は安全に ○ 箱に入れよ ● 何らかのエネルギーで動く ○ ガソリンにしよ

Slide 55

Slide 55 text

なぜアジャイルになりにくいのか？自動車作ろ！ ● 時速100km出る ● 乗ってる人は安全に ○ 箱に入れよ ● 何らかのエネルギーで動く ○ ガソリンにしよ要件定義

Slide 56

Slide 56 text

なぜアジャイルになりにくいのか？承認要件定義提出自動車 ● 時速100km出る ● 乗る人は箱に入れる ● ガソリンで動く

Slide 57

Slide 57 text

なぜアジャイルになりにくいのか？承認基本、詳細設計で承認を得る —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- □□□—---- □□□—---- □□□—----

Slide 58

Slide 58 text

なぜアジャイルになりにくいのか？承認単体・結合・受け入れテストで承n(ry —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- —---- —----□□□ —----□□□ —----□□□ —----□□□ —----□□□ —----□□□ —----□□□ —----□□□

Slide 59

Slide 59 text

なぜアジャイルになりにくいのか？開発中...

Slide 60

Slide 60 text

なぜアジャイルになりにくいのか？開発中...

Slide 61

Slide 61 text

なぜアジャイルになりにくいのか？開発中...

Slide 62

Slide 62 text

なぜアジャイルになりにくいのか？各種テスト中...

Slide 63

Slide 63 text

なぜアジャイルになりにくいのか？自動車

Slide 64

Slide 64 text

アジャイル開発の進め方

Slide 65

Slide 65 text

アジャイル個人と対話動くソフトウェア顧客との協調変化への対応非アジャイルとアジャイル非アジャイルプロセスやツール包括的なドキュメント契約交渉計画に従うこと

Slide 66

Slide 66 text

アジャイルだとどうなる？早く移動したい！

Slide 67

Slide 67 text

アジャイルだとどうなる？早く移動したい！とりあえず早く動けるやつ作ってみた！対話成果物提示

Slide 68

Slide 68 text

アジャイルだとどうなる？時速100kmは出したい時速100km出せるようにした！

Slide 69

Slide 69 text

アジャイルだとどうなる？乗ってる人は安全に箱に入れつつ最近流行ってる目前に物が現れた時警告音出すやつ入れません？

Slide 70

Slide 70 text

何らかのエネルギーで動くアジャイルだとどうなる？今は電気で動く車がいいらしい！ガソリン＆電気で動けるようにしましょ！

Slide 71

Slide 71 text

電気自動車（アラート機能つき）アジャイルだとどうなる？

Slide 72

Slide 72 text

インクリメンタル開発の神話 “The Myth of Incremental Development” by Herding Cats under CC BY-NC-ND 3.0

Slide 73

Slide 73 text

おさらい

Slide 74

Slide 74 text

おさらい　- 非アジャイル開発の価値早く移動したい！要求ヒアリング ● 時速100km出る ● 乗ってる人は安全に ● 何らかのエネルギーで動く

Slide 75

Slide 75 text

おさらい　- 非アジャイル開発の価値早く移動したい！自動車作ろ！ ● 時速100km出る ● 乗ってる人は安全に ○ 箱に入れよ ● 何らかのエネルギーで動く ○ ガソリンにしよ要件定義〜設計

Slide 76

Slide 76 text

おさらい　- 非アジャイル開発の価値契約締結や開発者への負担を考慮すると一回定めた要件を変えたくない予算・期日内に確実に動くものが欲しい一度決まったことを正確に提出したい

Slide 77

Slide 77 text

Slide 78

Slide 78 text

おさらい　ーアジャイル開発の価値乗ってる人は安全に箱に入れつつ最近流行ってる目前に物が現れた時警告音出すやつ入れません？

Slide 79

Slide 79 text

おさらい　ーアジャイル開発の価値動いているモノを見ることで、安心し、また要求の解像度も上がっていく要求を受け入れるだけでなく「対話」をすることで、より価値のある成果物へつながる細かく成果物を提示することで最終成果物の認識相違が少なくなる価値ある成果物につながる

Slide 80

Slide 80 text

Slide 81

Slide 81 text

ウォーターフォール is 悪？

Slide 82

Slide 82 text

ウォーターフォール is 悪？ぶっちゃけ悪くはない

Slide 83

Slide 83 text

ウォーターフォール is 悪？ぶっちゃけ悪くはない創造性、想像性が不要で、世の中の情勢に左右されない（不変的な）開発なら多分特段問題にならない

Slide 84

Slide 84 text

ウォーターフォール is 悪？ただ、 1 つリスクをあげるとするなら仮に開発期間後半で仕様を変更しようとすると、相当な調整とコストが必要となってしまう

Slide 85

Slide 85 text

ウォーターフォール is 悪？参考：https://it-trend.jp/process_management/article/464-0012

Slide 86

Slide 86 text

ウォーターフォール is 悪？仕様変更問題発生参考：https://it-trend.jp/process_management/article/464-0012

Slide 87

Slide 87 text

ウォーターフォール is 悪？影響範囲甚大参考：https://it-trend.jp/process_management/article/464-0012

Slide 88

Slide 88 text

変化に対応しづらいウォーターフォール is 悪？

Slide 89

Slide 89 text

デジタル革新と多様な人々の想像・創造力の融合によって、社会の課題を解決し、価値を創造する社会 1. 変化が激しい 2. 物事の予測が困難 3. 複雑かつ不確実な世の中変化に弱い、予測型開発という点で、 Society 5.0な世の中にはマッチしていない... ウォーターフォール is 悪？

Slide 90

Slide 90 text

開発業務を体系的に把握するという点では非常に重要ウォーターフォール is 悪？

Slide 91

Slide 91 text

1. 開発プロセスの理解 a. 何をすれば成果物を世の中に出せるの ... ？ 2. 開発で考慮しなければならない事の理解 a. 非機能要件の定義 i. 可用性 1. SLA 【サービス品質保証 / Service Level Agreement / サービスレベル合意書】 a. バックアップ b. 冗長化 ii. 性能・拡張性 1. ネットワーク速度 2. キャパシティプランニング iii. 保守性 1. 設計思想の定義 2. 問題発生時の役割分担、体制、訓練、マニュアル整備 3. MTTR （平均修理時間） /MTTF （平均故障時間） iv. etc… ウォーターフォール is 悪？

Slide 92

Slide 92 text

アジャイル開発でドキュメント化をしなかったとしても「意識」はするし、エンジニアなら知っている前提という「責任」もあるウォーターフォール is 悪？

Slide 93

Slide 93 text

アジャイル/非アジャイルまとめ

Slide 94

Slide 94 text

● 大規模かつ関係者が多い ○ ウォーターフォールだと作業内容・工程が綿密に決められているため、誰が開発に携わっても迷わず進めることができる ○ またこの進め方についても説明は最小限ですむ ○ 工程別でリソース調整もやりやすい ■ 例：要件定義・設計フェーズには上流エンジニア2名、実装フェーズに下流エンジニア10名を採用すればスケジュール通りに進められそう ● 仕様に変更が加わりにくい ○ 世の中の情勢に左右されにくいシステムである ■ 例：在庫管理システム等 ● 明確な予算、期日が定まっている ○ ドキュメント、ツール等で不確実性を見える化し排除できる ■ 例：EVM、コンティンジェンシー予備、WBSガントチャート他ウォーターフォール開発が選択されるパターン

Slide 95

Slide 95 text

● 小規模かつ関係者が少ない ○ アジャイルだと良くも悪くも関係者の作業範囲が定まっておらず、また進め方もプロジェクトによってさまざま ○ 大規模であったり関係者が多いとこの進め方の認識があわず不和が生じる ■ これの解決に大規模アジャイル手法もあるがここでは割愛 ● 仕様が固まりきっていない（固まっていても変更のリスクがある） ○ 世の中の情勢に左右されるシステムである（レッドオーシャン） ● 価値＞予算、期日（品質） ○ 顧客価値が高いと判断されればQCDを差し置いてでも、それを実現したい！となればアジャイル開発が選択されるパターン

Slide 96

Slide 96 text

今日のゴール 1. なぜアジャイルなのかを知る a. 従来の開発手法だと世の中の変化についていけない 2. アジャイル開発と非アジャイル開発を知る a. 非アジャイル（になりやすい）開発例：ウォーターフォール b. アジャイルだと「対話」することで仕様も柔軟に変更がきく 3. アジャイル開発のプロセスを 1 つ例にとって感じてみる

Slide 97

Slide 97 text

Slide 98

Slide 98 text

アジャイル開発の進め方

Slide 99

Slide 99 text

アジャイル開発手法って何がある？チャットに書き込んでみましょう！

Slide 100

Slide 100 text

● スクラム（Scrum） ○ プロジェクト管理に重点を置いたアジャイル開発のフレームワーク ○ 素早いリリース、新たな要求への対応、技術や変化へ適応するために、チーム力の最大化に全力を注ぐ ● XP（eXtreme Programing、エクストリームプログラミング） ○ ソフトウェアの品質を改善し、顧客の要望の変化に適応する能力を高める ○ 短期間での頻繁なソフトウェアリリース ○ 開発を効率化し要求変更コストを抑える 12（19）プラクティス ■ ペアプログラミング、テスト駆動開発など ... ● ユーザー機能駆動開発（ FDD） ○ ユーザーにとっての価値を重視して開発 ○ ユーザーが利用する機能やビジネスモデルに合わせて必要な機能から設計・開発代表的なアジャイル開発手法

Slide 101

Slide 101 text

Slide 102

Slide 102 text

スクラム開発の進め方

Slide 103

Slide 103 text

スクラムって何

Slide 104

Slide 104 text

ほとんどはじめてのスクラム開発の内容是非後で見て下さい

Slide 105

Slide 105 text

スクラムとは、アジャイル開発手法の 1つであり、ユーザーに価値のあるプロダクトを素早く生み出すための軽量なフレームワークです。 1990年初頭にKen Schwaber(ケンシュエイバー)とJeff Sutherland(ジェフサザーランド)により生み出されました。また、スクラム開発におけるチームメンバーの役割、イベント、作成物などのルールは「スクラムガイド」で定義されています。参考：スクラムガイドスクラムとは

Slide 106

Slide 106 text

スクラムは以下2つの考え方に基づいて作成されています。・経験主義　理論よりも経験を重視し、その経験を基に物事を判断する。・リーン思考　ムダを省き、本質に集中する。当初計画に固執することなく、日々の状況変化に柔軟に対応し、ユーザーにとって本当に価値のあるプロダクトを提供するための開発手法です。スクラムとは

Slide 107

Slide 107 text

スクラム開発の3・5・3

Slide 108

Slide 108 text

・プロダクトバックログ　プロダクトの開発や改善に必要なタスクが優先度順に並べられた一覧。・スプリントバックログ　スプリントで実施するプロダクトバックログの項目を実行可能なタスクに詳細化したもの。・インクリメント　プロダクトゴールへ向けた具体的な成果物のこと。 3つの成果物

Slide 109

Slide 109 text

3つの成果物 - インクリメント

Slide 110

Slide 110 text

5つのイベント

Slide 111

Slide 111 text

5つのイベント

Slide 112

Slide 112 text

5つのイベント

Slide 113

Slide 113 text

5つのイベント

Slide 114

Slide 114 text

5つのイベント

Slide 115

Slide 115 text

5つのイベント

Slide 116

Slide 116 text

3つの役割

Slide 117

Slide 117 text

3つの役割・プロダクトオーナー（PO）　プロダクトの価値を最大化することに責任を持つ。　プロダクトバックログの管理（優先順位づけ）を行う・スクラムマスター（SM）　スクラムの考え方とノウハウを全員に理解してもらうことに責任を持つ。　チームが自己組織化されるようトレーニング、コーチングする。・開発者　プロダクトに関するあらゆる側面（品質、計画、専門性）に責任を持つ。スクラムチームは上記メンバーで構成されますが、プロダクトに対するレビューやフィードバックをもらうためステークホルダーとも密に関わります。（顧客、エンドユーザー、関連部署の人など）

Slide 118

Slide 118 text

3つの役割

Slide 119

Slide 119 text

これらを行う上で意識すること

Slide 120

Slide 120 text

スクラムの三本柱と五つの価値基準

Slide 121

Slide 121 text

透明性プロセスや作業は、作業を実行する人とその作業結果を受け取る人に見える必要があります。透明性によって検査が可能となるため、透明性が欠けた状態での検査は、誤解を招き、ムダなものになります。スクラムの三本柱と五つの価値基準

Slide 122

Slide 122 text

検査スクラムの作成物と合意されたゴールに向けた進捗状況は、頻繁かつ熱心に検査される必要があります。検査によって適応が可能となります。スクラムイベントは、変化を起こすように設計されているため、適応のない検査は意味がないとされます。スクラムの三本柱と五つの価値基準

Slide 123

Slide 123 text

適応プロダクト開発のためのプロセスが上手くいかなかったり、成果物であるプロダクトが受け入れなれなかった場合は、現在適用しているプロセスやプロダクト開発のための構成要素を調整する必要があります。スクラムチームは検査によって新しいことを学んだ瞬間にその学習した内容を適応することが期待されています。スクラムの三本柱と五つの価値基準

Slide 124

Slide 124 text

スクラムの三本柱

Slide 125

Slide 125 text

確約スクラムチームはゴールを達成し、お互いにサポートすることを確約します。スクラムの三本柱と五つの価値基準

Slide 126

Slide 126 text

集中スクラムチームはゴールへ向けて進捗できるように、スプリントの作業に集中します。スクラムの三本柱と五つの価値基準

Slide 127

Slide 127 text

公開スクラムチームとステークホルダーは作業や課題を公開します。スクラムの三本柱と五つの価値基準

Slide 128

Slide 128 text

✨ 尊敬スクラムチームのメンバーはお互いに能力のある独立した個人であると尊敬します。スクラムの三本柱と五つの価値基準

Slide 129

Slide 129 text

勇気スクラムチームのメンバーは正しいことをする勇気や困難な問題に取り組む勇気を持ちます。スクラムの三本柱と五つの価値基準

Slide 130

Slide 130 text

スクラムの三本柱と五つの価値基準 🏁👀🔓✨ これらの価値基準がスクラムチームや一緒に働く人たちによって具現化されるとき、スクラムの三本柱「透明性」「検査」「適応」に息が吹き込まれ、信頼が構築されます。

Slide 131

Slide 131 text

スクラムの五つの価値基準

Slide 132

Slide 132 text

スクラムのまとめ

Slide 133

Slide 133 text

スクラムの三本柱と五つの価値基準 1. スクラムはユーザーに価値を素早く提供するためのフレームワークである。 2. スクラムチームは「プロダクトオーナー」「スクラムマスター」「開発者」の 3つの役割で構成される。 3. スプリントで「スプリントレビュー」「デイリースクラム」「リファインメント」「スプリントレビュー」「レトロスペクティブ」の5つのイベントを実施する。 4. 「プロダクトバックログ」「スプリントバックログ」「インクリメント」はスクラムで必要な成果物である。 5. スクラム実施時は、「三本柱」と「五つの価値基準」を常に意識する。

Slide 134

Slide 134 text

Slide 135

Slide 135 text

Slide 136

Slide 136 text

後付け

Slide 137

Slide 137 text

● スクラムは奥が深い ○ スクラムガイドにもこんな感じに書いてある ■ スクラムとは、以下のようなものである。 ● 軽量 ■ 理解が容易 ■ 習得は困難 ● 興味があれば #tech-scrum へ ○ スクラムに限らずアジャイルについても語っていますスクラムについて

Slide 138

Slide 138 text

● アジャイル開発を元にスクラム開発が生まれた ○ 各種適応型、漸進的開発手法をまとめてアジャイルが生まれた ● ウォーターフォールではなかったのでアジャイルです！ ○ 蓋を開いてみたら ■ 細かいウォーターフォール ■ 行き当たりばったりなプロセス ○ 上流工程が面倒だからやらないウォーターフォール開発 ● フェーズを切って細かくリリースしていたのでアジャイルです！ ○ 明確なゴールが決まった状態で部品をリリースしていくだけではアジャイルとは言い難いよくいるエンジニアある間違い

Slide 139

Slide 139 text

胸に手を当てて考えてみましょう（投げやり）弊社はアジャイル開発しているのか？

Slide 140

Slide 140 text

参考 ● スクラムガイド ● なぜ今アジャイルが必要か？ ● はじめてのスクラム開発 ● ウォーターフォールモデルとは？メリット、アジャイルとの違いを解説

Slide 141

Slide 141 text

おしまい