Recommended
More Related Content
Similar to 名古屋アジャイル勉強会「XPから学ぶアジャイル」
Similar to 名古屋アジャイル勉強会「XPから学ぶアジャイル」 (20)
More from hiroyuki Yamamoto
More from hiroyuki Yamamoto (20)
名古屋アジャイル勉強会「XPから学ぶアジャイル」
- 2. 講師自己紹介 山本 博之（やまもと ひろゆき）：yama__moto@twitter ● ITベンダー子会社勤務のSE/PG。 ● 親会社のソフトウェア製品の導入やカスタマイズ、テクニカル サポートを行っています。 ● XPとの出会いは2002年頃だと思うんですけど、英和システム マネジメントの平鍋さんが作った「eXtreme programming FAQ」をたまたま見つけて読んだことです。すごい衝撃を受け ました。 2 XP FAQ: http://objectclub.jp/community/XP-jp/xp_relate/xp-faq
- 5. アジェンダ ● 自己紹介 ● XPとは ● XPの特徴 ● XPのプラクティス、価値、原則 ● ワーク：価値、原則、プラクティスの感想共有 ● XPは語彙だとして、語彙でなにができるか ● スクラムとカンバン ● XPとスクラムやカンバンとの関係 ● プラクティスは自分たちで作ってもいい？ ● ワーク：プラクティスによる問題解決 ● まとめ 5
- 6. 自己紹介 みなさんにテーブル内で自己紹介をしていただきます。 A3コピー用紙に以下を書いてください。 ● お名前（呼ばれたいお名前でかまいません） ● お仕事（話せる範囲でかまいません） ● 今日この勉強会に参加された動機 みんなが書けたら、順番に紙を見せながら自己紹介してください。 6
- 11. XPのプラクティス ● 全員同席 ● チーム全体 ● 情報満載のワークスペー ス ● いきいきとした仕事 ● ペアプログラミング ● ストーリー ● 週次サイクル 11 ● 四半期サイクル ● ゆとり ● 10分間ビルド ● 継続的インテグレーション ● テストファーストプログラミ ング ● インクリメンタルな設計
- 12. XPのプラクティス ● 本物の顧客参加 ● インクリメンタルなデプロイ ● チームの継続 ● チームの縮小 ● 根本原因分析 ● コードの共有 12 ● コードとテスト ● 単一のコードベース ● デイリーデプロイ ● 交渉によるスコープ契約 ● 利用都度課金
- 13. XPの5つの価値 根源的な価値観。判断や行動に目的を与えます。 ● コミュニケーション 多くの問題はコミュニケーション不全から起こる。 ● シンプルさ うまくいくなかで最もシンプルなものを選ぶ。 ● フィードバック 学びを得てよりよくする、変化に対応する。 ● 勇気 勇気を尊び、それが発揮できる環境を指向する。 ● 尊敬 基盤は人間関係であり、それを成り立たせるもの。 13
- 14. XPの14の原則 ● 人間性 人の弱さを認め強さを活 用する。 ● 経済性 ビジネスゴールを達成し、 ビジネスニーズを満たす。 ● 相互利益 関係者全員の利益になる ようにする。 14 ● 自己相似性 うまくいった行いの構造を 活用する。 ● 改善 始めから完璧を求めず、 継続的によりよくする。 ● 多様性 さまざまなスキル、考え 方、視点を組み合わせる。 価値とプラクティスをつなぎ合わせる指針です。
- 15. XPの14の原則 ● ふりかえり 結果を分析して学ぶ ● 流れ 間欠的な大きな成果より も途切れない成果 ● 機会 問題は変化の機会 ● 冗長性 複数の方法で問題を解決 し、失敗のリスクを抑える 15 ● 失敗 積極的に失敗から学ぶ ● 品質 品質を下げてもコストは減 らない ● ベイビーステップ 小さな変更の繰り返し ● 責任の引き受け 責任を外から割り当てるこ とはできない。引き受ける ことしかできない
- 23. ここまでの理解度確認 「表明じゃんけん」でここまでのみなさんの理解を確認させてくださ い。 ● 完璧に理解した：パー ● だいたい分かった：チョキ ● 全然分からない：グー せーの、で上記のいずれかを出してください。せーの！ 質問、ご意見などあればお願いします？ 23
- 26. ソフトウェア開発現場でしばしば発生する問題 1. スケジュールが遅延している 2. 不採算プロジェクトを損失少なく打ち切りたい 3. システムの保守が重荷になる 4. 欠陥率が高い 5. 移行フェーズで要件理解の食い違いが発覚する 6. 開発中にビジネス状況が変化し要件が変わった 7. 使わない機能ばかり作っている 8. 開発メンバーのモチベーションが低い 9. 作業の属人化が進んでいる 10. 手戻りが多すぎる 26
- 27. まとめ ● XPは圧倒的なソフトウェア開発によって自己実現とビジネス 貢献するアジャイルソフトウェア開発手法です。 ● アジャイルな開発の語彙というべきプラクティス、それらの言 葉遣いたる価値・原則から構成されます。 ● スクラムやカンバンと組み合わせて使われます。 ● プラクティスはXPの書籍に書かれているもの以外にもたくさん あるし、みなさんの現場にもあります。知見を語彙として共有し 対話していきましょう。 27
- 28. ここまでの理解度確認 「表明じゃんけん」でここまでのみなさんの理解を確認させてくださ い。 ● 完璧に理解した：パー ● だいたい分かった：チョキ ● 全然分からない：グー せーの、で上記のいずれかを出してください。せーの！ 質問、ご意見などあればお願いします？ 28
- 29. 参考文献 ● エクストリームプログラミング K・ベック著、角征典訳、オーム社刊 ● パターン、Wiki、XP 江渡浩一郎著 ● スクラムガイド K・シュワバー＆J・サザーランド著、角征典訳 ● リーン開発の現場 H・クニバーグ著、角谷信太郎監訳 29
- 30. プラクティスの概要 ● 全員同席 チーム全体が入れる十分な広さの オープンスペースで開発すること。 ● チーム全体 プロジェクトの成功に必要なスキル や視点を持った人たちをチームに 集めること。 ● 情報満載のワークスペース 仕事の内容や状況がひと目でわか るようなワークスペースを作ること。 ● いきいきとした仕事 生産的になれる時間範囲内で働く こと。 30 ● ペアプログラミング 同じマシンを前にした二人でプログ ラムを書くこと。プログラムを書く作 業・時間のなかに、意見交換、アイ デアの明確化、手助け、助言、知 識の共有を持ち込むこと。 ● ストーリー 顧客に見える機能の単位を使って 計画すること。顧客に見える機能、 意味ある単位をストーリーと呼ぶ。
- 31. プラクティスの概要 ● 週次サイクル 一週間分の仕事の計画をまとめて 立てること。そのための毎週のミー ティングでは ○ 進捗状況をレビューする。今 週実装する一週間分のストー リーを決める（顧客に選んでも らう）。 ○ ストーリーをタスクに分解す る。 ○ タスクを見積もる。 31 ● 四半期サイクル 四半期分の計画をまとめて立てる こと。四半期に一度は、チーム、プ ロジェクト、進捗、大きなゴールに ついてふりかえること。 ● ゆとり どのような計画にも、遅れたときに 外せるような重要度の低いアイテ ムを含めること（回復のためにそれ らを計画から落とす）。 ● 10分間ビルド 自動的にシステム全体をビルドし て、すべてのテストを10分以内に 実行させること。
- 32. プラクティスの概要 ● 継続的インテグレーション 変更はそれごとにすばやくインテグ レーションしテストすること。 ● テストファーストプログラミング コードを変更する前に、自動テスト を書くこと。コードを変更する前にテ ストを実行し失敗することを確認 し、そのテストが成功する最もシン プルな変更を実装すること。 32 ● インクリメンタルな設計 システムの設計を漸進的に変化さ せていくこと。そのときのシステム のニーズに合致させること。事前に 盛り込みすぎないこと。シンプルか つ清潔に保つこと。
- 33. プラクティスの概要 ● 本物の顧客参加 開発対象のプロダクト/システムに よって生活やビジネスに影響を受 ける人（顧客）をチームの一員にす ること。 ● インクリメンタルなデプロイ システム変更の本番環境への投入 は、少しずつ繰り返し行うこと。 ● チームの継続 優秀なチームは継続させること。 33 ● チームの縮小 チームの能力が高まったら、より大 きな仕事量をこなすようにさせるよ りも、仕事量を維持しながら少しず つチームの規模を縮小すること。 チームを離れた人はまた別のチー ムを作ることができる。 ● 根本原因分析 欠陥が見つかるたびに、欠陥とそ の原因を取り除くこと。同じ結果の 再発防止だけでなく、同じ種類の過 ちをチームが二度と侵さないように すること。
- 34. プラクティスの概要 ● コードの共有 チームの誰もが、システムのあらゆ る部分をいつでも改善できる、その ような環境を用意し用いること。 ● コードとテスト コードとテストだけを第一級の作成 物として保守すること。それら以外 のドキュメントはできるかぎりコード とテストから生成すること。 ● 単一のコードベース コードの流れ（ブランチ）はひとつだ け。一時的なブランチを用いてもよ いがすみやかにマージすること。 34 ● デイリーデプロイ 新しいソフトウェアを毎日プロダク ションに反映すること。 ● 交渉によるスコープ契約 ソフトウェア開発の契約では、期 間、費用、品質を固定し、スコープ は継続的に交渉すること。長期的 なひとつの契約よりも短期的な契 約をいくつも結ぶこと。 ● 利用都度課金 システムを利用するたびに課金が 発生する仕組みを用いること。シス テムの価値を直接的に測りフィード バックを得ることができる。