タグ付けされた質問 「jira」

4
関係のなくなったバグを閉じる方法
現在、中規模のWeb開発者チームに所属しています。バグ追跡にjiraを使用しています。 私たちは頻繁にレイアウトを変更する製品に取り組んでいます。多くの場合、一部のブラウザのレイアウトのバグについてバグが報告されます。時々、優先度の低いバグに対処する頃には、レイアウトはすでに変更されており、関連性がなくなっています。 何を閉じますか? 私が言いたいのは、これらの問題をどう扱うべきかということです。Jiraは私たちが使用するバグ追跡ソフトウェアですが、私はこれらの種類の問題全般をどのように処理するかにもっと興味があります。 それも重要ですか?(後でレイアウトに戻る可能性がありますが、ほとんどありません)

4
GitFlowを使用して別のブランチからのコードのマージを待機することにより、開発者がブロックされました
私たちのチームは、FogBugz&Kiln / MercurialからJira&Stash / Gitに切り替えました。ブランチにはGit Flowモデルを使用し、機能ブランチからサブタスクブランチを追加しています(Jira機能のJiraサブタスクに関連)。プルリクエストを作成して親ブランチにマージするときにStashを使用してレビュアーを割り当てます(通常は開発しますが、サブタスクは機能ブランチに戻ります)。 私たちが見つけている問題は、複数の開発者が同じ機能、たとえばフロントエンドとバックエンドで相互に依存しているコードで作業している場合、機能ケースの最適な計画と内訳でもです。別のブランチでは、1人の開発者が他の開発者をブロックします。 開発中に、お互いのブランチ間をプルしようとしました。また、各開発者が複数のブランチからプルして、開発時に統合をテストできるローカル統合ブランチを作成しようとしました。最後に、これはこれまでのところ私たちにとっておそらく最もうまく機能しているようですが、もう少しオーバーヘッドがありますが、機能ブランチからすぐに統合ブランチを作成しようとしました。サブタスクブランチ(機能ブランチ外)がプルリクエストとコードレビューの準備ができたら、これらの変更セットをこの機能統合ブランチに手動でマージします。その後、関心のあるすべての開発者は、その統合ブランチから他の依存サブタスクブランチにプルできます。これにより、コードレビューに合格するために依存しているブランチを誰も待つことができなくなります。 これは必ずしもGitの問題ではないことを知っています。これは、独自の作業プロセスと文化が混在する、複数のブランチで相互依存するコードを操作することに関係しています。開発(厳密な統合ブランチ)のための厳格なコードレビューポリシーがない場合、開発者1は、開発者2が引き出せるように開発にマージできます。もう1つの複雑な点は、QAに機能を渡す前に、コードレビュープロセスの一部としていくつかの予備テストを行う必要があることです。バックエンド開発者2が終了し、プルリクエストがコードレビューに1週間座っている場合、フロントエンド開発者2はコードレビューアができないため、技術的にプルリクエスト/コードレビューを作成できませんバックエンド開発者2 'のためのテスト 結論として、これらのインスタンスでは、どのルートに行くかに応じて、パラレルではなくはるかにシリアルなアプローチで自分自身を見つけており、これを回避するために使用するプロセスを見つけたいと考えています。 最後に言及することは、コードのレビューとファイナライズが完了していないブランチ間でコードを共有することで実現していますが、本質的には他のベータコードを使用しています。ある程度まではそれを避けることはできないと思いますし、ある程度それを受け入れるつもりです。

3
変更のリスク別にタスク/バグを分類する
私が現在取り組んでいるプロジェクトには問題があります。バグやタスクは、あまりにも新しい人や経験の浅い人に割り当てられることが多く、彼らの仕事は将来的にさらにバグを生み出すことになります。問題は、コードの品質の問題のために、ソフトウェアの一部が他の部分よりも「危険」であるということです。私は、タスクに関連するリスクを推定し、どの開発者にどのタスクが割り当てられるかに細心の注意を払うことで、この問題に対処しようとしています。 JIRAを使用しているため、この推定を追跡するために問題のラベル付けを開始しました。バグ/タスクを分類するためにいくつかのメトリックを使用することになったことに気付きました: それがどれほど明確/単純か。たとえば、多くの設計作業が必要なのか、単純なUIのバグ修正が必要なのかなどです。 コードの影響を受ける領域の保守性。うまく設計されたエリアなのか、泥だらけの大きなボールなのか。 必要な変更の影響を受けると思うプログラムの量。 考えられるカテゴリが何であるかを始めたとき、私は明確な考えを持っていなかったので、私のラベルは少し厄介です。仕事を誰かに割り当てる前に見積もりを要求できるように、新しいフィールド(「リスク」のようなもの)の追加を要求することを考えています。 誰もこのようなことを以前に扱ったことがありますか?

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

3
不良コードのコストを計算する
私は経営陣にリファクタリングへの努力を投資するよう説得するための議論を探しています。 Jiraを使用して作業を記録し、すべてのsvn-commitをjira呼び出しに関連付けます。 私のアイデアは次のことです。 実装が非常に悪いが頻繁に使用されるコードの領域を手動で見つけます。User-POVとDeveloper-POVの両方(バグ修正) JIRA-Issuesを含むsvn-commitsを取得します いくつかの基準(問題の種類、バージョン、優先順位など)に従って問題をフィルタリングします。 これらのバグに費やされた時間/努力を計算する リファクタリングの労力とリスクを推定する 数字を提示し、それを修正する努力を求めます。 これについてどう思いますか?そのような測定は有用であり、説得力があるでしょうか?長所と短所は何ですか?

3
複数のプロジェクトにまたがって取り組む問題のストーリー準備をモデル化する方法
当社では、複数のチームが同時に複数のプロジェクトのさまざまなコンポーネントに取り組みます。たとえば、あるチームが特定の種類のプロジェクトに特定の種類のソフトウェア(またはハードウェア)を作成し、別のチームが別の特定の種類のソフトウェアを作成する場合があります。Jiraプロジェクトを使用して特定のプロジェクトの問題をホストし、Jiraボードを使用して異なるチームのスプリントを実行します。 私たちはプロジェクト間でコードの重複を回避するという問題に直面し、それらのプロジェクトで使用する一連のコアライブラリを開発しました。プロジェクトに取り組んでいる間に、一部の開発者は、自分が書いたコードの一部がより興味深く、コアライブラリに抽出する必要があること、または使用している一部のコアコードにバグがあり、さらにパラメーター化が必要であること、または新機能...あなたはそれに名前を付けます。 したがって、コアプロジェクトのバックログに入るコアライブラリの問題を作成します。これらの問題はすべて、コアライブラリミーティング(週に1回)でレビュー、優先順位付け、推定され、将来のスプリントでは(プロジェクト固有の問題と共に)優先順位に従って取り組みます。 優先順位付けは問題を並べ替えることで行われ、並べ替えられた問題にsortedラベルを付けます(並べ替えられていない問題を検索できるようにするため)。次に、コアコンポーネントごとに1つの課題をバックログの先頭に手動で配置して、それらを最初に処理します。一部のチームがそのような問題をスプリントに入れる場合、代わりに別のアイテムをバックログの上部に手動でドラッグする必要があります。 これはかなりエラーが発生しやすいです。基本的に、私たちが持っているのは、「未解決」と「進行中」の間の「ソート済み」と「推定済み」の追加の問題ステータスです。これをsortedラベルとボード内での位置で反映することは、かなり面倒でエラーが発生しやすくなります。(たとえば、誰かがスプリントで問題を上下に移動すると、これはコアボードに反映され、数週間前の広範なディスカッションでチームが決定した可能性がある問題の順序を静かにスクランブルします。) これを実装するより良い方法は何でしょうか?

5
コードコメントにJIRAの問題を含めることは、一般的に役立ちますか?
たまにはこういうコメントをします # We only need to use the following for V4 of the computation. # See APIPROJ-14 for details. または # We only need to use the following for V4 of the computation. # See https://theboringcompany.atlassian.net/browse/DIGIT-827 for details. そうすることに関する私の主な懸念は、JIRAへの依存度が高まることです。そのため、別のプロジェクト管理システムに移行する場合、これらのコメントはまったく意味がありません。近い将来に発生することは予測できませんが、組織コンポーネント(この場合は、コード、コードリポジトリ、プロジェクト管理システム)の結合の増加に引き続き注意します。 ただし、コードベース全体で、文書化された設計の決定と機能のインスピレーションへの参照があることの利点はわかります。私の知る限り、メリットは 設計の決定への明確な道筋。これは、見慣れないコードの特定のセグメントのデバッグと強化に役立ちます。 複数行のコメントが少ないため、コードがよりクリーンになり、新しい貢献者を脅かすことが少なくなります。 (潜在的に)現在の技術的および非技術的利害関係者への明確な道筋 前述の理由により、「なぜここにあるのか」という質問の数は減少しています。
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.