2012年 はじめてのアジャイル

1.4K Views

March 24, 22

スライド概要

アジャイルプロセス協議会でお話しした内容です。

profile-image

木村 卓央(Takao Kimura) 合同会社カナタク 代表社員/アジャイルコーチ 2003年頃にアジャイルに出会い、アジャイルコミュニティへの参加を通してアジャイルを学び。個人や小さいチームでアジャイルの実践を行ってきた。 2009年よりスクラムマスターとして経験を積み、2012年にはアジャイルコーチとして、他社へのアジャイル導入支援や、アジャイル研修などを行っている。 LeSS Study主催 Agile Discussion!!主催 Fearless Change アジャイルに効くアイデアを広めるための48のパターン 共訳 大規模スクラム Large-Scale Scrum(LeSS) アジャイルとスクラムを大規模に実装する方法 共訳

シェア

埋め込む »CMSなどでJSが使えない場合

関連スライド

各ページのテキスト
1.

はじめてのアジャイル ©2012 atWare,Inc flickr glennia

2.

自己紹介 株式会社 アットウェア 木村 卓央 KIMURA Takao tw̲takubon http://facebook.com/kimura.takao ©2012 atWare,Inc

3.

アジャイルプロセス協議会 • 2004/3 アジャイルプロセス協議会 アジャイル プロジェクトマネジメントWG (APMWG) 参加 • 2010 アジャイルプロセス協議会会報誌に執筆 • 超訳!? クリスタルクリア(第二回) ©2012 atWare,Inc

4.

今日お話すること •アジャイルとは? •アジャイルな開発のはじめ方 ©2012 atWare,Inc flickr soma-samui.com

5.

アジャイルとは? ©2012 atWare,Inc flickr Paul Hedges

6.

最近アジャイルって聞くようになりましたね。 ©2012 atWare,Inc http://www.nttdata.com/jp/ja/news/release/2012/041700.html

7.

3つの真実 1.プロジェクトの開始時点にすべて の要求を集めることは出来ない 2.集めたところで、要求はどれも必 ずといっていいほど変わる 3.やるべきことはいつだって、与え られた時間と資金より多い ©2012 atWare,Inc

8.

SEC Software Engineering for Mo No Zu Ku Ri No.1 No.2 No.3 … 1. 2. 3. 25% 63% Copyright © 2012 IPA, All Rights Reserved. 12% Software Engineering Center 10 「非ウォーターフォール型開発の普及要因と適用領域の拡大に関する調査」調査概要報告書 http://sec.ipa.go.jp/reports/20120328.html ©2012 atWare,Inc

9.

機能の利用度 ©2012 atWare,Inc

10.

アジャイルとは 迅速かつ適応的にソフトウェア開発を行う 軽量な開発手法群の総称 ©2012 atWare,Inc

11.

アジャイルソフトウェア開発宣言 ©2012 atWare,Inc http://agilemanifesto.org/iso/ja/

12.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

13.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 顧客満足を最優先し、価値のあるソフトウェアを 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 早く継続的に提供します。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

14.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 お客様の競争力を引き上げます。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

15.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で リリースします。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

16.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

17.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで 彼らを信頼します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

18.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 情報を伝える最も効率的で効果的な方法は ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 フェイス・トゥ・フェイスで話 をすることです。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

19.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 動くソフトウェアこそが進捗の最も重要な尺度です。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

20.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 アジャイル・プロセスは持続可能な開発を促進します。 一定のペースを継続的に維持できるように しなければなりません。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

21.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 技術的卓越性と優れた設計に対する 不断の注意が機敏さを高めます ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

22.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 シンプルさ(ムダなく作れる量を最大限にすること) が本質です。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

23.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 最良のアーキテクチャ、要求、設計は 自己組織的なチームから生み出されます。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

24.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 チームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

25.

重要なこと 顧客満足を最優先し、価値のあるソフトウェアを 早く継続的に提供します。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、 お客様の競争力を引き上げます。 チームがもっと効率を高めることができるかを 定期的に振り返り、 それに基づいて自分たちのやり方を最適に調整します。 ©2012 atWare,Inc

26.

誤解 早いの〜、うまいの〜、安いの〜 ©2012 atWare,Inc

27.

誤解 •設計しない? •ドキュメントを書かない? •計画を立てない? •いつでも仕様変更出来るよね? ©2012 atWare,Inc

28.

アジャイルやってます ビジネス/ユーザー プロセス 利用者満足 仕様 Lean UX ATDD,BDD チーム活動 技術プラクティス Scrum CI,TDD Metrics Delivery テスト,品質 計測 スムーズなリリース E-Agility Conference 2012 To be an agile enterprise 〜 楽天でのふつうのアジャイル・アダプションの進め方 楽天 川口さん https://speakerdeck.com/u/kawaguti/p/eagility ©2012 atWare,Inc

29.

問題を解決する手法ではない •問題を早期に発見しやすくする • The Scrum Team The Product Owner The Scrum Master The Development Team Scrum Board Burndown Chart Definition of “Done” Product Backlog Sprint Backlog Increment ©2012 atWare,Inc

30.

Agileとは? be Agile ©2012 atWare,Inc

31.

アジャイル開発手法の種類 http://www.versionone.com/state̲of̲agile̲development̲survey/11/ ©2012 atWare,Inc

32.

アジャイルな開発のはじめ方 ©2012 atWare,Inc flickr glennia

33.

アジャイルコーチに来てもらう ©2012 atWare,Inc flickr somecanuckchick

34.

自力でがんばる flickr SURF&ROCK (Miguel Navaza) ©2012 atWare,Inc

35.

出来るところにお願いする flickr Michael Dawes ©2012 atWare,Inc

36.

©2012 atWare,Inc flickr tomplunkett

37.

©2012 atWare,Inc flickr Form<->Function

38.

アジャイルな開発のはじめ方 ©2012 atWare,Inc flickr fraggy

39.

ユーザー企業 織田さん 情報システム部に所属 開発はベンダーに依頼している 携帯向けサービスプロジェクトを担当 趣味は自転車 昨今のビジネススピードに対応すべく アジャイルに開発を⾏行行いたい ©2012 atWare,Inc

40.

Scrumから始めましょう The Scrum Team The Product Owner The Scrum Master The Development Team Scrum Board Burndown Chart Definition of “Done” Product Backlog Sprint Backlog Increment ©2012 atWare,Inc

41.

スクラムチーム ユーザー企業 プロダクトオーナー 開発ベンダー 開発チーム 第三者 スクラムマスター ©2012 atWare,Inc アジャイル コーチ

42.

我われはなぜここにいるのか • 大事な理由その1 エレベーターピッチ パッケージデザイン • [潜在的なニーズを満たしたり、 潜在的な課題を解決したり] したい (プロダクトの名前) • [対象顧客] 向けの、 • 大事な理由その2 • [プロダクト名] というプロダクトは、 • 大事な理由その3 (素敵な写真) • [プロダクトのカテゴリー] です。 <このプロジェクトの根幹に 関わる理由を1つ、ここに書く> やらないことリスト • これは [重要な利点、対価に見合う説得力のある 理由] ができ、 (最高のキャッチコピー) (ユーザーへのアピールその1) • [代替手段の最右翼] とは違って、 (ユーザーへのアピールその2) • [差別化の決定的な特徴] が備わっている。 (ユーザーへのアピールその3) プロジェクトコミュニティは... やる やらない (ほげほげ部門) (他のチーム) コアチーム 関係者全員を! あとで决める (○○グループ) ...思っているよりもずっと大きい! 技術的な解決策の概要 インセプションデッキ 夜も眠れなくなるような問題は何だろう? • もし起きたらこわーいこと、その1 • もし起きたらこわーいこと、その2 • もし起きたらこわーいこと、その3 採用する技術: * <プログラミング言語> * <ライブラリ> * <ツール> * <その他の要素技術> 期間を見極める リリース! 構築 受入テスト トレーニング ~3ヶ月 1週間 1週間 あくまで推測であって、確約するものではありません。 ←リスクがある箇所 ←今回は対象外 トレードオフ・スライダー 典型的なフォース MAX MIN 機能をぜんぶ揃える(スコープ) MAX MIN 予算内に収める(予算) MAX MIN 期日を死守する(時間) MAX MIN 高い品質、少ない欠陥(品質) 上記以外で重要なこと MAX MIN 簡単に使える MAX MIN 考えさせない! MAX MIN 詳細な証跡(なんでもログを取る) MAX MIN (などなど) 俺たちの“Aチーム” 人数 役割 強みや期待すること 1 アナリスト 必要な分だけ必要なときに分析するスタイルで働ける。 テストも喜んで手伝える。 素早い繰り返し型の開発スタイルで働ける。 2 開発者 C#、MVC.NET、jQuery、SQL ユニットテスト、リファクタリング、TDD、 継続的インテグレーション 0.5 マネージャ 顧客と直接顔を合わせてのコミュニケーションを担当する。 状況報告、スコープ調整、予算管理、レポートラインへの報告 ©2012 atWare,Inc

43.

プロダクトオーナーとしての責務 •プロダクトバックログは優先順位順 に並べる •優先順位の高いバックログアイテム は開発チームが理解出来るほど詳細 か •プロジェクトの為に毎日時間を割け るようにする •プロジェクトの決定を下せる ©2012 atWare,Inc

44.

最初の数スプリントは •開発チームが作られていく過程で重 要です •以降、安定したチームとなる事が理 想(なっていない場合はどこかに問 題がある) ©2012 atWare,Inc

45.

発注者側の不安 •アジャイルな開発は、開発チームの 自己組織化で運営していくけど、本 当に成果が出るの?期日には納品し てもらわないと困るのだけど。。。 ©2012 atWare,Inc

46.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 意欲に満ちた人々を集めてプロジェクトを構成します。 環境と支援を与え仕事が無事終わるまで 彼らを信頼します。 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 ビジネス側の人と開発者は、プロジェクトを通して 日々一緒に働かなければなりません。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

47.

SIer 佐々木さん システム開発部所属 社内の標準的な開発手法はウォーターフォール 会社としては、アジャイル開発手法にも力を入 れようとしている お客様満⾜足度度を上げる為に、開発を アジャイルに⾏行行いたい ©2012 atWare,Inc

48.

スクラムチーム お客様 開発ベンダー プロダクトオーナー 開発チーム 第三者 スクラムマスター ©2012 atWare,Inc アジャイル コーチ

49.

受注者側の不安 •アジャイルな開発では、最後まで変 更を受け入れると言うけど、結局、 今まで通り期日までに全て納品して って言われるんじゃないの ©2012 atWare,Inc

50.

原則 我々は以下の原則に従います: 我々は価値のあるソフトウェアを できるだけ早い段階から継続的に引き渡すことによって お客様の満足度を高めることをもっとも優先します。 要件の変更は例え開発の後期であっても受け入れます。 アジャイル・プロセスは変化を味方につけることによって お客様の競争力を引き上げます。 顧客満足を最優先し、価値のあるソフトウェアを 動くソフトウェアを 2~3週間から2~3ヶ月というできるだけ短い時間間隔で 繰り返し引き渡します。 早く継続的に提供します。 ビジネスをする人と開発者はプロジェクトを通して 日々一緒に働かなければなりません。 意欲に満ちた人々を集めてプロジェクトを構成します。 ですから彼らが必要とする環境と支援を与え 仕事が無事終わるまで彼らを信頼してください。 開発チームに対して、あるいは開発チーム内部で 情報を伝えるもっとも効率的で効果的な方法は 面と向かって話をすることです。 要求の変更はたとえ開発の後期であっても歓迎します。 変化を味方につけることによって、 動いているソフトウェアこそが進捗の最も重要な尺度です。 アジャイル・プロセスは持続可能な開発を促進します。 スポンサ、開発者、ユーザは一定のペースで 永続的に保守できるようにしなければなりません。 お客様の競争力を引き上げます。 卓越した技術と優れた設計に対する 不断の注意こそが機敏さを高めます。 単純さ - 作業せずに済む量を 最大限に引き上げる技量 - が本質です。 最良のアーキテクチャ、要件、設計は 自己組織的なチームから生み出されます。 どうしたらチームがもっと効率を高めることができるかを 定期的に振り返り、それに基づいて自分たちのやり方を 最適に調整します。 ©2012 atWare,Inc

51.

一開発者 吉田さん システム開発部所属 社内の標準的な開発手法はウォーターフォール 今回のセミナーで感銘を受けてアジャイル開発 手法を導入したいと考えている お客様満⾜足度度を上げる為に、開発を アジャイルに⾏行行いたい ©2012 atWare,Inc

52.

まずは一人でもはじめてみよう お客様 開発ベンダー 開発チーム ©2012 atWare,Inc

53.

始めやすい •ふりかえり •見える化 •タスクかんばん •バーンダウンチャート •インピーディメントリスト(障害 リスト) ©2012 atWare,Inc

54.

必ずやった方が良いプラクティス •ユニットテスト •リファクタリング •CI •TDD ©2012 atWare,Inc

55.

信頼関係が重要 ©2012 atWare,Inc

56.

アカウンタビリティー 「自分の意思で、現実を見つめ、問題に当事者 として取り組み、解決策を見出し、その解決策 を実行しようとする意識」 ©2012 atWare,Inc

57.

お話したこと ① •アジャイルとは? •アジャイルが話題になる理由 •価値と原則 •アジャイルについての誤解 ©2012 atWare,Inc

58.

お話したこと② •アジャイルな開発のはじめ方 •3つの方法 •はじめ方モデルケース •ユーザー企業として •SIerとして •開発者として •信頼関係が重要 •アカウンタビリティ ©2012 atWare,Inc

59.

参考書籍 http://www.scrum.org/scrumguides/ : 2011 Developed and sustained by Ken Schwaber and Jeff Sutherland http://www.infoq.com/jp/minibooks/scrum-xp-from-the-trenches ©2012 atWare,Inc

60.

参考書籍 ©2012 atWare,Inc

61.

コミュニティ #suc3rum http://www.taoofscrum.org/ #scrumdo #agilesamurai  #横浜道場 https://github.com/agile-‐‑‒samurai-‐‑‒ja/support/wiki/Readingagilesamuraiinyokohama ©2012 atWare,Inc

62.

regional 2013.1.15-16 at Akihabara UDX CONFERENCE 2012年10月上旬エントリー開始予定!! n e g r u J 氏 郎 次 郁 中 野 氏 o l e p p A . O s Jame 氏 n e i l p Co Scrum Alliance Regional Gathering - Tokyo - 2013 http://www.scrumgatheringtokyo.org/ #sgt2013 @ScrumTokyo 主催 : Scrum Regional Gathering Tokyo 2013 実行委員会 / 共催 : 株式会社翔泳社

64.

ご清聴ありがとうございました ©2012 atWare,Inc