エクストリームプログラミング
ちょっと読みづらいけれど、良い本だった。
ソフトウェア開発手法の、方法論でなく原則からよく説明されている。良い開発スタイル・チームに共通する点をこの本では「価値」と呼んでいて、そこから具体的にどうすればよいか (「プラクティス」) の説明を展開している。ここでの「プラクティス」は今のなっては定着しきっていたり古臭いものもあるが、この本自体はアジャイル開発の基礎となっているものらしく、その原則となる「価値」は今でも間違っていない。なぜそれが大事なのかという根本まで立ち返って考えることは、技術を低レイヤーまで深掘りすることと同じで、しっかりと問題を理解しいろいろなケースに対応するために重要だ。開発フローやチームビルディングの方法論を学び・実践していくなかでこの本を読むと、今までの知識をすっきりと整理できて良いと思う。
この本で説明されている「価値」は、例えば「シンプルな方がいい」とか「適切な頻度のフィードバックを得る」などといった、抽象度の高く、このままなにかに使えるものではない。その分、この「価値」に反するフローや習慣があれば、「なにかおかしい」と感じるための指針として使えると思った。具体的な方法論自体は時と場合によって変わっていくので、その軸としての「価値」を抑えておきたい。
内容が古いせいか、あるいは「パターン」という仰々しい書き方のせいか、読みやすい本ではない。それでも、開発手法やチームを改善したい人にとっては、読む価値のある本だと思う。
以下は読書メモ。
価値
- コミュニケーション
いちばん大事なのはコミュニケーションという認識をもつこと- 情報共有も含める
- シンプリシティ
- システムも方法もシンプルな方がいい
- フィードバック
- 適切な頻度のフィードバック
- 従来よりも頻度を上げることを意識することのほうが多そう
- ノイジーなフィードバックが多すぎてもいけない
- フィードバックを元にした改善活動も含める
- 適切な頻度のフィードバック
- 勇気
- 何かをやるときに奮い立たせるために入れている項目かな
- これだけではだめ
- 尊敬
- 基本姿勢として
- 採用時にも
プラクティス
- 全員同席 (Sit Together)
- 同じ場所で働く
- チーム全体 (Whole Team)
- クロスファンクションで 1 チームとする。帰属意識を持つところまで
- 情報満載のワークスペース (Informative Workspace)
- 物理的なかんばんやダッシュボードなどをオフィスに作る
- いきいきとした仕事 (Energized Work)
- 長時間労働をしない
- ペアプログラミング (Pair Programming)
- ストーリー (Stories)
- ユーザーに見える機能単位で計画する
- 週次サイクル (Weekly Cycle)
- 振り返り、計画のリズム
- 四半期サイクル (Quarterly Cycle)
- 振り返り、計画のリズム
- ゆとり (Slack)
- 計画にはゆとりをもたせておく
- 10 分ビルド (Tne-Minute Build)
- ビルド、テストにかかる時間は短いほどよい
- 継続的インテグレーション (Continuous Integration)
- テストファーストプログラミング (Test-First Programming)
- インクリメンタルな設計 (Incremental Design)
- システムの設計に毎日手を入れること
導出プラクティス
- 本物の顧客参加 (Real Customer Involvement)
- 本当のユーザーをチームに入れる
- あるいはドッグフーディング?
- 本当のユーザーをチームに入れる
- インクリメンタルなデプロイ (Incremental Deployment)
- 一気に大きなリリースをしない
- チームの継続 (Team Continuity)
- 小さいチームを保つ
- 適切な分割の話?
- 小さいチームを保つ
- チームの縮小 (Shrinking Teams)
- 効率をよくするということ?
- 根本原因分析 (Root-Cause Analysis)
- 問題が起こったら深く追うこと
- コードの共有 (Shared Code)
- チームの誰でもどこにでもアクセス・修正できる
- コードとテスト (Code and Tests)
- コードを正として、コードからドキュメントを生成する
- 単一のコードベース (Single Code Base)
- 複数のブランチをメンテするようなことを避ける
- デイリーデプロイ (Daily Deployment)
- 頻繁にリリースする
- 交渉によるスコープ契約 (Negotiated Scope Contract)
- 期間・費用・品質を固定し、スコープを調整すること
- 利用都度課金 (Pay-Per-Use)
- 従量課金のプロダクト設計にするとフィードバックが得やすいということ
チームの役割
- テスター
- つまらないミスはプログラマーが自分で見つけるべき
- テスターは通常見つけられないようなケースを発見するなど
- 自動化をプログラマーと一緒に推進する
- インタラクションデザイナー
- ストーリーを書いたり、リリース後の状況から新たなストーリーの機会を探したりする
- アーキテクト
- 大規模なリファクタの調査・実施や、パフォーマンス・チューニングなど
- 小さく継続的に実施していく
- プロジェクトマネージャ
- チーム内のコミュニケーションの円滑化、顧客・サプライヤー・その他のチーム外組織とのコミュニケーション調整
- 進捗把握、報告、ファシリテーション
- プロダクトマネージャ
- ストーリーを書いたり、四半期のロードマップを引いたり、週次のストーリーを選択したりする
- 経営幹部
- 方針を示す、チームに的確な説明を求める
- 改善の監視、促進、円滑化
- テクニカルライター
- フィーチャーのフィードバックを早期に早期に提供、ユーザーと密接な関係性を築く
- CS・CE に近そう
- ユーザー
- ストーリー記述の支援、専門領域の意思決定
- プログラマー
- 見積もり、ストーリーをタスクに分解、テスト、実装
- 人事
- 人事評価と雇用
気になる本
テイラー主義はソフトウェア開発にはマッチしないと紹介されていた
