プロジェクトは現在、同社の開発に関与している非常に成熟し、安定したプロジェクトで、すべてのユーザーのプライマリ考慮に影響を与えることなく、リリースのための新しいバージョンをアップグレードするので、このプロジェクトは、ディーラーの利用を促進するために数年前から国になっています新機能と修正のバグ。開発者のために、各新しいリリースには、多くの圧力に直面するだろう。
我々はあまりにも慎重に、必然的に新しいバージョンを公開するとしてもいるので、ユーザーはわずかな影響はありません。時には、いくつかのより深刻かつ緊急のバグを生み出します。
何回かは、私はいくつかの考えを行っている新バージョンのリリース後は、次のように結論付けました。
1.各新しいリリースの間の時間が長すぎるすべきではない、新しいバージョンでは、バグのニーズが含まれておりませんあまりにも多くのバグのニーズや緊急性や重要性に応じてソートし、新しいニーズの特定の数を選択して、バグを公開するべきです。（このような毎月リリース新バージョンごとのバグ総需要となし、30以上のように応じてプロジェクトの特定の場合には、当然の、適切です。）
ニーズの2.理解は、需要が会議の終了を議論した後、開発者が自分の理解に基づいて要求仕様を行います、それはスタッフのニーズに発行された仕様が必要な場合は、また一度確認し、顧客に行くことができる、ことを確認した要件が推奨され、特別な要件や人員が存在しない場合は、予定の時間を確認するために、ユーザに指示することができます。開発チーム内で完了することができ、詳細な設計レビューを書いた後、要求仕様の完了を確認した後、いくつかの説明をするためにも詳細設計および運用・保守担当者の人員を実装するので、最後に完了した開発・運用・保守の実施を避けることをお勧めしますプロジェクトの実現には、ニーズを理解するために来たが、また、彼らはできるだけ早くいくつかの提案を前方に配置することができます。
彼らはまた、コードの品質を向上させることができ、また自分のスキルを向上させ、お互いから学ぶことができますが、グループ3.プロジェクトの各他のメンバーのコードを確認するには、両方のいくつかのエラーが発生を防止します。これは、コストが増加しますが、利点は明白ですが。レビューは、コードが、毎週午後3時を提供するものとして、システムとしてのダウンに設定することができますことをお勧め14：00--15：00と14の5週間：00--15：00コードレビュー。
4.ときにバグ修正と毎回新しい要件を開発することは、自分自身のユニットテストで文書を完成するために作られた厳格なユニットテスト、ユニットテストやドキュメントにする必要があります
レビューは再び自分自身をテストするために開発者が完了した後、担当の二人は再びそれをテストされた後に書き込みした後、ユニットテストケースは、グループ内で検討されなければなりません。それから
そして、テスト用テスターに引き渡さ。
いくつかの問題は、時間の長い期間を必要とするかもしれない場合テストグループが危険な感じた場合には、人々にテストするための十分な時間を与えるために5.テストは、（例えば、遅延放出、一週間のための）遅延放出であり、テストは、解決することができます発見されました次のリリースでは、これらの問題を解決するために左に検討していきます。現在の前提は、これらの問題がリリースされていないことを確実にするためである、システムを使用するための重要な影響はないユーザーがいます。
2週間このリリースの基礎として、このバージョンを分岐する前にリリース最高のバージョン6.、新たに開発されたコード、あるいは移民場合、このブランチに移動するためのコードを公開していないこの時点で完了することができませんまた、このリリースでは、試験対象となる人々のテストグループをブロックしました。テスト後に発見されたバグも、このブランチのバージョンに変更されます。その後トランクコードにマージ。
リリース前の週に7、システムは、出版のリスクの減少として、裁判を実装し、テストするために、同社の社内担当者が、会社内のシミュレーション環境を解放するために公開できるようになります。
リリースの最初の2日間で8、リリースには、人々のテストグループで可能性のあるリスクとテストカバレッジを評価します。そして、判断のテスターと開発者からのフィードバックに基づいて時間に公開するかどうかの判断を行います。
ます。https：//www.cnblogs.com/kevinGao/archive/2012/07/20/2605585.htmlで再現