WBS（Work Breakdown Structure）によるプロジェクト管理
ソフトウェア開発プロジェクトでは、短期開発の要求が高まっている。受託開発も例外ではない。特定の顧客から長期に渡って大型案件を請け負っている場合でも、開発期間はますます短縮される傾向にある。 納期に対する高い要求を満たすには、プロジェクト管理が重要である。正確な見積もりと、的確な進捗管理ができなければ、短期開発では容易にデスマーチに陥ってしまう。 筆者の開発プロジェクトでは、WBS (Work Breakdown Structure) を使ったプロジェクト管理を導入した。WBSは見積もりのための強力な道具として広く使われている。筆者はさらに、実績も管理できるようにWBSを拡張し、見積もりから進捗管理まで一貫して管理できる手法を確立した。 ここでは、筆者が拡張したWBSの書き方と、それを使ったプロジェクト管理の手法を提案し、実際の開発業務に適用した経験から得られたWBSの運用ノウハウを紹介する
日本人の器用さがプロジェクトを失敗させる― ＠IT自分戦略研究所
皮肉なことに、プロジェクトと失敗とは相性がよい。納期どおりにできなかった、要求どおりにできないことが多い、機能を削減することが多いなど、もともとの目的、スコープから、後退したプロジェクトの経験を持つITエンジニアは多いに違いない。なぜ目的どおりにいかないのか。どこを改善したらいいかを本連載で明らかにし、処方せんを示していきたい。 WBS作成がプロジェクトマネジメント高度化の第一歩 WBS（Work Breakdown Structure）を明確にすることは、プロジェクトマネジメントを高度化する第一歩である。PMBOKでは、スケジュールの作成、予算の作成など重要な計画はすべてWBSをベースに作成する。また、多くのシステム開発やソフトウェア開発も、WBSの定義を行うことを前提としている。 WBSとは、プロジェクトで実施する作業を細分化し、階層構造で示したものである。これがないと、本来であればシ
人と人をつなぐ技法「チームビルディング」
「チームはできるものではなく、つくるもの」。この視点はありがたい。チームをまとめる立場なら、この視点+技法は必須。プロジェクトチームから町内会まで使える。 好むと好まざるとにかかわらず、社畜でいるかぎり、三十路も後半になると、一匹オオカミでいさせてくれない。「面倒みてやれ」という暗黙のメッセージとともに、何人か付けられる。たいていは、数回の毎朝ミーティングでチームらしくなってくる。 これが10人、20人のプロジェクトチームになると話が違ってくる。さらに、「思惑」「肩書」パラメータが追加されると厄介だ。以前のわたしは、アイスブレイクをいくつかと、赤ちょうちんぐらいしか知らなかった。仕事を通じてチームは形成されるものだと思っていた。 ところが、本書では、チームをつくる方法があるという。短期間で活性化したチームとして機能させるためのメソッドが紹介されている。[アジャイルレトロスペクティブズ]がチ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
