「挫折しないRedmine」の資料が分かりやすい - プログラマの思索
僕が使い始めた2008年頃と違って、現在はかなりRedmineが普及している。 ソフトウェア開発者だけでなく、製造業や製薬業、営業や事務、勉強会のタスク管理に使っている事例も多い。 最近特に目立つのが、初心者がRedmineを使っているものの、Redmineの良さを出し切れていない場面。 上記の資料では、「Redmineは、チームでチケットを消すゲーム」と定義して、わかり易く説明しているのがすごくいい。 アジャイル開発では、XPの計画ゲーム、Scrumのプロダクトバックログのように、ストーリーやタスクをチケット化して、イテレーション(Redmineならバージョン)単位にグループ化して、リリースしていく戦略を取る。 すると、チケット管理とは、チームでチケットを消すゲームなのだ、と感覚で分かるようになる。 この辺りの感覚は、40代以上の中年SEよりも、20代の若手PGの方がすぐに馴染んでくれる
Redmine・Gitlab・Jenkins のログインパスワードの管理が大変になったので OAuth 化した - suer のブログ
開発環境として Gitlab、Jenkins、Redmine をセットで使っているのですが、それぞれにパスワードの設定が必要となって管理が面倒です。 アカウントを一つに統合したい。ということでやってみました。 環境 Redmine 2.3.0 Jenkins 1.499 Gitlab 5.2 方針 Redmine にプラグインで OAuth プロバイダの機能を追加し、Redmine のアカウントで Jenkins と Gitlab へログインできるようにします。 Redmine に OAuth プロバイダの機能をつける やりたいことに近いプラグインがあったのですが、Rails3 以降の Redmine に対応していなかったので、fork して、ついでに日本語化しておきました。 https://github.com/suer/redmine_oauth_provider http://red
Redmineが1000人のエンジニアに使われるまでのこと
デブサミ2011の後に、Shibuya.tracの第10回勉強会で初LTをしました。テーマは「EnterpriseレベルのRedmine導入結果について」です。外の勉強会は緊張しますが、@yusuke_kokuboさんや@akipiiさん、アジャイルなゆかいな仲間たちにお会いすることができ、とても楽しい勉強会でした。また学びに行かせていただこうと思います。 はじめに 上の資料はそのときのものです（Slideshareはこちら）。5分間のLTだったため、あまり詳細をお話しすることができませんでしたが、勉強会の時に知り合った方と、今度、Redmine導入＆運用の情報交換会を企画しており、そこで共有するネタとして、まずは、Redmine導入時の経験をここにまとめようとおもいます。まずはその前に、私の仕事内容を少しだけ説明させてください。 標準化とか全社共通とかいう仕事 私は入社以来、サービス開発
3年使ったRedmineの使い方について共有したい10のこと
前回は、1000人のエンジニアがRedmineを使い出すまでの事例を紹介させていただきました。今回は、Redmineの使い方や、大規模に変化してくRedmineの運用について、2年間の運用や改善から得たナレッジや、気がついたことをまとめていこうと思います。 1. Redmineのオブジェクト構造を理解した方がいい Redmineは以下の構造になっているので、タスクの属性をうまく分類する必要があります。 プロジェクト > サブプロジェクト > バージョン > 親チケット > 子チケット > トラッカー > カテゴリ 注意したいのは、プロジェクト・サブプロジェクトには期限が設定できず、バージョンには終了日時、チケットには開始日時と期限をつけることができる点です。期限があるものには、期限のあるものを当てはめるのがすっきりします。Redmineを使って「何を」「どう」管理していきたいのかを、まず考
Redmineチケットのステータスのネーミング方法 - プログラマの思索
チケットのステータスのネーミングは結構悩みがち。 ラフなメモ書き。 【元ネタ】 Redmineのチケットのステータスは「～待ち」にすべき - nazonoDiary Redmineのチケットステータス - gdgdでも生きてる Redmineチケットのステータスをデフォルトで運用すると、うまく回らない時がある。 その理由は、今誰がチケットを担当すべきか、認識が一致しないから。 以前の僕も「検証中」「検証完了」「リリース完了」というステータスを作っていた。 だが、複数のチームで運用した所、特にリーダー層から不満が出てきた。 彼らとしては、「～前」というステータス名が欲しいらしい。 例えば、「検証前」なら、開発者が修正完了したがリーダーのレビューが終わっていない状態。 「リリース前」なら、リーダーの検証が終わったので、ライブラリアンが受入環境へリリースするのを待っている状態。 似たようなステー
Redmine, git, Jenkinsの状態を横断的かつリアルタイムに表示する『Dashbozu』をリリースしました。 - みずぴー日記
Redmine, git, Jenkins などプロジェクト管理ツールの状態を横断的かつリアルタイムに表示するWebアプリ『Dashbozu』を作りました。 これを使えば、一つの画面でプロジェクトの”今”の状態を把握できます。 WebSocketを用いているので、ただ開いているだけで、次々と情報を得ることができます。 iPadで開きっぱなしにして、机の上に置いておくような使い方を想定しています。 なぜこれを作ったか 一般的なソフトウェア開発現場では Redmineでチケットを作成する gitでコミットを繰り返し、中央レポジトリにpushする JenkinsによるCIが実行される 結果を確認し、Redmineのチケットを閉じる という流れで作業が進んでいきます。 これらの作業の中で、開発者は「適切な」タイミングでチェックとフィードバックをすることを求められます。 例えば、チェックのタイミング
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
