この記事はサムザップ Advent Calendar 2017の19日目の記事です。
昨日はsatotinさんのUnityからIL２CPPビルドしたXcodeプロジェクトにブレイクポイントを貼ってデバッグしたいでした。
昨日のsatotinさんありがとうございます。
戦いとは、常に二手三手先を読んで行うものだfujisyunです。
別の事書くつもりだったけれど
｢変更管理知らなかったです!｣って言う人がいたので、
変更管理についておさらい。
アジェンダ
- これだけは覚えていってね
- やること
- おわりに
これだけは覚えていってね
要求の変更やインシデントに対し、
変更管理することでプロジェクトへの影響を最小限にして対応する。
プロジェクトマネジメントの領域では、
プロジェクトの進行において、変更は起こりうるものと認識されています。
変更管理という行動はプロジェクト開始したときから行われます。
ニュアンスとしては、準備と考えてもらうとよき。
統合マネジメント PMBOKより
- プロジェクト憲章作成
- プロジェクトマネジメント計画書作成
- プロジェクト作業の指揮・マネジメント
- プロジェクト作業の監視・コントロール
- 統合変更管理
- プロジェクトやフェーズの終結
ちゃんとPMBOKにも載っているかんね。
※PMBOK=プロジェクトマネジメントの知識体系
参考:不確実性コーン
プロジェクトの進行は立ち上がりの時ほど、
コスト(見積もり)と結果の乖離が大きくなる可能性がある。
変更管理を実施する前に注意すること
計画、リスク洗い出し、振り返りがあっての変更管理。
そのようにしてプロジェクトのチームを強化していかなければ、
何度となく変更管理が発生しプロジェクトの失敗に繋がることになる。
計画
WBSや見積もり、変更を管理するには変更を監視するための計画が必要。
作業者が迷いなく進められるくらいに詳細であること。
抜けがちな作業としては、異常系や非機能系。
見通しが立たない範囲は別途計画を立てるようにするほうがオススメです。
リスク洗い出し
インシデントにたいして予め対策を立てておく。
Bプラン。
振り返り
次、同様の変更管理が発生しないように、
原因の追求と対策をしっかり行う必要があります。
変更管理
主に、変更を要求する者がプロジェクトマネージャーに対して変更を要求する。
- プロダクトの仕様変更
- 人員、機材などの変更
- スケジュールの変更
などなど、計画からの変更があった場合に起票する。
起票内容
主に3点くらいは押さえておくとよきかと。
- 対応者と作業内容
- 影響する作業
- 影響する条件(見積もりや予算、制約など)
プロジェクトを成功させるために詳らかにする。
これらの情報をもとに変更の決裁を行う。
おわりに
変更管理"だけ"の話なので
｢何かあれば変更すればいいや!｣｢変更してよかったんや!｣とみえてしまっていたらすみません。
それは文章の書き方がまずいか認識の間違いです。
プロジェクトの管理者は、変更管理が発生しないように
計画、リスク洗い出し、振り返りなどを実施する必要があります。
そして、もし変更管理が必要になった場合は、詳らかに情報を共有しながら、
プロジェクトの成功へ向けて最小限の影響でおさまるよう努力しましょう。
それがプロジェクト管理者の義務です。
変更管理が発生しなければしないほどプロジェクトの成功の可能性が高くなってくると思います。
プロジェクトは変更が発生するものですが、その変更に柔軟に対応出来るよう常に準備して進めましょう。
ということで明日はyou1933さんで
『Unity ちょっとシェーダーで遊んでみた』のお話です。
you1933さんのシェーダーテク楽しみっす!
では、よろしくおねがいします!