感想「Redmineによるタスクマネジメント実践技法」

Redmineによるタスクマネジメント実践技法

Redmineによるタスクマネジメント実践技法

devsumi2011 のセッションには参加できなかったけど、TiDD (Ticket Driven Development) は面白いと思います。
まちゅさんの記事の公開も結構昔なので、
「もうやってる」という現場も多いんじゃないでしょうか。

この本はそういった知識の集大成+実例になっててなんかすごいですね。

まえがき

プロジェクト管理の問題点

これまでのプロジェクト管理の問題点として次の3点が挙げられていました。

  1. 進捗管理 (Excelガントチャートだとタスク管理が大変)
  2. 情報連携 (構成管理ツール不在による必要資料の偏在、指示内容の不整合)
  3. イテレーション管理 (ポストイットを複数の視点で集計、管理するのが大変)

前2つは分かりますが、3番目は ?
ふつうの開発してる人達の話題で「ツールは問題じゃない」とか「ポストイット/ホワイトボードは最強」とかよく聞きますし、
人月的な観点からの問題と理解すると納得できます。
"3.8.1 PMBOK の EVM" あたりに繋がる問題意識のようです。

Trac による運用の失敗談

Trac による運用の失敗談は参考になりました。
特に、「チケットを乱発し放置してしまう」、というところは私も経験しました。

Redmineによるチケット駆動開発で運用を工夫した点

Scrum とかに傾倒してると違和感を覚える節です。
「1. チケットは作業指示書である」とか「2.プロジェクトリーダがチケットを常時保守する」とか。

しかし、学ばないプログラマの集団とか、人月いくらでお願いしているパートナーさんとかを相手にしている場合、
プロパー社員はこうせざるを得ないなとも思いました。自分でもやってしまいそう。

メンバーの成長を期待しつつも現実の課題を解決するための判断と理解しました。

第1部 チケット駆動開発技法

第1章 障害管理ツール (BTS)

ソフトウェア開発の難しさ
古の紙の帳票による進捗管理はいまだ現役ですよね。
何十MB もある ExcelWBS を印刷して進捗レビューをするとか。
Redmine でも Trac でもいいので、プロジェクトのダッシュボードを生成する方法を知りたいです…

BTS の歴史
OSS としての BTS の歴史的な変遷や、障害管理について記載されていました。
基本的な内容ですが、理解が曖昧なところもあったのでふむふむしてました。

第2章 BTSとツールの連携

OSS としての構成管理の歴史的な変遷が記載されていました。
バージョン管理システムを構成管理ツールと表現するのって普通なんですかね。

第3章 チケット駆動開発

「作業の進捗をチケットで管理する」単純で分かりやすいですね。
明記されてませんが、完了することで 1 つ以上の成果物が残る単位が作業だと思います。

機能的な観点で BTS・メール・スプレッドシートWiki・付箋の優劣を比較してます。
結論ありきですが、客観的にも異論はありませんね。

Redmine のチケット集計機能はいいですね。
でもそれ Trac で (ry。

第4章 チケット駆動開発のはじめかた

運用方式や、チケットの権限ポリシーが説明されています。
「補完チケット方式」はすぐにでも始められそうでいいですね。というか自分はすでにやってた。

権限ポリシーの「ワークフロー型」はいわゆる「担当者にボールを渡す」になりやすくて、
個人的にはどうかなぁと思ったりしてます。

システムテストでの実例は面白いですね。
WBS と併用するやり方で、WBS にない作業をチケットに登録したら、次のような数字になったとか。

システムテストのチケット 31
本番環境構築のチケット 42

WBS のほうにどれほどの課題があったのかは分からないのですが、結構多いなと思いました。
これだけの浮き作業が管理されなかったらと思うとぞっとする話です。

第2部 Redmineによるタスク管理

第7章 チケット駆動開発の実践的な運用方法

チケット関係ないけどリポジトリのブランチ運用とかの説明が分かりやすいですね。
この本に記載されているとか。読んだことなかった。

パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

パターンによるソフトウェア構成管理 (IT Architects’ Archive―ソフトウェア開発の課題)

第8章 チケット駆動開発を発展させるアイデア

PMBOK の EVM
EVM が計算できるとどう嬉しいのか理解できてないのですが、PMBOK というくらいですから
管理者層、経営者層を説得するためのよい数値なんだと思います。

測定できれば制御できる
「ソフトウェア・リポジトリ・マイニング」という研究分野があるとのこと。
リポジトリのコミットログを分析すればプロジェクトの健康状態を判断するよい指標が見つかるのではないかと考えてるので、
ちょっと調べてみたいキーワードでした。

第3部 RedmineTestLinkの連携

TestLink の実際的な使い方がみっしりと書かれてました。
運用方法に関するプラクティスだけでもとても参考になります。
TestLinkCnvMacroを使うとなんか無敵っぽいです。