概要設計工程でRedmine導入してみた事例 - T/O

やっぱり事例だよねということで、自分とこの事例をまとめてみる。 お仕事の概要 規模 => 当初の見積もりは900時間。ただし、途中で2割くらい減った。 期間 => 2ヶ月 メンバー => 3~4名。自分込み。 2〜3名が設計書作成、自分はレビュアーとして参加しつつ雑務。 概要設計に先立ち、要件定義は完了。30項目ほど。 滝。 Redmineの設定など 「概要設計」をバージョンとして作成。 30項目の要件をチケットとして登録。 ターゲットバージョン => 「概要設計」 開始日 => 登録したその日 期限日 => 概要設計完了予定日の2w前 予定工数 => それぞれの見積もり値を設定 担当者 => 設定しない ユーザの権限は全て「管理者」。 5名程度なら問題ないんじゃないの？ チケットのフロー 新規 -> 担当 -> 作成済 -> レビュー済 -> 完了 運用方法 タスクの割り振り それぞれが

[katzchang]

チケットのフローについて追記。厳格な管理をどれだけ捨てるかポイントなのかな。/id:suVene 全体的な予定はチームとして管理できれば大丈夫なので、6人体制くらいまではコレで行けそうな気がします。

[sinsengumi-2]

[for:@twitter]

[devillikeaangel]

運用事例

[chroQ]

うーん5人月程度だと何とも言えないな...／タスクの大きさにもよるけど、このフェーズなら進捗率を0or100で取るのは結構キモかな。

[Nagise]

ウォーターフォールの概要設計で利用という事例は興味深いね。チケット駆動はアジャイルで使ってこそ真価を発揮だが、滝でも相応の効果は出るだろうな。

[imai78]

案件規模とチームの規模と使いどころがマッチした事例、かな？

[NOV1975]

ざっくりとした見積もりが大体合っててよかった的な雰囲気を感じなくもないなあ。

[suVene]

『個人に対して「なぜ計画より遅れているのか？」なんて尋問する必要がなくなった』 目先のタスクだけで全体的な予定が見通せないと不安になりそうだがそうでもないんだ。事例の規模の小ささにも関連？

[atsuizo]

管理ツールとしてだけでなく、管理手法としても面白い事例。IT土方の上流ぶった会社の管理屋アタマではなかなかマネできんなー。