仕様書をTracのWikiに記載する - rabbit2goのブログ
「仕様書をSubversionとTracで管理する」に続いて、今回は仕様書をTracのWikiで作成する話。 Tracの登場以前に、仕様をPukiwikiで書き始めたのがそもそも発端だけど、Wikiを使うメリットとして下記が挙げられると思う。 仕様同士のリンク 経験的に言って、仕様書は一つだけでは収まらないことが多い。関連する仕様として、仕方なくたくさんのファイルを作っていく事になるのだけど、数が増えると相互参照が大変な作業になる。この点、WikiならWebのリンクを辿るだけなので、情報へのアクセスが容易だ。 仕様の一意性確保 （社内サーバにて）一意のURLと仕様が紐づけられるので、仕様として意味するところを明確に指定できる。ファイルだとファイル名に整理用の数字を入れたり、最新版の資料の置き場所を常に意識しておく必要があった。 ファイルよりも更新が簡単 気分的なものが大きいかも知れないけど
Redmineのトラッカーやステータスの付け方 - プログラマの思索
Redmineのトラッカーやステータスの付け方の記事があったのでメモ。 【元ネタ】 Redmine チケットのトラッカーとステータス項目の意味と設定 - developer (引用) * トラッカー o ドキュメント + ドキュメント書き。 o 調査・検証 + 調査、検証、研究など。 o 機能 + 機能の追加や変更など。 o 不具合／バグ + バグや不具合登録する。 o 要望 + ユーザーからの要望。 + 後で「機能」や「バグ」に変化する可能性がある。 o サポート + ユーザーからの問い合わせは、とりあえず登録。 + 後で「要望」や「バグ」に変化する可能性がある。 o 障害 + なんらかの障害が発生したら、とりあえず登録。 + このチケットに関連した「不具合／バグ」のチケットが後から追加される可能性あり。 o 環境 + 環境構築・環境整備や設定変更など。 o アイデア + アイデアを登録
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Kanonってなぁ～に？～楽々Kanonで華麗にお仕事しよう～
