The Doppler Quarterly (日本語) 春 2017 - Page 65

DevOps に対する 熱意が高まりつつある。 私たちのセグメントで 十分に機能を検証したので、 本番環境に統合しよう。 クラウドはまだ最小限か。 現実が見え始める : この DevOps 担当者は 一体誰なのか。 素晴らしい プロトタイプが 完成した。 幹部とお客様が データプロトタイプを 気に入ってくれて 予算が増えた。 アジャイルな関係が 築かれる前 何を構築しているのか。 DevOps 担当者は エクスペリエンスデザイナーと 連携しているのか、または ソフトウェアエンジニアと 連携しているのか。 JIRA の谷底 : この JIRA のチケットは 何を意味するのか。 「...できるようにすべての データを確認したい。」 図 1: アジャイル関係の浮き沈み スタートアップやコンサルティング会社でよく見られる、分散的 で変化できるチームでは、共通目標、個人目標、チームアイデン ティティの継続した再編成や見直しと、相乗的な結果が得られ る新しい戦略の探求を行わざるを得ません。動的、協力的、相 乗的で変化できるチームは、エクスペリエンス設計、アジャイ ル、 DevOps の統合、 DevOps、アジャイル方法論をすでに実 イノベーションに向けたコラボレーション CTP では、クライアントにも設計と開発競争に深く関わっても らいます。また、私たちは、 CTP の内部とクライアントの外部と の間でコラボレーションを促進します。 践しているように見えます。 • 継続的なフィードバック 革新的なソリューションを提供するアジャイルチームの構成に • 継続的な統合 は次が必要です。 • 製品オーナー • エクスペリエンスデザイナー • 設計者 • ソフトウェアエンジニア • QA • IT 運用 • 継続的な製品の繰り返し • 継続的な展開とデリバリ ソリューションが顧客、ひいては企業にもたらす価値について、 近視眼的に考えることを止め、問題を協力して解決すると、す べての関係者が利益を得ます。では、チームが、エクスペリエン ス設計、アジャイル、 DevOps の統合、アジャイル、 DevOps 方 法論の採用を受け入れるために、どのように支援をすればよい でしょうか。具体的な手順を次に示します。 1. 以下のように、製品、設計、エンジニアリング部門に知識を 広く分散するように働きかけます。 • 設計と製品の会議にソフトウェアエンジニア、設計者 を招きます 2017 年春号 | THE DOPPLER | 63