システムについて
私が働いている会社は、MTFのような独自の取引プラットフォームを開発しました。 このシステムでは、毎秒数万の取引操作が実行され、Disruptorパターンを使用すると、取引の平均速度は20.5ミリ秒を超えません。 このプロジェクトには、大手銀行、ロンドンクリアリングハウスLCH、その他の企業などのサードパーティとの複雑な統合が含まれていました。
プロジェクトの開発には約3年、約20人のエンジニアのチームが必要でした。 このプロジェクトには、プロジェクトマネージャー、コーディネーター、プロジェクト計画、ガント図、アーキテクチャドキュメント、要件仕様、テスト計画はありません。
優れた技術に対する賞に加えて、同社はそのシンプルで効率的な開発プロセスでアジャイルコミュニティで認められています。 この投稿で彼についてお話したいと思います。
プロセスについて
同社はアジャイルベースの開発プロセスを使用しています。 システム開発は決して停止せず、新しい顧客の要件は定期的に満たされ、2週間ごとに新しいバージョンをリリースするサイクルがあります。
同社の開発者は3〜4つのグループに分かれており、それぞれが特定の方向に取り組んでいます。 各グループには5〜6人のプログラマ、テスター、アナリストがいます。
すべてのチームの作業は、2週間の反復に分けられます。 反復は水曜日に始まり、火曜日の2週間後に終了します。 仕事が遅れて金曜日に緊急に開発を完了する必要がないように、週の真ん中が選ばれました。
新しいバージョンの要件は、主に顧客、マーケティング部門、販売部門から寄せられます。 すべての願いは、計画壁に接着されている段ボールカードに書かれています。
計画壁は垂直方向にチームに、水平方向に反復に分割されます。 壁全体には、1年の4分の1、6反復のタスクが含まれています。 新しいカードは一番上に接着され、バックログは一番下にあります。 それらの間-6回の反復。
毎週火曜日、すべての関係者が計画壁の近くに集まり、優先順位に従ってカードを貼り直し、次の反復を計画します。 通常、チームのイテレーションには2〜4枚のカードがあります。
アナリストは、次の反復カードの詳細な要件を収集します。 要件はMingleシステムに記録されます。 通常のカードには、「トレーダーが注文サイズを設定した場合、次の変更まで保存する必要があります」などのオファーの形式で、5〜10個の受け入れ基準が含まれます。
反復作業について
毎週水曜日の午前10時に、回顧展が始まり、次の反復のキックオフが行われます。 チームは会議室またはソファ（十分な人数がいない）に散らばり、ケーキを食べて会議を開始します。
振り返ってみると、チームは何が良いのか、何が悪いのか、どんな質問やアイデアがあったのかを話し合います。 これを行うために、ボードは4つのセグメントに分割され、
回顧が終了すると、ローテーションが発生し、その結果、各チームが1人の開発者を失い、別の開発者を獲得します。
次に、新しいストーリーの分析を開始します。アナリストは、次の反復の計画について話します。 開発者は、要件を明確にして質問します。
カードは、このチームの計画壁からかんばん壁に移動しています。 かんばん壁は、水平方向のタスクと垂直方向のステータスに分けられます。 最初の列には、開始されていないすべてのタスクが含まれます。 次の列は、開始されたカードを占め、「進行中」および「終了」します。
ストーリーの開発は、サブタスクに分割することから始まります。 チーム全体がキッチンに集まり、付箋紙でカードをサブタスクに分割します。 多くの場合、この段階でソリューションが設計されます。これには、白い壁とマルチカラーのマーカーを使用します。 付箋は、「開始済み」セクションのかんばんボードに移動します。 最初と2番目のタスクが選択され、それぞれに2人のエンジニアがいます。
通常、最初のタスクはテストを書くことです。 これは、プログラマとテスター、テスターとアナリスト、またはアナリストとプログラマのカップルによって行われます。 テストは、受け入れ基準に基づいて作成されます。
すべてのテストは実行可能な仕様です。 テストはシステムコードの直接の一部であり、継続的インテグレーション（CI）環境に参加します。 現在、約20,000のテストがあり、各コミットはこれらのテストに対する自動テストの対象となります。
直接開発は常にペアで行われます。 ほとんどの場合、2人のプログラマーが開発に携わっていますが、これは多くの場合、テスターまたはアナリストの組み合わせです。 ペアプログラミングの結果、コードの品質が向上し、システムの知識が分散され（ドキュメントの必要性がなくなり）、より正確な決定が行われます。
「交配」に加えて、「混雑」（群がり）-同時に複数のペアで1つのストーリーを展開することも使用します。 ユーザーインターフェイスを作成するものもあれば、サーバー側を作成するものもあります。 サブタスクと設計への分解はチーム全体によって行われたため、誰もが何をする必要があるかを知っています。
開発では、一定の回転もあります-ペアは収束し、発散し、タスクを変更します。 その結果、誰もがすべてを理解し、個別のコードレビューの必要性がなくなります。 さらに、チームの信頼と関係が向上します。これは、単に1つの生物として機能するためです。
変更は常にSVNに送信され、そこで自動的にテストされます。
理論的には、システムはいつでも起動する準備ができています。 オフィスの中央には、テストステータス、実行速度、待ち時間、その他のパラメーターを表示するモニターがあります。
この開発プロセスは、金融機関には一般的ではありませんが、London Diverse Assets Exchange（LMAX）で使用されています。 すべての計画は公開され、各開発者はシステム全体の操作とほぼすべての特定の機能を知っています。 「ペアリング」と「混雑」の仕様は必要ないため、組織の異なる部分の間で競合はありません。 誰でも、隣のチームの「壁の絵」に慣れていれば、いつでも新しいソリューションを提供できます。 クラスとしてドキュメントが欠落しているため、電子メールは実際には使用されません。 計画を議論する決定委員会や退屈な会議はありません...
ところで、才能のあるJavaテスターとプログラマーが常に必要です。
ロンドンでのPSの仕事