まえがき
この記事は非常に主観的で、IT業界での経験に基づいています（私はさまざまなプロジェクト、チーム、国（カザフスタン、カナダ）で10年の経験と経験を持つ開発者です）。 多くの人が私の視点を支持せず、この記事を「恐竜の叫び」と呼ぶかもしれませんが、それでも共有したいと思います...
DevOpsとは
Wikipedia DevOpsによると、開発スペシャリストと情報技術スペシャリストとの積極的な相互作用と、作業プロセスの相互統合を目的とした一連のプラクティス。 つまり これは、実装と保守を含むアジャイルのソフトウェア開発プロセス全体をスケーリングする試みです。 DevOpsの主な目的は、リリースの頻度を増やし、製品に対するチームの責任を高めることです。 それは完璧に聞こえます...マーケティングのスローガンのように...
私の観点からすると、DevOpsの主な目標はビジネスのコストを削減することです（これは良いことですが、多くの場合、製品の品質が犠牲になります）。
DevOpsが品質を損なう方法
90年代と00年代に戻って、製品を作成するには、チームでアナリスト、プロジェクトマネージャー、開発者とテスター、および実装者のいくつかの役割が必要でした。 これらの各役割は、高品質の製品を作成するために重要です。アナリストは要件を収集し、開発者を顧客/ユーザーとの過度のやり取りから保護し、マネージャーはチームの作業を調整し、組織的および財務的な問題を解決し、開発者はコードを記述してバグを修正し、テスターはこれらのバグを見つけて検証します実装者はソフトウェアをインストールし、ユーザーサポートの最初の行であり、開発者を不必要な質問から保護します。 このシステムは少し面倒ですが、チーム内の役割が明確に分離されており、新しい機能が複数のユーザーを通過するため、品質が向上し、いくつかの観点から問題を確認できるため、結果として良好で安定した結果が得られます。
2000年代に、このアプローチはアジャイルに置き換えられました。アジャイルは、一方では開発により多くの顧客を関与させ、他方ではアナリストとプロジェクトマネージャーの役割を大幅に削減または排除しました。 この場合、実装はチームの主要部分から分離されたままでした。 徐々に拡張されたプロダクションは、バックログの機能に置き換えられ始めました。 開発者として、私はまだアジャイルを好きではありません。 チームメンバー間のやり取りの質を向上させ、顧客をプロセスに関与させました。 このアプローチの主な欠点は、プロジェクト全体の視野が失われたことです。 つまり 製品全体の概念が一連の機能に置き換えられ、品質の最初の障害に至りました。 新しい機能が既存の機能に釘付けになったとき、開発はパッチワークキルトになり始めました。その結果、システムの整合性が失われました（ただし、この問題は、適切なアーキテクト/アナリストがいるチームには存在しません。
現在、アジャイルはDevOpsに変わりつつあります。 製品に対する責任の増大をスローガンに、テストはほとんど完全にチームから切り離され、実装は大幅に削減され、開発の一部になります。 開発者の役割は増えていますが、実際には、チームに残るのは彼らだけであり、テスト自体は部分的に自動化され、部分的にはベータテスターと顧客の肩にかかっています。 現在、多くの企業（特に労働コストがはるかに高い西欧諸国）では、チームにテスターがいないことを誇りに思っており、開発者は製品を所有し、品質に責任を負っています。 しかし、問題は何ですか？
最初に、製品は品質管理のいくつかの段階を経ました。最初に、アナリストが顧客の要件をフィルターで取り除き、実装を検討し、次に開発者が声明を確認し、アナリストと対話して改善しました。 さらに、実装の過程で、改善のためのアイデアが生まれ、それらが作業に追加されました。 その後、テスターが製品をチェックし、エラーが修正されました。 さらに、アナリストは顧客に作業を実証し、コメントは削除されました。
現在、バックログには機能のみがあり、開発された機能と自動テストがあり、顧客による承認（ある場合）があります。 実際、機能を所有しているのは1人だけであり、チーム内でそのレベルのやり取りはもはやありません。
開発者のDevOpsの問題。 要件を定性的に分析して結果をテストすることはできません。 ユーザーの観点からではなく、コードのプリズムを通して製品を見ます。 そのため、ソフトウェア製品の品質は最近急激に低下しており、ユーザーにとって利便性が低くなっています（たとえば、最新バージョンのSkypeには、さらに多くの例がありますが...）。
解決策はありますか？
私の観点から、解決策があり、それは非常に簡単です。 アナリスト、テスター、チームの実装の役割を維持する必要があります。 分業は品質と生産性の向上につながります（スタハノフと鉱山での分業の考えを思い出してください）。 さらに、これらはすべてDevOpsプロセスに簡単に統合できます。 私の考えは次のとおりです：アナリストは顧客と顧客の要件を収集し、開発者の製品所有者であり、テスターと開発者の役割は理解できます。実装はアナリストと統合するか、アナリストと密接にやり取りします（それによりDevOpsサイクルを終了します）。 DevOpsからは、テストと実装の高度な自動化、製品の安定したバージョンの継続的な可用性、およびリリースの頻度が残っています（むしろ、この場合はすべてのビルドがリリースであると言えます）。 別の重要なルールは、顧客志向で顧客中心であることです。 つまり 顧客のニーズは何よりも重要です。 奇妙なことに、これらの原則はどちらもEPAM（元同僚にこんにちは！）などのアウトソーシング企業で長年使用されており、そこで実証されています。 確かに、自動化は以前はそれほど高度ではありませんでしたが、すでにこのギャップを埋めていることを願っています...