タグ: 47redmine

shinagawa.redmine 第2回勉強会

日付:2012/01/21

URL: 第二回勉強会 – shinagawa.redmine – Redmine

場所:IPA様会議室

shinagawa.redmine 第二回勉強会 – Togetter



数千人が利用する楽天redmineの過去と未来

ご本人によるコメント付きスライド↓
数千人が利用する楽天Redmineの過去と未来 #47redmine | 世界

2008年に導入

最初は1人、そして2~3人
10人で使ったら失敗して当時は全く相手にされなかった

2009年4月

空いている仮想サーバにインストールして利用(mem 516M)
64ユーザ
たまに固まるのでcronで再起動していた

プロジェクトを細かくすると、重みのかけかたで放置されやすくなるので、プロジェクトを分けすぎるのはダメと気づく

進捗が見えるプラグインを作成・導入した

redmineの活用、進捗の見える化、ユーザが拡大

2009年9月

ユーザ数拡大によりWEBRickの限界が見える
340ユーザ

問い合わせをredmineで管理するようにした。
具体的な利用方法はwikiに書いた(wikiはredmineのではなく、別のを利用)

細かい工数入力を実践→めんどくさいので半年でやめた
そのかわり成果を見ることに(どれだけチケットを消化したか)
バーンダウンチャートプラグイン
パーキングロットチャートプラグイン → 社内でも成功したプラグイン

プラグインは見てすぐわかるシンプルさが重要

2010年

告知しなくてもクチコミで広がっていった。結果、登録ユーザが1000人超える(所属エンジニアの60%を占める)

redmineのバージョンアップをこまめに行った。

仮想サーバでは処理しきれなくなったため、リアルサーバに切り替え
WEBサーバの2台化やSVNの負荷が問題になり、SVNサーバのスケーリングを行う

1つのプラグインで全員を止めてしまう事象が発生する
(プラグイン内でのSQLによっては固まってしまう。そのプラグインを見ないようにすると正常に動く)
全文検索を使うのは厳しくなった

最近

アジャイルコーチとなって教えることとなり、redmineは問い合わせ管理ぐらいしか使わなくなった。

タスクボード+バーンダウンチャート(手集計)+日めくりカレンダーのアナログツールを使用

タスクボードの写真を撮って記録。ローコストで手軽

徹底的に見える化を行うこと

2011/秋頃:4,100ユーザ、160,000チケット、2,500プロジェクト
redmineがあると使ってしまうが、本当に必要かを考えるようにした

予想以上に広まった結果、無茶な利用をしないようにルールを決めて利用することに

融通が聞かないようになる

独自redmineが使われるように

「個人の対話が重要」

redmineでも日本語全文検索

利用目的

チケットドリブンのサポートツールとして利用

OSS版ITILツールとして

商用でチケットドリブン型ツールもあるが、高い、技術が古い、機能が多すぎる

運用現場に導入した→状況の共有に効果がでた

欲が出て情報の共有をしたくなった
「ドキュメントの中のどこに書いてあった」を知りたい

→文書管理と紐付けたい→システムを統合へ

変更内容

DMSFの修正
Hyper Estraierを使用するようにした

linuxでやったら簡単に実装できたが、Microsoft Officeのドキュメントが扱えない
→OpenOfficeサーバで抽出させることに

少し遅くてもいいからインデックスなしでの検索がほしい

今回の方法は、大規模化やセキュリティに課題あり

プラグイン開発ガイド

プラグインタイプ

  • wikiマクロの追加
  • redmineの機能拡張
  • 管理データの追加

ALMinium

Redmineと便利なプラグインをまとめたインストーラー

3種の神器(yum, Git, ALMiniumのインストーラー)でらくらくインストール

LT

redmineチケットにおけるプロジェクト火消し戦略

ケーススタディ

  • 終了済みバグ、タスクが大量に残る
  • 優先度や期日が有名無実化
  • チケットのドキュメントがGoogle Docsなどで併用して存在する
  • 次から次へとタスクが追加
  • 大量のチケットが同じ担当者

対策

「トリアージ

納期を遵守するために、作業に優先・非優先の観点で順位付けをおこなう
機能・人員・時間・品質を調整

「効率化」

チケットの初期化時

  • ツールをRedmine一本化
  • 棚卸と全チケット化
  • 最小作業時間5分以上かかるものをチケット化
  • 1日以上のものは分割
  • 担当者名を「社名 未担当」という形で割り当てる
  • 優先度、開始日、期日を設定する
  • 優先度と未担当のカスタムクエリを追加して、一覧化

チケット運用時

  • チケット管理者を立てる
  • 理想は専任
  • チケットフローを簡略化
    完了時コメントはテンプレ化
    担当者が作業を完了したら管理者に担当を変更する。その後のステータスの処理などを管理者が一手に引き受ける

一番大事なのはモチベーション

redmineのPDF文字化け問題とその修正

資料参照

Redmine Graph Activitiesプラグイン

meumacha/redmine_graph_activities – GitHub

誰が、いつ(時間、曜日)、何回コミットや変更されたかを棒グラフで表示するプラグイン

時間別、曜日別のコミット量を視覚化することで、作業担当者の行動特性がわかるようになる(朝方、夜型など)

○○からのメッセージをお読みください。(仮)

管理者から利用者に伝えたいこと(バージョンアップ・メンテナンス)を周知させたかった

  • 専用ページを作ったが、見に来ないといけない
  • メールを送ってみたが、見てくれない

バナー表示ができるプラグインを作成した

System Notification – r-labs – Redmine

CandyCaneについて

Downloads for yandod’s candycane – GitHub

PHP製Redmine

  • PHPなので、だいたいどこでも動く
  • PHPなので、プラグイン導入時に再起動の必要がない

WordPressを参考に

  • インストール 1分以内
  • 管理ページからプラグインの管理(追加・削除)ができる
広告

shinagawa.redmine 勉強会 第一回

URL: shinagawa.redmine – 第一回勉強会 – Redmine

場所:IPA様 会議室

日時:2011/09/08 19:00 to 21:00

Toggetter:第1回品川Redmine勉強会 – Togetter

1.障害管理からチケット駆動開発へ~ソフトウェア開発の3種の神器 (@akipii)

【公開】第1回品川redmine勉強会の発表資料「障害管理からチケット駆動開発へ~ソフトウェア開発の3種の神器」 #47redmine: プログラマの思索

Excelによる障害管理の課題

  • バグ情報が散在しやすい
  • バグ修正と検証のワークフローが複雑
  • リリース管理が大変

BTSの特徴

  • 障害管理のためのシステム
  • バグ情報をチケットで一元管理
  • チケットのステータスでワークフロー制御
  • 終了チケットをリリース履歴として残せる

BTSからITS(課題管理システム)

  • 障害だけでなく、課題や要望をチケットにする
  • チケット駆動開発が誕生
  • ワークフロー管理をソフトウェア開発全般に拡張
  • トレーサビリティでの変更管理をサポート
  • ツール連携で新しい運用方法を見出す
    →ITS+Wiki+SCM+CI

アジャイル開発でのチケット駆動開発

  • XPのタスクカードがチケット
  • XPのタスクボードがチケット一覧
  • XPのイテレーションがITSバージョン

2.RedmineのSCM機能(@marutosijp)

marutosi / redmine-shinagawa-20110908 / overview — Bitbucket

  • リポジトリブラウザ
  • タグやブランチ
  • ソースツリー
  • ファイル単位での履歴 など
  • 統計グラフ
  • チケットの関連付け

内部構造

  • SCMによらず内部データベーススキーマーは一緒
    →リビジョンをすべてDBに保管する
  • SCMにsubversionのリモートを採用していると少し遅い
    →ツリー表現処理にsvn listを使っているため
  • redmineのSCMにおいてgitよりmercurialが優位な点
    • リビジョン番号が存在
    • リビジョン番号の並び順が保証
      →内部的に取り込みやすいGitのブランチはリビジョンへのポインタだから、リビジョン間に何があったか表示するのが大変
    • Redmine 1.2から改善を行い早くした

Redmine開発での問題点

  • コントリビューター・ コミッタ不足
  • チーム内で英語に少し不慣れ

3.Redmineの実業務における活用事例紹介(@yohhatu)

アンチパターンあり

事例1

背景

  • メンバー全員初Redmine
  • Redmineの管理権限がもらえなかった
  • クライアントとの信頼関係あり
  • これまでJava開発をメインでしていたが心機一転Ruby On Railsを採用
  • イテレーション単位での反復開発

やったこと

  • WBSの1タスクを1チケットにした
  • ガントチャートと併用
  • カスタムクエリを工夫(前日に発行されたチケット一覧、未対応バグ一覧 など)

よかったこと

  • リーダーが楽しそう
  • 今やることに集中できた

課題

  • チケットの粒度が大きかった

改善点

  • チケット粒度を細かく(2.5〜4時間で1チケットを1日3個 消化する)

事例2

背景

  • 前回と同じメンバー
  • 納期が短い
  • リーダーを担当した

やったこと

  • 全面Redmine、ほぼチケット駆動開発
  • ガントチャートはマイルストーンのみ
  • イテレーションごとに動くものを見せた

よかったこと

  • メンバーがチケットを取るようになった
    (メンバーがチケットを書く、そしてそれをアサインする)
  • 余計な管理作業がなかったので実装に集中できた
    (進捗などはRedmineでわかるから)
  • 追加仕様がなく クライアントから高評価だった

課題

  • マネージャーからマイルストーンの提出を求められた
    →Redmineを見せてとにかく説明した

事例3

背景

  • 社内向けシステム
  • メンバー10人
  • 経験豊富なメンバー
  • 社内システムなので新しいものを挑戦できる環境
  • Redmineの管理権限が使えた

やったこと

  • TiDD(No Ticket, No Commit)の採用
  • スクラムで開発
  • 3種の神器を利用(@akipiiさんの発表参照)

よかったこと

  • トレースがしやすくなった
  • プラグインの導入で開発が早く、楽しくなった
    Code Review / Burndown Chart / WorkTime / Redmine Graph Activities
  • 3種の神器の連携は楽

課題

  • 他のチームへの展開が課題

 

Redmineはあくまでツール(銀の弾丸ではない)

 

LT1.Redmineを利用した定量的プロジェクト管理(@yohwada)

発表資料

ITプロジェクトの見える化

暗黙知(KKD:勘と経験と度胸)から形式値へ

見える化ツールの必要性

レポーティング、品質管理、課題管理 etc

 

IPAさんではオープンソースのツールを組み合わせた、定量的プロジェクト管理ツールを年内公開を目標に作成中

 

LT2.うちのRedmineの使い方(@tkusukawa)

 

インフラ運用の現場でRedmineを利用中

  1. wikiに議事録
    履歴で閲覧集計をチェック
  2. 朝会
    worktimeの日程メモを参照しながら
  3. 工数集計
    worktimeでチケット感の工数付け替え集計

LT3.プラグイン開発者への道(@haru_iida)