最新の銀行を想像するのが難しい主なことは、モバイルデバイスに適したアプリケーションです。 人間は快適さを愛し、すぐにそれに慣れる生き物です。 したがって、銀行と銀行とのやり取りが支店に行き、通常の業務のために書類を記入するというパラダイムに全員を取り戻したら、誰もが悲しむでしょう。
銀行はアクセス可能でなければならず、アプリケーションは最も手頃な数の操作の実行、自動支払いの設定、友人への送金、支払い可能なものの支払い、カードの注文などを可能にする必要があります。
Alfa-Bankには、このためにAlfa-MobileとAlfa-Business-Mobileがあります。
iOSの責任者であるIlya Tsarevです。今日は、モバイルアプリケーション開発プロセスの仕組みを説明します。
私はAlfa-Bankで2年以上働いており、シニア開発者から始め、現在はすべてのiOS開発を担当しています。 1年前、私たちはすべてのことについて6人のiOS開発者がいました。 品質は低下せず、速度も大幅に向上することなく、開発プロセスを正常に拡張できました。
それから
急速な発展のいくつかの期間がありました。 それはすべて2年前に始まり、開発チームを完全に変更しました。当時は1つの大きなチームでした-2つのiOS、2つのアンドロイド、複数のデザイナー、1つの製品、分析、そしてこの群衆全体（合計約20人）はAlpha Mobileによって開発されました。
私たちはこのチームで働き、月に1回、平均で約3つの機能を含むアプリケーションアップデートをリリースしました。
2016年後半、この群衆を3つの部分に分割しました。 その結果、3つのチームが作業するAlpha Mobileアプリケーションがあり、各チームには独自の特定の作業があることが判明しました。 これらのチームは小規模で、5〜8人です。 それぞれ-各役割に1人の参加者、つまり1人のiOS開発者、1人のアンドロイド開発者、1人のデザイナー、1人の製品など。
この場合、他のチームに関係なく、各チームは自分の作品を見ることができます。 たとえば、チーム番号1は支払いと送金を扱います。 チームNo. 2-裕福なクライアント（これらは通常、平均よりもはるかに高い支出をする人であり、もちろん銀行にとって非常に重要です）。 チーム番号3-再設計とあらゆる種類の全般的な改善。
このすべてを行ったとき、1つのチームのフレームワークよりもはるかに優れた機能を発揮することがわかりました。 各チームは独自の機能を作成し、チーム内の決定はより迅速に行われ、その結果、1つの大きなチームからよりも多くの機能がリリースに組み込まれました。 まあ、それは始まった、私たちは3チームではなく、約20個を行うことにしました。
そして、まさにそれが私たちが2017年に始めたものです。
いま
現在、15のチーム（Alfa MobileとAlfa Business Mobileを含む）があり、これは非常に細分化されており、各チームは再び独自の作業を行っています。 誰かが支払いと送金を行い、誰かが-例えば、FIFAとの協力の下で、ターゲットを絞った機能を提供します。 同時に、このチームのメンバーがそれを入手して、今はFIFAタスクを持っていない場合、承認プロセスの改善など、何か他のことを始めます。
その結果、15のチームがあり、同時に何かを行っているため、2週間に1回リリースされます。各リリースには以前よりも多くの機能（約10）と編集が含まれます。
つまり、そのような変更は非常に簡単に聞こえます、彼らはチームごとに人を連れて行き、それぞれが何か異なることをしますが、実際にはプロセスに非常に複雑な変化をもたらしました。 結局のところ、チームは孤立しており、チーム内のほとんどの部分で通信しています。このすべての周りには、iOS、Android、デザインのレイヤーもあります。 これはすべて同期する必要があります。そうでない場合はすべて:)
プロセス技術
このすべてが外出先でバラバラにならないように、プロセステクノロジを次の形式にしました。
- インスピレーションでコードを書く開発者がいます。
- リモートリポジトリに共通のコードがあります。
- 開発者が完了すると、彼はプルリクエストを作成し（インスピレーションも少なくありません）、みんなに「私はみんなだから自由になりましょう」と書いています。
同時に、いくつかの自動チェックがあり、このコードを静的アナライザー（swiftlint）でチェックします。これにより、たとえば、ブラケットがない場所やメモリリークのリスクがあるなど、問題のある問題をすばやく修正できます。 swiftlintについてもう少し話してください-私たちはほとんどすべての標準ルールを含めており、独自のルールもいくつか持っています。 これにより、コードレビューの時間を節約できます。
Continuous Integrationサーバー（この場合、Jenkinsが使用されます）は、静的コードアナライザーを実行し、アプリケーションでテストを実行し、ビルドと実行を支援し、これについてSlackに書き込みます。 このすべての後、手動のコードレビューが既に進行中です。
コードが受け入れられると、最愛のジェンキンスは、テストデバイスへのインストール、セルフテスト、および可能なリリースのために、いくつかのアセンブリをビルドします。 チーム内のテスターがそのようなアセンブリをチェックし、すべてが順調であれば、コードは次のリリースに投入される可能性があります。
AppStoreを使用すると、以前のようにすべての人ではなく、特定の割合のユーザーに対して新しいリリースを展開できます。 そのため、まずユーザーの1〜5％に新機能を展開し、そこにあるものと一般的な方法を検討します。 必要に応じて、何かを修正し、10％展開します。 さらに、独自のソリューションを使用して、特定の機能を特定のユーザーグループに展開し、これらすべてを柔軟に管理できます。 これらの2つのメカニズムにより、技術的実験と製品実験の両方を行うことを恐れることはありません。
このすべては詳細な分析にかかっています。これにより、何が間違っていたのか、どこで、どのように素早く修正するのかを時間内に理解できます。 また、ユーザーの2パーセントのみがアプリケーションの特定のセクションにアクセスし、残りの98パーセントがそれを無視することも決定できます。 通常、これはセクションの場所やその一般的な意味の便利さを示唆しています。
チーム
Alfa Mobileは現在、15人のiOS開発者に取り組んでいます。 上記のAlpha Business Mobile-3。
製品チームに加えて、彼らはいわゆるテクニカルチームに積極的に参加し、これはスケーリングと並行して現れました。 アーキテクチャを監視するチームがあります（ところで、このチームはAlfa-Mobileで使用する独自のソリューションを開発しています ）、設計システムを開発するチーム、およびCI / CDを改善するチームがあります。 このすべてのために、彼らは製品チームに時間を割り当てました。
設計システムチームは、UIコンポーネントのライブラリを開発しています。 開発者がすべての人に役立つ可能性のある何かを書くとき、彼はそれを共有ライブラリにアップロードします。 したがって、何らかの新しいプロジェクトがある場合、チームはすぐにこのライブラリに接続して、多くの準備ができて有用なものを得ることができます。
ところで、チームの理想的なサイズについて。 リーダーとして、私たちはすでに多すぎると言えます（パニックなしで、モバイル開発者を積極的に採用しています）。 私はただ、より多くの人々がより多くの時間を同期に費やしていると言っています、これは正常です。 ちなみに、このため、ジュニア開発者は考慮していません（ただし、例外はありますが）。
主にミドル、ミドル+開発者を採用しています。 これらは必要な技術をすでにかなり自信を持って知っている人々ですが、同時に彼らは自分自身のために研ぎ澄まされ、現在のチームで働くために指導を受けることができます。 私たちは多くの新しいテクノロジーを使用しています。たとえば、 私たち自身のアーキテクチャであるSwiftコードの半分以上があり、通常あまり積極的に使用されないものがいくつかあります。 もちろん、スタンディングシニアも高く評価されます。 ただし、社内ですでにリードを形成することを好みます。
現在、私たちにはアクティブなモバイル開発者のセットがあり、新しいチームがたくさんあります（アイデアのある製品がたくさんあり、チーム内に人が必要です）。銀行、恥ずかしがらずに-https ://hr.alfabank.ru/vacancies/ios-dev
銀行でのモバイルアプリケーションの開発の特殊性について、または私たちとの仕事の一般原則についての質問に喜んでお答えします。