第二回 shinagawa.redmine勉強会で「数千人が利用する楽天Redmineの過去と未来」を発表させていただきました。資料はSlideShare、SpeakerDeckで公開しております。QAの時間が取れなかったため、質問などがあればTwitterでもなんでもご連絡ください。 数千人が利用するRedmine 来月、第3回RxTstudyでもRedmine事例の発表させていただくのですが、品川Redmineはシステム視点、RxTstudyではタスクマネジメント視点で資料を作りました。 はじまりは、使われてないサーバ上に作った仮想VMを使っていました。ユーザ数も少なかったので、WEBRickを利用し、ポートを分けることで複数Redmineを構築していました。WEBRickが固まることがあったので、cronで一日一回夜間に再起動して運用していました。 自分のグループで使ってみようという
最近は、課題管理システム、チケット管理システムがメジャーになっており、私もこの種のツールをサービス開発、ソフトウェア開発で利用し、開発プロセス改善を試みています。 今回は、Shibuya.trac第12回勉強会 ～チケット管理システム大決戦 第二弾～で紹介させていただいた、Redmine利用事例の詳細解説を、共有させていただこうと思います。上記、勉強会の資料は、こちらに公開されています。各種ツールの事例が詰まった内容ですので、ぜひご確認ください。 Redmineのプロジェクト画面 上記が自社のRedmineのプロジェクト画面です。私のチームは「A-Team」といい、すべての作業は「A-Team」プロジェクトで管理しています。トップページには、勤怠の連絡や、Redmineを利用するときのルールなどがまとめてあり、資料を見ていただければわかると思いますが、プロジェクトメニューにはたくさんのモジ
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
デブサミ2011の後に、Shibuya.tracの第10回勉強会で初LTをしました。テーマは「EnterpriseレベルのRedmine導入結果について」です。外の勉強会は緊張しますが、@yusuke_kokuboさんや@akipiiさん、アジャイルなゆかいな仲間たちにお会いすることができ、とても楽しい勉強会でした。また学びに行かせていただこうと思います。 はじめに 上の資料はそのときのものです（Slideshareはこちら）。5分間のLTだったため、あまり詳細をお話しすることができませんでしたが、勉強会の時に知り合った方と、今度、Redmine導入＆運用の情報交換会を企画しており、そこで共有するネタとして、まずは、Redmine導入時の経験をここにまとめようとおもいます。まずはその前に、私の仕事内容を少しだけ説明させてください。 標準化とか全社共通とかいう仕事 私は入社以来、サービス開発
Trac、Redmineといったチケット形式のプロジェクト管理ツールが人気となっています。 デブサミ2011では、[デブサミ]速報：2011ベストスピーカー賞(敬称略) via IWAKIRIさんのブログにもありますように、ベストスピーカー賞3つのうち、2つがチケット管理システムに関しての発表でした。「チケット管理システム大決戦」というセッションは、デブサミ史上最大の観客数となったと聞いています。 なぜ、プロジェクト管理ツールがここまで注目されているのでしょうか？ 開発の現場はそれぞれ異なり、抱える課題も様々だと思います。しかし、プロジェクト管理の中でもタスク管理に関しては、「作業を適切なサイズに分割する」「優先順位をつける」「人をアサインする」という固定のパターンがあり、さらに、現在のアジャイルムーブメントにより、これらの要素がより明確化され、その重要性が認識されてきたように思います。
最近 Graphviz で DFD 的なものを書いていたのですが、これを Redmine の Wiki に埋め込もうと思いまして。 図が Graphviz だけなら Wiki Graphviz plugin で対応できるんですが、画面遷移図は blockdiag で書いていたりするので、もっと汎用的に使える Wiki External Filter Plugin のほうを導入してみましたので、その手順等を書いておきます。 環境は CentOS 5.4、Redmine 1.1.0.devel.4760 です。 Wiki External Filter Plugin のインストール ndl/wiki_external_filter - GitHub に載っているインストール手順に沿って説明します。 作業はすべて root で行いました。また、Redmine は /usr/local/redmi
鈴木雄介 氏 / 小川明彦 氏 / 吉羽龍太郎 氏 / 大澤俊介 氏 パネルセッションです。チケット管理システムに関する質問に回答する形で進行していました。 まとめ チケット管理システムはツールである。必要に応じて最適なものを選ぶことが大切。 チケット管理システムをすべて比較できるひとは少ない。色々調べて、聞いて、使ってみると良い。 開発の規模が大きくなると導入効果も上がる。 前提として導入するだけじゃなくて、ちゃんとみんなで使うこと、日々改善すること。 コミュニケーションにかかるコストを節約できる。 頻繁な変更への対応、メンバ間、顧客との課題共有がしやすい。 資料が公開されています。あわせてどうぞ。 チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのかView more presentations from Sean O
TiDD初心者が陥りやすいアンチパターンを実際に見つけたのでメモ。 【1】チケット駆動開発の概念に慣れておらず、Redmineでタスク管理をまず始めた人に多い特徴がある。 それは、バージョンが設定されておらず、ロードマップが空っぽないし非表示な状態。 話を聞くと、Redmineのバージョンの意味や使い方が理解できないらしい。 だから、彼は、Redmineのチケット一覧画面でタスク管理を実施している。 彼のチケット一覧画面を見ると、スクロールできないくらい、たくさんのチケットが無造作に一覧表示されている。 どうやら、必要なタスクはチケットに登録しているが、彼のチケット管理を見ていると、チケットの納期が意識されていない。 そのチケットはいつリリースするのか？の観点が漏れているみたい。 何故なら、チケットがたくさんありすぎて、どのチケットが必要なのか、チケット一覧画面では分かりにくいからだ。 だ
id:bleis-tiftによるgitのフックスクリプト集がマジ便利。 gitとredmineを使ってる人はぜひ使うべき 機能 チケット番号付加 id/12というブランチで作業してるときは、コミットメッセージの末尾にrefs 12を自動でつけてくれます Redmineのチケットごとにブランチを切るようにすると、マジ便利 masterブランチへのコミット拒否 masterブランチへのコミットを拒否する 必ずトピックブランチを切るようになる pushされたときにチケットIDのないコミットの拒否 チケットIDのないコミットのpushを拒否します ダウンロード・インストール方法 https://github.com/bleis-tift/Git-Hooks に書いてある通りにすれば簡単にインストールできます
更新が止まってるので、以前検索してもヒットしなかった小ネタをひとつ。 以下、redmineをmantisっぽくするtipsです。 alternateテーマを選ぶと優先度で色が付きますが このtipsは、優先度ではなくチケットステータスに対して 色をつけます。 ↓これが ↓こうなります。 —– redmineをインストールしたディレクトリの中にある /public/themes/alternate/stylesheets の中の application.cssの 以下の行をコメントアウトした後、 /* tr.odd.priority-5, table.list tbody tr.odd.priority-5:hover { color: #900; font-weight: bold; } tr.odd.priority-5 { background: #ffc4c4;
こんにちは。開発ブログ言いだしっぺの satoshi です。リートでは、AddClips と Lancers というサービスが現在の主力サービスですが、AddClips は1人のエンジニアが担当し、Lancers は2-3人 のエンジニアが開発を担当しています。 当たり前ですが、1人と3人では開発スタイルが大きく異なり、気をつけるポイントも全く違います。当たり前の事が多いのですが、リートで特に気をつけていることをご紹介できればと思います。 開発環境 VMware ESXi を使って開発環境は5秒で用意する 通常、VMwareはLinuxやWindows上で動作しますが、VMware ESXi はその上で直接、複数のVmware（仮想化マシン）を立ち上げることができます。 Vmwareを導入するために、Linuxを導入したりする必要はなく、その容量も32MBとコンパクト。しかも無償で利用可能
こんにちは、gumiの奥田です。 肌寒い季節になってきました。体調管理には充分気をつけましょう。 さて、弊社では各プロジェクトの管理としてRedmineを使っています。 今回はRedmineのちょっとした活用方法をご紹介します。 カスタムクエリ タスクの管理としてチケットを起票していくと思いますが、たくさんのチケットがある場合、埋もれて探すのが大変だったことはありませんか？ 自分の担当するチケットだけ見たかったり、解決していないチケットだけ見たいときってありますよね。 そんな時にカスタムクエリを作成すると便利です。 カスタムクエリを作っておくことで、チケットの情報をフィルタリングして該当するチケットだけを表示することができます。 それでは実際にやってみましょうー! 自分の担当するチケットだけを見たい。 チケット一覧画面を表示します。カスタムクエリは「フィルタ」の部分を変更することで作成でき
Home インストールガイド Redmineのインストール » メールの設定例 アップグレード Step 1 - 動作環境の確認 Step 2 - バックアップ Step 3 - アップグレードの実行 Option 1 - リリースバージョンのダウンロード SVNチェックアウトのアップグレード Step 4 - データベースの更新 Step 5 - クリーンナップ よくある問題 リポジトリ管理に関するエラー secret_token.rb の生成 関連情報 Redmineのバックアップとリストア 他システムからの移行 システム管理者向けガイド プロジェクトに対する管理操作 ユーザに対する管理操作 グループに対する管理操作 ロールと権限 課題管理システム カスタムフィールド 選択肢の値 アプリケーションの設定 システム管理者向けガイド — 高度な設定 リポジトリ メールによるチケット登録 リ
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
Redmineを運用して気づいたことを書いてみる。 【元ネタ】 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第6回 運用の開始｜gihyo.jp … 技術評論社 ソフトウェア開発の必須アイテム，BTSを使ってみよう：第9回 BTSの運用データを解析して役立てる｜gihyo.jp … 技術評論社 [redMine] 最近の redMine 05/02-05/06 - Don'tStopMusic (2007-05-06) 【1】チケットのステータスは、トラッカー(チケットの種類)に応じて異なる Redmineによるチケット管理で重要な概念はトラッカー。 Redmineのトラッカーは、チケットの種類を意味する。 デフォルトでは、バグ(defect)・機能(feature)・サポート(support)の3種類がある。 バグ修正、機能追加、その他のタスク(例えば、環境構築など)で使い分け
ここ最近ずっと Redmine を使ってプロジェクトを運営してるんだけど、どうもしっくりこない、というか面倒臭い、というかわかりずらい…んで、運営方法を色々と見直しているんだけど「トラッカーの種類」。これが諸悪の根源。たぶん複雑すぎた。WBSのすべてのフェーズのタスクと1対1でチケット化してしまっていることや、作業実績を細分化して統計情報を取ろうと思っていたこともあって、トラッカーをかなり細かく設定してしまっていた。いろいろと試行錯誤してみたんだけどたぶんこの程度↓で充分な気がする。Feature 機能. 設計やプログラミング、テストなどはすべてこれ。 基盤構築と言われるような作業(サーバー構築や初期設定など)もこれで良い気がする。Note メモやアイデア。Support ユーザー(顧客)からの問い合わせなど。 このチケットは Close するか、または Issue や Request や
ここ数ヶ月の成果。やっぱり中心にはgitがある。 チケット駆動開発の良さはわかっていたが、なかなかうまくいかないなぁと思っていたが、gitをちゃんと使うようになってそれができるようになってきた。 チケット駆動開発を実践するにはまずはチケットをきらないといけない。けど、それができない。やっぱりいきなり手をつけちゃうんだよね。それってなんでそうなっちゃんだろうと常々思っていた。 それをある意味抑制するやり方。今やっている方法は、作業するなら作業用のブランチを切れ！それにはチケット番号を付けろ！という方式にしている。 たとえば会員管理の機能に追加したい場合は以下のような手順になる。 会員管理を拡張したいなぁ じゃRedmineでチケットを切るぞ チケット番号が振られた(たとえば #567 だとする) さぁ、ブランチ切るか(members_567) そのブランチで作業開始！ 濱野さんがWEB+DB
Ruby製のプロジェクト管理ソフトウェアRedmineのインストール手順。 Redmineの特徴 Ruby(Rails) + (MySQL | PostgreSQL | SQLite) 複数プロジェクト管理 プロジェクト毎のWiki、リポジトリ、フォーラムなど ユーザー認証、マイページ など。 よくTracと比較され、Tracはプラグインで拡張しないと使いにくいと言われている、個人的にもデフォルトだとRedmineの方が圧倒的に使いやすかった。 インストール環境 CentOS 5 Ruby 1.8.5 RubyGems 1.1.0 Ruby on Rails 2.0.2 Mongrel 1.1.4 MySQL 5.0.22 Redmine Rev:1319 インストール手順 パッケージ管理で必要なものをインストール（Rootで作業） $ yum install -y ruby rdoc r
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
