パスワードを忘れた? アカウント作成
8071 story
ソフトウェア

職場でのバグ管理はどうやってる? 98

ストーリー by Oliver
バグをまとめて仕様書と呼ぶ 部門より

tty77 曰く、 "オープンソースに代表されるようなオンラインでのソフトウェア開発では、メーリングリストとウェブページそしてCVSなどのバージョン管理システムを使って開発を行っていることが多いようです。対して、企業での開発では、バージョン管理システムは当然としても、コミュニケーションは直接のディスカッションとミーティング (とそれを補助するメール) というのが大勢だと思います。さて、今回、考えたいのは、バグ管理について。前者 (オンラインでの開発) では、多くの場合、たとえば SourceForgeBugzilla などのサイト/ツール (バグ管理システム:BTS) を使って行っているでしょう。ところが後者 (企業(小規模)プロジェクトの開発) では、文書や管理簿を使っているところも多いのではと思うのです。
みなさんの場合、どのようにバグ管理をしていますか。あるいは、うまいこと BTS を導入する方法があったら教えてください。"

"ちなみに、うちのプロジェクトの場合は

  • 障害処理票 (Word 文書) を記述する
  • これをもとに、障害管理簿 (Excel 文書)に新しい行を追加
  • 障害対応担当者に障害処理票を配布
  • 担当者が調査。原因や判明したり、対応が決定したら、管理者に報告 (メールなど)
  • 管理者(または担当者)が障害管理簿に原因や対応内容を随時記入
  • 最終的に、担当者が障害処理票に記入して、管理者に提出
  • 障害管理簿については、定期的にクライアントとのミーティングで提出

と、なっています。もちろん、管理簿には、「内部用」(中途半端な状況を記入可能。なんでも書ける) と「外部用」(クライアントに提示する) があって、転記転記の状態。クライアントのやりとりさえなければ、ひとつのファイルですむのに、と思いつつ。"

この議論は賞味期限が切れたので、アーカイブ化されています。 新たにコメントを付けることはできません。
  • by shado2001 (6090) on 2004年05月03日 11時53分 (#541051) ホームページ 日記
    ウチは障害等管理の1次情報は、クライアントには提出してません。

    正確に言うと、コーダが書いてくる伝票(Email連絡)の文書(情報)は意味不明事が多く、その上
    自己弁護率が高く、真の原因が見えにくいのです。
    それを帳簿形式にまとめたら、まずクライアントに説明をつけられません。
     一度、適切な言葉で書くように指導していたらメインの
    デバッグや検査より、奇麗な言葉をさがす方に時間をかけるコーダが続出して、あげくに、当人さえ意味が不明のバグ票になってしまったのでした。(哀)

    ですから、クライアントとのミーティングで要求されたら
    1. やんわりと、理由を尋ねる
    2. 口頭で難しいと御断りする。
    などと時間稼ぎして、その間、必死になって文書を修正して、ミーティングで説明できる書類を提出しています。

    連休中も出勤してるけどID
  • 職場では (スコア:3, 参考になる)

    by j3259 (7093) on 2004年05月03日 12時38分 (#541060) ホームページ 日記
    商用バージョン管理ソフトと統合された(オマケ機能の)バグ管理ソフトを使っています。 一度導入しちゃえば、どんな小さいプロジェクトでもバグをしっかり文書化できるので便利だと思います。

    サポートからのバグ報告だけど、直接言われるのが最悪で、電話でも仕事のリズムが崩れるので、バグ管理ソフトに入れて名指ししてもらえば自動でメール通知が来るので効率がいいです。で、修正した後でステータスを変えれば、バグの通知者にメールが返る仕組み。

    ただ、こういうソフトは全員に渡らないと意味がないので、商用ソフト使うと値段が馬鹿にならない。 以前学生同士でオープンソースでやったプロジェクトで Mantis [mantisbt.org] というバグトラッカを使っていましたが、シンプルで使いやすかったです。ただ、日本語に対応してるかどうかは不明。

    プロの場合は、バグ管理ができてくると、その一段階前の CRM(顧客サポート)、バグ報告、そして、要求仕様、開発者のタスクリスト、テストプラン、とプロセスの流れを統合したくなってくるんではないでしょうか。

    Joel Test [joelonsoftware.com] じゃないですが、最低バージョン管理とバグ管理ソフトを使ってないと品質は期待できないでしょう。 金も時間も節約できるのに使わない理由が分からん。 コード規定(coding convention)も自動テストもだけど。

    • Re:職場では (スコア:2, 参考になる)

      by j3259 (7093) on 2004年05月03日 12時41分 (#541062) ホームページ 日記
      ジョエルテストの和訳 [joelonsoftware.com]がありました。
      親コメント
    • Re:職場では (スコア:2, 興味深い)

      by koduckin (15749) on 2004年05月03日 14時55分 (#541092)
      結構たくさんツール [google.com]ありますね。

      実プロジェクトではExcel使っています。(現実問題、オンサイトだからツールを導入しにくいのデス。以前、ディビジョンにいたときは、ClearDDTS 使っていたのですが。あの頃はよかったなあ。)

      「Triage」(トリアージュ)という言葉があります。
      本来は病院関係の用語らしいです。テロや大規模災害が起こったら、負傷者全員をFIFOで対処していると間に合わないので、最初に緊急度を診断・順番付けして、重症の人からしかるべき医療機関にディスパッチします。軽症の人は後回し。これをTriageといいまして、これと同じことが障害管理では当然求められます。
      この意識をしているかしていないかで、ツールのよしあしに関わらず結果が変わってきます。
      親コメント
      • Re: Triage (スコア:2, 興味深い)

        by j3259 (7093) on 2004年05月03日 15時59分 (#541109) ホームページ 日記
        Mantis その他のバグトラッカーを使って効果が出るのはまさにそういう所ではないでしょうか。

        閉じたバグを非表示にしたり、プライオリティを付けたり、グループ分けしたり、担当者ごとに並べ替えるのは当然として、プライオリティが低くてもバグを放置するのを避けるために、最終更新でのソートも役に立つでしょう。レポートにはバグ解決までの平均時間も含まれていたり。
        Excel でもソートはできるだろうけど、いざバグの詳細を得ようと思ったら、コメントの投稿ができないと不便じゃないですか? バグトラッカで大切なのは、バグ表だけじゃなくて、トラック(追跡)の部分だと思うんで。「報告がありましたが、再現できませんでした」とかメールに散らばってると後日検索しづらい。 あと、どのバージョンのバグで、いつのバージョンで解決したのか、とか。

        Mantis みたいな web アプリなら PHP と MySQL があれば走るので、どこにいても使えます。

        親コメント
      • by blackcat (13318) on 2004年05月04日 9時16分 (#541313)
        日本ではトリアージュではなくてトリアージと良く呼ばれています。
        また、重症の人から医療機関に送ったりはしません。
        重症度と緊急度で分類します。極端な例が分かりやすいと思いますので...
        死者は最重症ですが、緊急度は全くありませんので、病院には送りません。
        親コメント
      • by G7 (3009) on 2004年05月05日 0時37分 (#541601)
        >緊急度
        (略)
        >この意識をしているかしていないかで、ツールのよしあしに関わらず結果が変わってきます。

        ちなみに、意識だけでは駄目です。

        たとえ意識は有っても、理解が間違っていると、悲惨なプロジェクトになります。

        何をどうやって緊急度を評価すべきかって点を間違っていると、
        価値の無い(酷い時には価値のマイナスな)順序付けをしてくれちゃいます。

        #間違った理解の嵐に揉まれた数年間だったのでG7(T_T)

        よく世の中で「キモチが大事だ」と言いますが、実際には、
        それに正しい技術がきちんと組み合わさっていないと、効力はゼロ、酷い時にはマイナス、になります。
        皆様も、ゆめゆめ脳みそのご自愛を。
        親コメント
  • 職場でのバカ管理 (スコア:2, おもしろおかしい)

    by Anonymous Coward on 2004年05月03日 11時19分 (#541044)
    「職場でのバカ管理はどうやってる」と呼んでしまった(--;
  • (スコア:2, 参考になる)

    by Anonymous Coward on 2004年05月03日 12時53分 (#541064)
    • 摸造紙大の紙の綴を用意し、壁に貼っておく(大きめのカレンダーの裏でもよい)
    • 障害に気づいた人はサインペンで一番上のページにどんどん書き込んでゆく。
    • 手が空いた人はそのリストから作業を取って取り掛かる。
    • 毎朝、一番上のページを破り、次のページに前日の残りを転記する。
    • 古い紙は捨ててしまう (fixの記録はChangeLogに残る)

    小規模(10人程度)、1拠点での開発でした。特に締切前の、空気がやばくなってきた頃に、新しいツールを入れようとしても抵抗が大きすぎるので、むしろこのくらい「軽い」方法が効きました。 締切は絶対に外せないが、締切後のメンテはそんなにシビアではないとか、バグの再現用のデータを必要としない(UIの操作手順だけが問題)とかいう特殊な開発だったせいもあるでしょう。

    この方式のメリットは、バグの重要度、深刻度、複雑度、相互の関連といった情報が、繁雑なUIを操作しなくても自然に表現できることです。細かいルールは決めませんでしたが、重大なバグは大きな文字で記されるし、関連する問題が多いバグはなんとなくごちゃごちゃと註記が増えてゆき、またなかなかfixされないバグは毎日転記されるのでおのずと頭に刻まれます。バグをfixして物理的に紙上のバグを線で消してゆく行為に達成感を覚えたりもします。

    • by deleted user (13014) on 2004年05月03日 13時26分 (#541068)
      プロジェクト管理にデジタルな道具はよくないですね。
      bugzillaやjitterbugは、あれは、遠隔地でやらざるを得ないときにいいかもしれない。できなゃ導入する意味はないですね。(まぁ、あたりまえか)
      親コメント
      • グループのブース内では
        ホワイトボード+ポストイットシステムで
        運用しております。

        もちろん開発担当者の評価期間に限ってのことですが。
        親コメント
  • Webアプリ (スコア:2, 参考になる)

    by Oggbi (22064) on 2004年05月03日 14時04分 (#541076)
    あるプロジェクトで作った専用管理Webアプリを流用したり,Excelで管理したりしてましたが,最近は影舞(http://www.daifukuya.com/kagemai/)ってので管理しているプロジェクトもあります。 基本的にはWebアプリでやるのがやりやすいなとは感じていますね。
    • by ioctl (606) on 2004年05月03日 14時33分 (#541082)
      影舞いいですね。私が担当しているプロジェクトでも使っています。少し前のバージョンでは動作が遅い感じでしたが、最新版では、データ形式が変更になったためか、きびきびと動作しています。
      親コメント
    • by monaka (4489) on 2004年05月03日 16時07分 (#541111)
      私も影舞を推します。

      プロジェクト内での利用はもちろんこと、顧客を巻き込んだ開発のときの連絡窓口としても重宝しています。進捗状況を分類できるBBSっていうノリです。

      BugzillaやGnatsを試してみたこともあるのですが、複雑すぎて、使ってもらえませんでした。
      優れていることは解るのですけれどね…。
      --
      from もなか
      親コメント
    • by kicchy (4711) on 2004年05月04日 12時42分 (#541360)
      最近、プロジェクトのBTSとして
      影舞 [daifukuya.com]とScarab [tigris.org]で迷ったんですが
      BTSまるごと納品をする可能性も考えて、結局Scarabにしてみました。
      (ScarabはApacheスタイル&利用ライブラリもJakrtaプロジェクト製、影舞はGPL)

      Scarabどなたか使っている人いないんでしょうか?

      # 個人的な用途では影舞を使ってます・・
      親コメント
  • by Matthew (12158) on 2004年05月03日 11時40分 (#541049) 日記
    ほぼ同じルーティンで管理してたことがありました。 ISO絡みでWordやExcelになってるところが多いのでしょうか? BugzillaやAlexandiraを利用して、 文書出力をやろとして余裕がなかった...。 あるのかな。
    • いいなあ 導入したい。
       でも、例えばウチの上司や同僚にBugzillaやAlexandiraの使い方を教えるとすると それだけで大幅に工程が遅延しそうで 正直踏み切れていません。
      親コメント
      • by Anonymous Coward on 2004年05月03日 12時24分 (#541055)
        影舞と言う名前の怪しい奴を使ってましたが、内部連絡と積み残し確認用と割り切ってたので簡単に導入できました。BugzillaとAlexandiraというのはそんなに難しいんですか?
        ISO9000を導入したり、バグ数等の管理を真面目に(ツールだけで)やろうとするとかなり難しそうですけど、小規模(10人程度2拠点)でISOなしなので助かりました。
        2~3人を越えたらBTS無しでの開発はもう考えられないなあ。最悪の場合でも、途中でやめてしまえば今まで通りですから、次回から導入してみてはどうでしょう。
        親コメント
  • 障害管理は専用システムでやってます。
    システム単体で見ればそこそこ上手くまわってる方かなとは思います。
    障害通知->回答->確認(改善されてない場合は再度回答要求)という比較的単純な仕組みなせいもあるかもしれませんが。
    もっとも、他のコメントにもあったように、そもそも障害通知でおかしな内容を入れてくる人がいたりとか、その手の問題はありますが。
    これで他のシステムとの連携さえ上手くいってれば言うことなしなんですが、それは言いっこ無しってやつですかね。

    で、障害事例を蓄積しておいて未来に活かそうという志の高い目論見もあったはずなんですが、過去に開発した装置の履歴は...誰も見てないんだろうなぁきっと。
  • by G7 (3009) on 2004年05月03日 13時54分 (#541074)
    BTS以前の話はオフトピかな?とも思ったけど、一応「バグ管理の」話のようなので、ここに。

    なんとなくキーワード(?)をタイトルに並べてしまいましたが、
    まさにそんな感じで、どっかで経験した某プロジェクトだと、もう悲惨でした。

    例えば。バグ報告のためのファイルの雛型が(Wordか何かで)用意されてたんですが、
    問題はその雛型の構造。
    バグの原因だのなんだのについて、三者択一とか10者択一とかの選択欄が用意されてるんですが、
    その選択肢が実情にそぐわなくて、選択可能な選択肢が無いという事が非常に頻繁に有りまして…。

    #作った偉いサンに「選択できないんですけど」と質問したら、「できないはずはない」の一点張りでして埒が開かない。

    例えば。(バグを見つけたので)そのファイルを書いて担当者に渡してから、
    その担当者がそれを捌くまでに、要する時間が甚大だったり。
    なんで甚大になるかってーと、全てのファイルを捌く(捌くといっても事実上、承認"印"を押すだけ)のが、
    たった一人の担当者だ、という体制にしてたから。
    ただでさえ結構多量なバグ報告が、全部一人に集中しちゃうわけね。そりゃ遅延もするよ。

    #やいてめえ!報告を50個も貯めたまま、一人でとっとと帰宅するんじゃねーよ!!
    #いかに偉いサンでご老体で不健康といえど、その任務を(しかも自分から)背負った以上、
    #ひとより早く帰宅するなんて元来許されるこっちゃねーんだぞ!

    #なぜ、せめて担当者を10人に増やすとかの知恵を使うことが出来ないかな?
    #ああそうか。バグ承認の"印"が重要だからか。内容じゃなく偉いサンの承認が有ったかどうかが重要だってことか。ああそうかぃ。

    で、遅延するわ、正しい選択肢が無いわ、なので、
    そのバグ記録ファイルは結局、「使われない」か「テキトウに嘘書いてお茶を濁す」か、
    が横行してしまって。
    偉いサンは「品質を上げるために」その報告をやれと言うわけだが、
    実情としてその報告をやっても品質上がらないのは(直感的に)明らかなんだもんな。(だから使われなくなる。)
    もう滅茶苦茶。

    >もちろん、管理簿には、「内部用」(中途半端な状況を記入可能。なんでも書ける) と「外部用」(クライアントに提示する) があって、
    >転記転記の状態

    (俺が経験した状況に比べれば遥かに)素晴らしい!!
    裏表が有るのが良くない、というのはご尤もなんですが、こっちだとそれ以前の問題で、
    その内部用に書いておくべきであろうような半端な事柄とかを、記録しておく場所が
    どこにも設けられてない、という状態でして。
    裏の存在を黙殺してるだけ。

    勿論、まともにバグなんて追える状態じゃないです。
    「経験と勘」という名のイイカゲンを行なっていただけです。はい。

    みんな、CVSとかにCheckinするときの一言コメント(?)の存在「意義」も理解(納得)していなかったから、
    ほんとに重要な"急所"の情報が記録される場所なんか、何処にも有りませんでした。
    え?ソース上のコメント?そりゃもう、建前の奇麗ごと以外を書いたらボツ食らってましたから(藁)。逆効果な"レビュー"だったなあ。

    まあ人間(客含む)相手になんぼ嘘ついてもいいんですよ。それで騙し遂せるならば。
    問題は、ロジックの神様は騙せないという点でして、肝心の納品ソフト自体が不作になるんですな。
    そしてバグは増える。そして似非バグ管理で状況は更に悪化する。雪だるま。

    BTSなどのツールについても同様です。
    そういうツールをいれようぜって言ったら、「信頼できないから」入れたくない、と仰る。
    あのー。人間の脳(しばしば間違う)のほうこそが信頼できないからこそ、世の中にはツールってものが有るのであって…

    そんな調子で、何をするにも手作業手作業。ミスの嵐。
    でも手作業で起きたミスは「仕方ない」で片付けて、ツール使うと「それ見た事か」というんだよな。
    ミス率も評価しないくせにさ。
    つまり、「頑張れば(結果が不味くても)評価する」という、およそソフト屋向きじゃない精神活動をなさっていたわけで。

    連中の頭にBTSをつけたかったです。マヂ。
  • by Anonymous Coward on 2004年05月03日 14時52分 (#541088)
    私の所の場合

    [汎用機系のシステム]
    ・トラブル時は客先や運用部門、あるいは開発者自身から報告書があがる。
    (逃れようが無い)
    ・バージョン管理のシステムもあり(開発系、リリース(運用)系)、しっかりしている。

    [オープン系(フリーという意味じゃなく汎用機でない、サーバ等)のシステム]
    ・トラブルがあっても報告書をあげるシステムが確立してない。
    また開発者はそれをいいいことにナーナーの世界。
    スパイラルというかスクラップ&ビルドを勘違いしていて
    オープン系のシステムはバグは当たり前みたいに思っている。

    ・バージョン管理のシステムもある(開発系、運用系)がMicrosoftの
    Visual Source Safeを中心としたシステムで、開発者、管理者、運用担当者も
    環境を理解してないのか使いこなせてないような感じ。

    #さすがにAC
  • by Anonymous Coward on 2004年05月03日 15時13分 (#541095)
    何のために運用してるか理解してない人が混ざると悲惨

    ・前もって見積もったバグの量と比較するため?
    ・バグの再発を防ぐため?
    ・バグを作った原因をさぐるため?
    ・バグを上司に報告させるため?
    ・バグを直すため?
    ・小さなバグで大きなバグを隠すため?
    ・単に不正コピーのExcelで遊びたいため?

    現場の考えと上司の考え、それと会社の方針が一致してるといいねえ(藁)
    • by G7 (3009) on 2004年05月03日 16時13分 (#541112)
      >前もって見積もったバグの量と比較するため?

      「コードの行数あたりのバグ検出数」が、予言(藁)の値より小さかったら、
      バグを探し直せ、と怒られるというプロジェクト運営を行なってくださる発注者を
      経験したことが有ります。

      ええ。勿論、まともなバグ報告なんて行なえなくなりました。
      実際に見つかった数をどうやってそれ以上増やせってんだか。

      どうということのない事象を「バグだ」とこじつけるとか、をする羽目になりましたね。
      勿論そうすれば仕様書は逸脱するが、どうせ仕様書自体が曖昧模糊としたものだったので(藁)、
      仕様書に「厳密に従う」方法が最初から存在しない…

      #これで某大手のシステムが動いてると思うと薄ら寒いのでG7

      #やつらの会社じゃ、あんな似非仕様書や似非バグ管理が、罷り通っているってのを
      #知っただけでも勉強になったのでG7。プログラム作成技術そのものの足しにはなりませんが。

      スラドでは糞下請けを罵るお言葉をしばしば聞きますが、
      同じくらい、糞発注元も存在してるんだと思います。
      発注者も下請けも、所詮は同じ人間。
      糞が混入する(そしてそれが場の主流を占めてしまう)確率も同じ程度じゃないかと。

      話を元(?)に戻すと、
      バグを管理しようにも、何がバグなんだかという判断自体を
      全くもってグチャグチャに混乱させてくれちゃう奴は、居るようです。
      で、そういう場合、一体全体どうしたものかと…(T_T)。
      まあ裸の王様の下で仕事を始めてしまった時点で負けが確定なのでしょうけどね。
      親コメント
      • by Takahiro_Chou (21972) on 2004年05月03日 18時17分 (#541151) 日記
        >「コードの行数あたりのバグ検出数」が、予言(藁)の値より小さかったら、
        >バグを探し直せ、と怒られるというプロジェクト運営を行なってくださる発注者を
        >経験したことが有ります。

        >ええ。勿論、まともなバグ報告なんて行なえなくなりました。
        >実際に見つかった数をどうやってそれ以上増やせってんだか。

        コード行数あたりのバグ件数が、経験を元に算出した予想値より極端に小さければ、テスト不十分の可能性が有るので、品質向上と称して再テスト。
        予想値より極端に多ければ、ソースの品質が、元からダメダメだったと判断して、やっぱり、品質向上と称して再テスト、と言うようなプロジェクトには、関わった覚えが何度か有ります。

        元々は、それなりに合理的な理由が有ったやり方が、いつの間にか形骸化してしまうのは、良く有る事なんでしょうかねぇ。
        親コメント
        • by G7 (3009) on 2004年05月04日 0時10分 (#541236)
          >経験を元に算出した予想値より極端に小さければ、テスト不十分の可能性が有るので、品質向上と称して再テスト

          たしか、ピッタリ同じ値でなければ了承してくれなかった、と記憶してます。うわー。

          あと、数なんていう細かい点まで拘る割には、「何をどうやって」テストしろ、という指令は、くれなかったなあ。
          不十分というからにはテストの「質」を変えないとならない筈だと思いますが、その点についてはノーコメントでした。
          新たな観点を授けて(笑)くれて、それでもって見直せば、なるほど数がこう変化するのか!…というのが有るならば
          まだ判るんですが、そういうのが何もない。
          テストの内容を問わず単に「数が合わないから駄目」と言ってくるだけ。

          逆に数さえ合ってれば(テストの内容に突っ込みもせず)OKを出す。

          管理してたのは「品質」ではないのでしょうね。

          #段ボールいっぱいの仕様書を寄越し、段ボールいっぱいの納品物を納めた(ソースを紙にPrintしないと駄目だったのね)のが、この案件だったと記憶してるのでG7
          #仕様書が長いのは、機能が多いからじゃなく、文体からしてワケワカなために異様に冗長になってしまっていたせいです…
          親コメント
  • by Anonymous Coward on 2004年05月04日 14時19分 (#541395)
    ■プロジェクト管理 で欲しいツール■
    http://science2.2ch.net/test/read.cgi/infosys/1009417487/

    漏れの元居た職場の場合は、
    ・関連会社が作ったウォータフォール専用のマネージメント・ツール
    (小汚いASP。何たら担当部長のプロジェクトは特別扱い、とか恥ずかしいソース入り)があって、
    でも、それがあんまりだから、
    ・Bugzillaを日本語化して、csvと関連付けるハックをしたり、
    ・VALinuxさんと協力して SourceForgeの導入を画策しようとした、
    んだけど、それとは別系統で
    ・Rational Suite 数セット/社 を試行導入
    つう話が通っちゃって、今はナニやってるやら不明でつ。。。

    ここ1~2ヶ月ちょろっと顔出してた、某CMM Level5企業の場合、
    な~んもプロジェクト管理ツールを使ってない(!!!)んで、
    ベースラインとしてSourceForgeを提案しようかと画策しましたが時間切れ。

    GW明けから始まる時期プロジェクトは、ナニ使うのかなぁ~。
    やっぱ、KNOPIX上にSourceForge2.5仕込んだCDROM用意して、
    前の現場と次の現場に持参しようかな~。
    と、こんな感じ。バグ管理だけじゃなく、プロジェクト管理全般の話になっちまったけどw
  • 最終的に統計取るのが必須なので、BTS が使えることが理想的なのですが、別会社との共同作業となる場合、共有できる閉じたネットワーク空間が必要になってきます。こっちはこっちで BTS 使って、という運用でもよいのですが (BTS に inport/export 機能を持たせるとか)、なかなかそこまで環境整備に時間も避けなくてむぐむぐ、といった感じで。。。(個人的にはやってみたいかなぁとか思わなくもないけど)

    CAD 系とかだと、データ依存のバグとかあって、そのデータというのが社内の超機密データだったりすることがあるんで (同様のバグが再現できる代替データが作れればいいんだけど、なかなかそううまくは行かない)、データによっては協力会社にもサンプル提出できなくて、そのバグの為だけに遠路はるばるお越し頂いてデバッグしてもらう、なんてこともあったりしました。バグ情報の共有ってのは、えてして難しいものです。

    ちなみに、閉じたネットワーク空間を共有できなかったときに取った手段は、単なる一続きのテキストファイルだったりします。こいつに、見つかったバグを、通し番号の ID 振りながら追加してゆき、メールで交換する、というやり方です。書式はある程度ルールを決めてやっていたので、後でちょこちょこっと CGI 化して検索とかできるようにしたり、HTML → chm (HTML Help) 化したりして、それなりに便利に使えていたりしました。ステータス管理も大切ですが、データベース化できないデータに意味はないと思う今日この頃なのです。>世界中の Word で「障害報告書」とかやってるみなさん

    # GW は完全に家でへばっていたのでこのトピ自体の存在に気付かなかった ID (;_;)/

    --
    むらちより/あい/をこめて。
  • うちも「一覧はexcelで・詳細はwordで」って感じでファイルベースのBTS(と呼べる代物ではないけど)遠隔運用してます。
    でも、詳細が一覧にBINDされていないため、管理番号なんかで人間系の管理しかできないのが不満。

    理想的には、
     ・一覧をhtmlで作成しブラウザで表示
     ・一覧から詳細(障害報告書)にリンク
     ・障害報告書本文もhtmlで作成しブラウザで表示
     ・添付資料を別フレームor別窓で表示
     ・できれば詳細のステータス等から一覧を自動作成
    と行きたいところ。

    割と困難なのが4番目で。
    # これさえなければ個人で案件管理に使ってるPukiWikiでもいいんだが
    word/excelで作成する(または設計文書等から頂いてくる)添付資料をpdfに変換して運用するのがベターかなぁ…とか考えたりします。
    (いちいちword/excelが起動されるのは面倒くさいので)
    この機会に試してみるかなぁ…

    # なんだかいつも通りまとまらない文章になってしまった
    # MS-Projectの使い方になじめないけどID
    --
    ---- 何ぃ!ザシャー
typodupeerror

犯人は巨人ファンでA型で眼鏡をかけている -- あるハッカー

読み込み中...