O slideshow foi denunciado.
Utilizamos seu perfil e dados de atividades no LinkedIn para personalizar e exibir anúncios mais relevantes. Altere suas preferências de anúncios quando desejar.

Xp入門 ~これで分かる!究極のxp入門~

611 visualizações

Publicada em

2016/06/24 に開催したセミナーの資料です。

Publicada em: Software
  • Seja o primeiro a comentar

Xp入門 ~これで分かる!究極のxp入門~

  1. 1. XP入門 ~これで分かる!究極のXP入門~ 2016年06月24日 日本XPユーザーグループ関西
  2. 2. 2 アジェンダ 1.自己紹介 2.本セミナー目的 3.XPの歴史 4.XPの基本思想 5.XPの開発プロセス 6.Q&A
  3. 3. 3 1.自己紹介
  4. 4. 4 【氏名】 西 丈善(にし たけよし) 1971年生まれ 【仕事】 組込系ソフトウェア開発 【スキル】 C、C++、オブジェクト指向、リファクタリング、デザインパターン、XP、PF 【コミュニティ】 ・「日本XPユーザーグループ関西」 副代表 ・「PFP関西」 スタッフ ・「IT技術者ダンス部」 主催
  5. 5. 5 宣伝!
  6. 6. 6 開発現場を変える エクストリーム・プログラミング入門 Share Wiz ACT 「開発現場を変える エクストリーム・プログラミング入門」 https://act.share-wis.com/courses/12 料金:3,000円 本日のセミナーのフルサイズ・バージョン を動画でご視聴頂けます。
  7. 7. 7 IT技術者向けパラパラ入門 Vol.2 日時:2016年7月2日 13:00 ~16:00 場所:AJITO 申込:Doorkeeper 47064 https://itdanceclub.doorkeeper.jp/events/47064 今回、運動不足がちなデスクワークの多いIT技術者の皆様へ向けて、「パ ラパラ」入門編を企画致しました。 パラパラに触れる事ができるこのチャンス、是非お見逃しなく。
  8. 8. 8 2.本セミナーの目的
  9. 9. 本セミナーの目的 1.「XP」の概要をご理解頂く。 2.「XP」と「WF」の大まかな差分をご理解頂く。 3.お時間の許す限り、皆様の疑問にお答えする。
  10. 10. 10 3.XPの歴史
  11. 11. 11 XPの歴史 • 最初にXPが実践されたのは「C3プロジェクト」。 • 危機的状況にあったC3プロジェクトを救うべく、過去に経験した 手法を最大限に実施。その結果、プロジェクトの建て直しに成功。 • この経験を元に、XP本を執筆。急速に拡大。 1996年 ケント・ベックがC3プロジェクトに携わる。 1999年 米国で『eXtreme Programming Explained』刊行。 2000年 日本で翻訳本『XPエクストリームプログラミング入門』刊行。
  12. 12. 12 名前の由来 •[extream]=極端な/究極の – 良い事を徹底的に行い – 不要な事を徹底的に行わない •[Programming] – プログラミングこそソフトウェア開発の「中心活動」と捉 えている。 良い事 不要な事 100% 0% ソフトウェア開発プロジェクト 100% 0%
  13. 13. 13 XPとアジャイル開発 •XPは「アジャイル開発宣言」に参加している 開発手法である。 アジャイルソフトウェア開発宣言 アジャイルソフトウェア開発手法 XP Scrum FDD Crystal Clear DSDM
  14. 14. 14 アジャイル開発宣言 •4つの「価値」と、12の「原則」で構成。
  15. 15. 15 アジャイル開発宣言~4つの価値~ プロセスやツール 包括的なドキュメント 契約交渉 計画に従う 個人と相互作用 動作するソフトウェア ユーザとの協調 変化に対応 より より より より 【従来の価値観】 【アジャイルの価値観】 • 左側にも価値はあるが、右側の方が、より多くの価値を 含んでいると考える。
  16. 16. 16 アジャイル開発宣言~12の原則~ 1. 顧客満足を最優先し、価値のあるソフトウェアを早く継続的に提供します。 2. 要求の変更はたとえ開発の後期であっても歓迎します。変化を味方につけることによって、お客様の競争力を引き上げます。 3. 動くソフトウェアを、2-3週間から2-3ヶ月というできるだけ短い時間間隔でリリースします。 4. ビジネス側の人と開発者は、プロジェクトを通して日々一緒に働かなければなりません。 5. 意欲に満ちた人々を集めてプロジェクトを構成します。環境と支援を与え仕事が無事終わるまで彼らを信頼します。 6. 情報を伝えるもっとも効率的で効果的な方法はフェイス・トゥ・フェイスで話をすることです。 7. 動くソフトウェアこそが進捗の最も重要な尺度です。 8. アジャイル・プロセスは持続可能な開発を促進します。一定のペースを継続的に維持できるようにしなければなりません。 9. 技術的卓越性と優れた設計に対する不断の注意が機敏さを高めます。 10.シンプルさ(ムダなく作れる量を最大限にすること)が本質です。 11.最良のアーキテクチャ・要求・設計は、自己組織的なチームから生み出されます。 12.チームがもっと効率を高めることができるかを定期的に振り返り、それに基づいて自分たちのやり方を最適に調整します。
  17. 17. 17 4.XPの基本思想
  18. 18. 18 XPの基本思想 「変化を抱擁セヨ」
  19. 19. 19 XPの基本思想 1.前提 3.5つの価値 4.14の原則 4つの管理変数 開発環境 見積もり 開発プロセス 開発Tips 5.開発プロセス プラクティス郡 ソフトウェア開発を成功 させるために配慮しなけ ればならない前提 XPの目指す方向性 XPの目指す方向を汎用的 に示す指標 価値を得るために 実施する行動原則 2.指針
  20. 20. 20 1.前提 ・すべてのシステムに適用可能な開発手法は無い ・人の重要性 ・変化は起きる 開発対象、開発者、規模……など、様々な条件が完全に一致するプロジェクトは無い。 プロジェクト毎に、開発手法を変える必要がある。 ソフトウェアは人の手によって生み出される。 人には個性があり、開発プロセスの画一化のためこれを排除しようとしてきた。 しかし、XPでは「個性」こそソフトウェア開発において重要な要素であると考えている。 「ツールのバージョンアップ」、「競合他社が類似製品をリリース」、「スタッフの移動、 転職、退職」、「景気の悪化」、「開発マシンの故障」、…… など、予測困難な変化が発生する可能性は十分ある。 ソフトウェア開発を成功させるために配慮しなければならない前提。
  21. 21. 21 2.指針 ・人が満足すること ・変化に適応すること ・実績を重視すること ソフトウェア開発の中心は「人」である。 ユーザーも「人」、開発者も「人」、管理者も「人」。 XPは、ユーザー、開発者、管理者、すべての「人」が満足することに焦点をあてている。 未来に起こる変化を予測することは非常に困難。 変化を予測して実装しても、予測が外れる場合、ムダなコストが発生する。 「予測」は止め、ソフトウェアをいつでも変更可能な状態にしておくことだけに集中する。 見積もりの際、「予測」が必要になる。 過去の実績から未来を予測することで、予測の確率を向上させることができる。 過去の実績を重視することで、あいまいな予測を可能な限り排除する。 ソフトウェア開発を成功させるために目指す方向性。
  22. 22. 22 3.5つの価値 ・コミュニケーション よりよいソフトウェア開発には、チーム内の円滑コミュニケーションが必須。 ・シンプル 必要なモノ・コトのみ残す。無駄なものは排除する。 ・フィードバック 「結果」を得ること。早く、多く、結果を得る方が良い。 ・勇気 判断、決断すること。 決断する際「コミュニケーション」「シンプル」「フィードバック」「尊重」が得られるか判断する。 ・尊重 相手(顧客、上司、チームメンバー、社長、事務、両親などすべての人)に気配りする心。 「指針」で示した方向性を汎用的に示す指標。
  23. 23. 23 4.14の原則 1.人間性 – 休養や達成感は必要。人間は馬車馬ではない。 2. 経済性 – 利益がちゃんと得られる開発をしよう。 3. 相互利益 – みんなの利益になるように活動しよう。他人のバグ でも取るのだ。 4. 自己相似性 – 開発の基本はみんな同じ。テスト作成→テストの動 作の繰り返し。 5. 改善 – 理想と現実を近づけるために日々努力しよう。 6. 多様性 – 多様性を否定しない。チームの衝突を納得行くよう に解決しよう。 7. 反省 – 失敗を隠さず理由を分析しよう。 8. フロー – ソフトウェア間の結合は細かく行い、開発のフロー を止めない。 9. 機会 – 問題が起きたら、それは変更するための機会と前 向きに考える。 10. 冗長性 – 冗長性も時には必要。大事な冗長性は取り除かな いように。 11. 失敗 – 失敗することは無駄ではない。解の出ない議論を 繰り返さず、とりあえず作ってみよう。 12. 品質 – 品質を低くしたからと言って、プロジェクトが早く進 むことはない。 13. 小さなステップ – 一度に大きく変更せず、小さく変更してすぐテスト。 14. 責任の受け入れ – 権限と責任にずれがないようにする。さもないと「お 前がやれ」ということになる。 プラクティスを実践する際、「5つの価値」を得るために実施しなければならない行動原則。
  24. 24. 24 5.開発プロセス 次章にてご説明します。
  25. 25. 25 5.XPの開発プロセス
  26. 26. 26 XPの開発プロセス • 繰り返し型開発(イテレーション型開発) • 「極小のウォーターフォール」の集合。 • 小さな設計/開発を何度も繰り返す。 • 何度もリリースする • 開発中に顧客からのフィードバックが得られる • 後工程のリスクを削減することができる • 全部完成するまで待たなくても、一部の機能か らメリットを教授することができる
  27. 27. 27 XPの開発プロセス ▼お客様 リクエスト ストーリカードストーリカードストーリカード タスクカードタスクカードタスクカード 製品 ▼リーダー ▼メンバー ・要求を1件づつカードに書く ・カード単位に見積もりを実施 ・優先度/工数/期間により、 実施するストーリーを決定 ・ストーリをタスクに分割 ・タスクを実行 ・期間内に開発したストーリ を満たすソフトウェアを リリース
  28. 28. 28 XPの開発プロセス リ リ | ス 計 画 リ リ | ス リ リ | ス リ リ | ス イテレーション ストーリストーリストーリ カード イ テ レ | シ ョ ン 計 画 イ テ レ | シ ョ ン 実 施 イ テ レ | シ ョ ン 実 施 イ テ レ | シ ョ ン 実 施 タスク タスク タスク 手 短 な 設 計 テ ス ト コ | デ ィ ン グ リ フ ァ ク タ リ ン グ ストーリストーリタスク カード ストーリストーリタスク カード ストーリストーリタスク カード イテレーション イテレーション ストーリストーリストーリ カード ストーリストーリストーリ カード タスクカードには、「ソフトウェア開発」 以外の内容も含まれる。 (例) ・仕様書作成 ・環境構築 ・手順書作成 etc" ペアプロ TDD リファクタリング
  29. 29. 29 プラクティス群 • 経験に基づいて有用性が立証された実践項目。 • XPの開発プロセスの中に、散りばめられている。 • XPでは、初版では14種類、第2版では24種類のプラクティスが提案さ れており、このプラクティスこそXPを最も象徴するものとなっている。 • プラクティスを実践することが、XPでは無い。 • ソフトウェア開発を成功させるために何を行うべきか現場に合わせて 取捨選択する必要がある。
  30. 30. 30 全員同席 計画ゲーム 短期リリース 最適ペース スタンダップミーティング ユーザテスト シンプル設計 ペアプログラミング テスト駆動型開発 リファクタリング 常時結合 コード共同所有 コーディング規約 メタファ プラクティス群の変遷 <主要プラクティス> 全員同席 チーム全体 情報満載のワークスペース いきいきとした仕事 ペアプログラミング ストーリー 週次サイクル 四半期サイクル ゆとり 10分ビルド 継続的インテグレーション テストファーストプログラミング インクリメンタルな設計 <導出プラクティス> 本物の顧客参加 インクリメンタルなデプロイ チームの継続 チームの縮小 根本原因分析 コードの共有 コードとテスト 単一のコードベース デイリーデプロイ 交渉によるスコープ契約 利用都度課金 XP入門 【初版】 14種類 XP入門 【第2版】 24種類
  31. 31. 31 XPの管理変数 • QCDに相当する。 • QCDに無い「開発規模」=Scopeがある。 • 「Scope」でQCDを明示的にコントロールする。 Scope Resource Quality Time ・Time(開発期間) ・Resource(開発人員/機材) ・Quality(品質) ・Scope(開発規模/ストーリの数) 限られた時間(Time)の中で、要求さ れる品質(Quality)のものを、予算内 (Resource)で消化可能なストーリ (Scope)をお客様に選択頂く
  32. 32. 32 相関図 Cost Quality Delivery Scope QCD Resource, Time, Quality, Scope Resource Quality Time Request
  33. 33. 33 開発手法の比較 XPは、従来型と逆の価値観を持っている。 XPの場合、変更コストを一定に保つことができる。 【従来型】 【XP】 実装後に単体テスト 単体テスト作成後に実装 ユーザは外部 ユーザは開発チームの一員 リリースは一番最後に1度だけ できるだけ頻繁にリリース すべて完成したら結合 1モジュールが完成したら結合 将来の要求を予測して実装 現在必要な機能だけを実装 開発後期の変更コストは高い 変更コストは常に一定 プロセス重視 人を重視 ドキュメント重視 コード重視 コスト 時間 ▼従来型 時間 コスト ▼XP
  34. 34. 34 6.Q&A
  35. 35. XPに期待することは何ですか? 会社の開発環境改善 XPについては、初体験です。分かりやすく解説してい ただければ幸いです。 今回は期待できるものがあるかどうかを知りたい。 XPで使われているプラクティスを理解し、今の現場に 適用させチームと商品、それぞれの価値向上を目指 したい。 勉強会で布教の仕方の入門がしりたい。 人間中心設計、リーンスタートアップ、コードを質のい い状態に保つ開発内コミュニケーションの改善 業務の効率化 開発サイクルの高速化 効果的なプロジェクト運営 実際のxpとは、どのように動くものなのか 開発における生産性の向上とコミュニケーションの円 滑化 テスト駆動の最新情報 品質の向上 プロジェクがうまく推進できること アジャイルプロセスの導入や評価方法が知りたい。 ウォーターフォールでの開発が多いので、どのように シフトして行けば良いのか考えたい。
  36. 36. 36 ご清聴 ありがとうございます。

×