Recomendados
Mais conteúdo relacionado
Mais de takepu
Mais de takepu (19)
Xp寺子屋出張版＃２「xp入門 追補版」
- 5. 5 ＸＰとは？ • eXtremeProgrammingの略称。 • ソフトウェア開発手法の１つ。 • ソフトウェア開発において「良い事を最大限に 実施」する手法。 XPJUG関西 / XP寺子屋
- 6. 6 ＸＰの提唱者 Three Extremos けんと・べっく うぉーど・かにんがむ ろん・じぇふりーず Kent Beck Ward Cunningham Ron Jeffries XPJUG関西 / XP寺子屋
- 7. 7 ＸＰの歴史 • 最初にXPが実践されたのは「C3プロジェクト」。 プロジェクト」 「C3プロジェクト • 危機的状況にあったC3プロジェクトを救うべく、過去に経験した手 法を最大限に実施。その結果、プロジェクトの建て直しに成功。 • この経験を元に、ＸＰ本を執筆。急速に拡大。 1996年 ケント・ベックがＣ３プロジェクトに携わる。 1999年 米国で『eXtreme Programming Explained』刊行。 2000年 日本で翻訳本『XPエクストリームプログラミング入門』刊行。 XPJUG関西 / XP寺子屋
- 8. 8 名前の由来 ソフトウェア開発プロジェクト ソフトウェア開発プロジェクト 開発 • [extream]=極端な／究極の extream] – 良い事を徹底的に行い – 不要な事を徹底的に行わない 不要な 良い事 不要な 不要な事 100% 100% 0% 0% • [Programming] – プログラミングこそソフトウェア開発の「中心活動」 「中心活動」 と捉えている。 XPJUG関西 / XP寺子屋
- 9. 9 アジャイル開発との関係 • ＸＰは、アジャイル開発宣言に参加している開 発手法である。 • アジャイル開発とは？ ソフトウェア工学において、迅速かつ適応的に ソフトウェア開発を行う軽量な開発手法群の総称 ～ 『ウィキペディア』からの抜粋 ～ XPJUG関西 / XP寺子屋
- 17. 17 ＸＰの基本思想 • 「変化を抱擁セヨ！」 – “変化”は与えられるものではない。 – 自分が変わらなければ、何も変わらない。 – 自分の不幸を嘆いても、誰も助けてくれない。 – 助けてもらっても、感謝しない。 XPJUG関西 / XP寺子屋
- 22. ＸＰが指し示す方向 • ソフトウェア開発関係者全員の満足 – ソフトウェア開発の中心は「人」 – 「人」＝ソフトウェアに関わる全員 – 開発者と顧客の成功（WIN-WIN）を目指す • 変化への適応を前提とする（変化はあたりまえ） – 未来を予測することは困難 – 変化を抑止することも困難 – だから、変化に適応できるソフトを作る • 実績を重視する – 予測は外れると無駄になる – 過去に蓄積した実績値を用いる – 「昨日の天気ルール」 XPJUG関西 / XP寺子屋 22
- 23. 23 これらの方向を、より明確に、 より汎用的に示す指標が 「５つの価値」である。 コミュニケーション、 シンプル、 フィードバック、 勇気、 尊重 XPJUG関西 / XP寺子屋
- 29. 29 フィードバック • 反応、結果 • 例 – システムを実際に動作させる – 顧客に使ってもらう • 「挨拶」「お礼」は最も身近なフィードバック – おはよう – ありがとう – おつかれさま
- 31. 31 勇気 • 判断する／決断する – 他の４つの価値に基づき、実施する／ しないを決定する。 – 何も考えないで実行する事は、「勇気」 ではなく「蛮勇」である。 • アンパンマン
- 41. 41 管理変数 ・Cost(原価) ・Quality(品質) ・Delivery(納期) これらをバランスさせる 事が大切 Cost Quality Delivery • 一般的に、管理変数として、「ＱＣＤ」を使用する。 • 「開発規模」は、明示されていない。 • 仕様変更時、暗黙的にパラメタが変化する。 XPJUG関西 / XP寺子屋
- 42. 42 ＸＰ#1 • 繰り返し型開発（イテレーション型開発） 型開発（イテレーション型開発） 型開発 – 「極小のウォーターフォール」の集合。 – 小さな設計／開発を何度も繰り返す。 • 何度もリリースする 何度もリリースする – 開発中に顧客からのフィードバックが得られる – 後工程のリスクを削減することができる – 全部完成するまで待たなくても、一部の機能からメリットを教授することができる • 要件／作業はカード単位 要件／作業はカード単位 – 見積もりはカード単位で行う – カードに予定／実績工数を記入し、次回の見積もりに使用することで、見積も り精度がどんどん向上する – 粒度が下がるため、見積もり精度が向上する – 本当にやるべき作業が明確になる – カードの枚数で進捗把握も可能 XPJUG関西 / XP寺子屋
- 47. 47 ＸＰの管理変数 Resource ・Time（開発期間） ・Resource（開発人員/機材） ・Quality（品質） ・Scope（開発規模/ｽﾄｰﾘの数） Time Quality Scope 限られた時間（Time）の中で、要求され る品質（Quality）のものを、予算内 （Resource）で消化可能なストーリ （Scope）をお客様に選択頂く • ＱＣＤに相当する。 • ＱＣＤに無い「開発規模」＝Scopeがある。 • 「Scope」でＱＣＤを明示的にコントロールする。 XPJUG関西 / XP寺子屋
- 48. 48 相関図 Request Resource Cost Time Quality Delivery QCD XPJUG関西 / XP寺子屋 Quality Scope Resource, Time, Quality, Scope
- 52. 52 プラクティス一覧 • 開発環境 – 1. 全員同席 • 見積もり – 2. 計画ゲーム • 開発プロセス – – – – 3. 4. 5. 6. 短期リリース 最適ペース スタンダップミーティング ユーザテスト • 開発Tips – – – – – – – – 7. シンプル設計 8. ペアプログラミング 9. テスト駆動型開発 10. リファクタリング 11. 常時結合 12. コード共同所有 13. コーディング規約 14. メタファ
- 53. 53 原則 • 「プラクティス」を実践する事で、価値が得られる。 • しかし、間違った方法では価値が得られない。 • 「原則」とは、プラクティスを実施して「価値」を 得るために守るべき事柄である。 • 14の原則が提案されている。 XPJUG関西 / XP寺子屋
- 54. 54 原則一覧 １．人間性 – 休養や達成感は必要。人間は馬車馬ではない。 2. 経済性 – 利益がちゃんと得られる開発をしよう。 3. 相互利益 – みんなの利益になるように活動しよう。他人のバグ でも取るのだ。 4. 自己相似性 – 開発の基本はみんな同じ。テスト作成→テストの動 作の繰り返し。 5. 改善 – 理想と現実を近づけるために日々努力しよう。 6. 多様性 – 多様性を否定しない。チームの衝突を納得行くよう に解決しよう。 7. 反省 – 失敗を隠さず理由を分析しよう。 8. フロー – ソフトウェア間の結合は細かく行い、開発のフローを 止めない。 9. 機会 – 問題が起きたら、それは変更するための機会と前向 きに考える。 10. 冗長性 – 冗長性も時には必要。大事な冗長性は取り除かな いように。 11. 失敗 – 失敗することは無駄ではない。解の出ない議論を繰 り返さず、とりあえず作ってみよう。 12. 品質 – 品質を低くしたからと言って、プロジェクトが早く進む ことはない。 13. 小さなステップ – 一度に大きく変更せず、小さく変更してすぐテスト。 14. 責任の受け入れ – 権限と責任にずれがないようにする。さもないと「お 前がやれ」ということになる。