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

組織の必要に応じて、問題のリストを管理および維持するプロセスを追跡する問題。

3
GitHub：課題リストとプロジェクトバックログを管理するための外部ツールはありますか
最近、GitHub に私のプロジェクトの1つを投稿しました。サイトの機能を調査していると、かなりまともな問題追跡セクションがあることに気付きました。 このセクションを、a）他の人が必要に応じてバグを報告できるようにし、b）他の人が私の知っているバグを確認できるようにしたい。ただし、他の人が指摘したように、プロジェクトバックログを作成するために問題リストに優先順位を付けることはできません。今のところ、私のバックログはテキストファイルですが、同じ情報が別の場所で保持されないように統合できるようにしたいと考えています。 私たちが仕事でも練習している完全に順序付けられたリストがあることは、1つのファイルを開き、1行目から始めて、完全な問題に戻ることなく、1か所で2つまたは3つのアイテムを発射できるため、非常に便利です。ストーリーバケット。GitHubはこれを提供していません。 GitHubが提供するものは非常に素晴らしくてクリーンなAPIなので、問題を他の何かに簡単にエクスポートできます。GitHubの問題と統合されている他のWebサイト（Trelloなど）があるかどうかを検索しましたが、何も見つかりませんでした。 そのような製品、サービス、オフラインツールを知っている人はいますか？GitHubを使用しているユーザー、バックログの管理での経験は何ですか？一部の人々がWikiプロジェクトページで行っているように見えるように、2つの切断されたリストを手動で管理するという考えはちょっと嫌いです。 1-恥知らずなプラグインはこのサイトで許可されていませんか？検索しましたが、明確な答えは見つかりませんでした。それが悪い習慣であるならば、やめて、さらに読み進めないでください 開発者として、私は1日に30回同じフォルダーのセットに移動することにうんざりしていました。そのため、デスクトップに行き詰まり、常に使用するフォルダーに簡単にアクセスできる、自動折りたたみ可能なユーティリティを少し書きました。
5
課題追跡のバックログを管理する方法
私たちはここ数年Tracを忠実に使用しており、「アクティブチケット」リストは約200アイテムに増えました。これらには、優先度が低すぎて複雑すぎて現時点では修正できないバグ、延期された機能リクエスト、実際に苦情が発生したことはないが誰もがいつか修正すべきであることに同意している問題、計画されたコードリファクタリング、およびその他の設計上の問題失くしたいなど その結果、これらの問題の約200と、リストはほとんど圧倒的です。現時点で取り組む必要のあるもののソースとしてはもはや有用ではありません。 この種の問題を追跡する最良の方法は何ですか？ 問題の一部は、これらの問題のいくつかは優先度が非常に低いため、実行できない可能性があることです。私はこれらのアイテムを見失うのが嫌いです（いつか必要になる場合に備えて、家から何かを捨てたくないのと同じです）。（Wontfixとしてマークすることにより）関係なくそれらを破棄する必要があり、将来必要になった場合にそれらを見つけることができると想定しますか？
4
匿名ユーザーにプライベートGitHubプロジェクトのバグを送信させるにはどうすればよいですか？
私たちの会社には、私が取り組んでいるプロジェクト用のプライベートGitHubリポジトリがあります。完全な夏の作業が終わった後、今週はローンチする予定です（wheee！）。ただし、GitHubで問題となるフォームにユーザーが記入できるフォームのどこかにつながる「バグを送信する」リンクをプログラムに含めたいと思います。グーグルで探しても解決策（または同じ問題を抱えている人）は見つかりませんでした。 これは可能ですか（おそらく一部のAPIを使用して？）、またはユーザーが報告したバグを手動で入力する必要がありますか？
4
誰がバグチケットの重複を排除しますか？
私のチームメイトの一人と私は別々のバグチケットを手に取り、自分たちに個別に割り当てましたが、チケットは重複しています！ 重複チケットを解決する最良の方法は何ですか？通常、これはQAリソースによって行われますか？私は、技術者以外の人が「フロー」を中断すると言う2か所で働いてきましたが、開発者へのアクセスが制限されている状況（つまり、基本的に常に）で、技術者以外の人ができることです。
5
最大の費用対効果をもたらすバグの解決[終了]
閉まっている。この質問はトピックから外れています。現在、回答を受け付けていません。 この質問を改善してみませんか？ 質問を更新して、ソフトウェアエンジニアリングスタック交換のトピックになるようにします。 4年前休業。 解決がどれほど簡単か、そしてどれだけの利益が得られるかに基づいて、バグを分類する方法を知りたいと思っていました。たとえば、解決に1時間かかる（2つのファイルを閉じるなど）バグと、1日かかる別のバグ（セグメンテーションエラー）がある場合などです。ただし、最初のバグの解決がそれほど重要でない場合は、おそらく2番目のバグに取り組みます。 費用便益または類似の指標に基づいてバグを分類する研究論文はありますか？ たとえば、セキュリティの脆弱性、メモリエラー、論理エラーなど、バグの特性に基づいてバグを分類することができるとしましょう。他の次元では、難易度（簡単、中程度、難しい）などのパラメータがある場合があります。私が探しているべき他の次元はありますか？物事を単純化するために、私は2つのことを想定できます。 チーム内のすべてのプログラマーは、あらゆるバグを同等に解決することができます 締め切りはありません
1
課題トラッカーとプロジェクト仕様書が重複しないようにするにはどうすればよいですか？
以前は専門のコンサルティング会社で働いていましたが、さまざまな契約条件で働いていました。時間と材料のプロジェクトを取得できたら、SCRUMで実行し、課題追跡システムでバックログを追跡しました。 ただし、ほとんどの場合、固定価格契約の下で納品する必要がありました。これには、契約の付録として仕様書が必要でした。そのため、仕様から作業項目をバッチインポート（さらには手動で入力）することになりました。変更注文は、特にプロジェクトの終わりに向かって、すべてが同期していることを確認するのに長い時間がかかりました。 このプロセス全体をDRYに保つ方法論またはソフトウェアツールはありますか？私はいくつかの検索を行ったが、どうやら正しい用語を使用していない。私の専門ネットワークのほとんどは固定価格の仕事をしていません。 私は次のことを受け入れます： バグトラッカーの切り替えまたはプラグインの購入（現在はFogBugzを使用）。 別の開発方法論に従う 仕様を管理し、バグトラッカーと仕様ドキュメントを更新するソフトウェアを作成する（ただし、これは、疑わしい利益のために多くの作業が必要と思われます） 最後に、これは本当に解決する価値がありますか？一部のプロジェクトではかなりの費用がかかりましたが、他のプロジェクトでは影響はありませんでした。
7
バグのためにケースを再度開く必要がありますか、それともバグを新しいケースとして開く必要がありますか？
現在、私の職場では、さまざまなWebアプリケーションのすべての機能とバグを管理するためにFogBugzを使用しています。 Webアプリケーションの1つに新しい機能を追加すると、新しいケースが作成されます。たとえば、「CSVアップロードフォームの作成」です。 次に、私が費やした時間を記録してケースに取り組みます。このケースが完了したら、それを解決すると、ケースオープナー（通常はプロジェクトマネージャー）に割り当てられ、ケースマネージャーがケースを閉じます。 この機能にバグがある場合、プロジェクトマネージャーがケースを再度開き、バグの箇条書きリストを付けてケースを割り当てます。 私の意見では、これらの箇条書きのバグは個別のバグケースとして開く必要があると思います。そうすることで、追跡が容易になり、元の機能ケースのメモが散らからないようになります。 私のマネージャーは、機能に費やされた合計時間をすべて1つの場合に計算する方が簡単であると述べることに同意しません。 さらに、機能の参照番号が1つしかないため、クライアントの混乱が少ないと考えています。ただし、これは元のケースの完了後なので、バグは別のケースとして処理する必要があることを強調します。 バグは新しいケースとして再開する必要があると私は言っていますか？そして、これを管理するそれぞれの方法の長所/短所は何ですか？
5
問題追跡システムを使用することの欠点についての調査はありますか？[閉まっている]
現在のところ、この質問はQ＆A形式には適していません。回答は事実、参考文献、専門知識によって裏付けられると期待していますが、この質問は、議論、議論、投票、または拡張ディスカッションを求める可能性があります。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前休業。 次の理由で、問題追跡システムは好きではありません。 その中で問題を説明するには時間がかかりすぎます。これはその使用を思いとどまらせます。 バグを保管する場所を作成します。そして、彼らのための場所があれば、人々は通常、バグを修正することについてあまり気にしないので、いつか誰かがそれを修正できるようにするためにバグをそこに置くことができます。 時間が経つにつれ、バグリストは非常に長くなり、だれもそれを処理できなくなり、多くの時間を費やしています。 ホワイトボードでポストイットを使用して問題を処理したり、顔を見ながら会話したり、重要なバグが現れたらすぐに殺したりすることを好みます。オーバーヘッドに見合うだけの価値はないと思うので、バグの履歴を追跡することはあまり気にしません。 私はここに一人ですか？問題追跡システムを使用することの欠点（または大きな利点）に関する研究（本/記事/何でも）はありますか？
7
リファクタリング作業を含むすべての開発に追跡の問題を伴うべきですか？
議論：リファクタリング作業を含むすべての開発には追跡の問題を伴うべきですか？（この場合、Jira） 共通点：私たちの主な目標は品質です。機能する製品、すべてのリリースは、何よりも重要です。私たちのコードベースは古く、自動テストが欠けています。私たちはこれに取り組んでいますが、それは長期的なプロジェクトであり、暫定的なプロセスが必要です。 ポジション1：リファクタリング作業はJiraで追跡する必要があります。変更と明らかに関係がない場合は、別の問題を提起する必要があります。そうしないと、レビューとテストが省略され、私たちの主な目標にリスクが生じます。PCIコンプライアンス（ビジネスの近い将来の目標）ではこのレベルの追跡が必要であるという議論が行われました。私はそれがどんなレベルの確実性でも真実か偽りであると言う立場にはありません。 ポジション2：コードの品質は非常に重要です。それが良くなればなるほど（ある程度、私たちがどこにも近くないほど）、機能する製品をリリースし続ける可能性が高くなります。どんなに小さくても、リファクタリングの方法で障害となるものはすべて、私たちの主な目標に対するリスクです。多くの場合、IDEが自動的に機能します。そのため、とにかく問題が発生することはほとんどありません。 次のケースが行われました： 開発者がカードに「リファクタリング」と関連するリビジョン番号を書き込んだ場合、それは両方の立場を満たしますか？正直なところ、これは皆を等しく不幸にしてしまうような気がします。それでも、リファクタリングの実行にはある程度の抵抗はありますが、十分な追跡機能はありません。 イテレーションのリファクタリング作業を網羅する、すべてを網羅するJiraの問題についてはどうですか？はい、これにより開発者の抵抗層が削除されますが、Jiraの問題があることによる追跡の利点も削除されると思います。QAは何をテストすべきかを明確に理解する方法を教えてください。これは政治的な解決策のようであり、軽量だが最終的には無意味なプロセスを追加することで誰もが落ち着くようにしています。 議論の双方が最終的に同じことを望んでいることを考えると、誰もが本当に幸せになる解決策があるはずだと私には思えます。私たちはこの質問をする最初の人ではあり得なかったので、同様の状況で他の人はどのような経験をしましたか？
6
アジャイル開発における「マイルストーン」の有用性
多くの課題追跡は「マイルストーン」と呼ばれるものをサポートしています。私はそれらの用途を見つけたことがありません。マイルストーンは、スケジュールされた大規模なプッシュを行う場合にのみ役立ちますが、新機能やバグ修正が完了したときに展開する場合には役立ちません。 マイルストーンを使用してアジャイル開発をいつ/どのように編成しますか？
3
分散型問題追跡[終了]
休業。この質問には、より焦点を当てる必要があります。現在、回答を受け付けていません。 この質問を改善してみませんか？質問を更新して、この投稿を編集するだけで1つの問題に焦点を当てます。 5年前休業。 分散型の問題追跡は、私にとってベルトのような考えのように見えますが、実際に大きな成功を収めたことはありません。その正当な理由はありますか？ 気がついた： どこでもバグズ セットアップするには複雑すぎる 要件が多すぎる ある程度成功し、一部の大規模プロジェクトで使用されている 化石 あまりにも多くのものを統合しようとし、最終的にそれらすべてのやや悪いバージョンになります-おそらく、まともな（おそらく私が見た中で最高の）分散型問題追跡部分を除いて 他のいくつかの小さなプロジェクト どれも牽引力を獲得していません 私は自分で作ることを考えていますが、始める前に、他の誰もが大きな成功を収めていない理由を知りたいと思います。 予想される問題：（すべて克服できると思います） 更新された分散問題をマージすることは、コードファイルをマージするのと同様に複雑です。 コメントはいつでも入ってくる可能性があり、おそらく正しいフローではないため、会話の継続性が破壊される可能性があります 最新の問題がある中央サーバーへの期待
4
バグを修正できない場合、どこに問い合わせればよいですか？
答えがわからないときの参考資料を探しています。私はソフトウェア開発者のチームを率いています。私たちは毎月新しいソフトウェアリリースを展開しています。 私のチームが修正できないバグがある場合、それは私にあります。ほとんどの場合、問題を解決できますが、行き詰まることがあります。 残念ながら、私は私たちの会社の最上位です。何かを理解するのに助けや助けを求めることができる人は誰もいません。 このような状況での推奨事項やガイダンスはありますか？
4
オープンソースソフトウェアのバグの修正を開始するにはどうすればよいですか？
私はCプログラミングの知識が豊富で、Cで開発されたオープンソースプロジェクトに貢献したい学生です。SourceForgeを検索し、7-Zipを選択しました。 私はまずバグを修正することから始めようと考え（ウェブサイトで多くの人から提案されました）、いくつかのバグを経験しましたが、バグへの対応方法と修正方法を理解できませんでした。何もわかりませんでした。 これへの取り組み方を説明していただけますか？ダウンロードしたソースコードのファイルをいくつか調べましたが、何も理解できませんでした。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.