Weitere ähnliche Inhalte
Ähnlich wie とりあえず30分でひととおり分かった気にはなれるアジャイル入門 (20)
とりあえず30分でひととおり分かった気にはなれるアジャイル入門
- 2. 自己紹介
滝川 陽一(たきがわ よういち)… takigawa401
• 1978年07月26日生 (34歳05ヶ月)
• 長野県飯田市近辺出身、東京在住
• 「技術コンサルG」という の組織に所属
• RIA、モバイル(スマートデバイス) 、アジャイル
• ブログ :ミッションたぶんPossible
• FC東京/中日ドラゴンズ/松本山雅
• 特記 :これがこの会社での最後のプレゼンです
- 10. 対象者
n アジャイルって最近良く聞くけど全然分か
んなくって…。
n そもそもウォーターフォールだって良く分
かんないのに新しいこと覚えたくない!!
n アジャイルって、ドキュメント書かないん
でしょ?
n アジャイルで開発すると早くて安く上がる
らしいじゃん?
n アジャイルだと大規模開発できないだろ?
n アジャイルなんて失敗多いもの採用出来る
か!
- 11. 対象者
n
ってアジャイルって最近良く聞くけど全然分か
か
んなくって…。
か
n そもそもウォーターフォールだって良く分
かんないのに新しいこと覚えたくない!!
!
n アジャイルって、ドキュメント書かないん
!
でしょ?
い
n アジャイルで開発すると早くて安く上がる
こ
らしいじゃん?
n アジャイルだと大規模開発できないだろ?
n アジャイルなんて失敗多いもの採用出来る
か!
- 28. アジャイル宣言の背後にある原則
私たちは以下の原則に従う:
1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。
2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お
客様の競争力を引き上げます。
3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。
4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。
5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるま
で彼らを信頼します。
6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。
7. 動くソフトウェアこそが進 の最も重要な尺度です。
8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるよう
にしなければなりません。
9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。
10. シンプルさ(ムダなく作れる量を最大限にすること)が本質です。
11. 最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。
12. チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちの
やり方を最適に調整します。
アジャイル宣⾔言の背後にある原則 http://agilemanifesto.org/iso/ja/principles.html
- 41. メリット
n 要求定義の工数見積に従って一括請負契約
を結ぶことができる
n 承認プロセスが明確であるため責任の所在
が明確である
n プロジェクト参加者が担う役割は固定的で
考える事が少ない(低スキルの技術者でも
参画し易い)
- 43. デメリット
n 開発途中での仕様変更に対応しきれない
n 仮説に基づいた要件にならざるを得ない
n システムの実物を確認出来るになるまでの
時間が長い
n 終盤にならなければ仮説の検証を行えない
n ひとつひとつの工程が長すぎる
n 前工程の成果物は完全であることを前提と
するため、誤りが発生した際手戻りが発生
する
- 49. 5つの価値
n コミュニケーション
n シンプル
n フィードバック
n 勇気
n 尊重
5つの価値は19のプラクティスに影響を与え、
XPの根幹を為す
- 57. 1993年、ジェフ・サザーラ
ンドら3名がラウンドトリッ
プ・エンジニアリング(一種の反
復型開発)を取り入れたオブジェ
クト指向プログラミング設計・
分析ツールを構築したのが最初。
当時、素早い開発が求められて
おり、要求仕様を簡単に動作す
るコードに変換する方法が求められていた。同じ頃、ケン・シュ
エイバーが自社(ADM)でのソフトウェア開発にこの手法を用い
た。
スクラム的手法を以前から活用していた企業として、富士ゼ
ロックス、キヤノン、(中略)などがある。これらのプロジェクト
については、一橋大学の野中郁次郎と竹内弘高が Harvard
Business Review 誌に 「The New New Product
Development Game」として発表している(1986年1-2月)。
スクラム (ソフトウェア開発) -‐‑‒ Wikipedia http://buff.ly/T8Cayk
- 62. プロダクトオーナー(PO)
製品の総責任者。 お
客様の意思の代表とし
ての役割を担う。ビジ
ネス視点(ROI等)でプ
ロジェクトに問題がな
い事を保障する役割を
持つ。顧客の要望に優
先順位を付ける。
スクラム (ソフトウェア開発) -‐‑‒ Wikipedia
http://buff.ly/T8Cayk
- 63. スクラムマスター(SM)
プロジェクトが円滑に
進むよう調整する。主
の作業はチーム内外の
ファシリテーションと
外部妨害を対処するこ
と。従来のPMの役割
を担う事が多いが、最
もプロジェクト管理責
任が少ない。
スクラム (ソフトウェア開発) -‐‑‒ Wikipedia
http://buff.ly/T8Cayk
- 64. チーム
各メンバーが協力し、全
体として同じゴールを目
指す。チームの人数は5
人から9人が適当とされ、
実装とテストの能力を持
つ。チームは作業プロセ
スと作業結果の責任も持
ち、自らチーム内の管理
を行う。
スクラム (ソフトウェア開発) -‐‑‒ Wikipedia
http://buff.ly/T8Cayk
- 65. 調整役
バランス
ビジネス要件
開発を実施 対立 を出す
往々にして対立しがち(協調出来るのが勿論望ましい)な
チームとPOの間を取り持ち、プロジェクトが円滑に進
むようにバランスを取るのがスクラムマスターの役割。
- 98. n 開発側に負担がかかり過
ぎる
n 評価軸が不確かな製品・
サービス
n ユーザーニーズの多様化
n ビジネススピードの加速
n アーキテクチャの複雑化
n etc…
- 115. 全員同席
開発チーム全員が同じ場所(同じ
ビル同じフロアの隣り合った席)
で一緒に仕事を行う。プロダク
トオーナーなども同様。
[Agile]Agile Buffet Cardを作りました – Ryuzee.com
http://www.ryuzee.com/contents/blog/4741
- 116. テスト駆動開発(TDD)
プロダクトのソースコードを書
く前にテストコードから書く。
プロダクトのソースコードはそ
のテストがクリア出来るように
記述する。
[Agile]Agile Buffet Cardを作りました – Ryuzee.com
http://www.ryuzee.com/contents/blog/4741
- 117. ペアプログラミング
二人一組で1台のPCを用いてプ
ロクグラミングを行う。TDD
と組み合わせて、1人がテスト
コードを、1人が実装を行う事
も。
[Agile]Agile Buffet Cardを作りました – Ryuzee.com
http://www.ryuzee.com/contents/blog/4741
- 118. 継続的インテグレーション
実装したソースコードを定期的
にテスト環境にデプロイしたり
自動テストにかけたりして開発
対象の品質を保つ事。Jenkins
などのツールを用いる事が一般
的。
[Agile]Agile Buffet Cardを作りました – Ryuzee.com
http://www.ryuzee.com/contents/blog/4741
- 119. 朝会
開発チーム全員が一同に会し、
短時間で進捗度合いや課題を共
有するミーティングを行う。
[Agile]Agile Buffet Cardを作りました – Ryuzee.com
http://www.ryuzee.com/contents/blog/4741
- 120. ふりかえり
イテレーションやプロジェクト
の終了時に開発チームで良かっ
た点反省点を出し、次の開発へ
繋げる改善案を話し合う。
[Agile]Agile Buffet Cardを作りました – Ryuzee.com
http://www.ryuzee.com/contents/blog/4741
- 121. Kanban
タスク毎に付箋に書き出し、ホ
ワイトボード等に貼って進捗状
況を可視化する。
[Agile]Agile Buffet Cardを作りました – Ryuzee.com
http://www.ryuzee.com/contents/blog/4741
- 122. リファクタリング
実装済みのソースコードを、よ
り読み易くシンプルに書き直す
ことで、メンテナンス性を高め
ておく。
[Agile]Agile Buffet Cardを作りました – Ryuzee.com
http://www.ryuzee.com/contents/blog/4741
- 123. コードの共有所有
CVSやSubversion、gitを
用いて、チームで開発中のソー
スコードやドキュメントを一元
管理する。メンテナンスはチー
ム全員で行うことを合意する。
[Agile]Agile Buffet Cardを作りました – Ryuzee.com
http://www.ryuzee.com/contents/blog/4741
- 124. ニコニコカレンダー
開発メンバーの体調や仕事の忙
しさをフェイスマークの表情で
可視化し、個々の状況をチーム
全員で把握し易くしておく。
ちはやふるの⽇日記 -‐‑‒ ゆるふわニコニコカレンダー
http://www.chihayafuru.jp/tdiary/?date=20090116