こんにちは、ディレクターの溜水です。 LIGではプロジェクト管理にRedmineというツールを利用しています。 今まで使用したことがなかったので、「何ができて、何が良いのか」を自分の勉強と兼ねて簡単にまとめてみました。 【こちらもおすすめ】 ☞ 時代は共有!タスク管理を共有できるWebサービス12選 Redmineで何ができるの? Redmineとはオープンソースの「プロジェクト管理ツール」です。 複数人でのタスク管理と進捗管理の情報共有がオンラインで簡便に行えます。 試しに「プロジェクトテスト サイトリニューアル」というプロジェクトを作ってみました。 Redmineの何が良いの? 早速、Redmineの魅力を以下に挙げていきます。 プロジェクトに関わる作業、スケジュールを確認できる 個人的にRedmineで一番良いと思うのは、「ガントチャート機能」で、いわゆる工程表です。 「チケット」と
おまけ―― ガチで使えるITS/BTS、6選 ITS/BTSには数多くのツールが存在します。その中でも有名なものを、特徴とともに紹介します。 【1】Redmine Ruby on Railsで作成されているオープンソースソフトウェアです。ライセンスは、GPL(GNU General Public License v2)です。 プロジェクト管理機能が優れており、タスク管理、進ちょく管理などが行えます。また、ファイル管理やWikiの機能を備えているため情報共有にも優れています。 プラグインが豊富でさまざまな機能を追加することもできます。プラグインのリストがありますので、導入時に1度目を通してみると良いでしょう。 また、有償になりますがSaaSで提供されている「My Redmine」などもあります。 【2】Trac Pythonで作成されている、修正BSDライセンスのオープンソースソフトウェアで
今回は、バグレポートの典型的な問題パターンを紹介します。ここで紹介するパターンは、バグ票ワーストプラクティス検討プロジェクトが収集中の「困った」バグレポートとして挙げられたものを参考にしています。プロジェクトは継続して困ったバグレポートを収集していますので、こちらのアンケートフォームから情報をお寄せください。 それでは、具体例を交えて問題のあるパターンの典型例を見てみましょう。 このバグレポートはいったい何を言いたいのか システムテストの開始直後 テストエンジニアA: このシステムでは、連携システムXからの日時のデータのタイムゾーンが他のサブシステムのタイムゾーンと違っていて、ここにバグがよく起こるんだよな・・。今回もそうかもしれないから、まずは、ここをテストしてみよう。 連携システムXを含めたテストの実施中 テストエンジニアA: ほら、やっぱり。連携システムXからの送信データが過去日付だ
バグレポートに関する問題はどこでも起きている 本記事は、バグの修正依頼として作成されるバグ票(バグレポート)を対象としています。プログラマが自身でデバッグを一通り終えた後で、テストを専門とするテストエンジニアにそのプログラムをテストしてもらい、その際に検出されたバグを報告してもらうための文書がバグレポートです。独立した部門でテストを実施している会社では、このような形態とバグレポートによる修正依頼が一般的だと思います。 本連載は、テストエンジニア向けに、バグ修正のプロセスにおいて非常に重要でありながら、あまり注目されていないバグレポートのあるべき姿をさぐってみたいと思います。 早速ですが、プログラマとテストエンジニアの間でこのようなやりとりがあるのを見たことはありませんか? テストエンジニアとプログラマの間でこんなやりとりが起こっていませんか? 開発進捗会議にて プロジェクトリーダ: Aさん
はじめに 最近、僕は開発者としての立場からは離れて、開発中に発生した障害(バグ)の管理みたいなことをやっていました。 そこで感じたことは、「バグの数が3桁超える、あるいは、開発メンバが3人以上ならバグトラッキングシステム(以下、BTS)を導入したほうが良い」ということです。 実践バグ管理―プロジェクトを成功に導くためのposted with amazlet at 12.06.03クジラ飛行机 あかさた ソシム 売り上げランキング: 392144 Amazon.co.jp で詳細を見る Excelによるバグ管理 今の開発現場では、多くのSierがそうであるように*1、Excelの一覧表によるバグ管理が行われています。 昔からExcelでバグ管理していたという歴史もあり、今回の開発も慣例に従い、Excelで管理しようとしたのですが、失敗だったと感じています。BTSを導入するべきだと今になって思
TracTrac について調べる機会があったので、忘れないうちにまとめておきたいと思います。Trac とはTrac は、オープンソースのプロジェクト管理(バグ管理)システム(BTS)です。特徴/機能を列挙すると、デフォルトの機能として、Wiki、ロードマップ、チケットシステム(とメール通知)、VCS(Subversion)管理 上記機能に連携した活動のタイムライン表示とRSS出力(チケット作成した時や、VCSにコミットした時など) チケットやWikiなどのリソースの検索 柔軟なチケットのレポート機能プラグインで幅広い機能が追加可能Python で書かれているみたいな感じです。詳しくは公式ページ や Wikiを参照してください。 Trac の問題点と解決方法僕は Redmine や JIRA をほとんど使ったことが無いので、他のBTSに対して浅い部分でしか比較できませんが、Tracには以下の
COLORBOXとは? Webシステム、アプリ開発からゲーム開発、組み込み系開発まで幅広く使えるバグ管理ツールです。 インターフェイスはスマートフォン、タブレット端末にも対応しています。
実は私、Ruby 2.0.0 のリリースマネージャです。8 月までに各種機能提案を取り仕切らないといけないので、Arduino で遊んでいる場合ではないのでした。 チケット残数を日ごろから意識するにはどうしたらいいか数週間くらい考えた末、こんなものを作りました。 見ての通り 7 seg が 3 つ載っただけの Arduino シールドです。PC 側で redmine の REST API でチケット残数を取得してきて、Arduino に転送・表示します。つまりこんなスクリプトを cron で動かす。 require "serialport" require "json" require "open-uri" DEV = "/dev/ttyACM0" RATE = 9600 URL = "http://bugs.ruby-lang.org/issues.json?project_id=1&t
“mixi Engineers' Blog » 新社会人のためのバグレポートの基本” htn.to/h66CSz— りーお@DeNAさん (@riywo) 3月 21, 2012 タイムラインに流れてきたこのリンク先の記事を見て下記の内容を書き込んだところ、いくつか反応を頂きました。せっかくなので、英語でのバグレポートの書き方について簡単にまとめてみます。ポイントは「英語に頼らずに英語を書く」です。 英語でのバグレポートが難しいという人は、日本語でもレポートが書けてない可能性を考えるべき。フォーマットに従って「現状の動作」「期待される動作」を書いて、後は再現ステップと再現環境を書けば、英語が理由で伝わらないということはあまり無いと思う。バグレポートの文章の大半は固有名詞だし。— Masahiko Tachizonoさん (@mshk) 3月 21, 2012 **「問題となっている現状の動
本日のAgileJapanでは、多くの人がチケット駆動開発の講演を聞いて下さりありがとうございました。 また、スタッフの皆様、お疲れ様でした。 AgileJapan2012講演資料「チケット駆動開発の課題と展望」をCCアトリビューションライセンスで公開します。 昨年のAgileJapanは聴衆の一人に過ぎなかったのに、今年は講演者としてメイン会場の午後1番のセッションで発表することになり、とても光栄でした。 自分としては資料をもう少し練れたかなと反省していたのですが、平鍋さんや岡山から来て下さった人から、今日の発表は良かったよ、と言われて正直ホッとしてます。 パネルディスカッションで良い議論ができたと思うのは、チケット管理で朝会やふりかえりを組み合わせて運用するのは効果的なのか?という質問があった時です。 朝会やふりかえりはプロジェクトファシリテーションのプラクティスの一つであり、僕個人の
⚡ タスクの計画と整理短いプロジェクトから大規模な部門横断型プログラムまで、Jira では大きなアイデアを実現可能なステップに分解できます。作業の整理、マイルストーンの作成、依存関係マッピングなどを行います。 作業を目標に合わせる作業を目標にリンクさせることで、自身の作業が会社の目標にどのように貢献するかを全員が確認し、重要なタスクで連携できます。
JIRA をご利用いただいているお客様からよくいただく声として、「高機能なのは分かるけど、できる事が多すぎてどこから手をつけたらいいか分からない」というものがあります。特にワークフローの作成は「難しい」といわれるものの 1 つです。しかし、実はワークフローの構造さえ理解してしまえば、あとは決まった手順を踏むだけでカスタマイズが可能です。ここでは、「10 分で分かる JIRA のワークフロー」と題して、ワークフローの基本をご紹介したいと思います。 JIRA ワークフローの概念 下記の図が、ワークフローの概念を示したものです。 ご覧のように、ワークフローを構成する要素はいくつかあることが分かります。順に解説していきます。 ステータス ステータスは、課題がワークフローの中で置かれる「状態」です。例えば、あるワークフローではまず「処理中」があり、次に「確認中」があり、最後に「解決済み」といった状態
チケット管理システム比較WikiへRedmineとSCMの機能の関連表を追記した。 BTSとSCMに関する考えをラフなメモ書き。 【元ネタ】 チケット管理システム比較Wiki 構成管理とは何なのか - watawata日記 SW構成管理とはそもそも何なのか?: プログラマの思索 17-B-3 チケット駆動開発 タスクマネジメントからAgile開発へ - miyohideの日記 Agile開発とチケット駆動開発の大きな違いは、チケット集計機能だけでなく、構成管理ツールとの連携にあると思う。 「No Ticket, No Commit!」を運用して、BTSチケットに構成管理情報を紐づけると、単にチケットとSCMリビジョンが紐づくだけでなく、ビルドモジュールとBTSチケット、SCMコードラインとBTSプロジェクト、SCMタグとBTSのリリース予定バージョンが対応づけられる利点がある。 つまり、チ
ここ半年ほどTracではなく、Redmineを使っているので、両者の比較をしてみようと思ったんですが、結論から言うと、自分が使っている範囲で両者に決定的な違いはなく、同じように使う事が出来ました*1。 #一応書いておくとScrumやチケット駆動とったことをやってるわけではありません。 ということで、両者の細かな違いなんかを書いてみようと思います。 比較のベースはTracになってるみたいです。 使ってる機能 活動(Tracのタイムライン) マイルストーン(Tracのロードマップ) チケット リポジトリブラウザ VCSとチケットの関連付け Wiki 活動(Tracのタイムライン) 違うところ Redmineの活動は、概要一行と詳細が数行にわたって表示されるので、活動のみで詳細を把握しやすいが、全体の流れを見通しにくい Tracのタイムラインは、概要と詳細が各1行ずつ表示されるので、全体の流れを
それぞれのBTSのワークフローはなかなか特色があるね。 Tracのワークフローは以下のようになります。 new(新規) → assigned(アサイン済み) → accepted(受け入れ済み) → closed(クローズ) TracWorkflow – The Trac Project TracはResolution(解決状況)がある。 解決状況についてはこちらが参考になる。 BTSの解決状況(Resolution)は障害管理の名残り: プログラマの思索 Tracの後発のRedmineのワークフローは以下のようになります。 New(新規) → Assigned(担当) → Resolved(解決) → Closed(終了) 課題管理システム - Redmineガイド Redmineは解決状況は無いですが、Redmine本家のサイトはカスタムフィールド作ってやっているようです。 Seasa
チケット管理システム、使っていますか? 小川 明彦さん、阪井 誠さんによる、 「Redmineによるタスクマネジメント実践技法」 が出版されました。trac, Jira, redmine などなど、ちまたには多くの優秀なチケット管理システム(BTS, ITS)があります。もし、チケット管理システムをまだ導入していないプロジェクトがあったら、この機会に導入を検討してはいかがでしょう。Excelでタスク管理などをやっている場合ではありません! 例えば「ソースコード管理システム」は、現代の必須インフラですね。SubversionやGitなどの版管理システムは、プロジェクトでもっとも大切な資産である「ソースコード」を全員で共有し、時間に沿って記録し変更を管理します。今はこれなしでは、ソフトウェア開発のプロジェクトは成り立たないでしょう。そして、現代のプロジェクトに必須なインフラをもう1つあげるとし
ソフトウェア開発のタスクをチケットに登録すると、作業を始めるチケット管理をメインに、進ちょく管理、問題管理などができる。 バグ管理システムだけでなく課題管理システム(ITS:Issue Tracking System)で運用する開発プロセスは、チケット駆動開発(TiDD:Ticket Driven Development)と呼ばれ、最近注目されている。 Ruby1.9の開発はRedmineで管理されているように、近ごろは事例も増えている。 Redmine運用前の問題点 筆者がRedmine運用前に持っていたプロジェクト管理の問題点は下記2点だった。 1.Excelでのタスク管理の限界 従来からプロジェクトマネージャやプロジェクトリーダーの多くは、進ちょく管理やタスク管理をExcelで行ってきた。 プロジェクト管理では顧客へ進ちょく報告するために、残工数と残タスク数を計算する必要がある。だが
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel! Redmineでアジャイル開発を楽々管理 - @IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く