Ship It!読了

Ship It! ソフトウェアプロジェクト 成功のための達人式ガイドブック

どのプラクティスもだいたい

• 概要
• ヒント
• どこから着手するか
• そのやり方は正しいか
• 警告サイン

のような構成となっていて非常に読みやすかった。
とりあえずTODOリスト(作業リスト)に優先度を割り当てることから始めてみるかな。

以下メモ

ツール、プロジェクト管理

• バージョン管理
  • 米国IT企業の40%はバージョン管理システムを使用していない
    • 意外に高くて驚き
  • 紙ぺら１枚のクイックスタートガイドを作る
    • これは他のツールでもすべきですね
  • 一部のバージョン管理システムはファイルを定期的に「食べて」しまう
    • 名前伏せないではっきり言ってほしい。VSS?

• ビルド
  • 初日にビルドスクリプトを作る
  • ビルドをIDEに依存させない
    • ビルドマシン(CI用)でビルドできるように
    • 同じIDE使用の強制を避ける
    • 同じIDEでも設定変更等を全員に伝えるのは困難

• 自動ビルド
  • リグレッションテストをCIシステムで実行すれば効果的
  • ビルド情報をメール、RSS、X10モジュール(LavaLamp、AmbientOrb、etc)等で通知
  • 手始めはローカルで環境を構築してみる

• BTS
  • 警告サイン「BTSへの入力が査定に使用されている」

• 作業リスト
  • 必ず優先度を割り当てる
  • 関係者に公開されている
  • 随時変更
  • 見積もりを行う

• 毎日のミーティング、コミュニケーション
  • 短時間で行う。一人の発言時間は１分〜３分ぐらいがベスト。
  • 問題の確認は行うが、解決は行わない。
  • 長いミーティングが常態化している場合、バーンレートを計算してみる。
  • ミーティングでは時計回りに発言を求める(不意打ちを受けた感じを避けるため)
  • ミーティングの議長役は持ち回りにする(ミーティングをリーダーを育てる為に利用)
  • 議論が長期化しだした場合(特定の問題について解決策のアイデアを出し合うのを関係のないメンバーが聞いている状況等)、議長がミーティング終了後に協議するよう指示する

• コードレビュー
  • 小規模なコードレビューを頻繁に行う
    • 数十人が関与して準備に何日間もかかるようなThe Mighty Awful and Dreaded Code Reviewを避ける
    • 少量のコードに限定する
    • レビュー担当者は多くても2人
    • 頻繁に(場合によっては1日に数回)実行する
  • ペアプログラミングのような敷居の高いプラクティスの別解
  • コミットの際のコメントにレビュー担当者の名前を書く(未レビューのコードはコミットしない)

曳光弾開発(Tracer Bullet Development:TBD)

• システムオブジェクトを定義
  • アプリケーションを上位レベルで複数の層に分割
    • クライアント層
    • Webサーバ層
    • データ処理層
    • データベースアクセス層
  • それぞれが単独で動作する
  • それぞれをチーム(個人)が単独で開発できる
• 複数のチームが協力してインターフェースを定義
  • メソッドシグニチャ
  • 通信方法
  • サーバのタイプ
  • アーキテクチャの設計はグループ作業として行う
• インターフェーススタブを記述
  • 全てのインターフェース定義が一通り完了するまで機能の実装は行わない

boolean login(String userName, String password) {
    return true;
}

• 各層間の呼び出し、応答を可能にする
  • ここで最初のマイルストーン完成！
    • 数ヶ月を要して最初のマイルストーンが完成する従来の方法とは異なる

boolean login(String userName, String password) {
    //実際にはDBアクセス層はDBにまだアクセスしない
    String realPassword = getPassword(userName);
    Boolean login = false;
    if (realPassword.equals(password)) {
        login = true;
    }
    return login;
}

• 実機能をスタブに実装
  • 各層間のAPIの変更は両チームの合意が必要