それはオープンアンドシャットケースのようです。
コードフリーズは遺物です。 堅い滝の方法論が製品開発および解放のための唯一の選択を提供した日からの残り。 バグやその他の機能上の問題をテストするためだけに、生産を停止してリリースを遅らせるという概念全体は、現代のアジャイルな製品管理にはあり
少なくともそれは多くのアジャイルの達人の間でコンセンサスビューのようです。
しかし、それは保持していますか？ アジャイル製品管理にコードフリーズを組み込むことに対する最も一般的な議論の表面を傷つけると、それらはまだ古風に見えますか？
この記事では、コードフリーズをアジャイル製品管理に組み込むことに対する三つの主要な議論を探り、それらの議論がどこにあるのかを分解し、コードフリーズをアジャイル製品管理に組み込むべきかどうかについてより良い決定を下すのに役立つようにします。
引数1: コードフリーズは無関係で不必要な
この議論は非常にシンプルで具体的です—近代的なアジャイル方法論とツールは、専用のQAとテストウィンドウの必要性を排除しました。
ピアコードレビュー、ペアプログラミング、システムの正常性の常時監視などのアジャイル方法論により、開発中のアプリケーションまたは機能のパフォーマ バグや問題は、開発自体の間に捕捉され、専用のテストやQAアクティビティの前に解決される方が簡単で、より可能性が高くなります。
新しいツールでも多くのテストが自動化されています。 彼らは常にコードを評価して、常にクリーンで本番環境の準備ができていることを確認します。 問題はリアルタイムで特定され、アラートはすぐにそれらをできるだけ早く解決するために送信されます。 自動化されたテストの数はすでに広範囲にわたっており、増加し続けており、実行する必要がある手動テストの量を劇的に削減しています。
これらの新しいアジャイル方法論とツールの結果は簡単に見ることができます。 コードフリーズ中に実行されるコアテストとQAアクティビティのほとんどは、開発中に実行されるか、ソフトウェアによって実行されます。 アジャイルでは、ソフトウェアと機能は、以前よりもはるかに高いレベルの信頼で開発を終了し、専用のコードの凍結を正当化するのが難しくなりま
引数2：コードがフリーズするコアアジャイルの原則を破る
この第二引数は少し高いレベルです。 基本的に、コードフリーズはアジャイル方法論のコア原則の一つを破るため、開発とリリースの間の時間を短縮するため、アジャイル方法論には家がないと主張している。
アジャイルへのアプローチが洗練されればするほど、この時間枠を縮めようとするでしょう。 アジャイルに対する現在の最も洗練されたアプローチは、継続的な統合と継続的な開発（CICD）であり、可能な限り迅速にコードへの変更を”リリース”するために、開発を小さな段階的な変更に分割することを目指しています。 CICDの最も純粋なアプリケーションでは、開発とリリースはほとんど別個のフェーズとして存在しません。
対照的に、コードフリーズを展開する場合は、個別の開発フェーズとリリースフェーズを維持する必要があります。 結局のところ、それはコードフリーズが住んでいる場所です—これら二つの異なる段階の間に。 ほとんどのアジャイル方法論のように、開発とリリースの間の時間枠を最小限に抑えたり排除しようとするのではなく、コードがフリーズすると、開発とリリーススケジュールを構築する必要がある時点までこのウィンドウを形式化するように強制されます。
コードがフリーズしてもコアアジャイルの原則と一致しない場合、それらがまだ方法論に属しているケースを作るのは難しいです。
引数3:コードがフリーズすると、低速で低品質のリリースが発生します
この最後の引数は大きなものであり、いくつかの異なる角度が含まれています。
まず、コードがフリーズすると、ロードマップに多くの複雑さと追加の可動部分が追加され、自然に何かが間違ってタイムラインからスローされる可能性が 何もうまくいかなくても、コードフリーズに関わる作業は時間がかかり、予測できません（どのバグが見つかるか、それらを修正するのにどれくらいの時間
次に、コードがフリーズすると開発チームの生産性が低下すると主張しています。 一般的にアジャイル、特にCICDは、開発者が絶え間なく生産性の連鎖の中で常に作業を続けますが、コードがフリーズすると、開発者は事前に定義された間隔で作業を停止するように強制されます。 これを行うことで、最も生産的なフローを見つけて維持するのではなく、リズムを崩してコードフリーズポリシーを回避しようとするように強制します。
最後に、ビジネス要件の受信を停止する専用のウィンドウを作成すると、リリースの機能と機能がフリーズ前に完了できるものに制限され、品質が低下し、包括的でないソフトウェアとアプリケーションにつながると主張しています。
コードフリーズのためのケースを作る：負けた戦い？
この時点で、まだアジャイル方法論にコードフリーズを含めたい人にとってはかなり荒涼としています。 この慣行からの批判者は、いくつかの非常に説得力のある議論と、現代のアジャイル方法論の開発以来、コードのフリーズがなっているという全体的な確:
- 時代遅れで無関係な
- 現代の開発慣行とのずれ
- 迅速で高品質なリリースへの障壁
しかし、これらの議論は説得力があり、多くの正確な情報を含んでいますが、防弾ではありません。 そして、アジャイル製品管理の有用な要素として、コードフリーズに関する本を閉じる前に議論する必要がある基本的な欠陥があります。
引数1の問題：自動テストは包括的ではありません
自動化されたQAとアジャイル開発の実践は、生成されるコードの品質を向上させました。 しかし、コードの一部が単体テストに合格したからといって、実際には本番環境に対応しているわけではありません。 最も洗練されたCICDアプローチでさえ、回帰テストのような重要なステップが常に含まれているわけではありません。 それになると、コードの一部が本番環境にある間にテストして解決できないことがいくつかあります。
コードフリーズを利用することを選択した場合、自動化されたQAとアジャイルのベストプラクティスの利点を放棄するつもりはありません。 あなたとあなたのチームは、生産中にコードのより小さく、より些細な問題をキャッチし、新しいソフトウェアや機能の全体的な安定性や信頼性など、凍結中に大きく、影響の大きい問題をキャッチすることに焦点を当てるためにデッキをクリアします。
引数2の問題：”排除”ではなく”減らす”
アジャイルは、開発とリリースの間の時間を短縮するように設計されていますが、それも事実です。 しかし、このウィンドウを削減しようとすると、それを完全に排除しようとするとの間に大きな違いがあります。 そうすることは、特に大規模なプロジェクトでは、次のように不可能になります。
コードフリーズはCICDでは非常に短いかもしれません—または他のブランチで開発が継続されている間に特定のブランチにのみ適用されるかもしれませんが、それはまだ存在しています。 アジャイルがどれほど洗練されたものになったとしても、ほとんどの場合、すべての開発とリリースのロードマップには、新しいソフトウェアや機能が実
引数3の問題: スピードと品質の再考
コードフリーズを利用する場合は、開発とリリースサイクルに新しいステップを追加します。 それについては間違いありません。 また、プロセスに新しいステップを追加するたびに、そのプロセスが遅くなり、新しい潜在的な障害ポイントが作成されます。 コードのフリーズも例外ではありません。
しかし、一歩後退し、減速と生産性の低下についてより広い視野を取ることが重要です。
あなたの機能にバグがある場合は、コードフリーズ中にそれらのバグを捕まえたかどうか、またはリリース後にそれらが知られていたかどうかに関係なく、そ 純粋な開発の観点から見ると、それらを修正するのに必要な時間は、両方のシナリオでほぼ同じになります。
しかし、あなたがライブ環境でバグを扱っているなら、あなたは対処するために時間を取る必要がある他の多くの問題を持っています。:
- バギー機能をロールバックするか、ライブのままにするかを決定します。
- 開発者が作業を開始した後、新しいプロジェクトからあなたの開発者を連れて行きます。
- バグの影響を受けた現実世界のユーザーにそれを作ります。
- 問題のあるリリースにあまり満足していない内部の利害関係者に回答し、管理します。
リストは続きます。 壊れた機能や製品をリリースするよりも、あなたとあなたのチームにとって、生産性にとって複雑で時間がかかり、破壊的なものはありません。 コードがフリーズすると、この問題が発生する可能性が最小限に抑えられます。
そして、コードがフリーズすると、収集できるビジネス要件の量が減るため、品質の低い機能や製品につながるという議論については？ あなたのビジネス要件は、常にあなたの製品や機能がどのように機能すべきかについての”最高の推測”よりも少しになります。 最も価値のある要件は、常に実世界のユーザーから来ており、実世界のシナリオで製品や機能を展開しています。 また、これらの要件を収集できるのは、ユーザーが可能な限り流動的かつバグのない機能的なリリースをユーザーに提供することによってのみです。
アジャイル製品管理でコードフリーズを利用すべきか？
最終的には、コードのフリーズは依然として多くのアジャイルプロダクトマネージャーにとって重要な役割を果たしています。
今、彼らはあまり重要な役割を果たしている場合があります。 非常に小さなプロジェクトでは、専用のコードフリーズ期間は必要ありません。 彼らは不完全に出荷した場合、比較的マイナーな結果を持っている新機能は、凍結の価値がないかもしれません。 Canaryのリリースのような段階的なリリース計画でも同じことが言えますが、バギーで不完全な経験を期待して準備を整えている暖かい聴衆と新機能をテス
しかし、ほとんどの場合、あなたの新しい機能が最も重要な人々、つまり現実世界のユーザーの手に渡る前に、あなたが思っているほど完璧であることを確
この記事は最初に公開されましたflagship.io
