Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

影響するバージョンの活用について

SmokeyBlues April 17, 2021

Jiraには、Affects version (影響するバージョン) と Fix version (修正バージョン)の2つのフィールドがあります。
直感的に、課題が見つかったときに、影響するバージョンフィールドに登録しました。

プロジェクトのバックログのバージョンパネルにいっこうに課題が表示されないのおかしいと調べていたところ、マニュアルには次のように書かれていました。https://www.atlassian.com/ja/agile/tutorials/versions

修正バージョンと影響するバージョンの違いは何ですか?

[Affects version (影響するバージョン)] とは、バグまたは問題が見つかったバージョンです。これは問題の追跡に役立ちますが、Jira ではそれほど頻繁に使用されません。

[Fix version (修正バージョン)] とは、顧客への機能のリリースまたはバグ修正を計画しているバージョンです。このフィールドはリリースの計画、進捗とベロシティの監視、および各種レポートに使用されます。通常は、これが必要とされるフィールドです。

バージョンパネルでは、修正バージョンでリストされるようです。
なぜ影響するバージョンでもフィルタすることができないのか疑問です。

あるオープンソースCRMのコミュニティでの課題解決システムでは、影響が出ているバージョンで課題を報告しトラッキングします。
1.1.1で影響が出ているということは、Fixされていないならば、その開発バージョンや上位公開バージョンでも影響が出ることを意味します。

Fix version (修正バージョン)という言語にひっぱられないように、修正を目指すバージョンととらえると、このフィールドがそのトラッキングの機能を提供する役割と理解できます。これが他の課題解決システムでいうところのマイルストーンと同一のフィールドでしょう。

この運用でみなさま不都合や使いにくさはないのでしょうか?
具体的な運用事例でお話を聞ければ理解できると思うのでご教示いただければありがたいです。

また、影響するバージョンはJiraではそれほど頻繁に使用しませんと説明されているのはどういうことなのでしょうか?

よろしくお願いいたします。

1 answer

0 votes
Rick Li
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 21, 2021

コミュニティをご利用いただきありがとうございます。

 

影響するバージョンは、基本的に、バグの課題タイプに関わると思います。

下記は、弊社JACサイトの例となります。課題タイプバグの場合、影響バージョンがありますが、改善要望課題タイプの場合、影響バージョンはありません。

 

影響するバージョン項目

影響するバージョンは、基本的に、バグの課題タイプのみに、意味があります。改善などタイプの場合、意味がないため、運用しておりません。

Fix version (修正バージョン)

Fix version (修正バージョン)の場合、バグと要望の両方課題タイプに、意味があります。

バグの場合、そのバグの修正バージョンとなります。バグ以外、要望などの場合、その要望のリリースバージョンとなります。


上記のため、影響するバージョンはJiraではそれほど頻繁に使用しません。

SmokeyBlues April 21, 2021

実例をご紹介いただきありがとうございます。

バグの場合、影響するバージョンフィールドを「Introduced in Version:」と名称変更されているのでしょうか。
セマンティックバージョニングで考えると、

  • 1.1.1
  • 1.1.2

がリリースされていて、この2つのバージョンを利用している異なるユーザーがいたとします。(1.1.1から1.1.2へアップデートしていない、古いバージョンを使用しているユーザーがいるということ)
1.1.2でも修正されていないとき、影響するバージョンという言葉であれば、1.1.1で発生して1.1.2で修正していないわけだから当然1.1.2でも影響を受けるわけですから、どちらのバージョンを利用しているユーザーからバグの報告を受けたかということで、報告を受けたバージョンとフィールド名を変更されて運用されているのであろうと推測できます。
このフィールドは複数値を登録できますので、複数入力を簡素化する意味合いもあったのでしょう。

バグについては理解できます。しかし、改善や新機能についても同じではないのでしょうか?どのバージョンを使っているユーザーが、既存機能の改善を求めているのか、機能がないので新機能を欲しているのか、修正バージョンがないときは、その報告を受けたバージョン以降どれも改善や新機能は対応されていないのでと、バグと同様に運用できるかと思います。
そこでバージョンパネルでは、影響するバージョンでフィルタする機能が欲しいわけです。

 

修正バージョンの場合、修正しなければ値はありません。
評価中の場合、修正バージョンはまだ決まらないし、1.1.5で修正しようと計画していたが、事情により1.2.0で修正されたというような、予定していても変更される場合もあります。
そう考えると、修正された結果の記録で使用するフィールドであり、修正目標で取り組んでいる、計画しているバージョンを記録するフィールドではないことを意味します。
目標や計画で利用するのであれば、バージョンパネルでフィルタし、適宜変更することに意味があるわけですが、修正完了のフィルタリングをすることに大きなメリットはあるのでしょうか?

この2つの影響する、修正するバージョンのフィールドは、各自ユーザーが適宜便利なように使ってくれということでしょうが、定義があいまいでかえってわかりずらくなっていると考えます。
特にバージョンパネルで影響するバージョンをフィルタするように切り替えができないので。

Rick Li
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
April 29, 2021

コミュニティをご利用いただきありがとうございます。

「Introduced in Version」は、影響バージョン(Affects Version)と別フィールドとなります。影響バージョンは、Jira Softwareの システムフィールド  となりますが、「Introduced in Version」は、運用上、追加されたカスタムフィールドとなります。

1.1.1と1.1.2は、両方とも、影響されている場合、課題の影響バージョンのフィールド上、両方を登録する必要があります。一般的に、影響バージョンフィールドに、複数の値があります。下記弊社JACサイトの例上、影響バージョンフィールドに、十件以上の値を登録されております。


バグ発生の最初バージョンを管理したい場合、「報告を受けたバージョン」のカスタムフィールドを追加すれば、と思います。弊社JACサイト上、「Introduced in Version」のカスタムフィールドがあります。


バグ追跡の運用の場合、修正バージョンのフィールドに、基本的に、修正済のバージョンを登録することになります。もし、予定されたバージョンに、修正をできない場合、課題上、修正バージョンの値を修正すれば、と思います。


開発計画には、必要なのは、修正バージョンフィールドとなります。影響するバージョンは、不具合発生するバージョンのみを示しますが、特に開発計画に、関わらないと思います。そのため、バージョンパネルで影響するバージョンをフィルタしておりません。


SmokeyBlues April 29, 2021

詳しくご教示いただきありがとうございます。

「Introduced in Version」は、影響バージョン(Affects Version)と別フィールドとなります。影響バージョンは、Jira Softwareの システムフィールド  となりますが、「Introduced in Version」は、運用上、追加されたカスタムフィールドとなります。

バグ発生の最初バージョンを管理したい場合、「報告を受けたバージョン」のカスタムフィールドを追加すれば、と思います。弊社JACサイト上、「Introduced in Version」のカスタムフィールドがあります。

なるほど、影響するバージョンのうち、バグ発生の最初のバージョンを管理したいということで、カスタムフィールドを作成し運用されているということを理解しました。

一般的に、影響バージョンフィールドに、複数の値があります。下記弊社JACサイトの例上、影響バージョンフィールドに、十件以上の値を登録されております。

影響するバージョンは、複数登録する必要があることを理解しました。

 

バグ追跡の運用の場合、修正バージョンのフィールドに、基本的に、修正済のバージョンを登録することになります。もし、予定されたバージョンに、修正をできない場合、課題上、修正バージョンの値を修正すれば、と思います。

開発計画には、必要なのは、修正バージョンフィールドとなります。影響するバージョンは、不具合発生するバージョンのみを示しますが、特に開発計画に、関わらないと思います。そのため、バージョンパネルで影響するバージョンをフィルタしておりません。

開発では、影響するバージョンで予定管理し、修正ができない場合変更することで理解しました。

 

バグではない、新機能や機能改善、タスクでの影響するバージョンや修正するバージョンの活用の仕方があれば参考に教えていただけるとありがたいです。

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
FREE
PERMISSIONS LEVEL
Product Admin
TAGS
AUG Leaders

Atlassian Community Events