職場でのバグ管理はどうやってる? 98
ストーリー by Oliver
バグをまとめて仕様書と呼ぶ 部門より
バグをまとめて仕様書と呼ぶ 部門より
tty77 曰く、 "オープンソースに代表されるようなオンラインでのソフトウェア開発では、メーリングリストとウェブページそしてCVSなどのバージョン管理システムを使って開発を行っていることが多いようです。対して、企業での開発では、バージョン管理システムは当然としても、コミュニケーションは直接のディスカッションとミーティング (とそれを補助するメール) というのが大勢だと思います。さて、今回、考えたいのは、バグ管理について。前者 (オンラインでの開発) では、多くの場合、たとえば SourceForge や Bugzilla などのサイト/ツール (バグ管理システム:BTS) を使って行っているでしょう。ところが後者 (企業(小規模)プロジェクトの開発) では、文書や管理簿を使っているところも多いのではと思うのです。
みなさんの場合、どのようにバグ管理をしていますか。あるいは、うまいこと BTS を導入する方法があったら教えてください。"
"ちなみに、うちのプロジェクトの場合は
- 障害処理票 (Word 文書) を記述する
- これをもとに、障害管理簿 (Excel 文書)に新しい行を追加
- 障害対応担当者に障害処理票を配布
- 担当者が調査。原因や判明したり、対応が決定したら、管理者に報告 (メールなど)
- 管理者(または担当者)が障害管理簿に原因や対応内容を随時記入
- 最終的に、担当者が障害処理票に記入して、管理者に提出
- 障害管理簿については、定期的にクライアントとのミーティングで提出
と、なっています。もちろん、管理簿には、「内部用」(中途半端な状況を記入可能。なんでも書ける) と「外部用」(クライアントに提示する) があって、転記転記の状態。クライアントのやりとりさえなければ、ひとつのファイルですむのに、と思いつつ。"
大筋で一緒ですが (スコア:3, 参考になる)
正確に言うと、コーダが書いてくる伝票(Email連絡)の文書(情報)は意味不明事が多く、その上
自己弁護率が高く、真の原因が見えにくいのです。
それを帳簿形式にまとめたら、まずクライアントに説明をつけられません。
一度、適切な言葉で書くように指導していたらメインの
デバッグや検査より、奇麗な言葉をさがす方に時間をかけるコーダが続出して、あげくに、当人さえ意味が不明のバグ票になってしまったのでした。(哀)
ですから、クライアントとのミーティングで要求されたら
連休中も出勤してるけどID
職場では (スコア:3, 参考になる)
サポートからのバグ報告だけど、直接言われるのが最悪で、電話でも仕事のリズムが崩れるので、バグ管理ソフトに入れて名指ししてもらえば自動でメール通知が来るので効率がいいです。で、修正した後でステータスを変えれば、バグの通知者にメールが返る仕組み。
ただ、こういうソフトは全員に渡らないと意味がないので、商用ソフト使うと値段が馬鹿にならない。 以前学生同士でオープンソースでやったプロジェクトで Mantis [mantisbt.org] というバグトラッカを使っていましたが、シンプルで使いやすかったです。ただ、日本語に対応してるかどうかは不明。
プロの場合は、バグ管理ができてくると、その一段階前の CRM(顧客サポート)、バグ報告、そして、要求仕様、開発者のタスクリスト、テストプラン、とプロセスの流れを統合したくなってくるんではないでしょうか。
Joel Test [joelonsoftware.com] じゃないですが、最低バージョン管理とバグ管理ソフトを使ってないと品質は期待できないでしょう。 金も時間も節約できるのに使わない理由が分からん。 コード規定(coding convention)も自動テストもだけど。
Re:職場では (スコア:2, 参考になる)
Re:職場では (スコア:2, 興味深い)
実プロジェクトではExcel使っています。(現実問題、オンサイトだからツールを導入しにくいのデス。以前、ディビジョンにいたときは、ClearDDTS 使っていたのですが。あの頃はよかったなあ。)
「Triage」(トリアージュ)という言葉があります。
本来は病院関係の用語らしいです。テロや大規模災害が起こったら、負傷者全員をFIFOで対処していると間に合わないので、最初に緊急度を診断・順番付けして、重症の人からしかるべき医療機関にディスパッチします。軽症の人は後回し。これをTriageといいまして、これと同じことが障害管理では当然求められます。
この意識をしているかしていないかで、ツールのよしあしに関わらず結果が変わってきます。
Re: Triage (スコア:2, 興味深い)
閉じたバグを非表示にしたり、プライオリティを付けたり、グループ分けしたり、担当者ごとに並べ替えるのは当然として、プライオリティが低くてもバグを放置するのを避けるために、最終更新でのソートも役に立つでしょう。レポートにはバグ解決までの平均時間も含まれていたり。
Excel でもソートはできるだろうけど、いざバグの詳細を得ようと思ったら、コメントの投稿ができないと不便じゃないですか? バグトラッカで大切なのは、バグ表だけじゃなくて、トラック(追跡)の部分だと思うんで。「報告がありましたが、再現できませんでした」とかメールに散らばってると後日検索しづらい。 あと、どのバージョンのバグで、いつのバージョンで解決したのか、とか。
Mantis みたいな web アプリなら PHP と MySQL があれば走るので、どこにいても使えます。
つっこみ (スコア:1)
また、重症の人から医療機関に送ったりはしません。
重症度と緊急度で分類します。極端な例が分かりやすいと思いますので...
死者は最重症ですが、緊急度は全くありませんので、病院には送りません。
Re:職場では (スコア:1)
(略)
>この意識をしているかしていないかで、ツールのよしあしに関わらず結果が変わってきます。
ちなみに、意識だけでは駄目です。
たとえ意識は有っても、理解が間違っていると、悲惨なプロジェクトになります。
何をどうやって緊急度を評価すべきかって点を間違っていると、
価値の無い(酷い時には価値のマイナスな)順序付けをしてくれちゃいます。
#間違った理解の嵐に揉まれた数年間だったのでG7(T_T)
よく世の中で「キモチが大事だ」と言いますが、実際には、
それに正しい技術がきちんと組み合わさっていないと、効力はゼロ、酷い時にはマイナス、になります。
皆様も、ゆめゆめ脳みそのご自愛を。
職場でのバカ管理 (スコア:2, おもしろおかしい)
Re:職場でのバカ管理 (スコア:2, 興味深い)
Re:職場でのバカな管理者 (スコア:2)
此処等の人種は特殊な言語を日常会話に用います。
「えーっと、こないだのアレどうなった?」
頼むから、まともな日本語使ってくれよ。
~~~~~~~~~~~~
viva!博多手弁党
Re:職場でのバカな管理者 (スコア:2, おもしろおかしい)
たとえ会話が盗聴されていても秘密を守ることができます。
Re:職場でのバカな管理者 (スコア:2, おもしろおかしい)
「え~っと、アレの件なんだけど。
解決しそうなんだけど30万円必要なんだ」
Re:職場でのバカな管理者 (スコア:1, おもしろおかしい)
俺::なんじゃその代名詞の迷宮は?「この間のアレと言うとナニの事ですか?」
上司「そうそうナニのこと」
俺::う、しまったボケにボケ返された「あれは美味しくいただきました」
上司「あ、君何の話をしとるんだね、アレは食べるものじゃないだろう」
俺::「先日のおみやげの事かと思いましたよ、で実際どの話なんですか、○○△長さんから頼まれた件は5つあるんですが」
上司「だからアレだよ」
俺::「皆目検討がつかないんですが」
上司「きみは人の話を聞いてないだろう」
俺::ひぇ~どうしよう。
#実話だよ。
こういう場合は (スコア:2, おもしろおかしい)
私:「ああ、P1のバグはレポート上げて、いま、対処のレスポンスを待ってるところですけど」
上司:「ちがう違う、えーと。。。」
(ここですかさず)
私:「昨日の昼飯はオムライスだったんですがね、やっぱそばのほうがよかったですよね?」
上司:「だから、それじゃなくて。。。」
(さらに間を置かず)
私:「あ、昨日言われたサンショウウオのえさ、あげてきましたよ」
上司:「だからぁ。。。」
(この時点で上司はなにを言いたかったのかたいてい忘れている)
上司:「あ、やっぱりいいや」
話題をあっちこっちに飛ばして、相手をケムにまくのがコツ。
Re:職場でのバカな管理者 (スコア:1)
認証サーバ側の蟲かもしれませんが、
この後、元AC氏は Disconnect され、
エラーログに記録されたんでしょう。
御愁傷様です。
# 認証システム側からの接続試行は本来無いと思うが、
# 会話可能な距離内に入ったため自業自得(^^;)と判断
オフトピだけどGWなのでID
紙 (スコア:2, 参考になる)
小規模(10人程度)、1拠点での開発でした。特に締切前の、空気がやばくなってきた頃に、新しいツールを入れようとしても抵抗が大きすぎるので、むしろこのくらい「軽い」方法が効きました。 締切は絶対に外せないが、締切後のメンテはそんなにシビアではないとか、バグの再現用のデータを必要としない(UIの操作手順だけが問題)とかいう特殊な開発だったせいもあるでしょう。
この方式のメリットは、バグの重要度、深刻度、複雑度、相互の関連といった情報が、繁雑なUIを操作しなくても自然に表現できることです。細かいルールは決めませんでしたが、重大なバグは大きな文字で記されるし、関連する問題が多いバグはなんとなくごちゃごちゃと註記が増えてゆき、またなかなかfixされないバグは毎日転記されるのでおのずと頭に刻まれます。バグをfixして物理的に紙上のバグを線で消してゆく行為に達成感を覚えたりもします。
Re:紙 (スコア:1)
bugzillaやjitterbugは、あれは、遠隔地でやらざるを得ないときにいいかもしれない。できなゃ導入する意味はないですね。(まぁ、あたりまえか)
アナログBTS(Re:紙) (スコア:1)
ホワイトボード+ポストイットシステムで
運用しております。
もちろん開発担当者の評価期間に限ってのことですが。
Re:紙 (スコア:1, すばらしい洞察)
それが意味がある場面って少なくないと思うが。
Re:紙 (スコア:1, すばらしい洞察)
「紙」運用に関してとても重要な前提があります。
「検索が必要なほどアクティブなバグを貯めない」
それが可能なプロジェクトは限られますが。
Re:紙 (スコア:1)
この場合のTPOって、どう判断すればよいでしょうか?
#判断の出来ない人に限ってTPOという言葉を使いたがる、という傾向を某所で見つけてしまった時には悲しかったのでG7
#つまりそこでは、TPOという言葉は、TPOの判断責任を「相手に」押し付けるための方便でしかなかったのね…
>まだまだデジタルの適用範囲ってのは狭いし面倒だし金が掛かる。
狭いかなあ?
ぱっと俺が思いつく範囲だと、計算機ベースだと
●メリット→文字
●デメリット→文字以外(絵とか)
って印象を受けています。
絵とかって、伝達だけならいいんだけど「描く」のが計算機だとショボショボでしょ。あれが悩ましい。
#結局悪いのは「マウス」なんだよな。もっと描くのに適した入力デバイスが増えないと。
金は、既に計算機が導入されてるであろうプログラム開発現場では、追加で必要な金はゼロでしょう。
BTSは無料なのを探せばいい。今の計算機は大抵余力も有るし。
#下手にサーバ云々とかいうより、デスクトップのPCのほうが、今ではリソースの宝庫なんだよね。活用しようぜ。
Re:紙 (スコア:1)
プロジェクトの規模・人数・拠点数や、そうしたツールに開発内容が馴染みやすいかどうか、なんかがポイントになるんじゃないですかね。
小規模で拠点が一箇所で短期間だったらわざわざツールを導入するよりも紙でやっちゃったほうがイニシャルコスト(導入・教育等)が低くすんでリーズナブルな場合が多いと思います。
ある程度の規模でも、利用する人がそうしたシステムにまったく慣れていないようならば Excel なんかの「割とみんなが普通に使っているシステム」を使うのが楽な場合もあります。
逆に「バグを恒常的に管理する必要がある」「複数人がアイテムに対してのアクションを起こすので、競合や割当の処理が必須」「拠点が多いので共有方法を考える必要がある」「教育にある程度のコストを払っても最終的にペイする」と言う場合ならば、何らかのBTSを入れちゃうのがいいと思います。もちろん少人数でもBTSになれた人たちだけならば、初めから使ったほうがいいですし、そうしたシステムと紙やホワイトボードを併用する方法もありますね。
> #結局悪いのは「マウス」なんだよな。もっと描くのに適した入力デバイスが増えないと。
70インチくらいで200dpi以上あってタッチパネルでペン書きなんかかも出来るディスプレイが普通に使えるならばデジタルだけでもいいんですけどね
Re:紙 (スコア:1)
・情報の表示面積・解像度が小さい(一覧できる情報量が少ない)
・インターフェイスが煩雑(紙に比べたらどんなソフトも)
・思ったときに即座に見られない(紙はいつでも貼っておける)
・表現自由度が低い(場合によるけど手書きで図を描くのは紙のほうが便利)
などの短所はありますね。
もちろんデジタルの方が優れている点も沢山ある(整理が容易、検索が容易、抽出が容易、共有が容易、可搬性が高い、などなど)ので、それこそTPOでしょうね。そのうちデジタルが紙の利点を全て取り込める日も来るとは思いますが、しばらくは先な気がします。
あと紙の場合、更新時にほぼ全て書き直す必要があることから、その時点でのリファクタリングを割とやりやすいんですよね。デジタル媒体だとCopy&Pasteしてしまうので、はじめに作った設計やスケジュールに結構引っ張られやすい気がします。
# なので私はUMLの草稿なんかは紙で書くのが好きです。
Re:紙 (スコア:1)
Webアプリ (スコア:2, 参考になる)
Re:Webアプリ (スコア:1)
Re:Webアプリ (スコア:1)
プロジェクト内での利用はもちろんこと、顧客を巻き込んだ開発のときの連絡窓口としても重宝しています。進捗状況を分類できるBBSっていうノリです。
BugzillaやGnatsを試してみたこともあるのですが、複雑すぎて、使ってもらえませんでした。
優れていることは解るのですけれどね…。
from もなか
Scarab (スコア:1)
影舞 [daifukuya.com]とScarab [tigris.org]で迷ったんですが
BTSまるごと納品をする可能性も考えて、結局Scarabにしてみました。
(ScarabはApacheスタイル&利用ライブラリもJakrtaプロジェクト製、影舞はGPL)
Scarabどなたか使っている人いないんでしょうか?
# 個人的な用途では影舞を使ってます・・
ほとんど同じだ (スコア:1)
Re:ほとんど同じだ (スコア:1)
でも、例えばウチの上司や同僚にBugzillaやAlexandiraの使い方を教えるとすると それだけで大幅に工程が遅延しそうで 正直踏み切れていません。
Re:ほとんど同じだ (スコア:1, 興味深い)
ISO9000を導入したり、バグ数等の管理を真面目に(ツールだけで)やろうとするとかなり難しそうですけど、小規模(10人程度2拠点)でISOなしなので助かりました。
2~3人を越えたらBTS無しでの開発はもう考えられないなあ。最悪の場合でも、途中でやめてしまえば今まで通りですから、次回から導入してみてはどうでしょう。
Re:ほとんど同じだ (スコア:1, 興味深い)
月イチでバグ数をプリントアウトしたんだっけな。詳細忘れた。
ウチの職場はハードウェア開発ですが (スコア:1)
システム単体で見ればそこそこ上手くまわってる方かなとは思います。
障害通知->回答->確認(改善されてない場合は再度回答要求)という比較的単純な仕組みなせいもあるかもしれませんが。
もっとも、他のコメントにもあったように、そもそも障害通知でおかしな内容を入れてくる人がいたりとか、その手の問題はありますが。
これで他のシステムとの連携さえ上手くいってれば言うことなしなんですが、それは言いっこ無しってやつですかね。
で、障害事例を蓄積しておいて未来に活かそうという志の高い目論見もあったはずなんですが、過去に開発した装置の履歴は...誰も見てないんだろうなぁきっと。
Re:ウチの職場はハードウェア開発ですが (スコア:1, 参考になる)
承認などは当然ワークフロー処理し紙送り時代より良くなったのだが、いくつか問題点が。
良い方法あれば教えてください。
(1)社外の協力会社に依頼している場合の取り扱い
社内LANには接続していないため、担当者代行投入という状況が発生。
紙のときは紙を送らせれば良かったのだが。
# 受信用メールアドレス準備し、そちらでXLSファイル受信し自動処理するかな。
(2)大量承認依頼メールによるDOS攻撃(^^;
1障害単位で即時メール送信しているため、大量発生時に責任者のメール処理能力オーバし悲鳴上がる。
(責任者はそうでなくともオーバフローしている)
担当者指定して承認ボタン押すだけなのだが、これだけメールベースの業務処理がメインになってくると、
SPAMやワーム関連で無くとも大量メールは鬱陶しいもの。
# 沢山障害出すなってのは置いといて:-)
実業務なのでAC
場末、デスマーチ、我鍋に綴じ蓋なバグ管理… (スコア:1, 余計なもの)
なんとなくキーワード(?)をタイトルに並べてしまいましたが、
まさにそんな感じで、どっかで経験した某プロジェクトだと、もう悲惨でした。
例えば。バグ報告のためのファイルの雛型が(Wordか何かで)用意されてたんですが、
問題はその雛型の構造。
バグの原因だのなんだのについて、三者択一とか10者択一とかの選択欄が用意されてるんですが、
その選択肢が実情にそぐわなくて、選択可能な選択肢が無いという事が非常に頻繁に有りまして…。
#作った偉いサンに「選択できないんですけど」と質問したら、「できないはずはない」の一点張りでして埒が開かない。
例えば。(バグを見つけたので)そのファイルを書いて担当者に渡してから、
その担当者がそれを捌くまでに、要する時間が甚大だったり。
なんで甚大になるかってーと、全てのファイルを捌く(捌くといっても事実上、承認"印"を押すだけ)のが、
たった一人の担当者だ、という体制にしてたから。
ただでさえ結構多量なバグ報告が、全部一人に集中しちゃうわけね。そりゃ遅延もするよ。
#やいてめえ!報告を50個も貯めたまま、一人でとっとと帰宅するんじゃねーよ!!
#いかに偉いサンでご老体で不健康といえど、その任務を(しかも自分から)背負った以上、
#ひとより早く帰宅するなんて元来許されるこっちゃねーんだぞ!
#なぜ、せめて担当者を10人に増やすとかの知恵を使うことが出来ないかな?
#ああそうか。バグ承認の"印"が重要だからか。内容じゃなく偉いサンの承認が有ったかどうかが重要だってことか。ああそうかぃ。
で、遅延するわ、正しい選択肢が無いわ、なので、
そのバグ記録ファイルは結局、「使われない」か「テキトウに嘘書いてお茶を濁す」か、
が横行してしまって。
偉いサンは「品質を上げるために」その報告をやれと言うわけだが、
実情としてその報告をやっても品質上がらないのは(直感的に)明らかなんだもんな。(だから使われなくなる。)
もう滅茶苦茶。
>もちろん、管理簿には、「内部用」(中途半端な状況を記入可能。なんでも書ける) と「外部用」(クライアントに提示する) があって、
>転記転記の状態
(俺が経験した状況に比べれば遥かに)素晴らしい!!
裏表が有るのが良くない、というのはご尤もなんですが、こっちだとそれ以前の問題で、
その内部用に書いておくべきであろうような半端な事柄とかを、記録しておく場所が
どこにも設けられてない、という状態でして。
裏の存在を黙殺してるだけ。
勿論、まともにバグなんて追える状態じゃないです。
「経験と勘」という名のイイカゲンを行なっていただけです。はい。
みんな、CVSとかにCheckinするときの一言コメント(?)の存在「意義」も理解(納得)していなかったから、
ほんとに重要な"急所"の情報が記録される場所なんか、何処にも有りませんでした。
え?ソース上のコメント?そりゃもう、建前の奇麗ごと以外を書いたらボツ食らってましたから(藁)。逆効果な"レビュー"だったなあ。
まあ人間(客含む)相手になんぼ嘘ついてもいいんですよ。それで騙し遂せるならば。
問題は、ロジックの神様は騙せないという点でして、肝心の納品ソフト自体が不作になるんですな。
そしてバグは増える。そして似非バグ管理で状況は更に悪化する。雪だるま。
BTSなどのツールについても同様です。
そういうツールをいれようぜって言ったら、「信頼できないから」入れたくない、と仰る。
あのー。人間の脳(しばしば間違う)のほうこそが信頼できないからこそ、世の中にはツールってものが有るのであって…
そんな調子で、何をするにも手作業手作業。ミスの嵐。
でも手作業で起きたミスは「仕方ない」で片付けて、ツール使うと「それ見た事か」というんだよな。
ミス率も評価しないくせにさ。
つまり、「頑張れば(結果が不味くても)評価する」という、およそソフト屋向きじゃない精神活動をなさっていたわけで。
連中の頭にBTSをつけたかったです。マヂ。
Re:場末、デスマーチ、我鍋に綴じ蓋なバグ管理… (スコア:1)
物理現象も同様ですな。
なーんか組織のシミュクラの中だけで生きてる奴が多すぎる。
# ような気がする。
汎用機系とオープン系のシステム (スコア:1, 興味深い)
[汎用機系のシステム]
・トラブル時は客先や運用部門、あるいは開発者自身から報告書があがる。
(逃れようが無い)
・バージョン管理のシステムもあり(開発系、リリース(運用)系)、しっかりしている。
[オープン系(フリーという意味じゃなく汎用機でない、サーバ等)のシステム]
・トラブルがあっても報告書をあげるシステムが確立してない。
また開発者はそれをいいいことにナーナーの世界。
スパイラルというかスクラップ&ビルドを勘違いしていて
オープン系のシステムはバグは当たり前みたいに思っている。
・バージョン管理のシステムもある(開発系、運用系)がMicrosoftの
Visual Source Safeを中心としたシステムで、開発者、管理者、運用担当者も
環境を理解してないのか使いこなせてないような感じ。
#さすがにAC
Re:汎用機系とオープン系のシステム (スコア:2, 興味深い)
・未だ汎用機を使っている所は「昔から分かっている所」が残っている確率が高い
・昔ムタクタだった所は、その文化そのままでオープンUNIX・Windowsに移行した
もあったりして。
(まあUnix・Windows界の方が「半可通」が入って来やすい、もあるとは思いますが)
手段はともかく (スコア:1, 興味深い)
・前もって見積もったバグの量と比較するため?
・バグの再発を防ぐため?
・バグを作った原因をさぐるため?
・バグを上司に報告させるため?
・バグを直すため?
・小さなバグで大きなバグを隠すため?
・単に不正コピーのExcelで遊びたいため?
現場の考えと上司の考え、それと会社の方針が一致してるといいねえ(藁)
Re:手段はともかく (スコア:1, 参考になる)
「コードの行数あたりのバグ検出数」が、予言(藁)の値より小さかったら、
バグを探し直せ、と怒られるというプロジェクト運営を行なってくださる発注者を
経験したことが有ります。
ええ。勿論、まともなバグ報告なんて行なえなくなりました。
実際に見つかった数をどうやってそれ以上増やせってんだか。
どうということのない事象を「バグだ」とこじつけるとか、をする羽目になりましたね。
勿論そうすれば仕様書は逸脱するが、どうせ仕様書自体が曖昧模糊としたものだったので(藁)、
仕様書に「厳密に従う」方法が最初から存在しない…
#これで某大手のシステムが動いてると思うと薄ら寒いのでG7
#やつらの会社じゃ、あんな似非仕様書や似非バグ管理が、罷り通っているってのを
#知っただけでも勉強になったのでG7。プログラム作成技術そのものの足しにはなりませんが。
スラドでは糞下請けを罵るお言葉をしばしば聞きますが、
同じくらい、糞発注元も存在してるんだと思います。
発注者も下請けも、所詮は同じ人間。
糞が混入する(そしてそれが場の主流を占めてしまう)確率も同じ程度じゃないかと。
話を元(?)に戻すと、
バグを管理しようにも、何がバグなんだかという判断自体を
全くもってグチャグチャに混乱させてくれちゃう奴は、居るようです。
で、そういう場合、一体全体どうしたものかと…(T_T)。
まあ裸の王様の下で仕事を始めてしまった時点で負けが確定なのでしょうけどね。
Re:手段はともかく (スコア:2, 参考になる)
>バグを探し直せ、と怒られるというプロジェクト運営を行なってくださる発注者を
>経験したことが有ります。
>ええ。勿論、まともなバグ報告なんて行なえなくなりました。
>実際に見つかった数をどうやってそれ以上増やせってんだか。
コード行数あたりのバグ件数が、経験を元に算出した予想値より極端に小さければ、テスト不十分の可能性が有るので、品質向上と称して再テスト。
予想値より極端に多ければ、ソースの品質が、元からダメダメだったと判断して、やっぱり、品質向上と称して再テスト、と言うようなプロジェクトには、関わった覚えが何度か有ります。
元々は、それなりに合理的な理由が有ったやり方が、いつの間にか形骸化してしまうのは、良く有る事なんでしょうかねぇ。
Re:手段はともかく (スコア:1)
たしか、ピッタリ同じ値でなければ了承してくれなかった、と記憶してます。うわー。
あと、数なんていう細かい点まで拘る割には、「何をどうやって」テストしろ、という指令は、くれなかったなあ。
不十分というからにはテストの「質」を変えないとならない筈だと思いますが、その点についてはノーコメントでした。
新たな観点を授けて(笑)くれて、それでもって見直せば、なるほど数がこう変化するのか!…というのが有るならば
まだ判るんですが、そういうのが何もない。
テストの内容を問わず単に「数が合わないから駄目」と言ってくるだけ。
逆に数さえ合ってれば(テストの内容に突っ込みもせず)OKを出す。
管理してたのは「品質」ではないのでしょうね。
#段ボールいっぱいの仕様書を寄越し、段ボールいっぱいの納品物を納めた(ソースを紙にPrintしないと駄目だったのね)のが、この案件だったと記憶してるのでG7
#仕様書が長いのは、機能が多いからじゃなく、文体からしてワケワカなために異様に冗長になってしまっていたせいです…
Re:製品といっしょに仕様書も成長 (スコア:1)
変化しつづけていつまでも確定しないというのは
アレすぎて説明しにくいなあと思っていました。
以下の本でも仕様が変化していくということに
言及していますね。
「ソフトウエア開発 55の真実と10のウソ 」の目次 [nikkeibp.co.jp]
関連スレ「■プロジェクト管理 で欲しいツール■」 (スコア:1, 参考になる)
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
バグ情報共有 (スコア:1)
最終的に統計取るのが必須なので、BTS が使えることが理想的なのですが、別会社との共同作業となる場合、共有できる閉じたネットワーク空間が必要になってきます。こっちはこっちで BTS 使って、という運用でもよいのですが (BTS に inport/export 機能を持たせるとか)、なかなかそこまで環境整備に時間も避けなくてむぐむぐ、といった感じで。。。(個人的にはやってみたいかなぁとか思わなくもないけど)
CAD 系とかだと、データ依存のバグとかあって、そのデータというのが社内の超機密データだったりすることがあるんで (同様のバグが再現できる代替データが作れればいいんだけど、なかなかそううまくは行かない)、データによっては協力会社にもサンプル提出できなくて、そのバグの為だけに遠路はるばるお越し頂いてデバッグしてもらう、なんてこともあったりしました。バグ情報の共有ってのは、えてして難しいものです。
ちなみに、閉じたネットワーク空間を共有できなかったときに取った手段は、単なる一続きのテキストファイルだったりします。こいつに、見つかったバグを、通し番号の ID 振りながら追加してゆき、メールで交換する、というやり方です。書式はある程度ルールを決めてやっていたので、後でちょこちょこっと CGI 化して検索とかできるようにしたり、HTML → chm (HTML Help) 化したりして、それなりに便利に使えていたりしました。ステータス管理も大切ですが、データベース化できないデータに意味はないと思う今日この頃なのです。>世界中の Word で「障害報告書」とかやってるみなさん
# GW は完全に家でへばっていたのでこのトピ自体の存在に気付かなかった ID (;_;)/
むらちより/あい/をこめて。
現状に不満が(汗 (スコア:1)
でも、詳細が一覧にBINDされていないため、管理番号なんかで人間系の管理しかできないのが不満。
理想的には、
・一覧をhtmlで作成しブラウザで表示
・一覧から詳細(障害報告書)にリンク
・障害報告書本文もhtmlで作成しブラウザで表示
・添付資料を別フレームor別窓で表示
・できれば詳細のステータス等から一覧を自動作成
と行きたいところ。
割と困難なのが4番目で。
# これさえなければ個人で案件管理に使ってるPukiWikiでもいいんだが
word/excelで作成する(または設計文書等から頂いてくる)添付資料をpdfに変換して運用するのがベターかなぁ…とか考えたりします。
(いちいちword/excelが起動されるのは面倒くさいので)
この機会に試してみるかなぁ…
# なんだかいつも通りまとまらない文章になってしまった
# MS-Projectの使い方になじめないけどID
---- 何ぃ!ザシャー
Re:企業での開発 (スコア:2, すばらしい洞察)
> さらにテンポラリな案件が多くて、
バグ表みたいなものは地味なので、小さいプロジェクトの場合、散らばって、忘れられてしまいやすい。バグトラッカーなら一括管理。
> 派遣さんを一時的にドバっと入れるので
知識やノウハウを文書化しておかないと、当時者がいなくなるため後日困る。
> 教えている暇がないし
バグ専用掲示板みたいなものです。誰でも二分で使い方を覚えられます。
> 海外企業へオフショアでプログラミング出すこともあるし
開発チーム、顧客、アーキテクトが地理的に分散した場合、web でバグ管理ができないと困りませんか?
他人事なんで、どうでもいいですが、理由が理由になってない気がします。「誰のバグか名指しするのが怖いから」とかいう文化的な理由ならまだ分かりますが。
Re:企業での開発 (スコア:1)
> バグ専用掲示板みたいなものです。誰でも二分で使い方を覚えら> れます。
使い方は憶えられるけど...
「BTS登録するのめんどくさいや、今目の前にコーディング担当者がいるから、わけ言って頼んじゃえ。 な~○○、これ修正頼むよー。」
「今、テスト中なんすけど...」
「いまこっそり直っちまったほうがいいよな、お客さんにもウケいいし」
Re:企業での開発 (スコア:1)
おや?こういう場合にこそ、FREE(自由にせよ無料にせよ)ソフトの面目躍如なんじゃないでしょうか?
高価だったり、ひどいときには一般に市販すらされてないソフト(つまり発注社自社内のもの)だったりすると、
現場に着てから覚えてもらわないとならんわけですが、
これが巷の有名FREEソフトだったりすると、
「これこれこういうソフトが有るから、使い方覚えておいてね。 URLはココね。
無料だからお前らでもすぐ導入して試せるでしょ。
当日までに覚えておかなかったらどうなっても知らないよ(^^;(脅し)」
とでも言えるってものでしょう:-)
ええ。そうです。公知技術&公知実装を使えば教育期間を丸々省けるという
「インターネットは究極の教育期間だ」路線を使えるんです(藁
ちなみにこれは諸刃の剣でして、
「あれ?XX社さん、このソフトのこーんな使い方も知らないの?」
と逆襲される恐れも有ります。
つまり、多くの発注社がこの作戦を採らない理由は、
自分らがむしろDQNであるのを外注に見抜かれたくない、という保身のためなんじゃないかと(藁
つまりですね、
うちはDQNじゃないぞという自信が有る会社さんでしたら(^^;、
ぜひともこの「インターネットでOJT(違)」作戦を採ってみて欲しいのです。
しかもこの作戦は、
●御社のためにも(導入コストは最小だし、外注への教育費も上記の通りゼロ)
●外注のためにも(現場と同じ環境を予習できることのメリットは絶大)
●FREEソフトのためにも(なんといっても普及するわけですから)
なるという、1粒で3度美味しい作戦なのです。情けは人のためならず。
#実際、いけてる職場ほど、FREEソフトをちゃっかり(?)利用するのが旨いよね。
----
>「ASPサービス型多地点TV会議使うのが手っ取り早いや」
ええと、それもネットワーク通してることになるのだったりしないんでしょうか??
あと、大雑把に喋るぶんにはTV会議は便利ですが、やっぱりコピペ(藁)しやすいテキストとかの形での情報伝達が
BTS(など)には重要ではないかと。
#コピペの重要性を認識してない会社が作ったソフトなんて、信用できないのでG7
Re:企業での開発 (スコア:1)
>>「ASPサービス型多地点TV会議使うのが手っ取り早いや」
>ええと、それもネットワーク通してることになるのだったりしないんでしょうか??
ASPと自社運営の違いを理解しています?
>あと、大雑把に喋るぶんにはTV会議は便利ですが、やっぱりコピペ(藁)しやすいテキストとかの形での情報伝達が BTS(など)には重要ではないかと。
ホワイトボードや文章共有ってご存知ない?
#ところでASP型BTSサービスってこの世に存在するのかのう?