リリースノートの作成のグッドプラクティス


12

ソフトウェアのすべてのバージョンの配信時に、リリースノートを作成する必要があります。たとえば、リリースノートを作成するときに追加する用語の一部を次に示します。

  • 発売日
  • 解決したバグ

それで十分ですか、それとも何かありますか?



1
追加された機能を忘れないでください
ラチェットフリーク

回答:


21

以下は良い習慣への道を与えると思います

//日付関連

  • 発売日

//機能関連

  • 追加された機能
  • 削除された機能
  • 変更された機能

//バグ関連

  • 解決したバグ
  • 未解決のバグ

//依存関係

  • 依存関係のリスト

//テスト関連

  • ユニットテスト結果
  • 受入試験結果

//バージョン管理関連

  • タグメモ
  • リビジョン番号

また、エンドユーザーが構成やワークフローを変更したいことを強調する価値があります。

ほとんどのエンドユーザーはテスト結果を気にしません。彼らは、リリースノートが何と言っても、それが高品質であることを期待しています。

リリースノートに関する最も重要なことは、すべての追加文が読者の別の10%を失うことに注意することです。したがって、現在のユーザーがリリースについて知っておくべきことを厳密に優先する必要があります。


1
また、エンドユーザーが構成やワークフローで変更したいことを強調する価値があることもあります
jk。

@jk。はい、あなたは正しいです。あなたの良いコメントとして私の答えを編集しました。
Mdマフブールラーマン

ほとんどのエンドユーザーはテスト結果を気にしません。彼らは、リリースノートが何と言っても、それが高品質であることを期待しています。
ヘンリック

@Henrikリリースノートは、エンドユーザー以外の人々にとっても有用かもしれません
jk。

5

リリースノートに関する最も重要なことは、すべての追加文が読者の別の10%を失うことに注意することです。したがって、現在のユーザーがリリースについて知っておくべきことを厳密に優先する必要があります。


4
各行は、カジュアルで興味のない(または怠zyな)読者の10%を失う可能性があります。これらの読者は、リリースノートが書かれていない読者です。あなたがしたことを気にする人はそれらをすべて読み、関連する各行に感謝します-あなたは本当に適切にドキュメントに入る必要がある綿毛を含めることに注意するだけです。
-gbjbaanb
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.