F-nameのブログ

はてなダイアリーから移行し、更に独自ドメイン化しました。

ソフトウェア開発とプロジェクトマネジメント(情報学の技術第12回)

プロジェクトに限らず、チームで仕事をするのが大前提なのだから、講義で語られた視点は持っておかなければと思う。

 

プロジェクトマネジメント技術。知識体系。PMBOK。PMIが提唱。業種にとらわれないベストプラクティス。共通言語。PMBOKは知識だけ、それだけなら苦労はしない。業界個別の問題点には対応できていない。アジャイルソフトウェア開発。アジャイルマニフェスト。プロセスより個人と対話。顧客との協調。変化への対応。ウォーターフォールと異なる。スクラムやエクストリーム。V字モデル。プロセスが水が流れるように。一度でソフトウェアが完成する?ウォーターフォールを複数回。アジャイル開発は品質確保が難しい?見積もり誤差。精度を高める。TSP。SEI。CMMI。組織プロセス。パーソナルソフトウェアプロセス。チーム活動のマネジメント。ベストプラクティス。
ソフトウェア開発が難しい理由。いわゆる手戻りが生じやすい。現在の進捗をどこまで信じたら良いか?頭の中で考えることが多いので、成果が見えにくい。意識労働。開発者個人しか把握できない。個人がマネジメントしないといけない。自らの能力を把握して実行するというコミットメント。責任持って約束し実行する。PSP。チームとして活動する。自律的なチーム。柔軟に要求変更に対応。品質の確保。メンバー自身が進捗状況を報告。
プロジェクトチーム。個人の知識労働を管理。一般的なプロジェクト。プロジェクトマネージャーが中心。プロジェクトの詳細を理解してコントロール。マネジメント。仕事を管理している。タスクだけでは上手くいかない。人が考えるという目に見えない活動も。外部から判断するのは難しい。大規模複雑に、全体の理解が困難。TSP。自律的なチーム。メンバー全員が共通のゴールにコミットメント。自身が計画を持ち、全員が常に最高のパフォーマンスを。円。角がない。まとまりのあるチームを表す。メンバーが輪を作っている。チームリーダー。チームメンバー。チームコーチ。自律的なチームを構築。適切に動機づける。終了まで維持。プロジェクトマネージャーとチームリーダーの違いは?プロジェクトはタスクマネージメントが基本。チームメンバーに指令を。個人の活動をガイドして成功に導く。細かなタスクを指示する代わりに、適切な動機づけを。役割マネージャーを割り当てる。実行に責任を。チームへの帰属意識。標準的な役割は8種類。全員がいずれかの。工程を考える。設計マネージャー。設計作業につき設計標準が守られているか?優れた設計を出来るようにする。TSPのチームメンバー。プログラマーが?自分が担当した仕事以外に、一部のマネージメントが割り当てられる。チームへの参加意識と動機づけを高める。TSPコーチ。特定のプロジェクトに属していない?長期的な視点で支援。TSPのプロセス。複数サイクルによる循環的。立ち上げプロセス。9つのミーティングと自己分析。ビジネスゴール。マネジメントレビュー開催。役割分担とチームゴールの定義。品質計画の策定など。TSPの特徴は?役割分担とチームゴールの定義。メンバーに役割マネージャーを割り当てる。帰属意識を高める。共通ゴールへのコミットメント。次の工程をトップダウンに構築。作り込み率と除去率。過去のデータからゴールを設定。コミットメントして作業に専念。直近の作業の計画を。メンバー全員が生産性などのデータを持つ必要がある。TSPの習得が求められる。チームの全体計画を再構築。調整。自己分析。立ち上げプロセスをレビュー。自律的なチームを構築。コミットした計画に沿って実行。
詳細なプロジェクト計画。進捗を測るのに。獲得価値法。各タスクに。週に1度の。TSPでは価値の捉え方が異なる。時間で価値を表現する。見積もり時間。価値の獲得方法、終わったら価値を獲得する。何故ソフトウェア開発ではこのように考えるのか?タスクの見積もり時間を実績時間に差が出る可能性がある。価値の高いタスクを獲得。進捗が分かる程度まで工程を分割する。週次ミーティングが基本。10時間以下に。チームメンバーがそれぞれの実績データを統合する。TSPの週次ミーティング。チームメンバー全員がレビュー。品質マネージャー。プロセスデータの記録を参照する。正確に評価し適宜修正をする。院生のプロジェクトの進捗状況。ベースラインの計画。進捗見込み。獲得価値は?進捗を見積もる。見積もり精度。定量的なプロジェクトの状況を把握できる。
品質管理の技術。欠陥の早期発見と早期処理。すぐにレビューを。テスト工程で品質を高めることが多い?除去効率ではレビューの方が良い。成果物の品質も良くなる。テストを軽視している訳ではない。インスペクション。2人以上のエンジニアが他のエンジニアの成果物をレビュー。その開発者が修正できるように問題を開発する。4つのフェーズ。説明フェーズ。レビューフェーズ。ミーティングフェーズ。修正フェーズ。母集団の数を推計する。統計技法。結果がランダムになっているのが前提。成果物にある欠陥の合計数を見積もる。残存欠陥数。キャッチャー。独立して発見した欠陥。あまりにも多かったりレビューがいい加減だと問題。インスペクションの品質の評価は?インスペクションレート。1時間あたりにレビューされた成果物の量。インスペクション欠陥除去率。レビューを堅実に行った場合はテスト時間が短くなる。詳細設計とコーディング。1000行あたりの。品質プロファイル。TQI値。設計レビューの効率が改善。第2サイクル。
作業が意識労働。コミットメントが重要。計画通りの開発を目指す。ベストプラクティス。取り込める活動から試してみると良い。

 

情報学の技術 (放送大学大学院教材)

情報学の技術 (放送大学大学院教材)