QLOOKアクセス解析
ホーム   »  Redmine
Category | Redmine

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

Redmineの導入事例紹介~ウォーターフォール開発の割り込み作業管理~

Redmineの導入事例紹介その1。
ウォーターフォール開発への一部適応について
あまり事例の紹介が無かったので自分自身の経験を紹介する。

◆プロジェクトの概要
・10人程度のチーム。プロジェクト全体としては2,3百人程度。
・チームの仕事は大きく以下の2つに分けられる。
 a) 案件開発
  新規機能開発。完全なウォーターフォール開発
 b) 市場問題対応
  市場リリースしたソフトの問い合わせや問題点対応。
  基本的に計画はなく逐次作業が割り込んでくる。
・構成管理/問題点管理は市販のソフトウェアで全社的に実現している
・開発は複数年継続して、開発⇒リリース を行っている


◆やりたかったこと
市場問題対応の仕事はいつ入ってくるかわからず
依頼も様々な部署からメールでくるため
作業管理が大変であったことと、作業のトレースも大変であった。
※対応した内容について半年後に再度問い合わせが来たり・・など。
あと、案件開発では基本的にWBSで管理でガチガチに進めるのですが
突発的な計画外作業については管理していない状態だったので
計画外作業の見える化をしたかった。
⇒要するに割り込み作業の管理をしたかったということですね。

◆案件開発に適応しなかった理由
今後は適応する計画だがとりあえずは以下の理由により一部適応とした。
・大規模開発ということもあり、計画外作業以外については
 既にプロセスやツールがが充実しており余り困っていなかった。
 顧客が必要とするビューは色々あるがRedmineの基本機能では
 達成することが出来ないのでカスタマイズしてから導入する必要があった。
 週次報告フォーマットなどは決まっているので
 そういったものを自動出力出来るようになってからでないと効果が薄いと判断
・導入にかかるコスト/効果を出す必要があったが
 ノウハウがないのでまずはRedmineの知識を深める必要があった。
 計画外作業だけであれば導入コストはほとんどないので
 顧客合意も不要であった。


◆方針
もともと実施しているWBSでの管理、構成管理/問題点管理、
課題管理、メトリクス計測等は改善の余地はあるが
十分なレベルであり、お客様を含めてプロセスが出来上がっているので
Redmineで全てを置き換えるのは一時見送り。
(単に適応するだけでは現時点の完成されたプロセスの方が効率が良いため)
ただし計画外作業については元々のプロセスではカバーされていないので
そこをターゲットにしてRedmineのチケットで管理を行う。

◆やったこと
①計画外作業については全てチケットで管理する
 顧客から作業依頼があった時点でチケット登録。
 メンバへはRedmine経由で作業依頼。

②問題対応/市場問い合わせ/見積もり
 といった分類で工数集計したかったので
 そういった作業分類でトラッカーを作成した。

③工数管理もチケットで管理
 計画外作業以外はメトリクス集計用の仕組みがあるので
 計画外作業についてのみチケットで工数管理して補完した。

④Wikiと文書管理での情報共有
 このチームは継続して開発を行うのでナレッジが重要。
 もともとは色んなフォルダに色んなナレッジ資料が散乱していたので
 いったん整理をしてRedmineのWikiと文書管理で一元管理をした。
 Wikiの記載は自由にすると統一性が無くなるので許可制とした。

⑤チケットには途中経過も随時記載していった。
 環境情報や調査結果も随時記載をしていき
 チケットを見るだけで作業状況や対応内容が把握できるようにした。
 基本的にはメール報告でそういったものは報告していたので
 メール報告時にその内容を貼り付けていくようにした。

⑥チケット登録と更新だけをメールの通知対象にした。


◆導入したプラグイン/基本機能の感想
①WorkTime
 ⇒工数管理に利用

②RedmineCharts
 ⇒工数を分類別に見たかったのとカッコがいいので
  Redmineの紹介用に利用した。

③CodeReview
 ⇒導入したがウォークスルー結果などの
  メトリクス集計が行いにくくなったので利用しなくなった。

④ガントチャート
 使いにくいので利用せず。
 割り込み作業だけ管理したので必要性も無かった。

◆良かった事
1.作業のトレースがしやすくなった
 これが一番改善された点。
 過去の作業について問い合わせされる事が多いのですが
 どういった経緯で、どういった判断で、どんな対応で
 工数はどれぐらいで・・といった事がすぐに回答出来るようになった。
 自然と作業移管も楽になった。

2.割り込み作業の見える化が出来た。
 どういった作業があって、どれだけ工数を使って・・
 といったものが数値で表現できるようになった。
 1回のイテレーションの中での計画外作業が見えるように
 なったことで次の開発時の見積もり工数が多く取りやすくなった

3.情報共有が進んだ
 一元管理することと、Redmineのものめずらしさで
 メンバが進んでWikiや文書を書くようになった

4.管理工数が少なくなった
 チケット一覧で残作業がぱっと分かるようになって、かつ
 作業経過もチケットに追記していってもらったので
 すぐに作業状況が分かるようになった。
 今まで日報でも記載をしてもらっていたが、日報は
 作業単位の時系列での報告ではないので
 作業の経過~現在の状況までを確認するのが面倒だった。

5.割り込み作業は優先度が高いものが多いのだが
 割り込み作業だけを管理したのでRedmineからメール通知は
 自然と優先度が高いものになった。
 なので狙ってはいなかったがメンバが優先して対応してくれるようになった。
 

◆悪かった事/要改善項目
1.案件開発も適応できるとBestだが
  ガントチャートやEVM表示などが出来なかった事や
  お客様指定のフォーマットへの自動出力対応が
  出来ていなかったので一旦あきらめた。
  カスタマイズすれば解決されるので
  一部適応しながらカスタマイズを行い完了後案件開発にも適応する予定。

2.Wikiの表現力が低く残念。

3.デフォルトのビューだけでは顧客への報告に必要な
  ものは満たせていなかったのでDBから取得して
  加工する必要があった。
  月別のチケット数やEVM等は出来ればデフォルトで装備して欲しい。
  

◆その他
構成管理については既に全社的に市販の
ソフトウェアが導入されており、
「チケットなしのコミット不可」というのは既に実現されていたので
RedmineのSCM連携はやりませんでした。
そういった環境がないプロジェクトは是非やるべきだと思います。
この連携により得られるトレース力というのはものすごく威力があります。

Redmineのチケット登録でのレコード生成調査

今の現場のお客様は独自でWBS管理(Excel)をされているので
Redmineからのインポート・エクスポートを行う必要があり、ExcelVBAでの実装を検討。
チケット登録でのレコード生成を調査したのでポイントを以下にまとめる。

・基本は issues テーブルのレコード生成。
 テーブルの詳細は本文の下に記載する。

・トラッカーIDやプロジェクトIDなどはそれぞれのテーブルのIDを指定するだけ

・ステータスIDは workflows テーブルで管理されているが
 
 指定するトラッカーによっては指定してはいけないID(利用不可)もあるので要注意。
 UIからだと選択できないですが、直接登録ではなんでも登録出来るので。

・先行するチケットや関連するチケットは issue_relations で管理される。

・チケットのウォッチャーを指定した場合は watchers にもデータ登録される。

・親子関係を作りたい場合、issues テーブルの lft・rgt 項目は要注意。
 このデータでチケットの入れ子関係を表現しています。
 以下の記事でとても分かりやすく説明されています。
 
 【Redmine】issuesテーブルのlft・rgtって?

・UI上でバージョンやカテゴリを追加した場合などはそれぞれの
 管理テーブルにもデータ生成されますが、今回の要件では動的に追加は無いので無視。

・添付ファイルをつける場合は attachments テーブルも生成する。
項目名
内容
関連するデータ
備考
id
チケットID。主キー。
 
 
tracker_id
トラッカーID
trackers.id
trackers.name
 
project_id
プロジェクトID
projects.id
projects.name
 
subject
題名
 
 
description
説明
 
 
due_date
期日
 
 
category_id
カテゴリーID
issue_categories.id
issue_categories.name
 
status_id
ステータスID
issue_statuses.id
issue_statuses.name
指定されたトラッカーによって
指定可能なステータスが変わる。
Workflowsテーブルで管理されている。
assigned_to_id
担当者
users.id
users.firstname
users.lastname
 
priority_id
優先度
enumerations.id
enumerations.type
enumerations.type
「IssuePriority」のもの
fixed_version_id
対象バージョン
versions.id
versions.project_id
versions.name
 
author_id
チケット作成者のid
users.id
users.firstname
users.lastname
 
lock_version
楽観的排他制御用ID
 
 
created_on
作成日
 
 
updated_on
更新日
 
 
start_date
開始日
 
 
done_ratio
進捗 %
 
 
estimated_hours
予定工数
 
 
parent_id
親チケットID
 
 
root_id
ルートとなるチケットのID
 
 
lft
チケットの入れ子を表現
 
チケットの入れ子(集合)を表す。
親子関係の場合、子チケットは親チケットの値の範囲に入るようにする。
rgt
チケットの入れ子を表現
 
 
is_private
プライベートチケットフラグ
 
0:OFF
1:ON

チケットの分類方法を考える

Redmineのチケット分類について私のプロジェクトでの例を紹介させて頂きます。

チケットの分類の方針は非常に重要です。
これを誤るとのちの工数集計も面倒になったり、場合によっては
必要なデータが残っていないという事態も発生します。

分類についてはそれぞれのプロジェクト特性によって
色々な方法があるかと思いますがご参考になればと思います。

◆プロジェクトの規模/特性
・10名~30名程度。開発フェーズによって増減。
・プロジェクト期間は半年~1年ぐらい。
・完全なウォータフロー開発。

◆やりたかったこと
1.機能 - モジュール - フェーズ - 作業単位で工数集計が可能であること
  ⇒例えば A機能のBモジュールの画面設計工数が集計出来ること
2.機能、モジュール定義はプロジェクト毎にカスタマイズが可能であること
3.仕様変更工数が「①」と同じレベルで集計可能であること。
4.機能-モジュール単位で進捗状況が確認したい。
  ⇒例えばA機能のXXフェーズでの残作業工数やチケット数。
  ⇒例えばA機能全ての残作業工数やチケット数。

◆チケットの分類イメージ
大きな方針は以下の4つ。
・機能や案件は『バージョン』で管理。
・フェーズは『カテゴリ』で管理。
・仕様変更は『カスタムフィールド』で管理
・その他の細かな作業はチケットの親子関係で管理。

イメージは以下の資料を参照。


◆参考記事
・実践Redmine カテゴリ設計にご用心

RedmineをWindowsのサービスに登録して自動起動させる

mongrel_serviceを利用した Redmine
Windowsサービス登録⇒自動起動方法です。

※以下のコマンドは管理者権限がないと実行出来ない場合があるので
 コマンドプロンプト起動時に
 ”管理者権限で実行”を選んで実行してください。
  スタートメニューからコマンドプロンプトを選んで右クリックで選択出来ます。

今回は以下の環境で試しています。
OS:Windows7 64bit
Redmine: 1.2.0

1.まずはmongrel_serviceをインストールしてお試しで起動してみる。
gem install mongrel_service
mongrel_rails start -e production

2.ここで一度アクセスしてみて問題がなければサービスとして登録する。
-N で指定しているのはサービス名です。
以下でWindowsのサービスとして登録されるので
後はコントロールパネルのサービスでスタートアップの種類を「自動」に設定する。
mongrel_rails service::install -N Redmine -c d:\redmine -p 3000 -e production


<<起動に失敗する場合>>
「`trap': unsupported signal SIGUSR1 (ArgumentError)」
こんなエラーが出ている場合は、一度 mongrel を削除してみてから
再インストールしてみて下さい。
アンインストールは以下のコマンドです。 以下のコマンドを叩いて
(1)mongrel-1.1.5-x86-mswin32-60
(2)mongrel-1.1.5-x86-mingw32
どっちを消す?と聞かれた場合は両方アンインストールして下さい。
削除したあとに、再度 mongrel_service のインストールをして見てください。
gem uninstall mongrel


◆補足
サービスを削除したい場合は以下のコマンドで。
mongrel_rails service::remove -N "Redmine"
サービス名の部分は環境に合わせて下さい。

Redmine1.2.0 でログイン時にエラーになる場合
コマンドライン起動では問題がないが、mongrel でサービス起動した場合
Redmine1.2.0 ではバグがありログイン時に以下のようなエラーが発生しました。
NoMethodError in AccountController#login
undefined method `destroy' for {}:Hash
RAILS_ROOT: C:/redmine


バグ対策がされているので以下の対処をして下さい。
・パッチの取得
  https://gist.github.com/471663

・「mongrel.rb」を config\initializers フォルダに置く。

・「mongrel.rb」のRailsのバージョンを環境に合わせて書き換える。
  今回の場合は 2.3.11 に変更してみました。
  ⇒if Rails.version == '2.3.11' && Gem.available?('mongrel' ...

定量的プロジェクト管理ツール(IPF)

現在Redmineを改造し、プロジェクト管理情報の一元化、
マネジメントの標準化と効率化を目指そうとしているのですが
似たような取り組みとしてIPAで開発を進めている
「定量的プロジェクト管理ツール(IPF)」というのがありましたのでご紹介です。

定量的プロジェクト管理ツール(IPF)
http://www.slideshare.net/hiroetoh/lt-20110730

こちらは現場で使用しているExcelやMSProjectなどの情報を収拾して
分析や診断などのレポートを行うアプローチで実施されようとしています。
現場では様々なデータが利用されますが、どのように汎用的に利用出来るようにするのか?
大変興味があります。

私の方で検討をしているのは少しアプローチは違い、
あくまでプロジェクト管理情報はRedmineのみで一元管理しようと思っていますが
最終的なRedmineでのOutputイメージは近いです。

こちらのツールは現場の情報を収集して統合してくるイメージですが、
私はRedmineで情報を一元管理して、顧客や上司などには異なるViewで
プロジェクト情報のOutput出力が出来るようにするイメージです。

どちらが効率よく出来るか?
またツールを見させて頂き勉強させて頂こうと思います。

現時点の私のイメージだと単純なWBSレベルのものについては問題ないのですが
評価フェーズなどでのバグ管理や評価数ベースでの進捗管理などについては
現実的なイメージが出来ていない状態です。
ちょっと単純なRedmineのカスタマイズだけでは利用しにくいかもしれないので
このツールのアプローチも評価フェーズでは必要かもしれないと思っています。
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。