闘うITエンジニア 「小さなチームのソフトウェア開発物語」(Gary Pollice Liz Augustine Chris Lowe Jas Madhur 杉本 宣男 杉本 宣男)|翔泳社の本
  1. ホーム >
  2. 書籍 >
  3. 闘うITエンジニア 「小さなチームのソフトウェア開発物語」

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





翻訳
原著

形式:
書籍
発売日:
ISBN:
9784798111377
定価:
3,520(本体3,200円+税10%)
仕様:
A5・344ページ

巨大プロジェクトでも、実は数人程度の「小さなチーム」で構成されている

本書はラショナル統一プロセス(RUP)、アジャイルプロセス、プロジェクト管理を扱った教科書ではなく、小規模チームがソフトウェアツールをどのようにして開発し、またなぜそうしたかをまとめた記録です。「実際にはどのようにするのか事例で教えてください」は、よく耳にする言葉です。成功、失敗のプロジェクト事例は、新しいプロセスを導入する際のキーポイントになることがよくあります。書籍やウェブサイトを利用して、理想的な進め方について何百ページもの記述を苦労して読むことはかなりの困難が伴います。理論に対して矛盾のない完璧な事例には説得力がありません。この本に価値があるとすれば、実際のプロジェクトで起こった真実、たとえばプロジェクトでの失敗、誤りの発生、制限などを著者たちがそれらに対して何を行ない、なぜそれがうまくいったのか、いかなかったのかを自ら批判の視点に立って読者に訴えているからです。

第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の実践原則

本書は付属データの提供はございません。

お問い合わせ

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

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

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

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

追加情報はありません。
この商品の「よくある質問」はありません。
正誤表の登録はありません。