20151127 agile japanpreseminar_公開用

（株）豆蔵

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved1

中佐藤麻記子（なかさとまきこ）

本トレーニングテキストの一部または全部を著作権法の定める範囲を超え、無断で複写、複製、転載、テープ化、ファイル化することを禁じます。

アジャイルジャパン・プレイベント企画

アジャイル初心者向けセミナー

2015/11/27

Copyright © 2015 MAMEZOU Co., LTD. All rights reserved

セミナープログラム

13:00 ～ 15:00 　：　初心者向け講義

15:10 ～ 17:40 　：　事例発表（ 4 トラック × 4 コマ）

17:45 ～ 18:00 　：　ふりかえり

18:10 ～ 19:30 　：　交流会

2


感謝

Thanks to　　 NEC ソリューションイノベータ様

Thanks to　　ファシリテーション担当の方々

3


このセミナーの背景

Agile Japan 2016 の「プレイベント」です

「アジャイルに詳しくない人こそ Agile Japan に来てほしい」という思いで始めました

行ったことのない外部セミナー参加に不安を覚える方に雰囲気に慣れていただく意味もあります

4

前回も参加された方は？


ところで

5

宿題しましたよね？実行委員長の和田さんからのメール内：

　“事前にスクラムガイド（日本語版）をお読みください（全17 ページ）。　このガイドを一読されていることを前提に、講義・事例発表をします。”


初心者向け講義のアジェンダ

セクション１：　アジャイルとは

セクション２：　事例について

セクション３：　 Agile Japan 2016 のテーマ

6


セクション１

7

アジャイルとは


アジャイルソフトウェア開発宣言（アジャイルマニフェスト）

私たちは、ソフトウェア開発の実践あるいは実践を手助けをする活動を通じて、よりよい開発方法を見つけだそうとしている。この活動を通して、私たちは以下の価値に

至った。

プロセスやツールよりも個人と対話を、

包括的なドキュメントよりも動くソフトウェアを、

契約交渉よりも顧客との協調を、

計画に従うことよりも変化への対応を、

価値とする。すなわち、左記のことがらに価値があることを認めながらも、私たちは右記のことがらにより価値をおく。

Kent Beck James Grenning Robert C. Martin Mike Beedle Jim Highsmith Steve Mellor Arie van Bennekum Andrew Hunt Ken Schwaber Alistair Cockburn Ron Jeffries Jeff Sutherland Ward Cunningham Jon Kern Dave Thomas Martin Fowler Brian Marick

© 2001, 上記の著者たちこの宣言は、この注意書きも含めた形で全文を含めることを条件に自由にコピーしてよい。 8


さまざまなアジャイル開発手法

エクストリーム・プログラミング（ Extreme Programming: XP ）

スクラム（ Scrum ）クリスタル（ Crystal ）フィーチャ駆動開発（ Feature Driven

Development: FDD ）適応型ソフトウェア開発

（ Adaptive Software Development: ASD ）

達人プログラマ（ Pragmatic Programmer ） Dynamic Systems Development Method:

DSDM Executable UML

など

9


エクストリーム・プログラミング（ XP ）

皆さんが（もしかしたら）ご存じの　テスト駆動開発（ TDD ）とか、リファクタリングと

か、　継続的インテグレーション（ CI ）とか、　顧客同席とか、ペアプログラミングとか、

　を、最初に言った手法

10

プラクティス

<<interface>>価値

コミュニケーションフィードバックシンプリシティ勇気

価値

プラクティス

＋リスペクト


プラクティス一覧

主要プラクティス全員同席チーム全体情報満載のワークスペースいきいきとした仕事ペアプログラミングストーリー週次サイクル四半期サイクルゆとり 10分ビルド継続的インテグレーションテストファーストプログラミン

グインクリメンタルな設計

11

導出プラクティス本物の顧客参加インクリメンタルなデプロイチームの継続チームの縮小根本原因分析コードの共有コードとテスト単一のコードベースデイリーデプロイ交渉によるスコープ契約利用都度課金

など


アジャイルプラクティスメトロマップ

12

アジャイルプラクティスメトロマップ


アジャイルプラクティスメトロマップ（表）

13

別途公開予定


アジャイルプラクティスメトロマップ（裏）

14

別途公開予定


イテレーション

イテレーション（スクラム用語：スプリント）開発期間を一定の期間に区切って、開発作業を反復的に

行う通常１イテレーション＝１週間から３か月

15


・・・イテレーショ

ンイテレーショ

ン

１イテレーション内で、要件分析から実装・テストまで、

すべての開発作業を行う

イテレーションの終わりには、ユーザーから見て分かる成果物をリリースする


会議体

計画会議（スクラム用語：スプリントプランニング）レビュー会議（スクラム用語：スプリントレビュー）レトロスペクティブ（ふりかえり）日次スタンドアップミーティング（朝会、スクラム用語：デイリースクラム）

16計

画会議

日次スタンドアップ

ミーティング


ミーティング


ミーティング

レビ

ュー

会議

レト

ロス

ペク

ティブ


Copyright © 2015 MAMEZOU Co., LTD. All rights reserved17

ストーリーリスト（スクラム用語：プロダクトバックログ）

：：

ストーリー

ユーザーストーリーとも呼ぶ要件リスト

イテレーションごとの計画会議でこの中のどれを対象にするかを決める


では

18

じゃあやってみよう！


そもそも

19

なんでアジャイル？


ウォーターフォール開発の問題？

Input Process Output

20

入力が正しいこと

設定されたゴールが正しいこと

途中に落とし穴が

ないこと

階層化されたプロセスにおいて 100%正しく IPO がつな

がっていること


計画型 vs 適応型

21

ウォーターフォール

アジャイル

スタート

ゴール

スタート

ゴール

初めにキッチリ決めて、その通りに

やろうとする

作るものだけでなく、

やり方そのものも

試行錯誤する


継続的～～

アジャイルは

計画を立て続けます要件定義をし続けます設計をし続けます実装をし続けますテストをし続けますプロセスを変更し続けます

22


立ち戻って

23

「価値」の意味とは


価値とプラクティスの関係

24

コミュニケーションフィードバックシンプリシティ勇気

プラクティス

<<interface>>価値価値

プラクティス


コミュニケーション

チームによるソフトウェア開発で最も重要なのは、コミュニケーション

25

顧客リーダー

開発者開発者

システム


フィードバック

26


日次

チームの進捗を毎日確認す

る

成果物や手法を頻繁に見直し、改善する

製品のビジネス的な妥当性を確認する

リリース



構成管理、 CI 、テスト、リファクタリングを組み合わせることで、継続的に設計を進化させていく環境を作ることができる TDD で最低限のテストと実装が維持される CI によってシステム全体の中で自分が作成したコンポーネントに問題が

ないかが分かるテストの存在と CI がリファクタリングのセーフティネットになる

27

SCMサーバー

CIサーバー

コード（実装・テスト）コミット

ビルド・テスト・インスペクションの結果を通知

・テスト駆動開発・リファクタリング

・構成管理

・継続的　インテグレーション


シンプリシティ

よりシンプルなものを選ぶ

※ 文書／口頭、どちらがシンプルなコミュニケーション？※ デザインパターンを使う／使わない、どちらがシンプルな設計？

28

シンプルな

コミュニケーション


設計


勇気

アクションを起こすための勇気／勇気を持てる仕組み悪い情報が外に出てこなければフィードバックサイクル

は回らない

29

顧客リーダー

開発者開発者

システム

嘘のないコミュニケー

ション

現実を受けとめる

システムをシンプルに保

つ


リスペクト

互いのリスペクト／めざすもの（プロジェクト）に対するリスペクト

30

ゴール


セクション２

31

事例について


事例の聴き方：事例聞きたい病

32

「事例聞きたい」病

対処療法として事例を聞かせると・・・

「でもうちの会社では」病


事例の聴き方：銀の弾丸

33

アジャイルはポンと一式導入すればどの会社でもうまくいく魔法の手法ではないし、そんなものは世の中に

存在しない


事例の聴き方：なんのため

34

では、事例紹介はなんのため？


事例の聴き方：事例の意義

「私の会社では、これがうまくいきませんでした」「うちのチームでは、朝会に 1時間かけています」「この手法は、今回は効果的でした」「このツールは一度トライして、やめました」「インセプションデッキは、とても役立ちました」「 TDD の導入は大変でした」「こういう契約形態でやりました」

35

：：

他の会社／組織／チームでの試行錯誤の経過となぜそうしたか／なぜそうしなかった

かを共有してもらえる機会


THINK

36

プラクティス

<<interface>>価値価値

プラクティス

事例はこれ

そのチームが

なぜそうしたかを読み取る

自分たちが重視すべきものを考え

る

自分たちが何ができる

か考える

コピー×


ベテランさんへのお願い

• 今回は発表者も初心者が多いです

• 誰でも「初めて」はあります

• 優しく質問してあげてください

37


セクション３

38

テーマについて


Agile Japan 2016 のテーマ

39

“ あなたとつくるアジャイル”



40

あなた



41

つくる


お待ちしています

42

Agile Japan 2016 でお会いしましょう

“ あなたとつくるアジャイル”

2016年 5月 31 日 (火 )@浅草橋ヒューリックホール