Entries

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
この記事にトラックバックする(FC2ブログユーザー)
http://burnlight.blog3.fc2.com/tb.php/425-1e96876f

トラックバック

コメント

コメントの投稿

コメントの投稿
管理者にだけ表示を許可する

Redmineによるタスクマネジメント実践技法 を読みました

Redmineによるタスクマネジメント実践技法Redmineによるタスクマネジメント実践技法
(2010/10/13)
小川 明彦、阪井 誠 他

商品詳細を見る


blog プログラマの思索は良く読んでとても参考になっていましたが、その方の共著。


興味はあったのですが、ちょっと読む時間がかかりそうだと思って、買うのを控えてました。

年末に立ち寄った本屋に平積みになってたので、ざーっと読んで思いついたことだけメモ。


■まとめ
ざっくりとまとめてみると、
開発インフラの三種の神器のSCM, BTS, CI,+ テスト管理システムといったツール群をうまく使い+
使うルールを決めることによってようやく小規模リリースを主体とした、
アジャイル開発の良さを実感できるようになりました。


運用で現場を回すには、基本原則を理解するだけではだめで、特にツールが重要なのでしょう。
自動車を運転する時のメータの数やハンドルの機能と、飛行機を操縦する時のそれとは
大きくことなるように、
シンプルなウォーターフォールと、いくつものバージョンが並行に開発されるウォーターフォールでは
ルールや管理指標はおのずと異なります。
そこを解決するためには、ある程度のルールが必要です。


私も導入時に、運用についての資料を書いて、説明しますが、
ワークフロー、チケットの状態、背景など一式資料書きますが、結構面倒です。
この本と似たようなことを書いていますが、時間と意欲がないので、ここまで細かくは書きません。
しかし、初心者のためにはここまで必要なのですよね。
最後の方のプラクティスとか。


ウォーターフォールだと、仕様、設計、プログラム作成 などのフェーズになり、
成果物の完成するのが、200頁とかの仕様書ができるタイミング。
アジャイルだと2週間のイテレーションの単位。
チケット駆動だと、チケットの単位に作業を細かく区切って完了まで持って行く。

と、開発する単位が段々小さくなっていってます。


これを可能にするのが、ツールと運用ルール。



Tracではうまくいかず、 Redmineでうまくいった理由があまり書かれてませんでした。
Trac lightこれは、配慮なのでしょうか?自分では、

私も
バグ管理するのに
・紙
・自作cgi
・Trac
・Redmine
を使った経験があって、


Redmineを特に気に入っているのは、以下の2つ。


・ワークフローをトラッカー種類、ユーザ権限ごとに設定変更できる。それも簡単に。
 チケットのワークフローって、導入しても変更することがままあるのですが、
 これを簡単に変更できるのは気が楽です。
 たまにチケットの棚卸しをするのですが、偉い人にワークフローの見直しを指摘され、
 その場で、トラッカーの種類とワークフローの設定をredmineの画面を
 プロジェクタに表示し、これで良いですかね?って設定出来たときは、
 説明時間、設定時間の省略もできたのでとてもよかったです。



・プロジェクトをまたいだチケットの関連づけができる。
 マルチプロジェクトって、1DBで登録できるとかじゃなくて、関連づけられることが重要です。
 バグを中心に記録する開発者のみのプロジェクトと、ユーザが要望、使い方、バグ報告の質問を入力する
 プロジェクトを作成し、ユーザの質問チケットと、開発者の機能追加のチケットを関連付けすると
 いうことも行っています。
 開発者とユーザでは、チケットに入力する項目も、チケットのワークフローもかなり異なるので、
 同一プロジェクトでフィルタで分けるより、別プロジェクトにした方が便利なのです。
 でも、完全に分離するよりは、簡単に関連づけしてたどれるほうがよいので。



■現場発!! 下流工程の~
と表紙に書いてありますが、本の帯かと思ってました。
よっぽど協調したいからここに書いてあるのだと思うのですが、
上司指示でなく、草の根的に始めたといういうことなのでしょうか?



redmine といバグ管理システムを"バグ"以外にもどんどん適用してみた。
ということですが、、もともとredmine は、用途を"バグ"に限定してないとのでは?
Trackerの種類も選べますし。
読者の想定として、
日本では、紙の障害管理票で障害を小分けで管理するのは一般的だったけど
機能追加要望を小分けで管理するのはなかったからという配慮なのでしょうか。

ITSとしては10年以上前から沢山ありますし。
Comparison of issue-tracking systems
スポンサーサイト
この記事にトラックバックする(FC2ブログユーザー)
http://burnlight.blog3.fc2.com/tb.php/425-1e96876f

トラックバック

コメント

コメントの投稿

コメントの投稿
管理者にだけ表示を許可する

Appendix

プロフィール

burnlight

  • Author:burnlight
  • 忘れないように色々メモします。

ブロとも申請フォーム

この人とブロともになる

ブログ内検索

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