プロジェクトキックオフの目次

細かい話はあるが、まずたたき台を起こす際に抑えておけばまぁ問題無い印象。
PMBOKとかこだわって考えると堅苦しい計画ができてプロジェクトメンバーの息が詰まるのでやめたい。

目次

[toc] とか書いとく

はじめに

本計画は、hogehogeのhogehoge対応におけるhogehogeプロジェクトである。
プロジェクト完遂までは定期的な再計画を行い、メンテナンスする。

目的

hogehogeのhogehogeに伴うhogehogeを完了させる。

コミュニケーション

コミュニケーション手段などを書く

管理方針

課題管理

課題管理にはhogehogeを利用する
※BacklogとRedmineとかExcel（吐き気がする）とか

運用フロー

図示とかしておくとわかりやすい

基本ルール（例えばBacklog）

• ステータスの定義
  • 未対応：新規課題を作成した状態
  • 処理中：課題に着手した状態
  • 処理済み：作業者が課題を完了した状態
  • 完了：チェック者が課題の完了を承認した状態
• 完了理由
  • 原則利用しない
• 件名
  • 〜が、〜を、〜する というように、主語/修飾語/述語を明確に記載する
    • 課題の目的が件名で理解できること
• 詳細/コメント
  • 5W1Hを意識し、具体的な課題内容を記述すること
  • 必ず課題/コメントに関する背景を記述すること
  • 課題を完了する基準となるゴール/成果物を記述すること

### 目的

### 背景

### ゴール

### 成果物

• 種別
  • タスク：通常の課題に設定する
  • 要望：明確な要望がある課題に設定する
  • 問題：解決すべき課題に設定する
  • 質問：プロジェクトに関わる質問事項に設定する
  • リスク：懸念を示す課題に設定する
    • 潜在的なリスクに気づく機会を増やすため、重要度の度合いに関わらず起票されることを期待
• カテゴリー
  • 計画：スケジュールに関わる課題に設定する
  • 環境：環境に関わる課題に設定する
  • 要件定義：要件に関わる課題に設定する
  • 開発：設計/実装/試験に関わる課題に設定する
  • リリース：リリース作業に関わる課題に設定する
• 発生バージョン/マイルストーン
  • 断続的な継続プロジェクトでは必ず抑える
• 優先度
  • 高：最優先で対処するべき課題
  • 中：通常の課題
  • 低：手の空いたときに対処すべき課題
• 担当者
  • 担当者が割り当てられない場合は、未設定とする
    • 残タスク等の気づきを発行できるようにする
  • 課題を現在保有している作業者を設定する
  • 質疑のやりとりが発生する場合に、担当者を変更することを忘れないこと
• 予定時間/実績時間
  • 予実管理に必須
• お知らせ
  • 通知したい宛先を指定すること

文書管理

Wiki

Wikiの目次を決める

ファイル

構成を決める

構成管理

Github/Subversion（無理）を使う

Git

• gitflowに従う
• pullRequestのテンプレートを定義する

# 概要

# 変更点

* 何を変更したか
* 変更した理由

# 残作業
残作業がわかってればレビュアーの為に書いておく

# 関連項目
関連するIssueとか書く

# 心配事、不安点など
〜が不安なので、重点的にレビューしてほしいとか

進捗管理

（ざっくり）定常的な進捗管理方法を定義する
※日報とか

ステークホルダー

体制

役割

凡例
◎：実行責任者　◯：説明責任者　△：サポート　▲：報告先

スコープ

前提条件

プロジェクトの前提条件を箇条書きで列挙する。
ステークホルダーで認識共有を行う。大事。

優先順位

全部大事！って無しにしてください。

成果物

各工程で作成される成果物など

計画

• プロジェクト計画書
• 予算管理表

設計

• システム概要図
• サーバ構成図
• ユースケース図
• シーケンス図

開発

• ソースコード
• レビュー記録（Github）

検証

• 試験計画
• 試験手順書
• エビデンス

環境

• 環境構築手順

リリース

• リリース計画

スケジュール

WBS

WBSにはhogehogeを利用する
※BacklogとRedmineとかExcel（ホント無理）とか

スプリント

定期的なイベントなど

リリース

リリース（ローンチ）日

コスト

想定される予算など
メンバーが流動的な場合、リソース計画も書いておく