redmine.tokyo 第10回勉強会に行ってきた

5/14に渋谷にある dots. にて、 redmine.tokyo 第10回勉強会に参加したのでメモ

■Redmine本体に関して

Redmineを開発している丸山さんがいらっしゃっていたので、Redmine開発の現状が聞けて興味深かった。

Redmine使っていて見つけたバグや機能改善などは、下記により報告すると良いらしい

twitterでつぶやく（ #Redmine タグつけると効果的）
Redmine本家にチケットを作成
- 発生した環境（OS、DB、Redmine、ruby、railsの種類やVer.、Redmineのプラグインの有無など）を記載
- テストコードがあるとさらに効果的（むしろ無いと厳しい）
- 再現手順大事

また、チケットを登録する場合は、Submissions on redmine.org をよく読んでチケットを記載すると良いとのこと。

一番驚いたのは、現状、アクティブなコミッターが2人しかいないという事。

後、Redmine build status ってサイトにて、色々な環境で常時テストしている事。
これだけテストしているので、安定しているのだと納得した。
環境違いだけでなく、テストコードも沢山あった。これって、Ruby開発者ならとても参考になるのではないだろうか。

また、丸山さんはバグの修正やrails5の対応で手一杯で、新しい機能をどうこう考える余裕は1㍉も無いとか。。。

■View Customize Pluginの話

作者である @onozaty さんの話が、とても参考になった。
どうやっていじるかがこれで分かったので、これから積極的に触っていこう。

View customize pluginを使いこなす from onozaty

www.slideshare.net

後、 @netazone さんのView Customize Pluginの活用事例について。
細かいところだけど、効果的な事例ばかりで、すごく参考になった。

ある工場のRedmine画面カスタム【View customize plugin 活用例】 from Kohei Nakamura

www.slideshare.net

■メトリクスの話

Redmineの作業時間を使うのはすぐに思いつく話だけど、運用にのせるのがとてもむずかしい。
ディスカッションや懇親会でも話題になったが、結局回している所は、いずれもトップダウン(-_-;)
すごかったのは、勤怠管理の1日の作業時間と一致しないと合わせるよう指示されるところもあるとか・・・(Redmineアレルギーなりそう)。

押し付けでは、適当になるだけだし結局のところ効果薄そう（実施者の自己満な感じがする）。
入力する人がポジティブな気持ちで入力してくれるような何か良い手段って無いのかなぁと思うもののなかなか思いつかない。

思いつく手段としては、、、
今日やるチケットをリスト表示して、スタートとエンドボタンで時間を計測して、RedmineにRESTで反映するとかするようなアプリでもあればまだやりやすいかも。
もしくは、ポモドーロ・テクニックと組み合わせて、1セット分計測したらリスト化済の一覧に割りつけて反映するとかってすると、生産性向上の一環として考えてもらえれば、メンバにも浸透するのではないかと妄想してみた。

また、@yohwada さんの「ソフトウェアメトリクス概要」がとても説明が細かくて、メトリクスについてとても参考になった。

ソフトウェアメトリクス概要 20160514 from Yutaka Ohwada

t.co

メトリクスは、何か解決したい問題があったり、何か悪い事が起こる前兆を察知したりするって目的のもとに、
モデルを定義して、そのモデルに必要な各種メトリクスを選んで計測し続けて、可視化するものだと思う。

なので、あれだけ沢山のメトリクスを見たら、目的に応じたモデルの定義方法とそれに紐づくメトリクスが何かって関連性とか知りたくなってきた（どこかにまとまっていないものかなぁ）。