re:workstyleワークスタイルとチームのための情報ブログメディア
ガチで5分で分かるITS／BTS＆使えるツール6選
課題管理／バグ管理とは、チケット駆動開発とは、概要やチケットの処理フロー、重要性、導入と運用の仕方、バージョン管理や継続的インテグレーションとの連携も含めて5分で解説します。おまけで使えるITS／BTSも6つ紹介。 0分―― ITS／BTSとは、課題管理／バグ管理とは 近年のソフトウェア開発は複雑化しており、さまざまな役割の人間が大人数かかわることも少なくありません。ソフトウェア開発を円滑に進めるためには情報の管理、共有がとても重要です。そこで活躍するのがITS／BTSです。 ITS（Issue Tracking System）、BTS（Bug Tracking System）は、それぞれ「課題管理システム」「バグ管理システム」と呼ばれますが、最近では両方の機能を併せ持つ場合も多く、ITS／BTSを明確に区別することは少なくなっています。 ITS／BTSは、簡単にいうと、課題管理、バグ管理
ITS／BTSによるプロジェクト運営7つの勘所と手軽に使える5ツール
ITS／BTSによるプロジェクト運営7つの勘所と手軽に使える5ツール：DevOps時代の開発者のための構成管理入門（2）（1/2 ページ） 「DevOps」という言葉にもあるように、ソフトウェア構成管理は、インフラ運用に取り入れられるなど、変わりつつある時代だ。本連載では、そのトレンドにフォーカスして、現在のソフトウェア開発に有効な構成管理のノウハウをお伝えする そもそも、構成管理とは 第2回目からはいよいよ、構成管理の具体的な内容に踏み込んでいきますが、最初にソフトウェア開発における「構成管理」とは何か、そのメリットは何なのか、を考えてみたいと思います。 「構成管理」という言葉は古くからあり、CMMIをはじめ、さまざまなフレームワークや標準化プロセスにおいて定義されていますが、ここでは本特集と内容のかかわりが多い、書籍「継続的デリバリー」の第2章より、その定義を引用します。 構成管理とは
Tracベースの「Apache Bloodhound 0.4」がリリース | OSDN Magazine
Tracをベースとしたプロジェクト管理システム「Apache Bloodhound」開発チームは1月28日、最新版となる「Apache Bloodhound 0.4」をリリースした。 Apache BloodhoundはTrac 1.0をベースとするプロジェクト管理システム。ソフトウェアの開発成果やバグの追跡、レポジトリのブラウズ、プロジェクト統合や情報保存のためのWikiといったソフトウェア開発プロジェクト向け機能を提供する。Trac向けのプラグインを統合することで、複数プロジェクトのサポート、直感的な操作性、容易なインストールといった機能の提供を目指す。Apache Bloodhoundは2012年よりApache Software Foudatioin（ASF）のインキュベータープロジェクトとして開発が進められている。 Apache Bloodhound 0.4では、チケットのエディ
デブサミでITSに関するセッションに登壇しました
ということで、2/17,18に行われたデブサミ2011で、「チケット管理システム大決戦 JIRA vs Redmine vs Trac ユーザーが語る、なぜ私はこのツールを使うのか」というセッションにパネリストとして登壇してきました。 たくさんの方にお越しいただきありがとうございました。 資料は既にアトラシアンの大澤さんがSlideshareにアップされています。以下に埋めて置きますのでご覧ください。 で、タイトルの「大決戦」ですが、45分の限られたセッションであんまり各製品間の大決戦にはなってなくて、実はExcelとの大決戦という感じになってました。 自分が話をした内容については、あえて製品間の大決戦にしないように話した部分もありますので、ちょっと以下で補足と私の真意を記載しておきます。 どのITSを使うのが良いのか？という一般的な質問は、実は答えられない質問。なぜなら利用目的やプロジェ
なぜITS導入は失敗したか？あるいは僕のがっかりメモ - ハードコイルド・ワンダーランド
出張してもどってきたら社内Tracが残念なことになっていた 最近、もともと所属していたチームをはなれて外で開発をしていた。 久しぶりにもどってきてTracを覗いたところ、非常に残念な感じなっていて、有り体に言えばゴミタメになる寸前だった。 （今現在も解決していない） ほかのチームでRedmineを展開してそこそこ上手くいっていたので、 なんでこんなことになったのか？どうすれば防げたのかをいろいろ考えた。 個人的なメモ。 何がいけなかったのか 個人的に思うところは以下の３点 ・マイルストーンの役割を誰も理解していない ・バグ表を作る人（≒リーダー）がTracを使えない、使う気がない ・求められる機能とTracの機能に乖離があった マイルストーンの役割を誰も理解していない 「ソフトウェアのリリースとITSのマイルストーン、リポジトリのブランチはそれぞれ同期する」なんて ITS使ってる人には常識
RedmineとTracの機能比較 - プログラマの思索
RedmineとTracの両方でチケット駆動開発を運用してみて、色んな気付きがあった。 以下メモ書き。 【比較対象】 ・Redmine0.8.0 ・Trac0.11.1.ja 【元ネタ】 脱Excel！ Redmineでアジャイル開発を楽々管理 － ＠IT自分戦略研究所 【1】複数プロジェクトの扱い RedmineがTracよりも機能が優れている点の一つは、複数プロジェクトに対応していること。 Tracはプロジェクトに親子関係を入れることができないため、特に大規模プロジェクトではチケット駆動開発を実践しにくいだろうと思う。 複数プロジェクトを作りたい状況は、二つある。 【1-1】開発チームが複数のサブチームに分かれていて、それぞれでタスク管理したい場合。 RedmineやTracを運用してみると、一つのプロジェクトでメンバーが5人以上だとチケットが乱発されたり、放置されやすくなるようだ。
Gitを触ってみるよ その7「GitHubに公式ITSが登場」 - Stellaqua - ＴＯＭの技術日記
Gitは非常に優れたバージョン管理システムではあるものの、BTS(Bug Tracking System)/ITS(Issue Tracking System)との連携はまだいまいちだなぁ、と個人的に思っていたんですが、GitHubに公式にITSの機能が追加されたようで、ちょっと触ってみました。 →GitHub Issue Tracker! - The GitHub Blog 今回はお試しなので、適当な空リポジトリを作って、それを使ってIssueの自動クローズなんかを体験してみたいと思います。 実験用リポジトリを作成する GitHubにログインして、"Create a Repository"で新規リポジトリを作成して、後は表示される手順に従って作業を進めます。具体的には以下のような感じ。 $ mkdir its-test $ cd its-test $ git init $ echo 'マ
Tracのワークフロー - プログラマの思索
Tracを使い始めて、Redmineと異なる視点を感じる所があったのでメモ。 【1】RedmineやTracを障害だけでなく要望も含めてタスク管理する発想は、Issue Trackingと呼ばれる。 元々、チケット駆動開発(Ticket Driven Development)は、バグ管理システム(Bug Tracking System)を汎用化した課題管理システム(Issue Tracking System)から発生した開発プロセス。 すると、障害管理で使われるステータスだけでは管理しにくい場面が出てくる。 例えば、ITILではシステム運用保守で、問題管理、インシデント管理、変更管理、リリース管理の4つの視点を提供する。 BTSのバグ管理は、問題管理と同じ。 問題管理のワークフロー(チケットの状態遷移図)は下記が普通だろう。 新規→担当→解決→検証中→検証完了→終了(リリース完了) このパ
第10回 その他のバグ管理手段・他のアプリケーションとの連携 | gihyo.jp
ここまで標準的なBTSの取り扱いについてご案内してきましたが、既存のBTSを使わずに自前で用意したり、類似の別のシステムを導入するという選択肢もあります。BTSの導入を検討するとき、これらの選択肢の存在も無視できないものですので、これらについても触れてみたいと思います。また、他の開発アプリケーションとの連携についてもご紹介したいと思います。 BTSを内製する場合の注意 既存のBTSが業務にうまくマッチしないと判断した場合や、カスタマイズの知識が無い場合、過去の経緯により不具合リストの機能を拡張して使用している場合など、内製のBTSを使うケースも見られます。割合的にも結構多いようで、BTSを使っている組織のうちおよそ2割くらいあるようです。 ここでは内製BTSでありがちな問題点を挙げてみたいと思います。 細かい部分の完成度が低くなる 内製BTSは業務に特化して作られるので、項目の設定などは思
Redmineを使って気づいたことpart4～チケットの状態管理 - プログラマの思索
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 0.8.0 release candidate！ - プログラマの思索
ついに来たRedmine 0.8.0 release candidate！ ver0.7.3が2008/7にリリースされて半年近く、ようやくメジャーバージョンアップする。 Redmine 0.8.0 release candidate のニュースには、下記の説明がある。 This new release brings a long list of features and fixes. Among them are: cross-project search engine cross-project time report free ticket filtering on calendar and gantt ticket integration via emails wiki page protection and hierarchy user's activity view ver0.
プログラマの思索: ツールが開発プロセスを改善する
Redmineでチケット駆動開発(TiDD)を運用して気付いたことは、開発プロセスが大きく改善されただけでなく、従来の開発プロセスの弱点が浮き彫りになったこと。 下記の記事を読んで考えたことを書いてみる。 【元ネタ】 ケント ベック氏のアジャイル開発における開発支援ツールの役割についてのホワイトペーパー 元請SIerがTracのような環境を提供できない３つの理由 - なからなLife 元請け企業が用意すべきもの - T/O 【1】強力な構成管理ツールが無い時代はライブラリアンが独裁者 構成管理の基本は、任意のバージョンのシステムを再現できること。 今時、Subversionのようなバージョン管理ツールの無いSW開発プロジェクトはありえないだろう。 CVSやVSSが無かった頃は、構成管理ツールなど存在せず、構成管理を人手でやるしかなかった。 今でも、Excelなどの設計書はバージョン管理で制
元請SIerがTracのような環境を提供できない３つの理由 - なからなLife
セキュアに公開されたソース管理システムと課題管理システム、つまりhttps接続のcvs/subversionとtrac/redmineを用意してほしい。 （略） 全てのプロジェクトメンバは計画と設計情報に対するアクセス手段を確保すべきだ。 元請け企業が用意すべきもの - @katzchang.contexts 激しく同意。 ツールの種類はともあれ、この手の情報は、 1箇所に集中 版の管理 セキュアなアクセス 誰でも参照できる を実現することよって、関係するすべての人にとって、作業負荷の軽減に寄与するものですから、さっさとやりましょうよ。 導入、周知、初期学習コストだけじゃん。 導入コストなんて、環境構築手順を確立して、場合によっては自動構築スクリプト化すればさくっと終わる話。 導入ノウハウなんて、みなさんいろんなところで公開してくれているわけだし。 初期学習コストなんて、初めて触る人だけの
元請け企業が用意すべきもの - @katzchang.contexts
セキュアに公開されたソース管理システムと課題管理システム、つまりhttps接続のcvs/subversionとtrac/redmineを用意してほしい。 で、下請だろうと大陸だろうと、同じ資産と課題を管理する。データ流出だって抑えやすい。移動時の紛失リスクと盗難リスクが0だもんね。データは基本的にWEB上で管理するから、ファイル交換による流出だって被害は減る。 運用の勘所を押えるには試行錯誤はいるかもしれないけど、これ用意するだけで結構違うと思うんだよね。SIerの方々、どうでしょう？それとも、もう実行済み？ 何ならユーザに公開してもいいってか、突き詰めればユーザこそ、これで管理すりゃいい。そうなるとSIerの仕事は完全にコンサルに特化しちゃうだろうけどね。 そもそもこの業界、みんな情報隠しすぎなんだよね。設計情報とか、全体計画とか。内容を把握する義務を科したりとか言及できる権利を与えるこ
Trac Lightningで始めるチケット式開発「電撃」入門
“泥”開発に対する最終兵器「Trac」とは？ 誰もが必ず1度はイライラしたことがある「情報の囲い込み」問題 情報の共有はプロジェクトを円滑に進めるうえで重要な課題です。極端な例ですが、例えば、図1の例で見てみましょう。 分かりやすいよくある例で示すと、各開発者の作業状況はメールや手帳上に記されています。検討やヒアリングした結果は、メールでほかの人に問い合わせたならメールボックス上にたまっていきます。打ち合わせなどで相手に会ってヒアリングしたなら、手帳やノート上にメモとして残っていきます。こうして、各開発者が自分のタスクの情報をメールやメモ、あるいは頭の中で“囲い込み”ながら開発が進んでいきます。 ここで、開発者がある機能を実装するために、「別の作業の状況や進捗（しんちょく）を把握したい」とします。 「誰が情報を持っているのか分からない」 まず、誰が情報を持っているのか分からないので、ヒアリ
プログラマの思索: BTSをプロジェクト管理の汎用フレームワークとして使う
チケット駆動開発の戦略part2として、BTSをプロジェクト管理の汎用フレームワークとして使うアイデアをメモ。 #走り書きは後でまとめる。 【元ネタ】 【バグ管理の作法】Trac徹底活用！ 第2回：なぜTracの導入に失敗するのか？ 質問「BTSについて教えて下さい」に対するgaryoさんの回答 【1】BTSはシステム開発に特化したToDo用のワークフローとgaryoさんは言っている。 --------↓引用開始↓----------- BTS自体は非常に使いやすいToDo用のワークフローシステムです。 「バグ」として登録している所を「機能(追加・要求)」にすれば開発管理（要求管理）になりますし、汎用的に「タスク」と捕らえればプロジェクト管理になります。 流れとしてはBTS→BTS+プロジェクト管理 となっていくと思います。 ---------↑引用終了↑---------- BTSのチケ
Redmineでプロジェクトを見える化する - プログラマの思索
顧客の業務を良く見ると、EXCELはシステム化してない業務で使われる。 経理で締めの計上をEXCELで計算して提出。 営業マンが集めた顧客データをEXCELでまとめて提出。 IT業界も然り。 仕様書をEXCELで書いて開発者に渡す。 バグ報告票をEXCELでやり取り。 更に、Excelで扱う業務では、ソフトウェア構成管理(SCM)が使いにくい。 バイナリファイルのため、履歴が残せないから。 IT化の利点はリアルタイムに集計して業務の見える化をすること。 又、集計をリアルタイムに自動化できること。 なのに、Excelの集計作業で、かなりの時間を浪費しているのが普通だろう。 進捗管理をExcelとRedmineで比較してみよう。 DBにあれば色んな観点からリアルタイムに集計できるのに、Excelで管理すると、VBAマクロを使いまくって、Excelが一つの複雑なシステムとなる。 特に、プロジェク
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
GitHub - bkeepers/gaskit: a git-backed issue tracker
IDEA * IDEA