闘うITエンジニア　「小さなチームのソフトウェア開発物語」

第1章　はじめに

チームを編成する
　　ゲイリー
　　リズ
　　クリス
　　ジャス
　　ラッセル
次に進む

第2章　小さなプロジェクトで開発プロセスを使用する

小さなプロジェクトとは？
小さなプロジェクトで使うプロセス
　　RUPを小さなプロジェクトで使用する利点
RUPを使ってスタートする
　　重要な成果物
　　形式性レベル
チームをプロジェクトに引き入れる
　　ワークショップをスケジュールする
　　メンターを任命する
軌道にとどまる
追加情報
まとめ

第3章　人、プロセス、ツール

人
　　ハリーとグウェン
　　コミュニケーションについて
　　チームの組成
　　学習環境の提供
　　信頼こそチームの接着剤
　　前向きに反論する
　　要請の力
　　成果を認める
プロセス
　　最も重要な命令
　　リスクに対処する
　　わざわざ一からやり直す必要はありません
　　プロセスを自分のものにする
　　知恵を出す
ツール
自分自身のツールを作る
何が悪い方向に導くのか？
まとめ

第4章　プロジェクトを立ち上げる：プロジェクトメンバーがチームを組む

チームをまとめあげる
　　チームを組成する
　　雇用者と地理的分散に対応する
　　メンバーを失う
開発個別定義書
　　開発個別定義書で使用される規約
　　役割マップ
　　開発個別定義書で定義された成果物
　　開発個別定義書の重要性
進捗報告
方向づけフェーズ反復計画の作成
まとめ

第5章　方向づけ：進行を開始する

開発構想書：目標を設定する
　　プロジェクトの範囲をつかむ：構築するものと構築しないもの
　　われわれの利害関係者は誰か？
　　利害関係者を識別する
　　ブローシャーを作成する
　　機能を明確にする
要求を定義し管理する
最初のユースケースを定義する
　　ダイアグラムについて一言
　　機能外要求を識別する
プロジェクト管理
　　要求に優先度を付ける
　　計画する
　　リスク
開発環境を設定する
　　言語ツール
　　要求管理ツール
　　構成管理とバージョンコントロールツール
　　テストツール
　　コラボレーションツール
　　他の環境におけるツール
反復の評価
確かにウォーターフォールに似ている
まとめ

第6章　推敲：フレームワークを作成する

推敲フェーズの目標
　　安定を目指して：変更率を減少させる
　　実行可能なアーキテクチャを実現する
　　要求に詳細を追加する
テストとテスト計画を作成する
　　調査テストを忘れるな
　　単体テスト
PSP Tools アーキテクチャを作成する
　　ログイン：想定外の難しさ
ツール環境の変更
　　ForteからXDEへ―さようならGUIビルダー
　　Grooveの新しい使い方
データベースの作成を延期する
　　データベースを代替する
　　データベース設計
スコープ管理：早めにそして頻繁に切る
製品を導入できないってどういうこと？
推敲フェーズを評価する
　　実行可能なアーキテクチャをレビューする
まとめ

第7章　推敲の詳細

推敲フェーズに着手する
　　どのJavaプラットフォームを使うか？
　　データベースは何を使うか？
　　他の開発ツール
　　ソースコードの構造
PSP Toolsのユーザーインタフェース
　　ユーザーインタフェースの連鎖反応
　　最初のUI
　　UIのコードを探る
PSP Toolsのデータベース
単体テスト
　　計画―Test-Firstプログラミング
　　現実
　　ツールと技法
　　JUnitテストの解剖
　　テストスイートはテストをグループ化する
　　単体テストを実行する
まとめ

第8章　作成：PSP Toolsを構築する

環境を再度調整する
　　バージョンコントロール
　　障害追跡
　　要求管理への追加
作成フェーズの目標
作成フェーズの計画：プロジェクトの鼓動
　　リズムをつかむ
　　リリースノートによるコミュニケーション
　　実験し、間違いを犯し、そしてわれわれ自身の計画スタイルへ到達する
実装を加速する
　　恐怖という要因―1つの事例
　　恐怖に対処する方法
　　もう1つの短い物語
作成フェーズの中を前進する
　　データベースの変更に対応する
　　使用可能な製品を目指して取り組む
　　作成フェーズ第1反復
　　作成フェーズ第2反復
　　作成フェーズ第3反復
なぜ開発は加速したのか？
　　習熟曲線を超える
　　アプリケーション基盤を構築する
　　自分たちのソフトウェアを使用する
作成フェーズの残りの反復
誰でも時には友達が必要になる：ペアでプログラミングする
作成フェーズでテストする
チームメンバーの変更を予期する
まとめ

第9章　作成の詳細

ユーザーインタフェースを微調整する
　　メニューに取り組む
　　コンテクストメニューを追加する
　　時間項目と障害項目を表示する
　　ユーザーの好みを追加する
データベースを完成する
　　新しいフィールドを追加する―データベーススキーマを更新する
　　フィールド内の単一引用符使用を許す
テスト
まとめ

第10章　移行：PSP Toolsを納入する

移行フェーズとは？
移行フェーズに移行する
移行フェーズの目標
要求については？
　　終盤での変更を回避する
　　短い移行フェーズを目指す
　　例
　　障害は要求ではない
移行フェーズ中のコード変更
独立したテスト担当者の重要性
　　ブラウンサム
　　自分自身のソフトウェアをテストする
製品をパッケージングする
　　ユーザー文書を作成する
ユーザー研修を行う
　　さらに大きなグループの研修を行う
まだ完了ではないのか？
　　顧客を支援する
　　次バージョンを準備する
まとめ

第11章　事後検証：次のバージョンをどのように改善できるか？

事後検証を実施する利点
事後検証レビューを実施する
　　チームメンバー全員が参加する
　　アジェンダを提示する
　　目標を設定する
　　準備ガイドラインと作業内容を提示する
　　司会進行役を採用する
　　レビューから実行項目を作成する
　　恒常的に実行し、また立ち返る
　　楽しいことをする
われわれの事後検証レビュー
　　何がうまくいったのか？
　　何を変更したいか？
　　何を学んだのか？
　　結論
次のプロジェクトチームのために整理する
　　リファクタリング
　　最終的なダイアグラム
　　その他のプロジェクト文書
変化していく展望
　　チームコミュニケーションとコラボレーション
　　RUPの変化
　　IDE
PSP Toolsの将来
まとめ

付録 A　ラショナル統一プロセス（RUP）入門

RUPへの玄関口
　　フェーズ
RUPの主要な概念
　　役割
　　作業
RUPマイルストーン
　　方向づけの目標
　　推敲の目標
　　作成の目標
　　移行の目標
まとめ

付録 B　Personal Software Process（PSP）概要

Personal Software Process（PSP）
目標と焦点
結論

付録 C　eXtreme Programming（XP）入門

主要な価値
XPの実践原則

お問い合わせ

内容についてのお問い合わせは、正誤表、追加情報をご確認後に、お送りいただくようお願いいたします。

正誤表、追加情報に掲載されていない書籍内容へのお問い合わせや
その他書籍に関するお問い合わせは、書籍のお問い合わせフォームからお送りください。

利用許諾に関するお問い合わせ

本書の書影（表紙画像）をご利用になりたい場合は書影許諾申請フォームから申請をお願いいたします。
書影（表紙画像）以外のご利用については、こちらからお問い合わせください。