[Think IT] 第2回：なぜTracの導入に失敗するのか？ (1/3)
【バグ管理の作法】Trac徹底活用！ 第2回：なぜTracの導入に失敗するのか？ 著者：masuidrive 公開日：2007/12/13（木） Tracの導入現場の今 「第1回：なぜバグ管理システムを使うのか？」でも紹介したように、TracはSubversionと連携するオープンソースのバグ管理システム（BTS：Bug Tracking System）だ。Ruby on Railsなど多くのオープンソースプロジェクトで利用されており、最近では商業開発でもっとも多く使われているツールの1つになっている。 その一方で、Tracの導入効果が出ていないケースも多々ある。それはなぜだろうか？ Tracの肝は「チケット管理」の運用にある！ Tracにはコンテンツを管理するシステムとしてのWiki、Subversionなどのバージョン管理システムのファイルをWebから閲覧するための「リポジトリブラウザ
masuidrive on rails » Blog Archive » masuidrive的プロジェクトの方針
初めて会社員になって早3ヶ月。会社の仕組みもやっと分かってきたし、そろそろ本格的に開発プロジェクトも動いて行くということで、今後、社内で私と一緒に開発して行く人に、「私がどういう考えで仕事を進めていきたいか」という事を知ってもらうためのプレゼンを作ってみました。(今のところ一人だけど) NIFTYさんと仕事した時も、作業に入る前に「今までどうやって遠隔地で仕事を進めてきたのか」をプレゼンしていました。特に初めて仕事をする場合、「今まで自分はどういう風に仕事をしてきて、この仕事はどういう風に勧めていきたいか」を明確にしておくと、スムーズに仕事を進めることができます。 仕事、特にその上でのコミュニケーションをうまく進めていくためには、信頼と共通認識が必要だと思ってます。信頼は当たり前の話ですが、開発を進める上での共通認識についてはあまり重要視されることが無い気がしています。 仕事をする上ではコ
チケットの使い方 - Meadow - Trac
チケットの使い方 作成されたチケットはどのように使っていくのがよいかを説明します。 筆者の個人的な見解がたぶんに含まれていますのでご注意を。 なので、ここで述べる内容に従わなきゃいけないなんてことはありません。 臨機応変に使っていきましょう。 まずはおおまかに チケットは単純で、およそ2つの状態と思ってよいでしょう new または reopened あるいは accepted などの、チケットが活きている状態 closed した、つまり完了した状態。 チケットを作成した直後は、状態として new となります。 通常のプロセスで行くと、作業担当者が acccept(担当)し、accepted 状態になります。 そして実際に作業が完了したら "resolved as 'fixed'" として、closed 状態になります。 あるいは、チケットの内容が標準外のelispパッケージによるものでme
チケットの書き方 - Meadow - Trac
BTSへの登録をする上でのガイドです。 このガイドに従わなければならないわけではありませんが、 迷った時の助けになると思います。 まだ方針がはっきりしていないものなどは記載されていませんが、 随時追記していく予定です。 チケットを登録してみよう チケットを登録する際の手順は以下のようになります。 画面右上のナビゲーションバーの『チケットの作成』をクリックして チケット登録画面に移動します。 まずチケット属性を指定しましょう。 『チケットの種類』は、新しい機能の要求であれば『新機能/拡張』を、 それ以外は『不具合』を使用しましょう。 『タスク』は主に開発者が使っていきます。 『機能区分』(コンポーネント)を選択しましょう。 適切なものがあればそれを選択します。 不明なら『その他/一般』を選択しておいてください。 使用しているmeadowのバージョンも忘れずに指定しましょう。 もし複数の系列で
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
http://www.rayofsunshine.jp/wiki/?Trac