タグ付けされた質問 「issue-tracking」

私は、レーザーの助けを借りて形状を金属にカットするCNC（コンピューター数値制御）プロジェクトに取り組んでいます。 現在、私の問題はたまに（20日間で1〜2回）カットがうまくいかないか、設定された内容に従っていないことです。 しかし、これは損失を引き起こすため、クライアントはそれについてあまり満足していません。 私はその原因を見つけようとしました ログファイルを含める デバッグ 同じ環境を繰り返します。 しかし、それは繰り返されません。 一時停止して続行操作を行うと、再びバグが再現することなくスムーズに実行されます。 この問題にどのように取り組むのですか？ハードウェアの問題として述べる必要がありますか？

16 debugging  issue-tracking 

閉じた。この質問は意見に基づいています。現在、回答を受け付けていません。 この質問を改善したいですか？この投稿を編集して事実と引用で答えられるように質問を更新してください。 6年前に閉鎖されました。 新しいコードを作成する前に、仕様を作成し、バグを修正する必要があることをパートナーに説得したいと思います。Joelテストを参照する必要がありますか？ジョエルのテストは最新だと思いますか？仕様を持たないことは、プロジェクト管理が悪いと思う。ジョエルのテストに同意しますか？何か追加してもらえますか？インスタンスのオープンソースについては言及していません。

16 issue-tracking  specifications  joel-test 

バグ追跡システムには「優先度」フィールドと「重大度」フィールドがあります。重大度は「ユーザーへの影響」、優先度は「製品への影響」として定義します。 私の質問は、「コード改善」タスクを重大度と優先度に分類する方法についてです。改善によって動作が変更されることはなく、「より良いコード」になると仮定します。全体的な長期的なメンテナンスの改善が見込まれますが、定量化するのは困難です。 優先度と重大度の定義を使用すると、予測が困難な長期的な利点を図に導入しない限り、コードの改善により両方の値が最も低くなります。したがって、コードの改善は簡単な作業ではなく、決して試みるべきではないことを意味します。 ただし、コードを絶えず改善してリファクタリングすることは非常に重要だと思います。 ソフトウェア開発自体は継続的な学習プロセスであり、コードを改善しなければ、それを上達させることはできません。 チームはコードを誇りに思うべきです。 今後のメンテナンスにかかる時間は短くなり、長期的には大幅な節約になります。 または、そのようなタスクは決して作成されるべきではなく、そのような改善は「オンデマンド」でのみ、「バグに関連する場合」に実行されると思いますか？それがバグに関連しているとしても、それがコードレビューの議論ポイントではないでしょうか？例えば、「なぜあなたはこの構造の劇的な変更をしたのですか？」

15 project-management  refactoring  issue-tracking 

JIRAを使用して、ソフトウェアプロジェクトの問題を追跡しています。私たちが気づいた1つの効果は、新しい問題を頻繁に作成することですが、問題がいつ修正されるのか/いつ修正されるのかはまだわかりません。そこで、そのような問題に割り当てられる偽の「遠い未来」マイルストーンを発明しました。 偶然にも、このマイルストーンに割り当てられた問題の山は常に増え続けているため、これは良いアプローチではないようです。それらの多くは今では非常に多くあるため、それらすべての妥当性を確認するのは非常に多くの作業になりました。それらの一部は、それらに関連するコンポーネントが削除されたため無効になりました。それらのいくつかは他の問題によって複製されました。それらのいくつかは、彼らがもう何についてであるかを本当に誰も本当に知らないほど不十分に表現された説明を持っています。 他のソフトウェア開発チームは、有効であるが、いつでも修正されないかもしれない問題にどのように対処しますか。まったくわざわざ録音しますか？それらを次の計画バージョンに割り当て、次のリリースが近づくにつれてそれらを再度確認しますか？他に何か？

15 issue-tracking  jira 

現在、作業中のバグプロセスがあります。 バグには3つのレベルがあります。 P1バグ：ユーザーの作業を妨げるバグ。それらはその場で解決されなければなりません。 P2バグ：影響はあるが、ユーザーは作業できるバグ P3バグ：影響がなく、ユーザーが作業できるバグ。 P1は必須であり、その場で対処する必要があります。しかし、P2とP3については、ケースバイケースで判断します。 3つのレベルがあるため、チームはP2とP3を扱うのではなく、顧客から求められたより緊急の新しい開発に取り組む傾向があります。 質問は次のとおりです。 P4を持つなど、別のレベルの優先度を追加する必要がありますか？ 今週のように、緊急ではないチケットを処理するためのターゲットも割り当てる必要があります。コーディングタスクを割り当てない場合は、少なくとも1 P2を処理する必要がありますか。 現在、私が上で挙げたような目標はありませんが、私の懸念は、そのような目標を与えることは残忍なことです。確かなことは、目標について話し合う必要があることです。チームは、特に目標を設定するときに議論に関与するのが好きです。 更新： この質問は、類似性の観点から提案されました。しかし、まったく似ていません。 私の質問は、厳密なアジェンダを課すことなくバグを処理し、それを解決する方法です。だから、暗示された質問は私を助けない。それでも、ありがとう。

14 agile  debugging  issue-tracking 

当社では、開発者は適切なバグ追跡ツールを使用して、アプリケーションの問題を管理したいと考えています。ただし、管理者は共有スプレッドシート（​​以前は共有Excelファイルでしたが、現在は同時アクセスを可能にするWebベースソリューションのスプレッドシート）の使用を主張しています。 彼らの主張は、スプレッドシートを使用すると、プロジェクトの状態をより高レベルで把握できるため、開いているバグの数を一目で確認できるためです。また、これにより、各バグに取り組んでいる人を確認し、それらをすべて閉じるのに必要な時間の見積もりを取得できます（開発者は、作業中のバグの時間見積もりを記入する必要があるため）。 理解できるように、これは開発者にとって実際に使用するのは実際的ではありません（バグ追跡ソフトウェアは、ある理由で発明されました）。では、開発者の作業を容易にするためにバグ追跡ソフトウェアをどのように提唱できますか？ ボーナスとして、管理者が高レベルのビューでフィードバック（バグのオープン数、それらに取り組んでいる人、時間の見積もり）を取得できるようにするソフトウェアをお勧めしますか？

14 management  issue-tracking 

私の現在の仕事では、優先度が低、中、高のバグがあります。 優先度の低いバグは、出荷を停止したり、ユーザーに深刻な問題を引き起こしたりしない小さなエラーです。 中優先度のバグは、一部の内部ユーザーに問題を引き起こしますが、既知の回避策があります。 優先度の高いバグとは、お客様が目にする問題、データの破損、システムのクラッシュを引き起こす可能性のある問題です。 優先度の分類を補完するためにバグの重大度を分類する方法は？

14 bug  issue-tracking 

いくつかの種類のバグがあり、それらは再現するのが非常に難しく、ごくまれに、ランダムに発生します。考えられる原因を見つけて修正し、プログラムをテストしても、バグを再現できないことがあります。ただし、バグを確実に再現することは不可能であり、まれにしか発生しなかったため、バグトラッカーでこれをどのように示すことができますか？それを行う一般的な方法は何ですか？ statusを固定に設定すると、solution完全に固定されたものになりますか？ 「固定」と「開く」を設定しstatusてsolution、テスターに​​「おそらく修正されているが、確認するにはもっと注意が必要」であることを示すのは一般的な習慣ですか？ 編集：ほとんどの（すべてではないにしても）バグトラッカーには、バグのステータスに関する2つのプロパティがあります。名前は同じではない可能性があります。ことでstatus私が意味する、固定、割り当てられ、新しいなど、閉じられ、そしてによってsolution私が意味する、（新）オープン固定、バグ、複製、再現性のない、解けないなど、

13 testing  issue-tracking 

bugzilla、mantis、またはJIRAなどのバグ追跡/問題追跡ソフトウェアを、バグやタスクだけでなく、最終的に決定につながる議論を開始および維持するために使用した経験はありますか？ たとえば、開発者は、すべての保護フィールドを廃止し、それらにアクセスする保護メソッドを持つプライベートフィールドに変更する必要があると考えています。それは彼の呼び出しではなく、彼はそれを議論したいと思います。通常、彼は次の開発者会議でポイントを持ち出し、最後に決定が下されます。代わりに、私の考えは、彼が特定のタイプの「決定」の問題を開き、通常はバグやタスクを説明するように彼の意図を説明することでした。 他の開発者は、自分がそう思うとコメントすることができ、最終的に、問題は「受け入れられた」または「拒否された」としてクローズされます。 私がこれで見る利点： 非同期通信：決定のすべての影響を監督する時間がまだないときに、会議で意見を述べることを強制される人はいません。 決定に至る考慮事項の記録されたログ。後でその質問を再度提起した場合、彼はそれを参照することができます。 他の問題との関係を作ることができます。たとえば、タスクをフォローして決定に戻ることができます。 コミットなどのバージョン管理ソフトウェアとの統合は、決定にまでさかのぼることができます。 短所： 金色のハンマーの激しい匂い：通常、問題追跡ソフトウェアは実用的なアイテムを追跡するために使用されます 組織のオーバーヘッドは不均衡な場合があります。小さな非公式の会話の代わりに、書面でアイデアを伝える必要があります。

13 development-process  tools  issue-tracking 

私はテスターまたは開発者としていくつかのプロジェクトに携わってきました。多くのプロジェクトでは、以下の欠陥のステータスがありました。 修正しない キャンセル そのようなステータスを使用し、どのように区別しますか？ほとんどの人は違いを説明できないので、お願いします。私の理解は： 修正されません、それは欠陥ではありませんが原因で、開発者は、欠陥が修正されません- 。 キャンセル済み -優先順位が最も低いため、欠陥を修正しないでください

13 tools  issue-tracking 

適切なバグレポートを提出する方法について、会社の他のメンバーを教育する方法について、いくつかのヒントとアドバイスをもらいたいと思っています。現在、次のようなチケットを取得しています： このリンクをクリックすると、404が表示されます（404のページは含まれますが、それを引き起こしたページは含まれません）。 右の列がボタンの列に流れ込むことがあります。（スクリーンショットまたは追加情報なし） xxxへの変更は正しく機能しているようです。（EOM） 可能な限り多くの情報を送信するようユーザーを誘導するバグ送信プロセス/フォームはありますか？

13 issue-tracking  bug-report 

前書き ウェブサイトまたはシステムでエラーが発生した場合は、ログに記録し、エラーの参照コードを含む丁寧なメッセージをユーザーに表示することはもちろん役立ちます。 また、システムがたくさんある場合は、この情報を点在させたくはありません-単一の集中化された場所を用意しておくとよいでしょう。 最も単純なレベルでは、必要なのは、増分IDとエラーの詳細のシリアル化されたダンプだけです。（そして、おそらく「集中化された場所」は電子メールの受信トレイです。） スペクトルのもう一方の端には、おそらく完全に正規化されたデータベースがあり、ボタンを押して1日あたりのエラーのグラフを表示したり、システムXで最も一般的なタイプのエラーを特定したりできます。サーバーBよりも接続エラーなど。 ここで言及しているのは、リモートシステムによるコードレベルのエラー/例外のログです。Jira、Tracなどで行われるような「人間ベース」の問題追跡ではありません。 ご質問 このタイプのシステムを使用した開発者から、特に次の点についての考えを探しています。 欠かせない基本的な機能は何ですか？ 本当に時間を節約する機能があると便利ですか？ どの機能が良いアイデアに思えるかもしれませんが、実際にはそれほど便利ではありませんか？ たとえば、エラーの複数の発生を識別する「重複の表示」機能（「重要でない」詳細が異なることを心配せずに）は非常に重要です。 [このエラーに対して[Jira / etc]で問題を作成する]ボタンは、時間の節約になります。 繰り返しになりますが、私が望んでいるのは、そのようなシステムを使用した人々からの実践的な経験であり、できれば機能が素晴らしい/ひどい理由を裏付けています。 （とにかく理論化するつもりなら、少なくともそのようなものとしてあなたの答えをマークしてください。）

13 exceptions  issue-tracking  errors  logging 

Androidアプリのメンテナンスを引き継ぎました。多少の問題は残っていますが、多少の修正はありますが、Android OSのバージョンが異なるためにまだ問題があります。 たとえば、MediaPlayerクラスを使用してWebリクエストを送信すると、リクエストが送信される前にOSによってカスタムHTTPヘッダーが取り除かれますが、Android 4.X（徹底的にテスト済み）のみであり、この特定の機能は依存するため失敗しますそれらのヘッダー。 これは既知の問題であり、回避しようとしていますが、次のような条件付きチェックを行うことをお勧めします if (OS.VERSION == 4) { knownIssueDialog(This feature will not work on your Android version... etc."); } 明らかに、サポートチャネルにこれを記載しますが、これらの既知の問題もソフトウェアに埋め込み、必要なときに必要に応じて提示することは（すべてを追跡することを前提とする）良いアイデアかどうか疑問に思っています。上記のようなものです。 このような種類の問題に基づいて、複数の悪いレビューと多くのサポートメールを受け取り続けるため、適切に機能しないことがわかっている機能をブロックするだけで、多くの時間と頭痛の種を節約できると思います。 2つの潜在的な問題があります。 ユーザーは、「既知の問題」ダイアログのようなものを見たことがないでしょう。多くのユーザーは、それが何を意味するのか理解していないかもしれません。 開発のオーバーヘッドが少しあります-これらの問題をコードのどこかに追跡する必要があります。幸いなことに、Javaアノテーションを使用すると、そのような条件付きチェックの前に、@KnownIssueまたはそれに類することができるため、それらの検索/変更が非常に簡単になります。 ソフトウェアに「既知の問題」プロンプトを入れるのは理にかなっていますか？ 編集：これは、約1週間前に発生し始めた問題であることを追加します。私は問題を半分修正しましたが、問題を引き起こしているのはOSであるため、4.Xで修正できる可能性は非常に低いです。修正された新しいバージョンをリリースして、ユーザーベースの50％を再び幸せにし、他の50％（4.Xユーザー）に4.Xでも問題が続くことを警告し、アップグレード（または何か）。問題は、ソフトウェアでそれを行う（つまり、4.Xユーザーにダイアログを表示する）か、「修正が機能しませんでした!!!」というサポートメールを送信するだけかどうかです。その後、問題をさらに詳しく説明するサポートページに移動します。

12 programming-practices  issue-tracking  user-experience 

バグトラッカーにメモを自動的に書き込むようにソース管理を設定しているプロジェクトに取り組んでいます。コミットメッセージにバグの問題IDを書き込むだけで、コミットメッセージがバグトラッカーへのメモとして追加されます。 このプラクティスの欠点はほんの少ししかありません。将来、ソースコードがバグ追跡ソフトウェアから分離された場合（または報告されたバグ/問題が何らかの形で失われた場合）。または、誰かがコミットの履歴を調べているが、バグトラッカーにアクセスできない場合。 私の質問は、コミットメッセージにバグ/問題の参照を含めることをお勧めしますか？他にも欠点はありますか？

11 programming-practices  version-control  issue-tracking 

現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、または専門知識によってサポートされると予想されますが、この質問は議論、議論、世論調査、または広範な議論を求める可能性があります。この質問を改善し、場合によっては再開できると思われる場合は、ヘルプセンターをご覧ください。 7年前に閉鎖されました。 ロックされています。この質問とその回答はロックされています。なぜなら、質問はトピックから外れていますが、歴史的に重要だからです。現在、新しい回答やインタラクションを受け入れていません。 私は長年にわたって多くのサイドプロジェクトを蓄積してきましたが、時間をかけて徐々に改善しています。1つに戻るたびに、デザイン、最近のバグ、次の機能などを含むテキストファイルを読むのに時間がかかります。 もっと正式なものに切り替えたいと思っています。理想的には、これはフル機能のオンラインのバグ追跡システムであり、これにより、自分のプロジェクトの無料またはほぼ無料のバグ追跡が可能になります。また、理想的には、これはプライベートな方法で実行可能です-私の側のプロジェクトと私がそれらのいくつかで作った混乱を誰も見てほしくありません。

11 issue-tracking  personal-projects