マニュアル-最新情報

長い間市場に出回っている製品があるが、毎日活発に開発されている場合-マニュアルを更新する頻度はどれくらいですか？最新のバグ修正が常に出荷されたバージョンに含まれていると組織が判断したために、ユーザーが常に最新バージョンに更新されている場合。つまり、ある日バグを修正し、翌日それが本番環境に移行する可能性があります。

マニュアルを更新します：

1. メジャーリリースごと
2. 重要な新機能が安定して成熟し、5分ごとに変更されないことがわかったとき。

コードの変更によりマニュアルの説明が変更される場合はいつでも（PDF）マニュアルを更新します。リリースプロセスのマニュアル部分を更新するだけです。

ユーザーが製品の使用方法をマニュアルに頼って、製品が変更された場合、マニュアルの関連セクションも変更する必要があるのは常識にすぎません

2010年も、印刷されたドキュメントを参照していますか？どうして？;）

真剣に考えると、ドキュメント（ "F1"アプリケーションヘルプ、PDF、またはオンラインドキュメント）は、すべてのリリースの一部である必要があります。言い訳はゼロ。「公開」するのはとても簡単です。実際のところ、IMOでは、問題が判明して修正されるとすぐに、リリースの合間であっても、ドキュメントを定期的に（オンラインとPDFで）更新しない言い訳はありません。同じレベルのQAは必要ありません。

私はあなたがエンドユーザーのドキュメントについて話していると思います。ドキュメンテーションを書くことは@ $$の苦痛であり、私は逆を説得するためにいくつかのテクニックを開発しましたが、それでもまだ問題があります。これは私がそれを管理しようとする方法です：

DoDのドキュメントの更新を統合します（完了の定義）

これにより、各ユーザーストーリーの完了時にドキュメントが最新の状態になります。

これが私たちが書いた完了の定義です。私は元のフォーマットを維持しようとしたので、あなたはアイデアを得ます。ホワイトボードに貼られたA4ページです。

---------- 8 <------------ここをカット------------ 8 <----------

交渉不可

「完了」の定義

• リポジトリにコミットされた、80％の単体テストカバレッジのコード

• 該当する場合はスクリーンショット（1024x728、395x281、170x121および729x329）

• 該当する場合は機能の説明（50文字、100文字）

• 完全なエンドユーザードキュメント

• 新しいファイルが正しく更新された

---------- 8 <------------ここをカット------------ 8 <----------

もちろん、ドキュメントにレビュープロセスを追加できます。私たちには英語を母国語とする人はいません。

このように完了の定義の利点の1つは、製品が各ユーザーストーリーの完了時に出荷される可能性があることです。

組み合わせで、この技術を使用して、この1。

私の組織では、通常3種類のリリースがあります。

1. エンジニアリングリリース-基本的に、特定の顧客または特定の顧客のみが即時に要求した機能のホットフィックス。
2. マイナーリリース-バグ修正、増分サポート
3. メジャーリリース-新機能のサポートなど

定義により、メジャーリリースには、オンラインとオフラインの両方で関連ドキュメントを配置する必要があります。私たちの追跡システムは、ドキュメントがチェックリストの大部分を占めることを保証します。

マイナーリリースでは、ユーザーの認識レベルで追加された新しいものについてのみドキュメントが必要です。したがって、特定のシナリオで時間の複雑さを軽減する可能性がある別のヒューリスティックを含めた場合、それをPDFに入れることは重要な呼び出しになる場合とそうでない場合があります。

エンジニアリングリリースは、ドキュメントがなくても実行できます。いくつかの非公式の使用上の注意は、始めるのに十分なはずです。

ドキュメントは、顧客に出荷するソフトウェアと同期する必要があります。その他の不一致があると、問題が発生します。スタッフにライターがいない場合は、請負業者に依頼してください。あなたが好きなものを見つけたら、彼を家に留めておいてください。