PJで起きていること
明確なことと曖昧なことが混ざりあう
- 開発方法論は関係ない
- 繰り返している場合は明確なことが多い
明確なのが多い ウォーターフォール
曖昧なのが多い アジャイル
パッケージの適用にはウォーターフォールが向いている(繰り返しが多いから)
曖昧なことは明確にする
プロトタイピング フロントローディング
明確になったら計画を立てる
WBS(タスク、見積り、スケジュール)
曖昧なまま見切り発車しないといけないときもある
いつ発生するのか分からない
バグ、問い合わせ、仕様変更など、
「新しく発見したナニカ」
不確定なことにどうやって立ち向かっていくのか
不確定さを予測する
- このぐらいバグが出る
- このぐらい仕様変更が出る
「時間枠」の中で、その不確定さの幅に収まっているか判断する
タイムボックス型(アジャイル的に言うと)
時間の枠の中で、何が出来るかを考える
そこで「課題管理」が重要
新しく発生したナニカ
- 内容
- 発生日
- 担当者
- 重要度
- デッドライン
プロジェクトマネジメントの初期のレベル
小さい会社だとスケジュールも曖昧だが、
大きな会社だと、課題管理をしないと致命的
メモ帳で全てが回せるならそれでもいいけど。
課題管理の最強ツールExcel
自由にカスタマイズできる(マクロやバリデーション、フィルタ、ピボットな
ども出来る)
多くの人のPCで、印刷して共有できる
それだけじゃ足りない
仕事のバトン
仕事は一人じゃ解決(完結しない)
プロジェクトの構成要素が複雑で、スキルが広範囲に及ぶ
成果物を分解し、タスクにして、プロセスとして並べていく
例:テスト工程
- バグ発見
- 修正
- 修正したものをテストサーバにデプロイ
- バグの修正を確認
- テスターがバグを発見
- エンジニアが修正
- デプロイヤがデプロイ
- テスターがバグの消滅を確認
1人が複数の役割を兼任することもある
ありがちな問題
どれをリリースするのか？
もう直っているのか？
いつ直ったのか？
誰が担当するのか？
これらの問題はバトンがうまく渡っていないことが原因である
バトンを待っている人からしたら、いつどのようにバトンが渡っているのか
すごく気になるところである。
その課題がプロセス全体のなかでどこにあるのか
プロセスが非同期に実行されているなかで、全体として同期すべきイベントがある
全体としてどういう状況なのか
上記はExcelだけでは足りない(出来なくはないけど…)
チームとしてどのように問題、課題を共有すべきなのか
課題管理ツール(Jira)の実践
- 個別課題のオーナーや状態を管理
- 横断的にくくるフラグを制御
- 全体をリスト化できる
適用への道程(仕事のバトンの渡しかた)
まずはテスト工程(バグ管理)から
- テスターが問題をチケット化する
- リーダーがチケットをエンジニアに振る
- エンジニアがチケットを進行中にし、修正
- デプロイヤーはあるていどリリースするものが貯まるまで待つ
- リリース(1.0→1.2)
- テスターが再度判定
- OKだったらチケットをクローズする
担当者の切り替えだけでなく、状態の切り替えとバージョンの管理も行う
プロセスだけでなくフローも考える
テスト以外の適用箇所
顧客とのQA管理 オフショア先のチーム間など。遠隔地に有効
pdfで落とせるよ
設計者or顧客がチケットの中身を作成、確認し、チケットを作成する
双方向リンクを利用することで負荷なく運用できる
顧客→リーダー→エンジニア(バージョンも設定する)→デプロイヤー→テスター
もちろん、チケット管理システムだけでなく、レポジトリ管理やCIツールも
使えばよい
管理のコツ
- 起票のルールを決める
- 気遣い重要。特に言葉遣いは丁寧に(くだらないコメントの応酬はやめよう)
- 事実を書く(バグの書きかたも参考に)
- プロセスを決める(誰がクローズするのかが一番重要)
運用のコツ
- 初期はメンバーの教育も必要なので、チェッカーの運用が重要(啓蒙する人が必要)
- 抱えがちな人には棚卸しを定期的に促す(チケットを引き受けまくる御人好しにいがち)
- リーダーが状況を把握するのに使う(誰が遅れているかが分かる)
- 複数プロジェクトで使う場合は事務局が重要(情報資産の管理もあるので、誰にどのような権限があるのか把握する人らが要る)
応用篇
- 品質管理
- バーンダウンチャート
- コンポーネントや独自フィールド(バグの要因など)を利用した分析
課題管理ツールのもう一歩先
注意点
いわゆるチケット駆動開発はレベルが高い
アジャイルは、どのタイミングで新しい作業が発生するのか
分からないときに有効であり、作業発生のタイミングが
はっきり分かっているときはウォーターフォールでよい。
チケット駆動にしたってプロセスが安定するわけではない
(問い合わせベースで開発をやっているひとは、いやでもチケット駆動に
なっていくはずである)
運用・改善フェーズは良い
チケット駆動を意識するより、まずプロセスとフローをちゃんとすることが重要
- 計画的なものはJIRAとかを使わず普通にエクセルを使ったほうがよい
- JIRAは設定しすぎるとダメになる場合が多い
- タスクを階層化しすぎるのはよくない(無駄に親子関係を発生させるとチケットがカオスになる)
- 複数のコミュニケーションツールを併用するのはやはりよくない(電話やメールなど窓口を増やしすぎるとわけが分からなくなる)
勿論、JIRAで解決しないものは電話やメールを使ってもいいですよ。
まとめ
そもそも「時間管理」のほうが重要
- WBSなき課題管理ツールは失敗する
- 課題管理ツールに先立って、まずはタイムマネジメントが重要
- ルーチン化した状態(=運用)でもOK
時間枠の中で不確定なことを管理する
- 計画してても不安定なことはありうる
- いつどこでどのような問題が発生するのか分からない
使うならまずはバグとQAから
- 運用フェーズもおすすめ
- 管理は少しずつ複雑にしていく(複雑になったら捨てる)
- 仕事のバトンを渡していく工夫をする
- 課題番号を長く使う
なるべく長く使うことが重要
