Redmineを会議室予約システムにしてしまうredmine_meeting_room_calendarプラグイン - プログラマの思索
小川 明彦, 阪井 誠 : チケット駆動開発 日本のソフトウェア開発の現場で生み出された「チケット駆動開発」という概念を、数多くの実例を元にモデル化・体系化を試みた最初の本。 小川 明彦, 阪井 誠 : Redmineによるタスクマネジメント実践技法 Redmineによるチケット駆動開発の実践技法に関する最初の本。アジャイルなソフトウェア開発への適用方法、TestLinkによるテスト管理手法についても言及。 清水 吉男: 「派生開発」を成功させるプロセス改善の技術と極意 組込システム開発をベースとして、ソフトウェア開発特有のスタイルである派生開発、特にXDDPについて解説した世界でも稀な本。既存製品を保守するのではなく継続的に機能追加していく昨今の開発では、派生開発特有の問題を意識しなければならない。XDDPはプロセス論だけでなく、要件定義などの上流工程の品質改善にも役立つので注意。 Le
僕がredmineに入れてる便利なプラグインとデザインの格好良いテーマ - Qiita
動作バージョン 「動作確認済」とは筆者が実際に動作させることができた環境を指す。他のバージョンでも動く場合があるので、詳しくは各プラグインのReadMeを参照。Redmine2系と3系で導入するプラグインのバージョンが異なる場合があるので注意。 不具合があったら GitHubのIssueを見ると案外自分と同じ問題が報告されていることも多い。意外と数ヶ月程度で対応してくれる作者もいるで、時々チェックするといつのまにか直っていることもある模様。 Easy Gantt 動作確認済：3.2.1／3.2.4／3.3.1 商用プラグラインの販売やRedmineのSaaSを開発しているEasyRedmine社によるプラグイン。マウスで直接操作できるガントチャート機能を追加できる。商用プラグインの無料版という位置付けだが、必要十分な機能は揃っている。 自分の環境では、通常のインストール手順の後に、データベ
【解決しました】RedmineのMarkdownで「_」アンダースコアが消える - Qiita
以下、解決しました。 Redmineの2.5をインストールすると、テキストの書式でMarkdownが使えるようになる。ただし、すべてのプロジェクトで書式がMarkdownになる。wikiだけとかできない。 Markdownになれるため導入。 みたいな文字をチケットに書くと、 filenameunderscore みたいに「_」アンダースコアが消える。 エスケープが必要なのか。 http://daringfireball.net/projects/markdown/syntax 気軽に使えない。 終了。 Textileに戻した。 解決方法 イタリックにしないようにfotmatter.rbにno_intra_emphasisを追加します。 lib / redmine / wiki_formatting / markdown / formatter.rb
Redmineの「チケット計測のススメ」の記事がすばらしい - プログラマの思索
チケット計測のアーキテクチャとしては、Redmineのチケット一覧画面で必要なクエリをあらかじめ作成しておく。 次に、RedmineのREST APIを使って、クエリを呼び出してCSVへ出力し、そのCSVをパース＆解析して、各種メトリクスを出力する仕組み。 仕組みは簡単だが、すごく良いアイデアだ。 従来のソフトウェア工学では、常時監視した方が良いメトリクスは既に知られている。 アジャイル開発ならば、下記が既に知られている。 詳細は「リーン開発の現場 カンバンによる大規模プロジェクトの運営」を参考にすると良い。 ・累積フロー図：ステータス毎のチケットの枚数を時系列に並べたグラフ ・Velocity：チームの開発規模を表す ・リードタイム：平均のリリース間隔を表す。チケットの平均完了日数。 ・サイクルタイム：ステータスが変更される平均時間を表す。 累積フロー図は、チケットの増減を通じて、チーム
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか
Redmineによるチケット駆動開発はストック型プロセスとフロー型プロセスの二面性を持つ - プログラマの思索
Redmineの運用の現場を見ていると、チケットをストックとして見る場合とフローとして見る場合で観点が異なるように思えた。 ラフなメモ書き。 【1】Redmineを運用し始めた時に、チケットよりもRedmineプロジェクトの分割に重きを置いたり、チケットをWBSと一体視して、1チケット＝1担当者で運用する現場を見かける時がある。 たいてい、上手く回っていない。 本来のチケット駆動開発では、チケットを経由して一つの作業を複数人が分担してやり取りする。 その流れがチケットで表現されるから、今誰がボールを握っているのか分かるのに、チケットをWBSで固定化してしまうと、手戻り作業が発生するたびに、現状を把握しにくくなる。 このアンチパターンを「WBS駆動」「担当者固定」と僕は呼んでいる。 【2】@akahane92さんも言っていたが、Redmineでは、チケットのコメントが長くなるような運用の方が
Redmineで崩壊したチケット管理を回復する方法 - 高柴ラボ
2015-02-16 Redmineで崩壊したチケット管理を回復する方法 プロジェクト管理ツールとしてRedmineを導入してみたけど、いつのまにか未完了チケットが数百個溜まったまま放置されていたり、発行されたチケットの進捗が別途Excelで管理されていたり、気づいたらまとも利用されなくなっちゃってることってありませんか？ ここ２年くらい、いくつかRedmineでプロジェクトを運用してきて、特に上記のように若干崩壊しちゃってるチケット管理を立て直す場合に、こういう風にするとうまくいくんじゃないか……という知見が溜まってきた気がするので書き残しておこうと思います。チームの規模は大体３〜８名程度で、非エンジニア(デザイナー、企画者)などもRedmineのメンバーに含まれる環境でした。使っていたRedmineのバージョンは2.x系です。 基本原則 チケット管理において、以下を意識する。 シンプル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
