RAD環境でリリース品質を改善する簡単な方法

ここに少しの背景があります-私たちは、大規模な非ソフトウェア会社の内部ソフトウェア開発を担当するRAD開発者の小さなチーム（5人）です。「内部ソフトウェア」は、MSSQLサーバーをバックエンドとして使用するデスクトップ.N​​ETアプリケーションと、バックグラウンドで実行されるPythonスクリプトからMS Word文書やテンプレートに至るまでさまざまです-技術の動物園。

チーム全体は、ユーザーから要件を取得し、コードを作成し、テストし、運用環境に展開できるすべてのアロンダで構成されています。本番環境のソフトウェアは、別のチームによって管理されていますが、通常、何か問題が発生した場合は簡単に介入できます。

これまでのところはすべて良さそうですが、問題があります-RADチームであるため、頻繁にリリースする必要があり、1つまたは2つのアプリケーションの新しいバージョンをリリースせずに1日を過ごすことはできません（または、スクリプト、更新されたWordドキュメント、C ++コンソールアプリなど）を本番環境に追加します。開発テストを行い、エンドユーザーがUAT環境でソフトウェアを実行できるようにすることで、エンドユーザーも関与させます...

...しかし、バグはとにかく生産に忍び込んでいます。ユーザーはこれらのバグと時折の不安定性が本当に欲しいものをすぐに手に入れるために支払う価格であることを理解していますが、同時に考えさせられました-おそらく開発やリリースのプラクティスを改善して安定性を改善できるかもしれません新しい機能を追加するときに導入するバグの数を減らします。

良いこと-そもそもプロセスがあまりないので、改善を開始しやすいはずです。悪いこと-実装する時間とリソースがあまりない小さなRADチームであること大きなことですが、次のイニシアチブについて検討しており、フィードバック、ヒント、ヒント、提案を歓迎します。

1. 現在、一部のアプリケーションは、ユーザー受け入れテストをバイパスして、開発者テストの直後に本番環境にリリースされています。その慣行は中止されるべきであり、小さな変更でさえエンドユーザーがテストする必要があります。各アプリケーションには、エンドユーザーから選択された専用のベータテスターがあります。ベータテスターが新しいリリースを承認した場合のみ、テストから実稼働環境に昇格されます。

2. コードレビューは実施しませんが、変更セットをチェックインする前にコードレビューを開始します。また、「ロールアウトレビュー」についても考えていました。基本的に、開発者の1人がソフトウェアロールアウト（バイナリのコピー、設定の更新、データベースへの新しいテーブルの追加など）を行う他のウォッチと一緒に隣に座っている必要があります-通常は5〜10分かかるため、「ロールアウトレビュー」の時間はあまりかかりません。

3. 新しいリリースが、本番環境から撤退し、適切な以前のバージョンに置き換えられるほどバグが多いことが証明されている場合に、ロールバック時間を短縮する方法。すべてのリリースの履歴を（バイナリとして）保存して、1つのバージョンに簡単に戻せるようにします。また、「新しくリリースされたバイナリを以前のバージョンのバイナリで上書きする」のは簡単ですが、エラーが発生しやすい手動プロセスです。また、「ロールバックが失敗し、システムがバグの代わりに使用不能になる場合はどうするか」を時々要求します。

ここでアイデアを使い果たしました。これらについてのフィードバックを受け取りたいと思います。簡単なリリース/開発プロセスの改善アドバイスを共有できれば、それは素晴らしいことです。

すばらしいテーマに触れると+1。「早期リリースを頻繁にリリースする」開発ラインを行うと、物事は実際のペースを取り戻し、勢いが増すにつれて、多くのそのような問題が発生します（説明したように）。最悪の恐怖は、人々がスピードを良い仕事の敵と見るときです。

私はこれについて非常に限られた文献を見ましたが、これは私たちが実践するものであり、間違いなく役立ちます：

1.効果的なバグ追跡
バグ追跡をより効果的にする-バグと目盛りのリストを保持するだけでなく、閉じたときに、「問題は再現可能か？」、「これは永続的な解決策ですか？」または作業修正？」、「トラブルの根本原因は何ですか？」これにより、前回このバグが表示されたときに何が起こったかを知ることができます。これは、バグが頻繁に繰り返されないようにするための鍵です。

2.主要なフォールバックポイント
を定義するバグが到着することは誰もが知っているため、最も頻繁に機能する効果的なフォールバックを提供する必要があります。何度も何度も（この例では10分の1の割合で）ファイナライズし、最も信頼性の高い方法でどこでも動作する最も一般的なリリースを作成します。リリースの総数は多くなる可能性がありますが、何か問題が発生した場合、フォールバックはごくわずかであり、それ以上フォールバックする必要はありません。最適なフォールバックを知る最も簡単な方法の1つは、多くの問題なく実稼働で最も長く実行されている最も古いリリースを確認することです。

3.リスクのある安定したバグ修正リリースまたは小さなバグ修正リリースを区別
する主要なアルゴリズムの変更があることがわかっている場合、すべてが予見されないシナリオでバグが忍び込む可能性が高くなります。問題が非常に小さい（または十分に理解されている）だけでなく、リスクが少ない場合があります。同じリリースでこのような機能と単純なバグをクラブ化しないでください。常に最初に小さなバグを修正します。これは必要な場所に移動する必要があります。特別な機能セットの専用リリースは、せいぜいその機能を廃止できますが、他のすべての重要なバグは以前のリリースで修正されて利用可能です。

4.重要な機能開発のためのブランチ
デザインに影響を与える変更を関連付けるものは、ブランチ上で個別に実行する必要があります。大規模な開発は、小規模なバグに比べてすぐには完了しません。まだ使用されていない機能に関連する「部分的な」作業が潜在的なバグ導入地域である中間コミットを導入する場合、機能の完全な作業がアトミックに完了した場合に発生しなかったバグ-したがって、これらは、ブランチがあった場合に解決する必要のないバグです。

5.テーマベースのリリースを常に計画
する異なるリリースの多くの場合、多くの異なるバグが到着します-しかし、同様のモジュールに影響するバグ（および機能）を整理することは、繰り返し作業を容易にし、その作業に起因するバグの数を最小限に抑えることをお勧めします 常にリリースロードマップを事前に準備してください。バグは絶え間なく注ぎ込まれます-そして、それは最適なリリースで一緒に撃たれるバグの最適なグループを持つために、異なるターゲットリリースに分類されます。同様のバグが組み合わされると、矛盾するシナリオに関するより良い洞察が常に得られます。

6.新規リリースを最初に数人の顧客に拡張する
今回のケースでは、最初にいくつかのサイトでテストし、他のすべてのサイトはリリースが必要な場合にのみリリースを適用します。多くの場合、一部の（またはほとんどの）ユーザーは、安定版リリースから別の安定版リリースのみにジャンプします。

7.回帰テスト
収集されたバグに沿って、回帰スーツを作成します。また、可能であれば、重大なバグをマークし、リリース候補が実際にリリースになる前にテストされる最小の資格基準となる最も重要なテストを行います。

8.一時停止と反映
多くのことをフルスピードで実行する場合、いくつかの休憩を入れる時間があるはずです。一時停止して機能的に良くないリリースをしてください。実際、しばらくの間リリースの休日があります。（期間は周波数に反比例します）。たとえば、多くの場合、これらのいわゆる「クリーンアップ」リリースがあり、機能の観点からは何も新しいことはありませんが、コードの保守性を維持するのに役立ちます。このようなリリースのほとんどは、それ以前の履歴をほとんど思い出せない素晴らしいフォールバックポイントです。

9.おそらく最も奇妙なの
は、これを頻繁に実装することは難しいと思うが、確かに良いトリックです。特定のモジュールの所有者を交換します。人々がコードレビューを行うように頼まれたとき、このプラクティスからあまり出てきません。しかし、その新しいコードに真剣に対処しなければならないとき、著者を入れ替えると、潜在的な「悪い」病気がコードを汚染し始める前にすぐに気づかれます。もちろん、これは速度を低下させます-しかし、これを頻繁に行うと、人々はコードのさまざまな部分を習得し、教えるのが非常に難しい製品全体について学ぶ可能性があります。

10.最後になりましたが、
ホワイトボードに頻繁に戻ることを学んでください。この機能が私たちの最も初期の設計の一部であるかのように再考するほど、そのときの設計をどのように考えたでしょうか？時々、インクリメンタル作業の最大の課題は、最初に構築した機能の順序に制約されすぎて、基本に戻れないことが非常に多いことです。秘Theは、この新しい機能やシナリオに対応するのではなく、どのように一般化するかを見続けることです。そのためには、設計を最新に保つ必要があります。これは、頻繁に図面に戻る場合にのみ発生します。また、新世代のプログラマーが参加すると、彼らは単にパッチを貼るのではなく、思考タンクの一部になります。

編集
11.回避策と設計のギャップを追跡します。
多くの場合、バグを修正して本番環境でリリースするというタイムラインのプレッシャーにさらされています。ただし、バグが設計レベルにある場合、変更する必要があるものはかなりありますが、多くの場合、締め切りに間に合うようにいくつかのショートカットで修正することがあります。これは大丈夫です。ただし、ソリューションに対するこのような複数の作業が増えると、コードが脆弱になります。設計のギャップがすでに発生している数について特別な追跡を行います。通常、プロジェクトマネージャーとタイムラインを交渉するときは、生産を節約するためにこれをショートカットで提供することをコミットするのが最善です。永久的な解決策を得るためのタイムラインとリソース。

私は小さな開発チーム（2人だけ）で働いていますが、あなたが言及した同様の問題を経験しました。私たちにとっての主な問題は、2人とも別々のタスクで作業する傾向があり、タスク/機能を完了し、テスト（開発者のみがテスト）して迅速にリリースすることが一般的になりすぎていることです。これにより、テストで簡単に見つけられるはずの小さなバグをユーザーが報告する多数の小さなリリースが作成されました。

プロセスを改善するために、私はかんばんボードを導入することから始めました。このボードは最初から非常にシンプルで、数列しかありませんでした（ホワイトボード、インデックスカード、色付きマグネットを使用したセットアップ）。

バックログ| すること| 完了

ただし、これは実際のプロセスを反映するために急速に進化しました。

バックログ| 開発| 開発者 テスト| UAT | 完了| リリース済み

ボードとともに、各タスク/機能は別の開発者（および機能を実装した開発者）によってテストされる必要があるというルールがあります。したがって、カードが「完了」列に到達するまでに、少なくとも2人の開発者によってテストされ、ユーザー受け入れテストも行われているはずです。

かんばんを使用することには、他にも多くの利点があります。私たちにとっては、コミュニケーションが改善され、両方のタスクにある程度関与しているため、知識を共有するのに役立ちました。また、リリースプロセスが改善され、リリース/完了の準備ができているタスク/機能を正確に確認できるようになりました。他のタスクがすぐに実行されることがわかっている場合は、リリースを延期できます。チーム外の人々のために、ボードは、私たちがスケジュールしたタスク、進行中の作業、最近リリースされたものを確認するためのクイックリファレンスとしても機能します。

余談ですが、現在開発中のカードにフラグを付けるために色付きの磁石（開発者ごとに1つ）を使用しますが、別のオプションとして、開発者ごとに1つのスイムレーン（行）を追加し、関連するスイムレーンにかんばんカードを配置します。繰り返しますが、これは各開発者が現在取り組んでいるものを確認するためのクイックリファレンスとして役立ちます。

他の便利なリンク：

ソフトウェア開発に適用されるかんばん：アジャイルからリーンまで

ソフトウェア工学のためのかんばんシステム-ビデオ

かんばんが質問のポイント1に対処することを願っています。コードレビューに関しては、レビュー後に必要な変更がUATに移行する前に再度テストされるように、開発テスト段階でこれを行います。ロールバックは環境によって異なりますが、現在のファイルの名前を変更し、中央サーバーから新しいファイルをコピーするバッチファイルを使用してターミナルサーバーにアプリケーションファイルを展開し、中央の場所にバックアップ（前のファイル）を配置することでかなり簡単にロールバックできますスクリプトを再実行します。

ソフトウェアの品質に影響を与えるプロセスの問題があることがわかっていることは既に確認済みです。この質問はさまざまな答えを引き起こしますが、ソフトウェアエンジニアリングのトピックを見て、何を試すかを学ぶことをお勧めします。メインの開発者は、その分野でますます多くのことを行っています。いくつかの優れたリソースを読み始めて、自分をキックオフすることをお勧めします。思い浮かぶいくつか：

• MaryとTom Poppendeickによるリーンソフトウェア開発は、「無駄」を特定する方法と、リーンで効率的なプロセスを変更するために何をすべきかを学ぶことに興味のある人々に素晴らしい読書を提供します。
• Dan PiloneとRuss MilesによるHead First Software Developmentは、一見「ダミー」の本の1つに少し似ていますが、混butとしたプレゼンテーションスタイルを少し過ぎてみると、ソフトウェアエンジニアリングの基礎に関する情報のほとんどが含まれています。また、テスト駆動開発について簡単に説明しています。
• BDDの紹介は、行動駆動開発への移行に関するDan Northのページです。または、BDD Wikiを好むかもしれません。これらはBDDのスターターリファレンスであり、おそらくあなたを支援するツールとフレームワークを検討する必要があります。理解すべき重要なことは、BDDは事実上TDDをより高い概念レベルに引き上げることです。仕様について考えているときにテストについて考え、仕様を書くときに使用するのと同じ言語でテストすることができます。通常、フレームワークは他の単体テストフレームワークと統合されるため、テストが必ずしもBDD構文の恩恵を受けない可能性があると判断した場合は、両方の長所を活用できます。
• ウィキペディアのアジャイルソフトウェア開発記事は、アジャイルソフトウェア開発に関する優れた入門書であり、開発コミュニティのより尊敬される人々による記事への多くの有用な参照とリンクを提供します。

あなたがどのように仕事をするかを改善するためには、あなたが完全にオープンマインドであり、あなたが見つけるかもしれない特定の概念に固執せずにあなたがしていることを改善することを学ぶためにあなたの快適ゾーンの外に十分に踏み出せるようにする必要がありますしがみつきやすい。個人的な経験から言えば、これはおそらく最も困難なことであり、他の人を励ますことでもあります。

変化を積極的に求めていると感じたとしても、変化は最高の状態では難しいので、私が本当にあなたに与えることができる最善のアドバイスは、長年にわたって開発されてきたさまざまなアジャイル手法を見て実践に慣れることです最も重要と考えられるもの（例：単体テスト、継続的インテグレーション、リファクタリングなど）を行い、あなたとあなたのチームが最も快適に感じる方法に最も近い方法を選択します。決定したら、チームが仕事をする方法に合うようにプラクティスと開発プロセスを調整し、それらの無駄のないプリンシパルとあなたがチームで最大の価値を生み出すことができるように働きたいことを念頭に置いてください無駄が少ない。最後に、

プロセスを微調整するだけでよいと感じているのに、ツールチェーンがニーズに十分に対応していないことに懸念がある場合は、おそらく改善を検討してください。少なくとも、継続的インテグレーション統合製品（Continuum、Cruise Control、Hudsonなど）、および問題追跡システム（Jira、Redmineなど）は、ビルドおよびリリースプロセスの一部を自動化するために優先されるべきです。バグや機能のリクエストをチェックし続けるため。

現実には、プロセスがどのようにRADであっても、チームにとって物事を「正しく」行うために時間を費やさなければ、問題は時間とともに増大し続け、利用可能な時間の認識はそれに応じて縮小します。通常、大きな変化は大きな時間のプレッシャーの下では問題外ですが、理想的な方法論のチームのビジョンに向けて赤ちゃんの一歩を踏み出すのに役立つシステムを配置するために、少し「小刻みに動く」ようにしてください。

欠陥について聞いたときはいつでも、最初の質問は、欠陥がどこで発生し、どこで検出および削除されるかについてです。欠陥除去効率は、これを測定および追跡するための良い方法です。欠陥の発生場所を把握し、それらの段階でプロセスを改善することにより、プロジェクトの時間とコストを削減できます。欠陥を注入点の近くで修正する方が安価であることはよく知られているので、欠陥の原因がわかったら、アクティビティの変更を見てそれらのフェーズを改善できます。

欠陥の原因に関する情報が得られたら、どのテクニックやテクノロジーを適用したいかを正確に確認できます。要件、設計、およびコードのレビュー、自動テスト、静的分析、継続的統合、およびより広範なユーザー主導のテストは、どのフェーズが欠陥を生成するかに応じて、検討すべきオプションです。

コードレビューの要望を拡大するには、モジュールの優先度とリスクに基づいて、さまざまなレベルのコードレビューを検討する必要もあります。低リスク、低優先度のモジュールは、コードレビューをまったく必要としない場合があります。あるいは、別の開発者が自分でコードを読んでコメントを提供するだけの単純なデスクチェックが必要な場合もあります。他のコードレビュー手法には、ペアプログラミング、ウォークスルー、批評、およびさまざまな数の開発者との検査が含まれます。

ロールバックの目的で、ある種のスクリプトを使用してそのプロセスを自動化し、エラーを起こしにくくすることを目指しています。完全な世界では、出荷する製品の品質を高めて、ロールバックする必要がなく、これを達成できるようにします。ただし、機能を使用することは良い考えかもしれませんが、可能な限り簡単にできます。

他の人が指摘しているように、回帰テストを追加すると、将来同じ欠陥が現れるのを防ぐのに役立ちます。ただし、新しい欠陥が発生した場合は、は、クラスとメソッドの前提条件、事後条件、および不変条件を指定するアサーション（別名コントラクト）をコード追加するあります。

たとえば、メソッドが10〜25の間の数値のみを受け入れるクラス（これは前提条件と呼ばれます）がある場合、メソッドの先頭にassertステートメントを追加します。このアサーションが失敗すると、プログラムはすぐにクラッシュし、その失敗につながった一連のメソッドをたどることができます。

Python、PHP、およびその他のプログラミング言語は動的に型指定され、メソッドに多くの条件を追加しません。何かを機能させるために必要なのは、特定のメソッドを実装することだけです。メソッドにはもっと条件が必要だと思います。メソッドがその環境で実際に機能することを確認するには、定義とテストを行う必要があります。

C / C ++プログラムの場合、メモリ割り当てのテストにアサーションを追加すると、プログラムのメモリリークの数を減らすのに非常に役立つことがわかりました。