Agile-development-course-advanced-1-2

アジャイル開発手法特論 © 2013 Miho Nagase
アジャイル
開発手法
特論 2013.6.12

今日やること
第1回
• イントロダクション
• Agile/Scrum概要
第2回
• 講義「チームで協働する」
• 演習
2

今日やること
第1回
➡ イントロダクション
第2回
• 演習
3

イントロダクション
アジャイル開発手法特論第1回

教員紹介
概要
目的と狙い
授業計画
評価
質疑応答
5

‣ 仕事
- アジャイルコンサルタント（現職）
- エンジニア → マネージャー → スクラムマス
ター→コーチ
‣ コミュニティ活動
- スクラム道スタッフ
- Scrum Gathering Tokyo 実行委員長
- E-AGILITY協議会委員
こんにちは、永瀬美穂です
6
http://about.me/miho

Reference
教員紹介
7

“
”
概要
8
仕事のすすめ方
評価されている
今日日の常識

“
”
目的と狙い
9
実践的な開発手法を学ぶ

Image+courtesy+of+David+Castillo+Dominici+/+FreeDigitalPhotos.net
授業計画
10
6/15
チームで協働する
6/29
開発環境について
7/6
テスト環境等について
6/22
将来を計画する
7/13
近い将来を計画する
7/27
計測し改善する
7/20
日々の作業をこなす
8/3
組織的な取り組み

評価
11
6/15
6/29
7/6
6/22
7/13
7/27
7/20
8/3
土曜日掲示→水曜日提出
Report
10
Report
10
Report
10
Report10
Report10
Report 10Report 10
exam
30

教員紹介
概要
目的と狙い
授業計画
評価
質疑応答
12

質疑応答
13

○○に興味
があるから
お題について書いてください
‣ あなたのお名前
‣ 普段やっている仕事や専攻
‣ 知識レベル
- Q1. アジャイルとか Scrum とか知っている？聞いたこ
とある？本読んだ？
- Q2. Unixのコマンドを知っている？使える？
‣ この授業を受講する動機や期待
14
永瀬美穂 ECサイトの
プログラマー
Q1. No
Q2. Yes

プログラマー
Q1. No
Q2. Yes
○○に興味
があるから
自己紹介をしよう
‣ 知識レベル
15
プログラマー
Q1. No
Q2. Yes
○○に興味
があるから
書いたカードを使って
隣の人と自己紹介してみよう

自己紹介をしよう
‣ 知識レベル
16
永瀬美穂
ECサイトの
プログラマー
Q1. No
Q2. Yes
○○に興味
があるから
書いたカードを使って
隣の人と自己紹介してみよう

今日やること
第1回
第2回
• 演習
17

Agenda
アジャイルソフトウェア開発
• 背景
• アジャイルソフトウェア開発宣言
Scrum
• Scrumとは何か
• Scrumの全体像
• Scrumのしくみ
18

Oxford+Dictionary+/+ロングマン英和辞典
アジャイルとは？
19
agile | ˈædʒəl
able to move quickly and easily
able to think and understand quickly
”
“

http://pragprog.com/magazines/2011-02/agile--
20

http://pragprog.com/magazines/2011-02/agile--
21

アジャイル開発手法特論 © 2013 Miho Nagase 22
今までうまくいって
いたやり方

今までうまくいっていたやり方
要求分析
基本設計
機能設計
詳細設計
コーディング
受け入れテスト
システムテスト
結合テスト
単体テスト

‣ 大前提
- 変化は激しくない
‣ やり方
- 綿密に計画を立てる
- 立てた計画に従う
24
どれだけ計画どおり
であったか？で評価

7%
13%
16%
19%
45%
システムの20%の機能
がシステムの価値を決め
ている The+CHAOS+Report,+The+Standish+Group,+2000
システム機能の利用度
まったく使わない
ほとんど使わない
たまに使う
よく使う
いつも使う
26

要求分析
基本設計
機能設計
詳細設計
コーディング
受け入れテスト
システムテスト
結合テスト
単体テスト
・
要
求
は
当
然
変
化
す
る
・
予
測
は
当
た
ら
な
い
こんなものが
欲しかった
わけじゃない!!

受け入れなければいけない現実
28
‣ 状況は必ず変化する
- 重厚長大な計画を遵守することのムダ
- 綿密すぎる計画をたてることのムダ
‣ 予測は当たるとは限らない
- 不確実性コーン

‣ 初期の見積もりは1/4∼4倍の誤差があるということ
- PMBOKでは超概算見積の精度は-50%∼+100%
Boehm,+B+(1981).+Software+Engineering+Economics,+PrenticeOHall.+/+Software+Project+Survival+Guide+(McConnell+1997)
不確実性コーン
30

‣ 1994年∼2001年世界売上高50位にとどまることができ
た平均年数は4.8年
‣ 経営戦略の見直しや変更がいつどの程度起こるのか予測しに
くくなっている
ITアーキテクト+vol.12,+2007
経営戦略の短命化
31
ビジネスモデルの
賞味期限が短くなった

IT活用のコモディティ化
‣ IT投資の種類
- 基盤関連投資
- 業務効率化投資
- 情報活用投資
- 戦略的投資
32
事業を創造したい
コストを抑えたい
サービスを創造したい
だいたいやり切ったはず
より価値の高いIT投資
が求められている

テクノロジーの進歩
‣ ハードウェア性能の劇的な向上
‣ 技術や技法の進化
‣ 集合知の活用
33
迅速にものを作れる
状況が整ってきた

アジャイルにならざるを得ない背景
‣ 価値を決めるのは顧客
- 20%の機能がシステムの価値を決定づける
‣ 変化は避けられないことを認めてうまく乗りこなす術
- 初期にすべての要求を洗い出すのはほぼ不可能
- 分析・設計という行為は新しい要求を生む
‣ 現実的な予測にしか意味はない
- 動くソフトウェアが進捗そのもの
- 計画は死守するものではなくフォーキャスト
- もっとも価値のあるものを価値のあるタイミングで
34

‣ 同時期にいろいろな人が提唱し始めた
課題に対応する様々な方法論
35
Crystal Clear
eXtreme Programming
Feature Driven Development
Adaptive Software
Development
Dynamic Systems
Development Method
Scrum

共通する特徴
36
Crystal CleareXtreme ProgrammingFeature Driven Development
Adaptive Software
Development
Dynamic Systems
Development Method
ScrumAgile Software
Development
‣ 細かく軌道修正してビジネスの要求に沿い続ける
‣ 顧客と開発者が協調して進める
アジャイルソフトウェア
開発宣言

アジャイル開発以前の課題
‣ 標準的な手順
- 従うことが目的になってしまう
‣ ドキュメント重視
- 絵に描いた餅で議論する
‣ 契約の遵守
- 人や組織の壁がムダを生む
‣ 計画が絶対
- 計画はいつでも正しいというのは誤解
37

“
”http://agilemanifesto.org/iso/ja/
アジャイルソフトウェア開発宣言
38
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

http://agilemanifesto.org/iso/ja/
アジャイル宣言 : 4つの価値
‣ プロセスやツールよりも個人と対話を重視する
‣ 包括的なドキュメントよりも動くソフトウェアを重視する
‣ 契約交渉よりも顧客との協調を重視する
‣ 計画に従うことよりも変化への対応を重視する
39
左を軽んじるのではなく
右をもっと重んじる

http://agilemanifesto.org/iso/ja/principles.html
アジャイル宣言 : 12の原則(1)
‣ 顧客満足を最優先し、価値のあるソフトウェアを早く継続的
に提供します。
‣ 要求の変更はたとえ開発の後期であっても歓迎します。変化
を味方につけることによって、お客様の競争力を引き上げま
す。
‣ 動くソフトウェアを、2-3週間から2-3ヶ月というできるだ
け短い時間間隔でリリースします。
40

‣ ビジネス側の人と開発者は、プロジェクトを通して日々一緒
に働かなければなりません。
‣ 意欲に満ちた人々を集めてプロジェクトを構成します。環境
と支援を与え仕事が無事終わるまで彼らを信頼します。
‣ 情報を伝えるもっとも効率的で効果的な方法はフェイス・
トゥ・フェイスで話をすることです。
41

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

‣ シンプルさ（ムダなく作れる量を最大限にすること）が本質
です。
‣ 最良のアーキテクチャ・要求・設計は、自己組織的なチーム
から生み出されます。
‣ チームがもっと効率を高めることができるかを定期的に振り
返り、それに基づいて自分たちのやり方を最適に調整しま
す。
43

7th+annual+state+of+agile+development+survey,+2013,+VersionOne
利用されている方法論
44
1%1%1%2%2%
2%
2%
4%
4%
7%
9%
11%
54%
Scrum
Scrum/XP Hybrid
Custom Hybrid
Scrumban
Kanban
Don’t know
XP
FDD
Lean
Other
Agile Uniﬁed Process
Agile Modeling
DSDM Atern

Kanban+vs+Scrum+O+Henrik+Kniberg
開発プロセスはツール
‣ プラクティスの多さによる分類
適応的計画重視
Kanban
(3)
Scrum
(10)
XP
(13)
RUP
(120↑)
Do
Whatever
(0)
45

いくつかの手法
‣ 扱う範囲による違い
組織経営
マネージメント
開発チーム
Lean
Scrum
XP
46

flickr - ksantome
方法論はいろいろ
47

計画駆動型開発とアジャイル開発
48
計画駆動型開発アジャイル開発
立ち上げ
計画
見積
見積単位
パラメータ
価値提供
成功の基準
品質
リスク管理
文化
情報共有
ツール使用
プロジェクト憲章などインセプションデッキなど
初期にすべてを計画する全体をざっくり、直近を詳細に
PMが一人で見積もるチーム全員で見積もる
絶対的相対的
QCD QCDS
プロジェクト完了時優先順位に従って順次
計画通りだったか現実に対応できたか
終盤でテストを実施して確保序盤から作りこみ
PMBOK等では規定されている検査と適応を常時行う
コマンド＆コントロール協調的リーダーシップ、自己組織化
ドキュメント、形式知重視会話、暗黙知重視
時に政治的、慣行的に選択人的負担軽減のための自動化

Agenda
アジャイルソフトウェア開発
背景
アジャイルソフトウェア開発宣言
Scrum
• Scrumとは何か
• Scrumの全体像
• Scrumのしくみ
49

“
”スクラムガイド+スクラム完全ガイド:ゲームのルール+2011年10月,+Ken+Schwaber+and+Jeff+Sutherland,+日本語版+角正典
Scrumとは何か
•
•
•
50

“
”スクラムガイド+スクラム完全ガイド:ゲームのルール+2011年10月,+Ken+Schwaber+and+Jeff+Sutherland,+日本語版+角正典
Scrumとは何か
51
“フレームワーク”

フレームワークとしてのScrum
‣ プロセスや技法ではない。
‣ さまざまなプロセスや技法を取り入れることができる。
‣ プロダクト管理や開発プラクティスの相対的効果を明確にす
ることで、改善を可能にする。
52
様々な技法を取り入れる
ことのできる枠組み

スクラムの三本柱
透明性検査適応
53

透明性
‣ 見える化
- 視認でき計測可能な状態を作ること
‣ 共通認識
- 全員が合意できること
‣ 正直さ
- 隠せない誤魔化せない嘘をつけない
- 問題対私たち
54

検査
‣ チェックポイント
- スクラムイベント
- いつでも!!
‣ 計測
- 見える化されていることが前提
- 異常がないかこまかくチェックする
55

適応
‣ 改善
- より良くしていくこと
- 想定外の情報こそが有益な情報
- 失敗が唯一のドライバー
- 小さな傷が広がる前に治すこと
56

Scrumのしくみ
‣ 反復的漸進的にプロダクトを届ける
- 常に動く状態にしておく
- 常に利用可能な状態にしておく
‣ フィードバックループを回し続ける
- プロダクトに対するフィードバック
- プロセスに対するフィードバック
57
改善に終わりはない

Scrumで定義されていること
‣ 3つのロール
‣ 5つのタイムボックス
‣ 3つの成果物
‣ Done の定義
58

- プロダクトオーナー
- 開発チーム
- スクラムマスター
‣ Done の定義
59

✔ ✔ ✔
3つのロール
60

3つのロール
61
‣ ロールとは役割のこと
‣ プロダクトを作ることに寄与する人たちはいずれかのロール
にあてはまる
‣ プロダクトオーナーは何を作るかに責任を持つ人
‣ 開発チームはどう作るかと作ることに責任を持つ人
‣ スクラムマスターはうまくいくしくみに責任を持つ人
‣ この3者をまとめてスクラムチームと呼ぶ

さながらこんな感じ
62
‣ プロダクトオーナーはカーレーサー
- 効率よくゴールへ向かう
- ハンドルを微調整する
‣ 開発チームはレーシングカー
- エンジンそのもの
‣ スクラムマスターはメカニック
- データを元に燃費やペースを分析する
- ドライバーに助言をする
- 車をメンテナンスする

顧客(Customer)は？
‣ スクラムでは顧客のロールは定義されていない
‣ 利害関係者（ステークホルダー）の中でも重要
‣ 顧客の声に耳を傾けることは大切
- 顧客の声は正しいとは限らない
- 顧客を観察しよう
- 顧客のフィードバックをもらおう
63

- スプリント
- スプリント計画ミーティング
- デイリースクラム
- スプリントレビュー
- スプリントレトロスペクティブ
‣ Done の定義
64

5つのタイムボックス
65
✔
✔ ✔
✔

5つのタイムボックス
66
‣ タイムボックスとは固定された時間の箱のこと
‣ Scrumのしくみをうまく働かせるための機会
- 1週間∼4週間の固定の期間（スプリント）で動くものを
作り続ける
- スプリント計画ミーティングでスプリントの過ごし方を計
画する
- デイリースクラムで毎日異常がないか検査する
- スプリントレビューで作ったものを確認し改善する
- スプリントレトロスペクティブでやり方を確認し改善する

Scrumのタイムボックス
67
月火水木金土日
9:00-9:15 デイリースクラム
9:00-9:15 デイリースクラム 9:15-13:15
スプリントレビュー
14:00-18:00
ふりかえり
9:00-13:00
スプリント計画
第1部
14:00-18:00
スプリント計画
第2部
月曜日開始
4週間スプリントの例

- プロダクトバックログ
- スプリントバックログ
- インクリメント
‣ Done の定義
68

3つの成果物
69
✔ ✔
✔

3つの成果物
70
‣ Scrumの成果物はアクションを促すもの
- 誰もが見られて触れる状態にしておく
‣ プロダクトバックログ
- やりたいことが優先順位順に並べられたリスト
- プロダクトオーナーが優先順位を決定する
‣ スプリントバックログ
- スプリントで実施する開発チームのためのタスクリスト
‣ インクリメント
- 何が終わっているか明確でないと出荷判断できない

‣ Done (完了)の定義
71

Done (完了)の定義
72
✔

Done (完了)の定義
73
‣ 何をもって終わったというのかを決めたもの
‣ これを満たしているインクリメントは出荷判断が可能になる
‣ 品質基準と考えていい
- 例
• リポジトリにソースがチェックインされていること
• テストカバレッジが80%以上であること
• 本番環境にデプロイしても通常通り動作すること

今日やること
第1回
Agile/Scrum概要
第2回
• 演習
74

アジャイル開発手法特論第2回

6/15
6/29
7/6
6/22
7/13
7/27
7/20
8/3

Agenda
なぜチームで協働するのか
自己組織化とは
Scrumで定義された役割
• プロダクトオーナー
• 開発チーム
• スクラムマスター
77

顧客が本当に欲しかったもの
78

全員が同じゴールを目指すために
79
‣ こんなカーナビゲーションシステムはどう？
- 目的地の設定
• どこが目的地かドライバーにもわからない
• ひとたび目的地が設定されたら簡単に変更ができない
- ルートの設定
• 渋滞情報が見えない
• 交通状況が変化してもルート再検索をしない
- ナビゲーション
• 10km道なりでも200mおきに「まだこのまま」と言う

次は
どうしたら
いいんだろ
コマンド＆
コントロール
80

全員が同じゴールを目指すために
81
‣ こんなカーナビゲーションシステムはどう？
- 目的地の設定
• 目的地がわかる
• 同等の施設があれば教えてくれる
- ルートの設定
• 渋滞情報が可視化されている
• ほぼリアルタイムで交通状況に合わせ再検索できる
- ナビゲーション
• 10km道なりなら「10km道なりです」と言う

よけよう
後について
行こう
こっちから
行けば
いいんだな
ぶつからない
ようにしよう
自己組織化された人々
82

ワークショップ
自己組織化
ゲーム
83

‣ 目的
- 共通のゴールにたどり着く
- ビジョンを実現する
‣ 自己組織化した人々が作業したほうが柔軟で創造性に富み、
生産性も最適化される
‣ 目的が明確でやることがシンプルであれば現場判断に任せた
ほうが良い結果が出る
84

‣ 誰の指揮命令を受けなくても、自分たちで自分たちのやり方
を考えながら課題を解決していくさま
‣ 効率と効果を獲得するしくみ
- 自分たちで課題を解決する
- 知恵を出しあって相互作用する
- ゴールに到達するために行うすべてのことの権限を持つ
85

自己組織化を阻む方法
‣ 自己組織化を阻害するには？
86

実際の仕事だと難しい…
‣ だって…
- 先のことはわからないし
- 壮大なプロジェクトだし
- やることはいっぱいあるし
87
ならば、
ゴールを明確にして作業
をシンプルにすればいい

そのためのしくみがScrum
88

Agenda
• プロダクトオーナー
• 開発チーム
• スクラムマスター
89

３つの役割
‣ プロダクトオーナー
‣ 開発チーム
‣ スクラムマスター
90

鶏と豚
91

(C)+KANME
プロダクトオーナー
‣ チームの作業の価値を最大限に発揮することに責任を負う役
割
- プロダクトのビジョンを持つ
- プロダクトの成功に責任を持つ
- マーケットについての深い知識を持つ
- プロダクトに熱意を持つ
- 意見は組織の全員に尊重される
92

‣ やること
- スクラムの力を最大限利用する
- Ready なプロダクトバックログをつくる
• プロダクトバックログはやりたいことリスト
• プロダクトバックログはプロダクトの道標
ログインする
商品をリストする
オススメを表示する
買い物かごに入れる
オーダーを決定する
クレジットカードで決
済する
コンビニ決済する
93
これをいかに
準備するか
プロダクトバックログリリース判断可能なプロダクト

‣ やること（くわしく）
- ビジョンやゴールやプロダクトバックログ項目について開
発チームと明確に共有する
- プロダクトバックログの優先順位を決める
- チームの成果を最大限にする
- プロダクトバックログを見える化し、チームが次にやるこ
とが明確であるようにする
- プロダクトバックログの項目をチームが理解できるレベル
にする
94

スプリントの中止
‣ プロダクトオーナーだけが中止させる権限を持つ
- スプリントゴールが世の中にマッチしなくなった場合
- スケジュールが全然守れそうにない場合
‣ 何をするか
- Doneになったものを確認する
- Doneになっていないものは再見積もりをしてプロダクト
バックログに戻す
95

(c)+KAME
‣ 作業する役割
- プロダクトバックログ項目をソフトウェアとして実現する
- クロスファンクショナル
- ドメインに特化したサブチームはいない
開発チーム
96

‣ やること
- 動くソフトウェアを作る
開発チーム
DB出力
ToDo Doing Done
Ajaxの実装
画面の表示
“Done!”
ログインする
商品をリストする
オススメを表示する
買い物かごに入れる
オーダーを決定する
クレジットカードで
決済する
コンビニ決済する
“Ready!”
Software
97
(c)+KAME

自己組織化する
‣ 最適な人数は6 3人
‣ 効率と効果を獲得するしくみ
- 自分たちで課題を解決する
- 知恵を出しあって相互作用する
- ゴールに到達するために行うすべてのことの権限を持つ
‣ メンバー構成が変われば生産性は変わる
98

開発チーム
‣ 動くソフトウェアを作るためには何をやってもいい！
- スクラムマスターを雇う
- スクラムマスターを解雇できる
99

(C)+KAME
スクラムマスター
‣ やること
- スクラムチームがスクラムを理解し、プラクティスやルー
ルを守ってもらうようにする
100

(C)+KAME
‣ やること：プロダクトオーナーを支援する
- プロダクトバックログの効率的な管理方法を探す
- 開発チームに言ってわかりやすいプロダクトバックログ項
目を作ってもらう
- 経験主義の中での長期にわたるプロダクト計画を理解する
- アジャイルを理解し実践する
- 状況に応じてスクラムイベントをファシリテートする
101

‣ やること：開発チームを支援する
- 自己組織化と機能横断についてコーチする
- 高価値のプロダクトを作る方法を教育し指導する
- 開発チームの進捗の妨げになるものを排除する
- 状況に応じてスクラムイベントをファシリテートする
- スクラムがまだ完全に適用、理解されていない現場でコー
チする
102
(C)+KAME

‣ やること：組織を支援する
- スクラムの採用と導入について指導、コーチする
- スクラムの推進を計画する
- スクラムや経験主義的プロダクト開発について社員や関
係者に理解してもらう
- スクラムチームの生産性を高めるような変化を促す
- 他のスクラムマスターと一緒になって、スクラムの組織
への導入効果を高める
103
(C)+KAME

(C)+KAME
‣ スクラムマスターは、スクラムチームにとってのサーヴァン
ト・リーダー
傾聴
共感
癒し
気づき
説得
概念化
先見力
スチュワード
シップ人の成長に関
わる
コミュニティ
作り
104

(C)+KAME
スクラム以前のマネージャ
‣ プロダクトオーナーに移行するには
- プロダクトマネージャは向いてるかも
- プロジェクトマネージャも向いてるかも
105

(C)+KAME
スクラム以前のマネージャ
‣ スクラムマスターに移行するには
- 分担(アサイン)を決めるのをやめる
- 報告を上げさせるのをやめる
- 問題解決策を決めることをやめる
- チームに指示することをやめる
俺の出番が
ないぞ…
106

by+Jeff+Sutherland
スクラム以前のロール
チーフ
プロダクト
オーナー
チーム
プロダクト
オーナー
スクラム
マスター
支援ロールチーム
プロダクトマネージャ
プロジェクトマネージャ
ビジネスアナリスト
プログラムマネージャ
管理職／ラインマネージャ
顧客
テスター
アーキテクト
開発者
UCD (UXデザイナー)
テクニカルライター
DB管理者
運用担当者
107

スクラム以前のロール
チーフ
プロダクト
オーナー
チーム
プロダクト
オーナー
スクラム
マスター
支援ロールチーム
プロダクトマネージャ ○ ○
プロジェクトマネージャ ○ ○ ○
ビジネスアナリスト ○ ○ ○ ○
プログラムマネージャ ○ ○
管理職／ラインマネージャ ○ ○ ○ ○
顧客 ○ ○ ○
テスター ○ ○
アーキテクト ○ ○
開発者 ○ ○
UCD (UXデザイナー) ○ ○
テクニカルライター ○ ○
DB管理者 ○ ○
運用担当者 ○ ○
108
by+Jeff+Sutherland

(C)+KAME
ロールの兼任
‣ スクラムマスターかつプロダクトオーナー
- 健全な利害対立が必要
- つまりかなり無理
あの人どっちの
立場なんだろ…
109

ロールの兼任
‣ プロダクトオーナーかつチーム
ステークホルダーと
調整する
時間がないなあ…
タスクもやらなきゃ…
110
(C)+KAME

ロールの兼任
‣ スクラムマスターかつチーム
のプレッシャーから
守らなきゃ…
タスクも
やらなきゃ…
111
(C)+KAME

結論：兼任はしないほうがいい
‣ 帽子の色分けを相当はっきりとする必要がある
‣ スクラムチームが成熟してないとかなり無理
112
応用は基本ができてから

Agenda
開発チーム
113

教科書と参考図書
114
http://bit.ly/scrumbcbook http://www.scrum.org/Scrum-Guides

質疑応答
115

今日やること
第1回
Agile/Scrum概要
第2回
講義「チームで協働する」
演習
116

今日やること
第1回
Agile/Scrum概要
第2回
講義「チームで協働する」
演習
117

本日の課題(レポート)
118
Scrumの全体像を表す一枚絵を
あなたの理解で書いてください

Agile-development-course-advanced-1-2

More Related Content

What's hot

Viewers also liked

Similar to Agile-development-course-advanced-1-2

More from Miho Nagase

Agile-development-course-advanced-1-2