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

1. エクストリームプログラミング入門木下史彦 (株)永和システムマネジメント f-kinoshita@esm.co.jp 早稲田大学理工学部キャンパス; 2015-09-12(Sat) XP祭り2015 Ore mo Extreme Programming Explained 俺も

2. 大事なことは最初に

5. 今日お話しすること

6. 今日は教科書どおりの話をします

8. XPとは

9. エクストリームプログラミング (XP) は、ソフトウェア開発ビジネスの規律であり、チーム全体が共通の達成可能なゴールに集中するためのものである。 XPの価値と原則を使えば、チームはXPの適切なプラクティスを自分たちの状況に取り入れることができる。 XPのプラクティスには、人間の創造性に刺激を与え、人間の弱さを受け入れるものが選ばれている。 XPチームは、高品質なソフトウェアを持続可能なペースで生み出すことができる。 ̶Kent Beck XPシリーズの紹介より

10. 以上

11. ご清聴ありがとうございました。

13. 教科書

15. XPシリーズ

17. 木下史彦株式会社永和システムマネジメントアジャイル事業部事業部長。 2005年頃からエクストリーム・プログラミングを開発現場で実践。2010年には「価値創造契約」を提唱し、ソフトウェア受託開発の新しい形を示した。ソフトウェアの利用者への《共感》と《アジャイルなプロセス》と《妥協のないエンジニアリング》をもって、お客さまに価値を提供し続けることを目指している。 Web日記 : http://fkino.net

19. 諸注意本資料ではXPシリーズの各書籍からの引用を多用しています。引用の際に、本資料では価値・プラクティスなどの用語を書籍『エスクトリームプログラミング』(オーム社) の訳文に合わせて変更しています。各書籍の訳文には敬意を払いつつも、訳語が異なることで、本資料を見た人が混乱しないように配慮しました。

20. 予備知識

21. 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 Jeﬀries, 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

23. 合計 111円 (時価です)

24. ルーツ

25. Three Extremos Ward CunninghamKent Beck Ron Jeffries

26. Ward Cunningham氏のEPISODES パターン・ランゲージは、アプリケーションを継続的に進化させる能力を重視する、起業家精神に溢れた組織におけるソフトウェア開発に着目したものであり、XPの先駆者とも言えるものです。 ̶『XPエクストリーム・プログラミング導入編』

29. これまでにもっとも成功したパターン言語 ̶Joshua Kerievsky 『XPエクストリーム・プログラミング適用編』より

30. XPとは

31. エクストリームプログラミングは、「ソフトウェア開発は人間どうしの協調によって成り立っている」という現実をしっかりと受け止めている。成功するソフトウェア開発プロセスは、人間の強さを最大限に活かし、弱みを最小限にとどめるものでなくてはならない。 XPは、チームメンバー各自の得意分野にもとづいて役割を明確にし、各自がその役割を果たし、補い合って1 つのチームとして働くように促進する。 ̶Roy Miller, Chris Collins 『XPの神髄』(IBM developerWorks)、『XPエクストリーム・プログラミング適用編』より https://www.ibm.com/developerworks/jp/java/library/j-xp/

32. XPは、規律の乱れたカウボーイ・アプローチであるという攻撃とは対照的に、実際は極めて規律正しい、協調的なソフトウェア開発アプローチなのです。 ̶『XPエクストリーム・プログラミング懐疑編』

33. XPはソフトウェア工学コミュニティの聖域に直接挑んでいるのです。つまり、プログラマの地位を向上させることで、ソフトウェア工学が30年にわたって積み重ねてきた価値観をひっくり返そうとしているのです。 ̶『XPエクストリーム・プログラミング懐疑編』

34. XPの原則は単なる方法論やプロセスではない。プロセスの対極にあるものだ。 XPは私たちの業界でもっとも重要な運動である。私は、SEIやCMM同様、最終的にXP は今の世代に欠くことのできないものになるだろうと予想する。 ̶Tom DeMarco 『XPエクストリーム・プログラミング実行計画』序文より

35. その名前とそぐわないが、エクストリームプログラミングとはプログラミングについてであると同時に、人についてであり、そして人と人との関わりあいは、人生そのものである。 ̶『エクストリーム・プログラミング導入編』

36. XPとは

37. 1. 恐れに対処する 2. 変更コスト曲線を平らにする

38. 恐れに対処する

39. すべての方法論は、恐れに基づいています。 ̶Kent Beck 『XPエクストリーム・プログラミング入門』より

40. 恐怖は怒りに　怒りは憎しみに　憎しみは苦悩へ ̶スター・ウォーズエピソード1/ファントム・メナス Yodaの言葉 ̶『XPエクストリーム・プログラミング導入編』

41. ソフトウェア開発における基本的な問題とはリスクである ̶Kent Beck 『XPエクストリーム・プログラミング入門』

42. リスク ✓ スケジュールの遅延 ✓ プロジェクトの中止 ✓ システムの陳腐化 ✓ 欠陥保有率の上昇 ✓ ビジネスの誤解 ✓ ビジネスの変化 ✓ 無駄な機能の搭載 ✓ 要員の入れ替わり ̶『XPエクストリーム・プログラミング懐疑編』

43. プロジェクトのリスクは症状であって病気ではない ̶Andy Hunt 『XPエクストリーム・プログラミング懐疑編』より

44. プロジェクトに影響を与えている病気とは、無知と焦りという2つの魔物によって生み出されるのです。 ̶『XPエクストリーム・プログラミング懐疑編』

45. 無知 XPはチームを同じ場所に配置することで、前提を置くのではなく質問を行うことをチーム全体に奨励しているわけです。 ̶『XPエクストリーム・プログラミング懐疑編』

46. 焦りエクストリームプログラミングにおける計画プロセス全体は、開発者と顧客の間で計画の責任を分担することによって、焦りの問題に取り組んでいるのです。 ̶『XPエクストリーム・プログラミング懐疑編』

47. 開発を成功させるためには、プログラマとユーザーが自分たちの不安を認識し、権利と責任を受け入れられる文化 (環境) を創らなければならない。不安が認識され権利が受け入れられれば、自信を持つことができる。たとえ達成することが難しくてもゴールを設定し、ゴールに向かって協調する。不安のために作られた、自分たちを邪魔する構造を打ち壊す。 ̶『XPエクストリーム・プログラミング実行計画』

48. 権利と責任

49. XPのエッセンスビジネス側と開発側の意志決定の分離 ̶Kent Beck 『XPエクストリーム・プログラミング適用編』より

50. XPに登場するロール顧客プログラママネージャ

51. 顧客の役割リリース日を決めるスコープを決めるプライオリティを決めるプログラマからの質問に答える受入テストを書く受入テストを実行するリリースを受け入れる

52. プログラマの役割何かをプログラムするとき、どの位かかるかを見積もるということは完全に技術的な決定である。 ̶『XPエクストリーム・プログラミング実行計画』システムを分析、設計、テスト、プログラミングするストーリーの見積りをする

53. 外部組織と折衝するチームメンバーを集めるリソースを確保するスポンサーに進を報告するミーティングを手配するパーティを開くマネージャの役割

54. XPのマネージャが行わないことプライオリティ付けは行わない。 ➡それは顧客の仕事である。タスクの割り当ては行わない。 ➡それはプログラマの仕事である。ストーリーやタスクの見積りは行わない。 ➡それはプログラマの仕事である。スケジュールを自分だけで決定しない。 ➡それは顧客とプログラマで交渉する ̶『XPエクストリーム・プログラミングアドベンチャー』

55. マネージャと顧客の権利 1. マネージャと顧客には、計画のどの部分に関しても、いつまでに、何が、どのくらいのコストで達成できるかを知る権利がある。 2. マネージャと顧客には、全プログラミング期間を通して、最高価値を手にする権利がある。 3. マネージャと顧客には、自らが書いた再現可能なテストを通すことで、システムが機能することをちゃんと証明してもらい、現行のシステムの進度合いを知る権利がある。 4. マネージャと顧客には、考えを途中で変えて機能を差し替えたり、プライオリティを変更したりする権利がある。その際に特別に多額の出費は必要ない。 5. マネージャと顧客には、スケジュールの変更があったら連絡を受ける権利がある。なお、その連絡は、最初に決めた期限を守るため、どうスコープを減らすかを決めるのに手遅れにならないよう、十分速やかに行われなければならない。そしていつでも発注を取り消し、その時点までの投資に見あう、ちゃんと機能するシステムを手にする権利がある。 ̶『XPエクストリーム・プログラミング導入編』、『XPエクストリーム・プログラミング実行計画』

56. プログラマの権利 1.プログラマには、何が必要とされているかを明確なプライオリティとあわせて知る権利がある。 2.プログラマには、つねに質の高い仕事をする権利がある。 3.プログラマには、同僚や上司、顧客に助力を求め、それを受ける権利がある。 4.プログラマには、自ら見積りを行い、またそれを更新する権利がある。 5.プログラマには、責任を割り当てられてるのではなく、自ら責任を引き受ける権利がある。 ̶『XPエクストリーム・プログラミング導入編』、『XPエクストリーム・プログラミング実行計画』

57. 顧客についての補足

58. XPの顧客は複数形? ここで、私たちが「顧客たち」ではなく「顧客」という単数形の表現を使っていることに注意してほしい。顧客が何人いようと、つねにその意見は1つにまとまっていなくてはならない。 ̶『XPエクストリーム・プログラミング導入編』初期のXPにおける誤った思想について留意して読み進めていただくようお願いいたします。その留意点とは「顧客」がたった1人の人間を表した言葉ではないというものです。顧客という言葉は、開発チームと同等、あるいはそれ以上の規模の集団を意味しているのです。 ̶Kent Beck 『XPエクストリーム・プログラミング懐疑編』本書推薦の言葉より

59. チーム全体ユーザー (ビジネスの決定を下す人) はチームの一員でなくてはならない。世界中のどんな素晴らしい才能、技術、プロセスを以てしても、ユーザーが参加していなければ失敗するだろう。 ̶『XPエクストリーム・プログラミング実行計画』

60. 良いユーザー (顧客) 自分が働いている分野(ドメイン)の業務知識がある。もしくはどのように仕事が流れるかを理解している。開発の助けがあれば、どのようにソフトウェアがその業務分野においてビジネスの価値を生み出すかを理解できる。定期的に価値を納品することに意欲的である。そして、何も納品しないのではなく、たとえ少量でも納品することを恐れない。今必要なものと、後で必要なものを見分けられる。プロジェクトが成功してもしなくても、全ての責任を取る意志がある。 ̶『XPエクストリーム・プログラミング実行計画』

61. プランニング

62. リリース計画はユーザーとプログラマの共同作業である。 ̶『XPエクストリーム・プログラミング実行計画』

63. 唯一確信を持って言えるとすれば、開発は計画通りにいかない。 ̶『XPエクストリーム・プログラミング実行計画』

64. 計画を立てることは未来を予想することではない。ソフトウェア開発の計画を立てても、実際の開発は決して計画のようにはいかない。ユーザーはたとえ開発が計画どおりに運んだとしても満足はしない。なぜなら、ソフトウェアが納品される頃には、ユーザーは計画されたものではなく別のものを欲しがるからだ。 ̶『XPエクストリーム・プログラミング実行計画』

65. プランニングの目的私たちは、常に最も重要なことを行い、他人と効率良く調和し、予期せぬ事態に素早く対応することを確認するために計画を立てる。イベントは起きるものであり、計画は変更するものだ。物事が計画通りに進んでいるように見えるときはトラブルの兆しである。プロジェクトに起こり得る最悪の事態は、計画と現実の相違である。罠にはまらないように気をつけよう。計画を正直に保ち、計画は常に変更するものだと思っていよう。 ̶『XPエクストリーム・プログラミング実行計画』

66. 時間がない?? 負担が多いと感じるときは、十分な時間がないからではなく、仕事が多すぎるからだと考えるべきだ。これ以上の時間を作ることはできない。十分に時間がないということは、望みのない状態のことだ。そして、望みのない状態はフラストレーションを生み、間違いを起こし、燃え尽き、結局失敗する。仕事が多すぎることは望みを生む。その状況にいることを恨めしく思うかもしれないが、少なくとも行うべきことは分かっている。 ̶『XPエクストリーム・プログラミング実行計画』

67. 時限爆弾というのは時間に対するプレッシャーのことだとずっと思っていた。しかし、本当はシビアなトレードオフの決断に集中することだ、ということが分かった。 ̶ Jim Highsmith 『XPエクストリーム・プログラミング実行計画』より

68. 計画ゲームは組織の意志決定能力と、こういった決定を維持する能力に対するリトマス試験紙として考えることができます。厳しい選択を行う能力が無ければ、XPを成功させることなどできないのです。しかし、見積りは交渉次第で何とかなると信じている組織が未だに数多く存在しているのです。 ̶『XPエクストリーム・プログラミング懐疑編』

69. 割愛

70. ストーリーと見積りがあってはじめて、計画を変更すること。 ̶『XPエクストリーム・プログラミング実践記』

71. 割愛

72. ストーリーの見積り

73. 相対見積りほとんどのストーリーはすでに実装されたほかのストーリーと比較し、相対的な大きさに応じてポイントをつけていけば、かなり正確に見積りを行うことができる。普通のプログラマというのはこの比較を行うのが上手なようだ。 ̶『XPエクストリーム・プログラミング導入編』

74. 実時間での見積り実時間で見積もるほうが私の好みだ。そのほうができるだけ明確で、直接的で、透明性のあるコミュニケーションがとれるからである。 ̶『エクストリーム・プログラミング』

75. ほとんどの環境で上手くいくシンプルなルール今日できた分は、明日もできる ̶『XPエクストリーム・プログラミング実行計画』

76. がんばってみます「がんばってみます (We’ll try)」という言葉は、プログラマにとって人生で一番悲しい言葉となる可能性がある。チーム速度を上げようとがんばるのはいい。だけど、計画は希望ではなく、実際のスピードをもとに立てなくてはならない。最後の最後であなたの味方をしてくれるのは、プログラマたちの「できますように」という願望なんかではなく、実際の速度なのだ。 ̶『XPエクストリーム・プログラミング導入編』劇的瞬間は、開発側の人間が押し返すときにやって来る。開発側が押し返せなければ、プロセスはバランスを失う。 ̶Michael Feathers 『XPエクストリーム・プログラミング適用編』励ましの言葉は、全員が信じられる計画の代用にならない。 ̶『XPエクストリーム・プログラミング実行計画』

77. できないものはできない与えられたストーリーにかかる時間はコントロールできない。できないものはできない。あなたにできるのは、そしてあなたがしなくてはならないことは、スコープをコントロールすることだ。 ̶『XPエクストリーム・プログラミング導入編』

78. プログラマが約束できること何ができるかを見積もること自分たちのベストを尽くすことを約束すること何が起きているかについて真実を伝えることを約束すること ̶『XPエクストリーム・プログラミング導入編』

79. 注意点最初の見積りは要求と同じように信頼できない。最初の見積りは7%程度の正確さしかないのだから。顧客は、「信頼できる見積りを得るためには、時間と会話が必要だ」ということを受け入れなくてはならない。顧客が見積りを気に入らなければ、顧客が気に入るまで対話を続ける。「とにかく見積りはそう出しました。受けるなりやめるなり、ご自由に」という状況ではないのだ。 ̶『XPエクストリーム・プログラミング適用編』

80. 最重要事項ストーリーの見積りは曖昧なものであるが、1度イテレーション計画のタスクに分割してからは、大きな空振りをしてはいけない。 ̶『XPエクストリーム・プログラミング実行計画』

81. ここまでのまとめすべての方法論は、恐れに基づいている。プロジェクトに影響を与えている病気とは、無知と焦りという2つの魔物によって生み出される。 XPは、前提を置くのではなく質問できる環境を作ることによって、無知の問題に取り組んでいる。→コミュニケーション XPは、開発者と顧客の間で計画の責任を分担することによって、焦りの問題に取り組んでいる。→プランニング XPでは、顧客とプログラマとマネージャの役割と権利を明確に定義している。プランニングは顧客とプログラマの共同作業だ。XPでは、計画を正常に保ち、計画は常に変更する。この過程で、組織の意志決定能力が試される。できないものはできない。スコープをコントロールすること。ただし、イテレーション計画のタスクに分割してからは、大きな空振りをしてはいけない。

82. 変更コスト曲線を平らにする

83. 変更にかかるコストが指数関数的に増大する ̶Barry Boehm 『XPエクストリーム・プログラミング懐疑編』より

84. 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

85. ̶Barry Boehm 『Software Engineering Economics』

86. この有名なグラフを目にした読者の多くは、実際には2本の線が描かれているという点を見落としてしまったのです。 1本目の線は、様々な要因が重なって「大規模プロジェクトの保守フェーズでの誤りの修正は、要求フェーズで行われるよりも100 倍以上高価なものになる」という有名な前提を裏付けるものでした。しかし、グラフには、より小規模かつ、さほど格式張っていない2つのプロジェクトからのデータも点線で描かれていたのです。興味深いことに、Boehm氏でさえも「完全に要求を凍結することに工数を割くよりも、製品プロトタイプの最初の開発を始める方が、費用対効果として優れているかもしれない、...こういったプロトタイプ・アプローチに適している状況として、変更コストの比率が 4:6-1に増大する小規模な格式張っていないプロジェクト、およびラピッド・プロトタイピングが可能な問題領域を挙げることができる」と示唆しているのです。 ̶『XPエクストリーム・プログラミング懐疑編』

87. XPにおける技術的前提変更コストが時間と共に劇的に増大していくことはない ̶『XPエクストリーム・プログラミング懐疑編』

88. エクストリームプログラミングは、プログラムの変更は優れたツールがあれば簡単に行え、アプリケーションの理解はソースコードを読むことで可能になるという考え方を具体化したものです。 ̶『XPエクストリーム・プログラミング懐疑編』

89. XPの世界における正しい設計方法とは、設計の意図を直接コードの中に表現するということがすべてになります。 ̶『XPエクストリーム・プログラミング懐疑編』ソフトウェア工学の世界 ➡UML仕様からのコード生成に重きを置いている XPの世界 ➡オブジェクト指向プログラミング言語の高い表現力に価値を置いている

90. リファクタリング

91. コンピュータが理解できるコードを書くのは、どんな馬鹿にだってできる。優秀なプログラマは人間が理解できるコードを書くものなのだ。 ̶Martin Fowler 『リファクタリング』、『XPエクストリーム・プログラミング適用編』より

92. コードは、プログラマの意図を明確に伝えなくてはならない。 ̶『XPエクストリーム・プログラミング適用編』

93. リファクタリングに必要なものオリジナルのコードユニットテスト改善を証明する方法適用方法が分かっているリファクタリングのカタログガイドとなるプロセス ̶『XPエクストリーム・プログラミングアドベンチャー』

94. 注意点「『十分』は『完璧』にまさる」のだ。自分のコードからゴミをすべて取り除こうとする態度は立派だが、改善の余地があるからといってシステムを出荷しないようでは、プロフェッショナルとは言えない。「プロフェッショナルであること」と「完璧であること」は違うのだ。 ̶『XPエクストリーム・プログラミング適用編』

95. 割愛

96. ここまでのまとめ XPの技術的前提は、変更コストが時間と共に劇的に増大していくことはないということである。コードは、プログラマの意図を明確に伝えなくてはならない。テスト駆動開発、リファクタリング、継続的インテグレーションと表現力豊かなオブジェクト指向言語によって、設計の意図を直接コードの中に表現する。これによって、変更コスト曲線を平らに近づける。プロフェッショナルであることと完璧であることは違う。

98. 価値

99. XPの5つの価値 ✓勇気 ✓コミュニケーション ✓フィードバック ✓シンプリシティ ✓リスペクト

100. 勇気

101. ̶『ウィズダム英和辞典』

102. 情報をあつめ、分析をおこない、自分を納得させて不安をしずめた後に「最初の一歩を踏み出す」ための決断を下す。その意味で courage という単語は、勇気ではなく「実行力」や「決断力」と訳すべきかもしれない。 ̶小野剛『XPエクストリーム・プログラミング検証編』訳者あとがきより

103. 勇気のまとめシビアな意志決定を行う決断力。リファクタリングを行う実行力。開発側が押し返す (劇的瞬間の) 勇気。それがなければプロセスはバランスを失う。

104. コミュニケーション

105. いかに多くのプラクティスを実践しようとも、十分なコミュニケーションが取れなければXPは成功しない。 ̶『XPエクストリーム・プログラミング適用編』

106. XPはチームを同じ場所に配置することで、前提を置くのではなく質問を行うことをチーム全体に奨励しているわけです。 ̶『XPエクストリーム・プログラミング懐疑編』

107. 効率的なコミュニケーション Alistair Cockburn によると、もっとも効率的なコミュニケーションの形態は、「ホワイトボードを利用して会話する2人」だそうだ。それに及ぶくらい効率的なのが、「1つのテーブルで、ストーリーカードを触っているビジネス側の人間と開発者」だ。 ̶『XPエクストリーム・プログラミング適用編』

108. コミュニケーションのまとめプログラマは前提を置くのではなく、顧客に質問を行う。信頼できる見積りを得るためには、時間と会話が必要。プログラマと顧客は、ゴールに向かって協調する。そして、不安のために作られた、自分たちを邪魔する構造を打ち壊す。

109. フィードバック

110. イテレーションをまとめあげることは、いくつかのストーリーを完成させ、そして、次の成果へのドアを開く。これをチーム全体で共有すること。ピザを持ち込んだり、または、ほかのちょっとしたお祝いを考えるのだ。リリースごとに素晴らしい達成感が得られる。新しいビジネス価値を顧客は手に入れる。素晴らしい日だ。とっておきのシャンパンを出そう。プログラマは子犬と似ている。もしかしたら子犬より幼稚かもしれない。プログラマは先に進むために、絶えず激励を必要としている。 ̶『XPエクストリーム・プログラミング導入編』

111. フィードバックまとめパーティを開こう。不安や人間の弱さに向き合って、次の一歩を踏み出すために。

112. シンプリシティ

113. シンプリシティとは 1.すべてのテストをパスし、 2.表現しなければならないすべての「考え」を表現し、 3.どんなことも一度、ただ一度だけであり (Once and Only Once)、 4.(上の3つと矛盾しないで) クラスとメソッドの数は最少でなければならない。 ̶『XPエクストリーム・プログラミング導入編』

114. シンプリシティに必要なもの ✓シンプルに考える能力 ✓コードを理解し、変えていく勇気 ✓秩序が失われ、コードが破壊されてしまわないように、定期的なリファクタリングを行う習慣 ̶『XPエクストリーム・プログラミング適用編』

115. 「もっともシンプルな設計とはなにか」にこだわりすぎてはいけない。「もっともシンプルなものとは何か」をすぐに分かろうとするより、リファクタリングしようとする意志の方がずっと重要なのだ。 ̶Robert Martin 『XPエクストリーム・プログラミング適用編』より

116. シンプリシティのまとめリファクタリングをしようとする意志が重要。コードは、プログラマの意図を明確に伝えなければならない。

117. リスペクト

118. チームのメンバーが、お互いのことやお互いがやっていることを気にかけなければ、XPは破綻します。ソフトウェアを記述するその他のアプローチも同様でしょうが、 XPはこういったことに対して、特に敏感なのです。 ̶Kent Beck 『XPエクストリーム・プログラミング入門』、『XPエクストリーム・プログラミング懐疑編』より

119. エクストリームプログラミング (および一般的なリーダーシップ) は愛のなせる技だ。相手を尊敬することを知らなければ、うまくやりようがない。私はいつも、正しいことを一生懸命やろうとしている人たちに対する多大な尊敬を表に出すようにしている。そして、たいていの場合、みんなもそうしようと努力しているものだ。 ̶Ron Jeﬀries 『Enforcing Methods』『XPエクストリーム・プログラミング適用編』、『XPエクストリーム・プログラミングアドベンチャー』より http://c2.com/cgi/wiki?EnforcingMethods

120. リスペクトのまとめ XPのエッセンスは、ビジネス側と開発側の意志決定の分離。でも壁を作るわけじゃない。それぞれの立場を認める。

121. その他の価値

122. 謙虚な心

123. 信頼関係なくして、プロジェクトの成功はありえない。絶対的な誠実さをつねに心がけなければ、信頼関係は成り立たない。そして、謙虚な心がなければ、誠実さは身に付かない。 XPチームに入ったらいつでも「自分は馬鹿だ」と感じる準備ができていなければならない。 ̶『XPエクストリーム・プログラミング適用編』

124. 人のせいにしない

125. それはChetのミスだ誰が悪かったかではなく、何をすべきかを探ろうとした。すべての出来事に対して全員が責任を受け入れるということを、私たちに思い出させた。 ̶『XPエクストリーム・プログラミング導入編』

126. まとめ

129. http://agile.esm.co.jp/contact.html ご用命をお待ちしております。

130. 結局のところ、ソフトウェア開発は楽しくなければならないのです。そうでなければ、そのプロセスは間違っているのです。 ̶『XPエクストリーム・プログラミング懐疑編』

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

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

Recommended

More Related Content

What's hot

What's hot(20)

Viewers also liked

Viewers also liked(20)

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

Similar to 俺もエクストリームプログラミング入門(20)

More from Fumihiko Kinoshita

More from Fumihiko Kinoshita(20)