Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

俺も エクストリームプログラミング入門

15,773 views

Published on

XP祭り2015

Published in: Software
  • Follow the link, new dating source: ♥♥♥ http://bit.ly/2Q98JRS ♥♥♥
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
  • Dating direct: ❶❶❶ http://bit.ly/2Q98JRS ❶❶❶
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here

俺も エクストリームプログラミング入門

  1. 1. エクストリーム プログラミング 入門 木下 史彦 (株)永和システムマネジメント f-kinoshita@esm.co.jp   早稲田大学理工学部キャンパス; 2015-09-12(Sat) XP祭り2015 Ore mo Extreme Programming Explained 俺も
  2. 2. 大事なことは 最初に
  3. 3. 今日お話し すること
  4. 4. 今日は教科書どおり の話をします
  5. 5. XPとは
  6. 6. エクストリームプログラミング (XP) は、ソフ トウェア開発ビジネスの規律であり、チーム全体が 共通の達成可能なゴールに集中するためのものであ る。 XPの価値と原則を使えば、チームはXPの適切なプ ラクティスを自分たちの状況に取り入れることがで きる。 XPのプラクティスには、人間の創造性に刺激を与え、 人間の弱さを受け入れるものが選ばれている。 XPチームは、高品質なソフトウェアを持続可能なペー スで生み出すことができる。 ̶Kent Beck XPシリーズの紹介 より
  7. 7. 以上
  8. 8. ご清聴ありがとう ございました。
  9. 9. 教科書
  10. 10. エクストリームプログラミング (XP) は、ソフ トウェア開発ビジネスの規律であり、チーム全体が 共通の達成可能なゴールに集中するためのものであ る。 XPの価値と原則を使えば、チームはXPの適切なプ ラクティスを自分たちの状況に取り入れることがで きる。 XPのプラクティスには、人間の創造性に刺激を与え、 人間の弱さを受け入れるものが選ばれている。 XPチームは、高品質なソフトウェアを持続可能なペー スで生み出すことができる。 ̶Kent Beck XPシリーズの紹介 より
  11. 11. XPシリーズ
  12. 12. 木下史彦 株式会社永和システムマネジメント アジャ イル事業部 事業部長。 2005年頃からエ クストリーム・プログラミングを開発現場 で実践。2010年には「価値創造契約」を 提唱し、ソフトウェア受託開発の新しい形 を示した。 ソフトウェアの利用者への《共 感》と《アジャイルなプロセス》と《妥協 のないエンジニアリング》をもって、お客 さまに価値を提供し続けることを目指して いる。 Web日記 : http://fkino.net
  13. 13. 諸注意 本資料ではXPシリーズの各書籍からの引用を多用して います。 引用の際に、本資料では価値・プラクティスなどの用 語を書籍『エスクトリームプログラミング』(オーム 社) の訳文に合わせて変更しています。 各書籍の訳文には敬意を払いつつも、訳語が異なるこ とで、本資料を見た人が混乱しないように配慮しまし た。
  14. 14. 予備知識
  15. 15. XPエクストリーム・プログラミング実行計画 Planning Extreme Programming Kent Beck, Martin Fowler (October 26, 2000) Foreword by Tom DeMarco XPエクストリーム・プログラミング検証編 Extreme Programming Examined Giancarlo Succi, Michele Marchesi (May 23, 2001) XPエクストリーム・プログラミング導入編 Extreme Programming Installed Ron Jeffries, Ann Anderson, Chet Hendrickson (October 26, 2000) Foreword by Kent Beck Afterword by Dan Rawsthorne, Ph.D. XPエクストリーム・プログラミング実践記 Extreme Programming in Practice James W. Newkirk, Robert C. Martin (June 5, 2001) Foreword by Martin Fowler XPエクストリーム・プログラミング アドベンチャー Extreme Programming Explored William C. Wake (July 28, 2001) Foreword by Dave Thomas XPエクストリーム・プログラミング懐疑編 Questioning Extreme Programming Pete McBreen (July 19, 2002) Foreword by Kent Beck XPエクストリーム・プログラミング適用編 Extreme Programming Applied Ken Auer, Roy Miller (October 11, 2001) Foreword by Ward Cunningham XPエクストリーム・プログラミング ウェブ開発編 Extreme Programming for Web Projects Doug Wallace, Isobel Raggett, Joel Aufgang (September 29, 2002) Foreword by Chet Hendrickson
  16. 16. 合計 111円 (時価です)
  17. 17. ルーツ
  18. 18. Three Extremos Ward CunninghamKent Beck Ron Jeffries
  19. 19. Ward Cunningham氏のEPISODES パターン・ランゲージは、アプリケーショ ンを継続的に進化させる能力を重視する、 起業家精神に溢れた組織におけるソフトウェ ア開発に着目したものであり、XPの先駆者 とも言えるものです。 ̶『XPエクストリーム・プログラミング導入編』
  20. 20. これまでにもっとも成功したパターン言語 ̶Joshua Kerievsky 『XPエクストリーム・プログラミング適用編』より
  21. 21. XPとは
  22. 22. エクストリームプログラミングは、「ソフトウェ ア開発は人間どうしの協調によって成り立っている」 という現実をしっかりと受け止めている。 成功するソフトウェア開発プロセスは、人間の強さを 最大限に活かし、弱みを最小限にとどめるものでなく てはならない。 XPは、チームメンバー各自の得意分野にもとづいて役 割を明確にし、各自がその役割を果たし、補い合って1 つのチームとして働くように促進する。 ̶Roy Miller, Chris Collins 『XPの神髄』(IBM developerWorks)、 『XPエクストリーム・プログラミング適用編』より https://www.ibm.com/developerworks/jp/java/library/j-xp/
  23. 23. XPは、規律の乱れたカウボーイ・アプ ローチであるという攻撃とは対照的に、実 際は極めて規律正しい、協調的なソフトウェ ア開発アプローチなのです。 ̶『XPエクストリーム・プログラミング懐疑編』
  24. 24. XPはソフトウェア工学コミュニティの 聖域に直接挑んでいるのです。つまり、プ ログラマの地位を向上させることで、ソフ トウェア工学が30年にわたって積み重ねて きた価値観をひっくり返そうとしているの です。 ̶『XPエクストリーム・プログラミング懐疑編』
  25. 25. XPの原則は単なる方法論やプロセスで はない。プロセスの対極にあるものだ。 XPは私たちの業界でもっとも重要な運動で ある。私は、SEIやCMM同様、最終的にXP は今の世代に欠くことのできないものにな るだろうと予想する。 ̶Tom DeMarco 『XPエクストリーム・プログラミング実行計画』序文より
  26. 26. その名前とそぐわないが、エクストリー ムプログラミングとはプログラミングにつ いてであると同時に、人についてであり、 そして人と人との関わりあいは、人生その ものである。 ̶『エクストリーム・プログラミング導入編』
  27. 27. XPとは
  28. 28. 1. 恐れに対処する 2. 変更コスト曲線を 平らにする
  29. 29. 恐れに対処する
  30. 30. すべての方法論は、 恐れに基づいています。 ̶Kent Beck 『XPエクストリーム・プログラミング入門』より
  31. 31. 恐怖は怒りに 怒りは憎しみに  憎しみは苦悩へ ̶スター・ウォーズ エピソード1/ファントム・メナス Yodaの言葉 ̶『XPエクストリーム・プログラミング導入編』
  32. 32. ソフトウェア開発における基本 的な問題とはリスクである ̶Kent Beck 『XPエクストリーム・プログラミング入門』
  33. 33. リスク ✓ スケジュールの遅延 ✓ プロジェクトの中止 ✓ システムの陳腐化 ✓ 欠陥保有率の上昇 ✓ ビジネスの誤解 ✓ ビジネスの変化 ✓ 無駄な機能の搭載 ✓ 要員の入れ替わり ̶『XPエクストリーム・プログラミング懐疑編』
  34. 34. プロジェクトのリスクは症状で あって病気ではない ̶Andy Hunt 『XPエクストリーム・プログラミング懐疑編』より
  35. 35. プロジェクトに影響を与えている 病気とは、無知と焦りという2つの 魔物によって生み出されるのです。 ̶『XPエクストリーム・プログラミング懐疑編』
  36. 36. 無知 XPはチームを同じ場所に配置すること で、前提を置くのではなく質問を行うこと をチーム全体に奨励しているわけです。 ̶『XPエクストリーム・プログラミング懐疑編』
  37. 37. 焦り エクストリームプログラミングにおける 計画プロセス全体は、開発者と顧客の間で 計画の責任を分担することによって、焦りの 問題に取り組んでいるのです。 ̶『XPエクストリーム・プログラミング懐疑編』
  38. 38. 開発を成功させるためには、プログラ マとユーザーが自分たちの不安を認識し、 権利と責任を受け入れられる文化 (環境) を 創らなければならない。 不安が認識され権利が受け入れられれば、 自信を持つことができる。たとえ達成する ことが難しくてもゴールを設定し、ゴール に向かって協調する。不安のために作られ た、自分たちを邪魔する構造を打ち壊す。 ̶『XPエクストリーム・プログラミング実行計画』
  39. 39. 権利と責任
  40. 40. XPのエッセンス ビジネス側と開発側の意志決定の分離 ̶Kent Beck 『XPエクストリーム・プログラミング適用編』より
  41. 41. XPに登場するロール 顧客 プログラマ マネージャ
  42. 42. 顧客の役割 リリース日を決める スコープを決める プライオリティを決める プログラマからの質問に答える 受入テストを書く 受入テストを実行する リリースを受け入れる
  43. 43. プログラマの役割 何かをプログラムするとき、どの位かかるかを見 積もるということは完全に技術的な決定である。 ̶『XPエクストリーム・プログラミング実行計画』 システムを分析、設計、テスト、プログ ラミングする ストーリーの見積りをする
  44. 44. 外部組織と折衝する チームメンバーを集める リソースを確保する スポンサーに進 を報告する ミーティングを手配する パーティを開く マネージャの役割
  45. 45. XPのマネージャが行わないこと プライオリティ付けは行わない。 ➡それは顧客の仕事である。 タスクの割り当ては行わない。 ➡それはプログラマの仕事である。 ストーリーやタスクの見積りは行わない。 ➡それはプログラマの仕事である。 スケジュールを自分だけで決定しない。 ➡それは顧客とプログラマで交渉する ̶『XPエクストリーム・プログラミング アドベンチャー』
  46. 46. マネージャと顧客の権利 1. マネージャと顧客には、計画のどの部分に関しても、いつまでに、何 が、どのくらいのコストで達成できるかを知る権利がある。 2. マネージャと顧客には、全プログラミング期間を通して、最高価値を 手にする権利がある。 3. マネージャと顧客には、自らが書いた再現可能なテストを通すことで、 システムが機能することをちゃんと証明してもらい、現行のシステムの 進 度合いを知る権利がある。 4. マネージャと顧客には、考えを途中で変えて機能を差し替えたり、プ ライオリティを変更したりする権利がある。その際に特別に多額の出費は必要な い。 5. マネージャと顧客には、スケジュールの変更があったら連絡を受ける 権利がある。なお、その連絡は、最初に決めた期限を守るため、どうスコープを減らすかを決める のに手遅れにならないよう、十分速やかに行われなければならない。そしていつでも発注を取り消し、そ の時点までの投資に見あう、ちゃんと機能するシステムを手にする権利がある。 ̶『XPエクストリーム・プログラミング導入編』、 『XPエクストリーム・プログラミング実行計画』
  47. 47. プログラマの権利 1.プログラマには、何が必要とされているかを明確なプライ オリティとあわせて知る権利がある。 2.プログラマには、つねに質の高い仕事をする権利がある。 3.プログラマには、同僚や上司、顧客に助力を求め、それを 受ける権利がある。 4.プログラマには、自ら見積りを行い、またそれを更新する 権利がある。 5.プログラマには、責任を割り当てられてるのではなく、自 ら責任を引き受ける権利がある。 ̶『XPエクストリーム・プログラミング導入編』、 『XPエクストリーム・プログラミング実行計画』
  48. 48. 顧客についての補足
  49. 49. XPの顧客は複数形? ここで、私たちが「顧客たち」ではなく「顧客」とい う単数形の表現を使っていることに注意してほしい。顧客が 何人いようと、つねにその意見は1つにまとまっていなくて はならない。 ̶『XPエクストリーム・プログラミング導入編』 初期のXPにおける誤った思想について留意して読み進 めていただくようお願いいたします。その留意点とは「顧客」 がたった1人の人間を表した言葉ではないというものです。顧 客という言葉は、開発チームと同等、あるいはそれ以上の規 模の集団を意味しているのです。 ̶Kent Beck 『XPエクストリーム・プログラミング懐疑編』本書推薦の言葉より
  50. 50. チーム全体 ユーザー (ビジネスの決定を下す人) は チームの一員でなくてはならない。世界中 のどんな素晴らしい才能、技術、プロセス を以てしても、ユーザーが参加していなけ れば失敗するだろう。 ̶『XPエクストリーム・プログラミング実行計画』
  51. 51. 良いユーザー (顧客) 自分が働いている分野(ドメイン)の業務知識がある。も しくはどのように仕事が流れるかを理解している。 開発の助けがあれば、どのようにソフトウェアがその業 務分野においてビジネスの価値を生み出すかを理解でき る。 定期的に価値を納品することに意欲的である。そして、 何も納品しないのではなく、たとえ少量でも納品するこ とを恐れない。 今必要なものと、後で必要なものを見分けられる。 プロジェクトが成功してもしなくても、全ての責任を取 る意志がある。 ̶『XPエクストリーム・プログラミング実行計画』
  52. 52. プランニング
  53. 53. リリース計画はユーザーと プログラマの共同作業である。 ̶『XPエクストリーム・プログラミング実行計画』
  54. 54. 唯一確信を持って言 えるとすれば、開発は 計画通りにいかない。 ̶『XPエクストリーム・プログラミング実行計画』
  55. 55. 計画を立てることは未来を予想するこ とではない。ソフトウェア開発の計画を立 てても、実際の開発は決して計画のように はいかない。ユーザーはたとえ開発が計画 どおりに運んだとしても満足はしない。な ぜなら、ソフトウェアが納品される頃には、 ユーザーは計画されたものではなく別のも のを欲しがるからだ。 ̶『XPエクストリーム・プログラミング実行計画』
  56. 56. プランニングの目的 私たちは、常に最も重要なことを行い、他人と効 率良く調和し、予期せぬ事態に素早く対応することを 確認するために計画を立てる。 イベントは起きるものであり、計画は変更するものだ。 物事が計画通りに進んでいるように見えるときはトラブ ルの兆しである。プロジェクトに起こり得る最悪の事 態は、計画と現実の相違である。罠にはまらないよう に気をつけよう。計画を正直に保ち、計画は常に変更 するものだと思っていよう。 ̶『XPエクストリーム・プログラミング実行計画』
  57. 57. 時間がない?? 負担が多いと感じるときは、十分な時間がないか らではなく、仕事が多すぎるからだと考えるべきだ。 これ以上の時間を作ることはできない。十分に時間が ないということは、望みのない状態のことだ。そして、 望みのない状態はフラストレーションを生み、間違い を起こし、燃え尽き、結局失敗する。 仕事が多すぎることは望みを生む。その状況にいるこ とを恨めしく思うかもしれないが、少なくとも行うべ きことは分かっている。 ̶『XPエクストリーム・プログラミング実行計画』
  58. 58. 時限爆弾というのは時間に対す るプレッシャーのことだとずっと思っ ていた。しかし、本当はシビアなト レードオフの決断に集中することだ、 ということが分かった。 ̶ Jim Highsmith 『XPエクストリーム・プログラミング実行計画』より
  59. 59. 計画ゲームは組織の意志決定能力と、 こういった決定を維持する能力に対するリ トマス試験紙として考えることができます。 厳しい選択を行う能力が無ければ、XPを 成功させることなどできないのです。 しかし、見積りは交渉次第で何とかなると 信じている組織が未だに数多く存在してい るのです。 ̶『XPエクストリーム・プログラミング懐疑編』
  60. 60. 割愛
  61. 61. ストーリーと見積りが あってはじめて、計画を 変更すること。 ̶『XPエクストリーム・プログラミング実践記』
  62. 62. 割愛
  63. 63. ストーリーの見積り
  64. 64. 相対見積り ほとんどのストーリーはすでに実装さ れたほかのストーリーと比較し、相対的な 大きさに応じてポイントをつけていけば、 かなり正確に見積りを行うことができる。 普通のプログラマというのはこの比較を行 うのが上手なようだ。 ̶『XPエクストリーム・プログラミング導入編』
  65. 65. 実時間での見積り 実時間で見積もるほうが私の好 みだ。そのほうができるだけ明確で、 直接的で、透明性のあるコミュニケー ションがとれるからである。 ̶『エクストリーム・プログラミング』
  66. 66. ほとんどの環境で上手くいくシンプルなルール 今日できた分は、 明日もできる ̶『XPエクストリーム・プログラミング実行計画』
  67. 67. がんばってみます 「がんばってみます (We’ll try)」という言葉は、プログラマに とって人生で一番悲しい言葉となる可能性がある。 チーム速度を上げようとがんばるのはいい。だけど、計画は希望では なく、実際のスピードをもとに立てなくてはならない。 最後の最後であなたの味方をしてくれるのは、プログラマたちの「で きますように」という願望なんかではなく、実際の速度なのだ。 ̶『XPエクストリーム・プログラミング導入編』 劇的瞬間は、開発側の人間が押し返すときにやって来る。開 発側が押し返せなければ、プロセスはバランスを失う。 ̶Michael Feathers 『XPエクストリーム・プログラミング適用編』 励ましの言葉は、全員が信じられる計画の代用にならない。 ̶『XPエクストリーム・プログラミング実行計画』
  68. 68. できないものはできない 与えられたストーリーにかかる時間は コントロールできない。できないものはで きない。あなたにできるのは、そしてあな たがしなくてはならないことは、スコープ をコントロールすることだ。 ̶『XPエクストリーム・プログラミング導入編』
  69. 69. プログラマが約束できること 何ができるかを見積もること 自分たちのベストを尽くすことを約束す ること 何が起きているかについて真実を伝える ことを約束すること ̶『XPエクストリーム・プログラミング導入編』
  70. 70. 注意点 最初の見積りは要求と同じように信頼できない。 最初の見積りは7%程度の正確さしかないのだから。 顧客は、「信頼できる見積りを得るためには、時 間と会話が必要だ」ということを受け入れなくてはな らない。 顧客が見積りを気に入らなければ、顧客が気に入 るまで対話を続ける。 「とにかく見積りはそう出しました。受けるなりやめ るなり、ご自由に」という状況ではないのだ。 ̶『XPエクストリーム・プログラミング適用編』
  71. 71. 最重要事項 ストーリーの見積りは曖昧なも のであるが、1度イテレーション計 画のタスクに分割してからは、大き な空振りをしてはいけない。 ̶『XPエクストリーム・プログラミング実行計画』
  72. 72. ここまでのまとめ すべての方法論は、恐れに基づいている。 プロジェクトに影響を与えている病気とは、無知と焦りという2つの魔 物によって生み出される。 XPは、前提を置くのではなく質問できる環境を作ることによって、無 知の問題に取り組んでいる。→コミュニケーション XPは、開発者と顧客の間で計画の責任を分担することによって、焦り の問題に取り組んでいる。→プランニング XPでは、顧客とプログラマとマネージャの役割と権利を明確に定義し ている。 プランニングは顧客とプログラマの共同作業だ。XPでは、計画を正常 に保ち、計画は常に変更する。この過程で、組織の意志決定能力が試さ れる。 できないものはできない。スコープをコントロールすること。 ただし、イテレーション計画のタスクに分割してからは、大きな空振り をしてはいけない。
  73. 73. 変更コスト曲線を 平らにする
  74. 74. 変更にかかるコストが指数関数 的に増大する ̶Barry Boehm 『XPエクストリーム・プログラミング懐疑編』より
  75. 75. Barry W. Boehm (born 1935) is an American software engineer, Distinguished Professor of Computer Science, Industrial and Systems Engineering; the TRW Professor of Software Engineering; and Founding Director of the Center for Systems and Software Engineering at the University of Southern California. He is known for his many contributions to the area of software engineering. —Wikipedia
  76. 76. ̶Barry Boehm 『Software Engineering Economics』
  77. 77. この有名なグラフを目にした読者の多くは、実際には2本 の線が描かれているという点を見落としてしまったのです。 1本目の線は、様々な要因が重なって「大規模プロジェクトの保 守フェーズでの誤りの修正は、要求フェーズで行われるよりも100 倍以上高価なものになる」という有名な前提を裏付けるもので した。 しかし、グラフには、より小規模かつ、さほど格式張っていな い2つのプロジェクトからのデータも点線で描かれていたのです。 興味深いことに、Boehm氏でさえも「完全に要求を凍結するこ とに工数を割くよりも、製品プロトタイプの最初の開発を始め る方が、費用対効果として優れているかもしれない、...こういっ たプロトタイプ・アプローチに適している状況として、変更コス トの比率が 4:6-1に増大する小規模な格式張っていないプロジェ クト、およびラピッド・プロトタイピングが可能な問題領域を挙 げることができる」と示唆しているのです。 ̶『XPエクストリーム・プログラミング懐疑編』
  78. 78. XPにおける技術的前提 変更コストが時間と共に劇的に 増大していくことはない ̶『XPエクストリーム・プログラミング懐疑編』
  79. 79. エクストリームプログラミングは、プ ログラムの変更は優れたツールがあれば簡 単に行え、アプリケーションの理解はソー スコードを読むことで可能になるという考 え方を具体化したものです。 ̶『XPエクストリーム・プログラミング懐疑編』
  80. 80. XPの世界における正しい設計方法と は、設計の意図を直接コードの中に表現す るということがすべてになります。 ̶『XPエクストリーム・プログラミング懐疑編』 ソフトウェア工学の世界 ➡UML仕様からのコード生成に重きを置いている XPの世界 ➡オブジェクト指向プログラミング言語の高い表現 力に価値を置いている
  81. 81. リファクタリング
  82. 82. コンピュータが理解できるコードを書 くのは、どんな馬鹿にだってできる。優秀 なプログラマは人間が理解できるコードを 書くものなのだ。 ̶Martin Fowler 『リファクタリング』、 『XPエクストリーム・プログラミング適用編』より
  83. 83. コードは、プログラマの意図を 明確に伝えなくてはならない。 ̶『XPエクストリーム・プログラミング適用編』
  84. 84. リファクタリングに必要なもの オリジナルのコード ユニットテスト 改善を証明する方法 適用方法が分かっているリファクタリン グのカタログ ガイドとなるプロセス ̶『XPエクストリーム・プログラミング アドベンチャー』
  85. 85. 注意点 「『十分』は『完璧』にまさる」のだ。自分のコー ドからゴミをすべて取り除こうとする態度は立派だが、 改善の余地があるからといってシステムを出荷しない ようでは、プロフェッショナルとは言えない。「プロ フェッショナルであること」と「完璧であること」は違 うのだ。 ̶『XPエクストリーム・プログラミング適用編』
  86. 86. 割愛
  87. 87. ここまでのまとめ XPの技術的前提は、変更コストが時間と共に劇的に増大してい くことはないということである。 コードは、プログラマの意図を明確に伝えなくてはならない。 テスト駆動開発、リファクタリング、継続的インテグレーション と表現力豊かなオブジェクト指向言語によって、設計の意図を直 接コードの中に表現する。これによって、変更コスト曲線を平ら に近づける。 プロフェッショナルであることと完璧であることは違う。
  88. 88. 1. 恐れに対処する 2. 変更コスト曲線を 平らにする
  89. 89. 価値
  90. 90. XPの5つの価値 ✓勇気 ✓コミュニケーション ✓フィードバック ✓シンプリシティ ✓リスペクト
  91. 91. 勇気
  92. 92. ̶『ウィズダム英和辞典』
  93. 93. 情報をあつめ、分析をおこない、自分 を納得させて不安をしずめた後に「最初の 一歩を踏み出す」ための決断を下す。その 意味で courage という単語は、勇気では なく「実行力」や「決断力」と訳すべきか もしれない。 ̶小野剛 『XPエクストリーム・プログラミング検証編』訳者あとがき より
  94. 94. 勇気のまとめ シビアな意志決定を行う決断力。 リファクタリングを行う実行力。 開発側が押し返す (劇的瞬間の) 勇気。 それがなければプロセスはバランスを失 う。
  95. 95. コミュニケーション
  96. 96. いかに多くのプラクティスを実践しよ うとも、十分なコミュニケーションが取れ なければXPは成功しない。 ̶『XPエクストリーム・プログラミング適用編』
  97. 97. XPはチームを同じ場所に配置すること で、前提を置くのではなく質問を行うこと をチーム全体に奨励しているわけです。 ̶『XPエクストリーム・プログラミング懐疑編』
  98. 98. 効率的なコミュニケーション Alistair Cockburn によると、もっとも効率的 なコミュニケーションの形態は、「ホワイトボードを 利用して会話する2人」だそうだ。 それに及ぶくらい効率的なのが、「1つのテーブルで、 ストーリーカードを触っているビジネス側の人間と開発 者」だ。 ̶『XPエクストリーム・プログラミング適用編』
  99. 99. コミュニケーションのまとめ プログラマは前提を置くのではなく、顧 客に質問を行う。 信頼できる見積りを得るためには、時間 と会話が必要。 プログラマと顧客は、ゴールに向かって 協調する。そして、不安のために作られ た、自分たちを邪魔する構造を打ち壊す。
  100. 100. フィードバック
  101. 101. イテレーションをまとめあげることは、いくつか のストーリーを完成させ、そして、次の成果へのドア を開く。これをチーム全体で共有すること。ピザを持 ち込んだり、または、ほかのちょっとしたお祝いを考 えるのだ。リリースごとに素晴らしい達成感が得られ る。新しいビジネス価値を顧客は手に入れる。素晴ら しい日だ。とっておきのシャンパンを出そう。 プログラマは子犬と似ている。もしかしたら子犬より 幼稚かもしれない。プログラマは先に進むために、絶 えず激励を必要としている。 ̶『XPエクストリーム・プログラミング導入編』
  102. 102. フィードバックまとめ パーティを開こう。 不安や人間の弱さに向き合って、次の一 歩を踏み出すために。
  103. 103. シンプリシティ
  104. 104. シンプリシティとは 1.すべてのテストをパスし、 2.表現しなければならないすべての「考え」 を表現し、 3.どんなことも一度、ただ一度だけであり (Once and Only Once)、 4.(上の3つと矛盾しないで) クラスとメソッ ドの数は最少でなければならない。 ̶『XPエクストリーム・プログラミング導入編』
  105. 105. シンプリシティに必要なもの ✓シンプルに考える能力 ✓コードを理解し、変えていく勇気 ✓秩序が失われ、コードが破壊されてしま わないように、定期的なリファクタリン グを行う習慣 ̶『XPエクストリーム・プログラミング適用編』
  106. 106. 「もっともシンプルな設計とはなにか」 にこだわりすぎてはいけない。「もっとも シンプルなものとは何か」をすぐに分かろ うとするより、リファクタリングしようと する意志の方がずっと重要なのだ。 ̶Robert Martin 『XPエクストリーム・プログラミング適用編』より
  107. 107. シンプリシティのまとめ リファクタリングをしようとする意志が 重要。 コードは、プログラマの意図を明確に伝 えなければならない。
  108. 108. リスペクト
  109. 109. チームのメンバーが、お互いのことや お互いがやっていることを気にかけなけれ ば、XPは破綻します。ソフトウェアを記述 するその他のアプローチも同様でしょうが、 XPはこういったことに対して、特に敏感な のです。 ̶Kent Beck 『XPエクストリーム・プログラミング入門』、 『XPエクストリーム・プログラミング懐疑編』より
  110. 110. エクストリームプログラミング (および一般的な リーダーシップ) は愛のなせる技だ。相手を尊敬する ことを知らなければ、うまくやりようがない。私はい つも、正しいことを一生懸命やろうとしている人たち に対する多大な尊敬を表に出すようにしている。そし て、たいていの場合、みんなもそうしようと努力して いるものだ。 ̶Ron Jeffries 『Enforcing Methods』 『XPエクストリーム・プログラミング適用編』、 『XPエクストリーム・プログラミング アドベンチャー』より http://c2.com/cgi/wiki?EnforcingMethods
  111. 111. リスペクトのまとめ XPのエッセンスは、ビジネス側と開発 側の意志決定の分離。でも壁を作るわけ じゃない。 それぞれの立場を認める。
  112. 112. その他の価値
  113. 113. 謙虚な心
  114. 114. 信頼関係なくして、プロジェクトの成功はありえ ない。絶対的な誠実さをつねに心がけなければ、信頼 関係は成り立たない。そして、謙虚な心がなければ、 誠実さは身に付かない。 XPチームに入ったらいつでも「自分は馬鹿だ」と感じ る準備ができていなければならない。 ̶『XPエクストリーム・プログラミング適用編』
  115. 115. 人のせいにしない
  116. 116. それはChetのミスだ 誰が悪かったかではなく、何をすべき かを探ろうとした。 すべての出来事に対して全員が責任を受け 入れるということを、私たちに思い出させ た。 ̶『XPエクストリーム・プログラミング導入編』
  117. 117. まとめ
  118. 118. 1. 恐れに対処する 2. 変更コスト曲線を 平らにする
  119. 119. エクストリームプログラミング (XP) は、ソフ トウェア開発ビジネスの規律であり、チーム全体が 共通の達成可能なゴールに集中するためのものであ る。 XPの価値と原則を使えば、チームはXPの適切なプ ラクティスを自分たちの状況に取り入れることがで きる。 XPのプラクティスには、人間の創造性に刺激を与え、 人間の弱さを受け入れるものが選ばれている。 XPチームは、高品質なソフトウェアを持続可能なペー スで生み出すことができる。 ̶Kent Beck XPシリーズの紹介 より
  120. 120. http://agile.esm.co.jp/contact.html ご用命をお待ちしております。
  121. 121. 結局のところ、ソフトウェア開発は楽しくなけれ ばならないのです。そうでなければ、そのプロセスは 間違っているのです。 ̶『XPエクストリーム・プログラミング懐疑編』

×