SW構成管理において、ビルド管理はバージョン管理と表裏一体の関係。 ワンクリックビルドできないプロジェクトは、テスト工程の障害管理でリリース漏れやコミット漏れが多発して、進捗や品質に問題が出ているはずだ。 また、継続的インテグレーションを実践するには、ワンクリックビルドするためのビルドスクリプトが必要不可欠。 JenkinsのようなCIツールを使いこなすには、目的に応じたビルドスクリプトが必要になってくる。 最新版のモジュールをビルドするだけでなく、単体テストを実施したり、JavaDocや単体テスト結果を報告したり、FindBugsやLintなど各種メトリクスを出力するなど、ビルドスクリプトには色んな目的がある。 昔から使われてきたビルドツールはmakeだろうが、JavaならAntやMaven、Rubyならrakeが普通に使われているだろう。 Antを使う機会があったので、もう一度見直して

Redmineによる工数集計について考えたことをメモ。 【1】工数集計の問題点 チーム運営する現場リーダーではなく、売上責任を持つマネージャがRedmineに期待する機能は工数集計だろう。 マネージャにとって、プロジェクトの成功とは、品質の良いシステムを確実に納品できるだけでなく、売上がコストよりも高くて利益が出ることだ。 ITプロジェクトは殆どが受託プロジェクトであるから、SEやPGの人月計算、つまり工数集計が重要になる。 特に運用保守のように、一定の金額で契約している場合、当初の予定工数よりも大幅に実績工数がオーバーしたら、ビジネスでない単なるサービスに過ぎない。 だから、予定工数よりも実績工数が上回らないように、もし上回ったとしても、多少の赤字に抑えるようにマネジメントしなくてはならない。 しかし、工数集計の作業は面倒極まりない。 従来のExcelの場合、メンバーに月末に指定のExc

TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか？の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ