私たちのプロジェクトを例として、私たちがどのようにうまくいったか、どのようなプラクティスを開発したかをお話しします。
SECR-2016でこのトピックに関するレポートを作成しました。スライドは記事の最後に添付されています。
問題の本質
私たちの状況では、すべてのクライアントが要求する一般的な機能には、それぞれが金融および法的規制によって課せられた独自のルールがありました。 この場合、最も重要なことは、これらの要件を特定してから顧客のニーズを満たすまでの過程で、これらすべての微妙さを失わないことです。
ソースデータ
私たちのアプリケーションは、ある有名な投資銀行の顧客が担保の入出金を管理して取引を清算するのに役立ちます。
アプリケーションは2つのビジネスラインをサポートします。
- 交換清算（上場デリバティブ）
- OTCクリアリング（店頭でクリア済み）
クライアントは、独自の金融規制を持つ3つの地域で表されます。
- 米国-米国
- EUR-ヨーロッパ
- イギリス-イギリス
したがって、各ビジネスラインおよび地域のすべての微妙な点を考慮して、同じ機能を作成する必要があります。
当初、私たちのチームは、誕生以来アプリケーションを実行していた顧客側の非常に有能なBAの管理下で働き、特別な問題はありませんでした。
しかし、いったん彼が辞めて、すべてが変わった。 その上で彼らはコンサルティング会社のアクロバット兄弟を2人与えました。彼らはすぐに暴力的な活動を展開し、何かを見つけ、いくつかのタスクを設定し、各バレルにプラグを取り付けました。
そして、UAT段階では、完全な失敗が待っていました。 コンサルタントは、ユーロ地域と英国地域で担保を返済するためのルールを巧みに混ぜ合わせたため、受け取った機能は他のどれにも受け入れられないことが判明しました。 これは、他の瞬間に説明されていないものと同様に、私たちの仕事の約6ヶ月を取り消しました。
コンサルタントは追い出され、私たちは新しいPMと一緒にフリースイミングに送られました。
私たちは何をしましたか
私は、顧客とプロジェクトをほぼ新たに確立する必要がありました。 そして、ここに私たちがやったことです：
組織変更
以前は、BAを介して顧客と連携していましたが、現在は直接顧客と連携しています。 5人の顧客。 ペアごとに、ビジネスライン+地域。 PMは、作業計画を定義し、顧客の要望を優先度順に並べる段階でのみ関与します。
将来的には、リリースカレンダーのみに従って作業プロセスに干渉することはなく、隣接するシステムにリビジョンを注文する必要がある場合は、予算編成を担当します。
残りの作業はチームが行い、要件を調整し、リリースを記入し、顧客と直接デモを実施します。
このため、中間段階や関連する歪みなしに、お客様とのコミュニケーションの時間を可能な限り効率的に使用します。 開発を遅らせることなく、必要なすべてを見つけることができます。
ユーザーストーリー
私たちは、「なぜ」という質問だけでなく、「誰が」、「どのように」も質問し始めました。 異なる規制機関の下でのクライアントの仕事の詳細は異なり、影響を受ける地域のクライアントが新しい機会をどのように使用するかを正確に知ることが極めて重要です。
たとえば、英国の規制の規則に従って、設定されている通貨でのみ債務を返済することができます。 そして、顧客の1人が希少な通貨を使用しており、その通貨の取引日が終了した後にのみ残高を取得できることが判明しました。 それで、突然、全く新しい象が出て、同盟国に行って、バランスを提供するためにスケジュールを変更しなければなりませんでした。
したがって、クライアントが異なる地域で何をするかだけでなく、どのように正確に行うかを知ることは非常に重要です。
影響分析
要件を管理するには、JIRA + Confluenceを使用します。 そのため、Storyの機関では、記載されている要件の影響を受けるすべてのビジネスラインと地域のラベルを示しています。
JIRAがStashと統合されているという事実により、影響分析を実行する際に、最初に検索オブジェクトに関連付けられているすべてのタスクを見つけます。そして、これらのタスクがタッチされたことがわかり、その後、コミットによって、開発者は依存関係と不要な効果をより正確に識別します。
この方法は、単なる楽観的なコード検索よりもはるかに効果的です。
統合
投資銀行のIT環境は広大で多様です。 したがって、アプリケーションが他のシステムに送信するものをどこに置くかを正確に知る必要があります。
たとえば、コンサルティングの兄弟はこの点を無視し、統合の第1レベルに制限し、アプリケーションが英国とユーロの証券ムーブメントをダウンロードするシステムを確認しました。ユーロと英国の2つがあります。
その結果、英国人は証券を口座に置いたが、貸借対照表には表示されなかったことが判明しました。
ネプリヤトネンコ。
QA
機能が地域やビジネスラインに影響を与えない望ましくない影響を防ぐために、テストにマイナスのステップを導入し、隣人が新しいものを受け取るにもかかわらず、すべてが以前と同じように機能することをこれらの顧客に確認しますまたは変更された機能。
UAT（ユーザー受け入れ）
冗長なUATを始めました。 以前は、たとえば、30件のケースがある場合、それらを顧客間で均等に分割し、それぞれ6件を取得しました。 現在、各顧客は、ラインとリージョンの組み合わせに影響するケースの完全なセットを受け取ります。
つまり 同じ30のケースでは、1つは25ケース、もう1つは20ケース、3つ目は5ケースというようになります。 ケースが影響する地域とラインが多ければ多いほど、顧客間でより多く複製されました。 これは、もちろん、受け入れ中の彼らの負担を増やしましたが、まさにそのようなアプローチの利点を彼らに納得させることができました。
まとめ
上記のすべての方法を適用して、ほぼ1年間正常に動作し、3つのリリースを実行しましたが、今回は単一のUATまたはPRODインシデントを受信していません。