スクラムとDevOpsの共有-スクラムとDevOpsのコンバージェンスの翻訳

Scrum.orgとDevOps Instituteによって書かれた記事の翻訳。 元のファイルへのリンク

翻訳者から

アジャイルに当てはまる用語のいくつかが私に知られているという事実にもかかわらず、この記事は私にとって非常に有用であるように見えましたが、翻訳するのは困難でした。 オリジナルの意味を歪めないように一生懸命努力しましたが、成功することを願っています。 いずれにせよ、英語を話す人なら誰でも、原本を読むことを強くお勧めします。 これは公開翻訳の分野での私の最初の仕事なので、厳密に判断しないでください。

実際、この記事はほとんどユーザーマニュアルです（ただし、非常にトップレベルのマニュアルです）。 唯一のことは、それからのアドバイスを単に受けて実装することはできないということです（おそらくどの方法にも適用されます）、そして私の観点から、それは主な原則に固執する価値があります-変​​更はスムーズでなければならず、動作するものを壊さないでください。 すべての変更は痛み（大きなまたは小さな）から流出し、チームはそれらの準備ができています。この痛みを人為的に作成する必要はありません。

メイン文書にあったリ​​ンクは、すぐにテキストに入れました。それらは括弧と斜体で区切られています。 用語の正しい翻訳について疑問がある場合は、英語で括弧内に複製しました。

スクラムとDevOpsの共有

「ソフトウェアは世界を飲み込みます」

（Andreessen、Marc。「ソフトウェアが世界を食っている理由」The Wall StreetJournal。2011年8月20日。

https://www.wsj.com/articles/SB10001424053111903480904576512250915629460 ）。

ソフトウェアはどこにでもあり、現代生活のあらゆる側面に影響を与えます。 これにより、組織はより高度な製品を作成できるだけでなく、顧客のニーズをよりよく理解できます。

ソフトウェアも変化の源です。 自動化を最大限に活用している組織は、「非デジタル」競合他社をバイパスします（「2017 State of DevOps Report。」Puppet。Https://puppet.com/resources/whitepaper/state-of-devops-report）仮説をより迅速にテストし、実験結果を取得して分析し、この情報を使用して改善すること。

新しい技術、市場、気候変動によって加速され、世界は急速に変化しています（フリードマン、トーマスL.遅れてくれてありがとう：加速の時代の繁栄への楽観主義者ガイド。Sl：PICADOR、2017） 。 生き残るための唯一の方法は、変化の道に着手することです。

2つの方法論-1つの目標

アジャイルとDevOpsは、組織が同じ目標を達成する主な方法です。開発サイクルの高速化、リリース用の機能の小さなブロック、フィードバックの使用によるプロセスの改善、障害や不適切な人件費の排除。 これらの2つの方法論で強調される側面は異なります。なぜなら、人々はこれらが異なるアプローチであると考えることがあるためです。 アジャイルはチームワーク、文化、価値に重点を置き、DevOpsは配信パイプラインとそのフローを最前線に置きます。 しかし、アジャイルは自動化にも関係しており、DevOpsはコミュニケーションと文化に関係しています。

DevOpsとアジャイルを同時に使用する必要があります。 最も人気のあるアジャイル開発方法の1つはスクラムで、最大1800万人のIT専門家（ https://www.infoq.com/news/2014/01/IDC-software-developers ）が毎日使用しています。一般的に）主要な開発コンポーネント。つまり、少なくとも「DevOps」という用語の「Dev」部分を提供します（翻訳者のメモ：Dev-英語の開発-開発、Ops-操作-操作）。

どちらの方法も、ユーザーにとって最も効率的な方法で価値を生み出そうとしますが、最初の焦点は異なります。 アジャイルは開発者であり、DevOpsはプロセスです。 これらの違いは、次の事実によって補強されます。

• 一部のアジャイルサポーターは、どのプロセスも悪いと考えており、Opsはプロセス構築を通じて安定性の豊富な歴史を持っています。
• DevOpsでは、ツールと自動化を使用して速度が向上しますが、アジャイルを使用する人は、せいぜい命令に避けられない悪を見て、最悪の場合は障害になります。
• DevOpsコンセプトは、問題を解決するために考えているシステムに対応しますが、アジャイルは、人々が変化の推進者になることを奨励します。
• 政治的なゲームと会社の部門間のコミュニケーションの欠如は、ギャップを広げます。

継続的な変化には強力なリーダーが必要です。 これらは、目的の明確さと開発の方向性を提供するだけでなく、変化を承認し刺激します。 また、組織の変化は、原動力としての信頼を獲得し、変化が結果を生むときに報いを受ける強い個性を引き付けます。

これらの人々の成功が変化のプログラムに関連しているとき、異なる行動プログラムが彼らの間で競争し始めるという問題が生じるかもしれません。 アジャイルとDevOpsの実装と使用が組織のさまざまな部分によって促進されると、競合する政治的目標が混乱につながります。

• 互いに敵対する利害関係者 。 ビジネスパートナーとマネージャーは対立を認識し、少なくとも誰かが自分のしていることを理解しているという自信を失います。
• 開発と開発の間の作物の衝突 。 オープンで人中心のアジャイルコミュニティは、プロセス指向の開発チームとは大きく異なります。
• 増加する恐怖と保護行動 。 リスクのレベルを上げたいと思う人はいませんが、同時にさまざまな方法で彼と協力します。 アジャイルでは、リスクの変更は数多くありますが、リスクの変更はほとんどありません。 Opsの観点から見ると、多くの変更は本質的にリスクを伴います。これは、対応が秩序、制御、および管理を強化することだからです。
• 開発者は、DevOpsを一時的な手段と見なしています。 ターゲットは「NoOps」と見なされます。 NoOpsは、運用の完全自動化を意味し、開発者が本番環境を管理できるようにします。 一般に、これが本当に可能か、単に望ましいかは重要ではありません。 ほとんどの組織は、DevOpsの概念を効果的に実装するには至っていないため、NoOpsは漠然とした価値のない目標です。

現実には、ソフトウェアの提供を通じて顧客に伝達される価値を創造するプロセスには、詳細で包括的なプロセスを必要とする要素と、柔軟性があり、チームが精力的に働くことを必要とする要素の両方が含まれます。 自動化は最終的にすべてを安定化させるプロセスですが、多くの場合、自動化は不可能であるか、そのコストが考えられるメリットを上回ります。 自動化、プロセス、および多くの権限を持つチーム間のバランスが重要です。 1つに焦点を合わせ、他を無視すると、次のようになります。

• 品質が悪い。 品質に対する体系的なアプローチは、製品の品質にとって非常に重要ですが、多くのチームにとって、品質は、せいぜい、継続的な統合プロセスを取り巻く手動テストによって小さな町によって保証されています。
• 何も終わらない 。 外部の調整または検証を必要とする複雑なプロセスが多すぎる場合、チームがタスクをバックログから「完了」状態にすることはほとんど不可能になります。
• 透明性と可視性の欠如 。 多くのプロセスは非常に複雑であるため、誰もが全体をカバーできず、情報に基づいた意思決定を行うことができなくなります。
• チームの構成が変わると、すべてが変わります 。 明確で理解可能なプロセスがなければ、人に関する変更を管理したり、何かをスケーリングしたりすることは困難です。
• プロセスに明示的に含まれていない隠し作業の外観 。 プロセスがより詳細かつ包括的になるにつれて、それらに含まれない作業がますます発生します（翻訳者のメモ：私はこのように理解しました：より詳細なプロセスはより多くの時間を必要としますが、単一のプロセスがすべてをカバーできるわけではないため、それらに含まれていない作品も行う必要があります）。 これは、多くの「隠された」作業と「バイパス」作業のどちらか、または無駄に作業することにつながります。

スクラムとDevOpsの組み合わせ。

機能横断的でビジネス志向のチームが常に機能するソフトウェアをリリースし、関連するすべての利害関係者間でリアルタイムにシームレスにワークフローが進む世界を想像してください。 これに加えて、その値は明確に認識され、測定され、説明責任を果たします。 このビジョンは、ビジネスとテクノロジーが混在し、顧客や市場と協力して顧客に利益をもたらす多くの小規模なスタートアップにとって現実です。 スクラムチームはソフトウェアの開発を担当し、オペレーティンググループは作業環境の維持を担当します。これにより、これを安全かつ効率的に行うことができます。

必要なスキルのセットを持つ機能横断型チームは、完全に開発されたソフトウェアをより迅速に提供します。

機能横断型チームの作成は新しいものではありません。 竹内博隆と野中I次郎は、1986年の新製品配信ゲーム（野中、竹内Hiro隆生次郎、「新製品開発ゲーム」、ハーバードビジネスレビュー、2014年8月1日）で、柔軟でクロスファンクショナルなチームの重要性を説明しました。 https://hbr.org/1986/01/the-new-new-product-development-game ）。 しかし、誰をチームに含めるか、チームに含めないかについて正しい決定を下すことは困難です。 現代の製品は、歴史的に特別なスキルとインフラストラクチャを必要としてきたさまざまなテクノロジーの驚くべき配列です。 また、開発チームには、実用的な製品を作成するために必要なすべてのスキルが必要です。 これは、スクラムガイド（The Scrumuide。Http : //www.scrumguides.org）で次のように説明されています。

「機能横断型チームには、作業を完了するために必要なすべての能力があり、チームに所属していないチームに依存していません。」

機能横断型チームには、仕事を行うために必要な一連のスキルが必要です。 チームが従来の役割ベースのアプローチから移行する場合、そのメンバーは利用可能なスキルの数を増やす必要があります。 彼らはまた、より良い製品を作るために顧客への共感を構築する方法を学ぶ必要があります。 これは、各個人が1つのチームにしか所属できないという意味ではありません。 運用経験のある人が一度に複数のチームのメンバー（チームの「サービスユニット」のように振る舞う）であり、その経験と知識をチーム（1つまたは複数）にもたらし、製品開発プロセスを改善できる場合の例は多数あります。他のチームメンバーをトレーニングしてスキルを伸ばすことができます。 ただし、これは、その可用性が、チームがバックログからタスクを開発する能力にどのように影響するかとバランスを取る必要があります。 また、通常は次のことも必要です。

• スローされるタスク（ハンドオフ）の数を減らします。 タスクをスローすると、レイテンシが増加し、コードの所有権と責任が減少します。 チームが完全なソリューションを開発するために必要なスキルまたは権限の完全なセットを欠いている場合、タスクの破棄は避けられない可能性があります。 しかし、これがチームによって行われる作業のほとんどに当てはまる場合、必要なスキルを持つ人々をチームに含める必要があります。
• 価値の創造に必要なすべてのスキルを開発します。 チームに必要なスキルがすべて揃っていない場合は、専門家の助けが必要です。 時間が経つにつれて、彼らは彼ら自身の独立性を高めるためにこれらの専門家から学ぶよう努力するべきです。 たとえば、アプリケーションの開発の開始時に、セキュリティの問題を考慮する必要があります。 安全に責任を持つ人々はチームを助け、彼らのチームは彼らの依存を減らし、仕事の質を改善することによって学ぶことができます。
• プロセスの自動化を促進します。 ソフトウェア開発プロセス中にチームによって機械的に実行される多数のタスクの自動化により、顧客満足に向けた貴重な仕事のための時間が解放されます。 このような機械的なタスクには、少なくとも次のものが含まれます。環境の継続的な統合、テスト、展開、準備。

障害物が取り除かれたときにDevOpsとスクラムが正常に使用されます

キューを使用すると、チームが状況を制御できなくなるため、チームの柔軟性が低下します。 サポートがキューを通じてアジャイルで作業しているチームと通信する場合、リクエストがキューの先頭に到達するまで待機するため、チーム全体の効率が低下する可能性が非常に高くなります。

将来の開発システムを構築する場合、キューを段階的に削除し、セルフサービス機能に置き換える必要があります。 環境、データベース、セキュリティ、ネットワークインフラストラクチャ、ソフトウェアの展開の維持など、従来のIT関連の機能は、セルフサービスシステムのセットとしてサポートされる必要があります。 これらのシステムは、アマゾンウェブサービス（AWS）、Microsoft Azure、Googleなどの企業が現在提供しているサービスに非常に類似しており、これらの外部クラウドサービスを頻繁に使用し、組織固有の知的権利を追加して、コンプライアンスを強化します。会社の準拠方針

企業に長く存在していたレガシーアプリケーションも柔軟性を低下させる可能性があります。時間がたつと非常に複雑になり、誰がどのように機能するかを理解できなくなるためです。 これらのアプリケーションは複雑であるため、単一のチーム内で必要なスキルセット全体を取得して、タスクを独立して実行することは困難です。 たとえば、統合プロセスを完全にカバーするテストを作成するために必要な作業とスキルの量により、このタスクを単一のスプリントで完了することはほとんど不可能です！ 残念ながら、この問題を迅速に解決する特効薬はありません。このため、会社はこのアプリケーションのアーキテクチャを書き換えて、モジュール式の開発、展開、およびテストを可能にする必要があります。

チームの能力向上を支援することには、次のものが含まれます。

• チームには、製品のリリースに必要なあらゆることを行う権限が必要です。 多数の制限を導入する代わりに、チームを自分自身から保護するために、意思決定を行い、製品全体を開発する権限をチームに与える必要があります。 ただし、まず、エンパワーメントの規模が変更のロールバックを容易にする規模に過ぎないことを確認する必要があります。次に、開発環境と適用されたアーキテクチャの原則が、変更に耐えるほど安定している必要があります。
• セルフサービス自動化に基づいた自動化により、外部依存関係を減らします。 複雑なプロセスにアジャイルコマンドを含める代わりに、Scrumチームが自律的に結果を提供できるセルフサービスサービスを提供します。 たとえば、仮想マシンのプロビジョニングやテストデータへのアクセスの提供など。
• チームが順番に待たずに利用可能な技術リソースにアクセスできるようにします。 ソフトウェアが単純であればあるほど、チームの開発とサポートはより柔軟になります。 個々のチームの複雑さと重要性が増すにつれて、それをサポートするために必要なすべてのスキルを持つことがますます難しくなります。 ただし、外部リソースへの依存がボトルネックになる可能性があります。 特定の技術を使用してチームをトレーニングおよびサポートできる専門家の助けを借りてスクラムチームのサポートに専念することで、ボトルネックを解消し、チームのスキルを向上させ、柔軟性と俊敏性を高めます。
• レガシーアプリケーションの簡素化とモジュール化。 敏systems性をより良くサポートするために、古いシステムを再設計し、開発環境やテストなどのインフラストラクチャをサポートするよう努めます。 つまり、1つの場所に集中するのではなく、テストの制限を緩和し、モジュールへのより良い分離を確保し、すべてのコマンドについて古いシステムに関する知識を広めることに集中する必要があります。

自動化、自動化、自動化

継続的なソフトウェア配信は、最も重要なDevOpsプラクティスセットの1つです。 その最良の実装では、次のようになります。開発者がコードをコミットするたびに、ビルドに組み込まれ（ビルドを取得）、テストされ、デプロイされます（すべてのリリース基準を満たしている場合）。 手作業の欠如は、リリースを高速化するだけでなく、人的要因によるエラーの可能性を排除することにより、品質を向上させます。

プロセスの自動化に向けたチームの最初のステップは、付加価値をもたらさない作業の存在に関する分析です。 同時に、アプリケーションアーキテクチャが改訂されています。 その結果、タスクの新しいバックログが表示される場合がありますが、その目的はアプリケーションを処理し、技術的な負債を排除することです。 自動化のためのいくつかの良いアイデアは次のとおりです。

• — . (complexity and over-engineered processes).
• . - , , , .
• Scrum-. , , . , , , , . Scrum- , . , , , , , , .

, , (apply an empirical process) / , , .

Scrum , , Scrum-Guide

: , , , .

, . , , :

• , , . , (lean thinking), , , Gembla , .
• , . , - . , . , — , , .
• , , - . , , , , . , , . , , , .
• , . -, : ", , "? , , . , , Scrum ( Scrum- : "There's value in the Scrum Values." Ullizee. May 03, 2013. https://guntherverheyen.com/2013/05/03/theres-value-in-the-scrum-values/ ) , , , , , . , , . , , , , .

,

, , , - , , : , (legacy) — . , , .

Agile DevOps , . , Scrum DevOps. , , , .

, , .

, , — , .

1:

, , , , , , . , , , . , , -.

, , -. , , , . , Nexus ("Scaling Scrum with Nexus." Scrum.org. https://www.scrum.org/resources/scaling-scrum ) Scrum'a Scrum-, Scrum.

Scrum-:

• , . , , . , Nexus, .
• , . — , . , " " ("Difinition of done") ("Definition of "Done"." The Scrum Guide. http://scrumguides.org/scrum-guide.html#artifact-transparencydone ) , . , , , Scrum- , . , , , .
• , , . Scrum-, "" ("Water-Scrum-Fall"), , , , , .

— :

• /. — , - , .
• . Scrum- , - ; , , Srcum-. , , "" , , , . .
• Scrum-. , , Scrum-. Scrum', - Scrum-, , . , , , , .
• , . Scrum- — , , . — , (holistic) .

2. .

, , , , , , , , -, . lean/- . , , .

Scrum- :

• . (Sprint Review) — , ; , , . , . Nexus , , , , " ", , .
• . , , , . (Emperical) . , , .
• . , , . Scrum- (stakeholders), . — , , Scrum- ( (Stakeholders)), , ( (release), - , ). , , .
• () , . , .

:

• . , , , . , , Scrum- .
• (dashboards), . , , . , , , , .
• -, Scrum', . , Scrum- (review). Scrum — ; , , , . Scrum-, , .
• , , , , DevOps. Scrum' , . — , , . . (release management), . () .

3. .

Scrum- , Scrum- , .

(This might sound like semantics), , Scrum-, , — , , Scrum- . Scrum- , , . "" . Scrum- , , , . :

• , (evidence-based measures), . ( : (evidence-baced) ) — , : , ("Evidence Based Management (EBMgt)." Scrum.org. https://www.scrum.org/resources/evidence-basedmanagement ). , .
• . . , . , — , . / — , - , , , .
• "" . ; , , , , , . Scrum- /, . , , , .
• , (stakeholders). , , , .

おわりに

DevOps , Agile- "Agile-". Agile- . , , , IT. , DevOps . Scrum/Agile- . , , . DevOps Scrum-, , , , (by inspection and adaptation through transparency).

, Scrum-. . — , . , Nexus, , , Nexus (Nexus Integration Team (NIT)), Scrum-. , , /, . , , — , , Agile. , , :

• - ? , , Scrum- , (agility) .
• , . , , Scrum-, — Scrum-. , .

. DevOps / . , . , . , , , . , :

• . , . , , , , , . , , . , , , , .
• , , . , , , , . , - , .
• , , . , . DevOps (make them part of the solution).

, , , , . , , , , . , . , , , , . , , Agile- — , "Agile" , (the opposite of agility). , (empirical), . .