エクストリームプログラミング

エクストリームプログラミング

エクストリームプログラミング

読了。 原著はもう10年前に書かれたものであるというのに、色褪せていない。 昨日と同じ事言うけど、色褪せていないと取るべきか、自分が進歩していないと取るべきか・・・。

第2版を読んだのが数年前なんだが、そのときからずっと転職したいと思い続け、結局いまもしてない。 転職するだけの能力がないから。

なんで転職したいと思い続けたのか。 新訳を読んで理由を思い出した。 XPチームへの憧れだ。強く憧れている。 憧れを抱いたまま死ぬのだろうか・・・。 いやだなぁ・・・。

第11章 制約理論

  • XP はソフトウェア開発の問題に対処するための価値、原則、プラクティスをまとめたもの
  • システム全体のスループットを改善するには最初に制約を見つけなければならない
  • 制約のキャパシティを増やすか、制約以外の負荷を下げるか、制約を完全に排除するか
  • モデルは地図であり、現地ではない
    • 人はモデルの中の箱ではない
  • たとえ評価や保護が得られなくても、自分自身でよりよい仕事をする覚悟を持たなければいけない

第12章 計画 : スコープの管理

  • 計画は未来の予測ではない
    • 明日起こりそうなこととについて、今日知っていることを表したものにすぎない
  • 満足度は質の高い仕事から生まれる
  • チームの全員が計画造りに参加すべき
  • 「昨日の天気」
  • 壁に貼ったカードは、透明性の実践

第13章 テスト : 早めに、こまめに、自動化

  • 自己防衛のために失敗を隠すのは、膨大な時間とエネルギーのムダ
  • DCI(Defect Cost Increase)
  • XP には 2セットのテストが用意されている
    • プログラマーの視点でかかれたテスト
    • 顧客やユーザーの視点で書かれたテスト
  • 自動テストはストレスのサイクルを断ち切る
  • コードとテストはどちらを先に書いても構わない
    • XP ではできるだけ実装前にテストを書く

第14章 設計 : 時間の重要性

  • パーマカルチャーとはバランスのとれたエコシステムにおける持続可能な生活の哲学および実践である
  • 建築のメタファー
  • 設計をするかどうかではなく、いつするか
  • XP の戦略は「常に設計する」
  • XP の多くのプラクティスは、進行中の設計コストを低下させるためのもの
  • Once and Only Once
  • Big ball of mud
  • 設計のシンプリシティを評価する4つの基準
    1. 対象者に適している
    2. 情報が伝わりやすい
    3. うまく分割されている
    4. 最小限である

第15章 XPのスケーリング

  • 人数
    • 統治分割戦略
  • 投資
    • 問題は XP そのものにあるのではなく、ソフトウェア開発の会計処理にある
      • 工場や製品の世界の会計モデルを何も考えずに適用すると歪みが生じる
  • 組織の規模
    • 新しく得た知識や力を自分の利益のために他人に押しつけてはいけない
  • 期間
  • 問題の複雑さ
    • お互いの専門分野を少しずつ学びながら全員を協力させること
  • 解決策の複雑さ
    • 継続的にデリバリーしながら少しずつ複雑さを削り取っていく
  • 失敗の重大さ

第16章 インタビュー

  • 純粋な XPプロジェクトでは欠陥がほとんど見られない
  • 生産性が 40% 向上したプロジェクトも
  • 解雇する勇気
  • 計画の項目は顧客が関心のあるフィーチャーでなくてはならない

第Ⅱ部 XP の哲学

  • 製造業の作業現場でうまくいったことがプログラミングの開発現場ではうまくいかないこともある
    • その逆も然り

第17章 はじまりの物語

  • 必要不可欠なことはすべて考えられる限り熱心に行い、それ以外はすべて無視
  • 「エンドツーエンドは思っているよりもはるかに遠い」

第18章 テイラー主義とソフトウェア

  • 科学的管理法
    • 観察、仮説、実験
    • 唯一最善の方法(The One Best Way)
  • 作業者は機械の歯車ではない
  • テイラーは作業者はとにかく「怠ける」と考えていた
  • ソフトウェア開発において、品質、アーキテクチャフレームワークはあまりにも重要

第19章 トヨタ生産方式

  • 後工程の品質保証が必要ないくらいにラインの品質を保つのがTPSである
  • 作業者個人が作業のやり方や改善について多くの意見を述べる
  • 最大のムダは「つくりすぎのムダ」
  • ソフトウェア開発には「つくりすぎのムダ」が満ちあふれている

第20章 XP の適用

  • XP は問題を解決するものではない
  • 自分で試すつもりのないことを他人に期待すれば、相手をリスペクトしていないことになる
  • 継続的改善とは継続的に、注意して、フィードバックに反応して、積極的に改善を受け入れるという意味
  • 学習は直線的では無い
  • コーチの選択
    • チーム内もしくはチーム外のリーダーシップが不可欠
    • コーチがいれば、学びをうまく促進させることができる
  • XP を使うべきではないとき
    • 実際の価値と XP の価値が相容れない組織
    • 秘密、複雑、孤立、臆病、不遜

第21章 エクストリームの純度

  • 目的は人間関係とプロジェクトの成功であり、XPクラブの会員になることではない
  • 認証と認定

第22章 オフショア開発

  • オフショアという言葉が好きではないので「マルチサイト」という言葉を使うことにする
  • 勇気はどんな状況でも重要
  • 仕事は賃金が安いとろこに流れるわけではなく、誠実性と説明責任があるところに流れる
  • コストの高い地域で生き残るには、効率性、誠実性、説明責任を高めることが不可欠

第23章 時を超えたプログラミングの道

  • あなたに必要なものを与えよう。必要かどうかは知らなくても構わない。
  • 調和とバランスはXPの狙い

第24章 コミュニティーとXP

  • 求められたときにだけ、自分の意見を提供すればいい
  • コミュニティーでは自分から話すよりも耳を傾けるスキルのほうが重要
  • 衝突を抑え込んでしまうのはコミュニティーが弱い証拠

第25章 結論

  • 最初に私自身を改善しなければ何も改善されない
  • XP の鍵は誠実性(integrity)