今日、ITは統一されたものではなく、常に同じルールに従って機能しますが、少なくとも2つの速度の教育です。
-セキュリティを優先し、リスクを最小限に抑える従来のIT。
-柔軟なIT。新しい市場の要件に対応する必要があります。
スピードの重要性を認識しているAmazon、Facebook、Googleなどの企業は、基本機能の信頼性を損なうことなく、1日あたりのシステムの多数のバージョンのリリースをサポートしています。 しかし、開発者の活動をどのように整理して、一定の品質で新しいバージョンを迅速にリリースするのでしょうか？ その答えは、IT企業だけでなく、ソフトウェアに依存した活動を行う産業にとっても興味深いものです。
開発プロセスを整理するために、従来のアプローチが考案され、長い間使用されてきました。たとえば、カスケード型の開発モデルや、柔軟なモデル、たとえばスクラムは、世界で最も人気のあるアジャイル開発テクニックです。 それぞれに長所と短所があります。 アジャイル開発方法論、特にスクラムにより、フィードバックを取得してエラーを早期に検出し、修正し、顧客に不可欠な機能を実装したバージョンを迅速にリリースし、当面はセカンダリ機能を破棄できます。 ただし、9人以上がチームに参加しているプロジェクトでは、アジャイルスタイルのアプローチはうまく機能しません。純粋に心理的な理由でチームが関心のあるサブグループに「バラバラ」になり、一般的なコミュニケーションが困難になります。 その結果、銀行業界や通信業界で事業を行うロシア企業を含む多くの企業は、変化する要件に対して最高の品質、利便性、適応性をユーザーに提供できる異種のチームを結集することができません。
おそらく、Waterfall、Scrum、そして実際にアジャイルのメソッドは単に時代遅れで、大規模なプロジェクトには不向きであり、他のものに置き換える必要があるのでしょうか？ ウォーターフォールモデルは古くなっていますか？ いいえ、請求などの基本的なビジネスシステム、銀行処理システムはゆっくりと変化していますが、業務の中断はビジネスを破壊する恐れがあります。 そのようなシステムの最大の安定性を達成するために、ウォーターフォールモデルも使用されます。 会社のITランドスケープの平均レベルを形成する競争優位システムは、古典的アプローチと柔軟なアプローチの両方で構築できます（スクラム）。 最後に、モバイルバンクや加入者の個人アカウントなどのイノベーションシステムは絶えず変化しており、エンドユーザーと直接やり取りしており、アジャイルとDevOpsを使用してそれらを開発しています。
大規模なタスクを解決する場合、会社のポリシーが遵守され、外部の要件に応じて1つまたは複数のアプローチを変更する準備ができていれば、さまざまなアプローチが必要になります。 しかし、大企業でカンバン、ウォーターフォール、スクラムを拡張して、あらゆるレベルの開発を同期し、何百人ものプログラマー、テスター、デザイナー、アーキテクトのチームの協調作業を確保するにはどうすればよいでしょうか？
HPEのR＆D部門は数十年前から存在しており、特にそのミッションは、内部開発プロセスを継続的に改善することです。 Waterfallは長い間使用されており、その問題は理解できるものであり、ここ数年で一部の開発者はスクラムに切り替えましたが、大規模な開発を個別にサポートすることはできず、高速でスケーラブルです-何らかの統一アイデア、方法論が必要でした 会社の内部プロジェクトの実装をサポートするためのこのような方法論は、独自の自動化ツールのプールからのプラットフォーム上のSAFeフレームワーク（ Scaled Agile Framework ）でした。 その結果、今日、HPE Codar、Jenkins、HPE ALM、HPE Agile Manager、HPE UFTなどのバンドルのおかげで、アセンブリ、展開、テストのプロセス全体が自動化されています。
SAFeはナレッジベースであり、 リーンアジャイルシナジーを使用して、非常に大規模な企業の規模に柔軟なアプローチを拡張できるフレームワークです。
ご存知のように、スクラムは、前の結果の分析に基づいて、後続のサイクルを調整しながら反復サイクルを実行することにより、プロジェクトの目標に近づくプロセスを編成することを目的としています。法人。 SAFeは、従来の柔軟な開発アプローチと新しい品質の追加を統合します。スクラムから、個々のサブタスクを解決するために協力できる開発者チームを構築する技術が採用されます。「エクストリームプログラミング」（XP）から、高品質プログラムコードを迅速に作成するためのルールが採用されます。 かんばんは、特に、チームと従業員が限られた量の進行中の仕事を持つべきだという考えを紹介します。 SAFeの特徴はリーンです。これは、新しいバージョンのリリースに対する障害を排除することにより、コストを最小限に抑えるのに役立ちます。
SAFeアーキテクチャ
SAFeの主な利点は、大規模開発のサポートです。言い換えると、大規模なチームの作業は、スクラムのようにスプリント（2週間サイクル）だけでなく、10週間続く計画（プログラムの増分）の追加反復で行われます。 同時に、計画に関与するのは1つの小さなチームではなく、1つのプロジェクトに関与する数百人の開発者のグループです。 製品バージョンは10週間以内にリリースできることが重要です。 リリースは計画に結び付けられていません。計画は、SAFeをウォーターフォールモデルと区別する大規模システムの開発にタクトを設定するためにのみ必要です。ウォーターフォールモデルでは、プロジェクトプランに予算が提供され、すべての作業に継続的に資金提供されるプログラムではありません。
SAFeでは、作業はリリーススケジュールなしで単一サイクルの連続プロセスとして編成されますが、アーキテクチャの整合性は明確に保持されます：次のバージョンは、誰かが事前に計画したときではなく、ビジネスによって要求された瞬間にリリースされます。 SAFeは、「リリースのスチームトレイン」のアイデアを実装します。これは、大規模企業のイデオロギーに適合しながら、スケーリングのための柔軟なアプローチの原則と対話プロセスの詳細な説明を維持します。 同時に、企業が利用できる自動化ツールはすべてSAFeで使用できます。SAFeの方法論は自動化ツールに関して不変です。
SAFeは、従来の開発方法論の主な問題の1つであるビジネスから次の反復のタスクを説明する開発者の大規模なグループへの知識の転送の解決を促進します。 従来の方法論では、通常、コミュニケーションは「壊れ」、アジャイル開発の原則に違反します。すべての開発者をいつでも制御することはできませんが、彼の貢献が全体像にどのように当てはまるかを知っている場合、彼は決定を下し、行動に責任を負うことができます。
SAFeを使用すると、開発者の生産性を20〜50％向上させ、ソリューションの品質を50％向上させ、製品の公開にかかる時間を30〜50％短縮できると主張されています。 SAFeのおかげで、すべての主題のプロジェクトからの満足度が高まり、プロジェクトは予算のブラックホールになるリスクはなくなりましたが、すぐに結果を出し始めました。 その結果、現在、フォーチュン100企業の60％以上に、既にITのITの全体像を形成するSAFe認定の専門家がスタッフにいます。これにより、ソフトウェア開発、エンジニアリングソリューション、運用組織のプロセスが調和します。
なぜこれがすべて可能になったのですか？
-SAFeは、開発者だけでなく、企業のすべてのサービス（マーケティング、計画部門、サービス部門など）に動きのビートを設定します。
-SAFeは「ボトルネック」を解消します。製品マネージャーが開発のすべての詳細に関与し、各決定に参加すると、ボトルネックになります。 チームへの権限の委任はこれを回避します。
-SAFeを使用すると、個々の開発者間のコミュニケーションを確立できるだけでなく、チームや部門の相互作用を促進し、DevOpsアプローチとうまく統合できます。
これに、チームのリーダーが彼の問題について最も大声で叫ぶことに基づいてのみ、開発の透明性と間違った決定を下すリスクの低減を追加できます。決定は個人的な目標ではなく、共通の目標を達成することを目的としています。
今日、カンバン、スクラム、リーンの方法論に精通し、彼らの助けを借りて最初の成功した結果を得た多くの国内企業は、世界の改善を望んでいますが、現在はスケーリングの問題に直面しています。 ロシアでは、開発プロジェクトを柔軟に管理する方法に関心のある大規模な組織がすでに多数ありますが、大規模なチームにスケールアップする経験はなく、SAFeはここで支援できます。