Pull to refresh

Ненормальный Agile в финансах

Reading time 4 min
Views 8.2K
О системе

Фирма, в которой я работаю, разработала свою трейдинговую платформу типа MTF. В этой системе ежесекундно производятся десятки тысяч торговых операций, и с помощью паттерна Disruptor, средняя скорость выполнения трейда не превышает 20.5 миллисекунд. В проекте задействованы сложнейшие интеграции с третьими сторонами — крупными банками, Лондонским Домом Клиринга LCH и другими корпорациями.

На разработку проекта ушло около 3 лет и команда из примерно 20 инженеров. В проекте нету и не было ни одного руководителя проекта, координатора, планов проекта, диаграмм Гантта, документов архитектуры, спецификаций требований, и планов тестирования.

Кроме наград за выдающиеся технологии, компания признаётся в сообществе Agile за простой и эффективный процесс разработки. О нём я и хочу рассказать в этом посте.

О процессе

Компания использует свой процесс разработки на базе Agile. Разработка системы никогда не прекращается, и новые требования клиентов регулярно исполняются, с циклом выпуска новой версии раз в 2 недели.

Разработчики компании разделяются на 3-4 группы, каждая из которых занимается определённым направлением. В каждой группе 5-6 программистов, тестер и аналитик.

Работа всех команд разделяется на двухнедельные итерации. Итерация начинается в среду, и заканчивается через 2 недели во вторник. Середина недели выбрана для того, чтобы не надо было срочно заканчивать разработку в пятницу, задерживаясь на работе.

Требования на новую версию появляются в основном от клиентов, отдела маркетинга и отдела продаж. Все пожелания записываются на картонные карточки, которые приклеиваются на стену планирования.

Стена планирования поделена вертикально на команды, и горизонтально – на итерации. Все стена содержит задания на четверть года, 6 итераций. Новые карточки приклеиваются на самый верх, а беклог находится внизу. Между ними – 6 итераций.

Каждый вторник все заинтересованные стороны собираются возле стены планирования и переклеивают карточки по приоритетам, таким образом планируя следующие итерации. Обычно в итерации на команду бывает 2-4 карточки.

Аналитик собирает детальные требования для карточек следующей итерации. Требования записываются в систему Mingle. Обычная карточка содержит 5-10 критериев принятия, в форме предложений типа «Если трейдер выставил размер заказа, он должен сохранится до последующего изменения»

О работе в итерации

Каждую вторую среду в 10 утра начинается ретроспектива и «кик-оф» следующей итерации. Команды разбегаются по митинг-румам или диванам (кому не хватило), и начинают встречу с поедания торта.

В ретроспективе команда обсуждает, что было хорошо, что плохо, какие есть вопросы и идеи. Для этого доска расчерчивается на 4 сегмента, куда назначенный доброволец записывает рассуждения членов команды. Цель этого упражнения — придумать улучшения для следующей итерации.

После окончания ретроспективы происходит ротация, в результате которой каждая команда теряет одного разработчика и приобретает другого.

Потом начинается разбор новых историй, где аналитик рассказывает о плане на следующую итерацию. Разработчики задают вопросы, проясняя требования.

Карточки переезжают со стены планирования на стену канбан для этой команды. Стена канбан поделена на задачи – горизонтально, и статус – вертикально. В первой колонке содержатся все неначатые задачи. Следующие колонки занимают начатую карточку, потом «в прогрессе» и «закончено».

Разработка истории начинается с разбития её на подзадачи. Вся команда собирается на кухне, и на клейких листках разбивает карточку на подзадачи. Нередко на этом этапе проектируется решение – для этого мы используем белую стену и разноцветные маркеры. Клейкие листки переходят на доску канбан в раздел «Начато». Выбирается первая и вторая задача, с парой инженеров на каждую.

Обычно первой задачей является написание тестов. Этим занимается пара из программиста и тестера, тестера и аналитика, или аналитика и программиста. Тесты пишутся ориентируясь на критерии принятия.
Все тесты – это исполнимые спецификации. Тесты являются непосредственной частью кода системы, и участвуют в среде постоянной интеграции (CI). На данный момент у нас около 20 000 тестов, и каждый комит подвержен автоматическому тестированию против этих тестов.

Непосредственная разработка всегда происходит парно. Чаще всего разработкой занимаются 2 программиста, хотя нередко это и комбинация включающая тестера или аналитика. В результате парного программирования качество кода повышается, знание системы распространяется (исключая нужду в документации), и принимается больше правильных решений.

Кроме «спаривания», мы используем «столпотворение» (swarming) – разработку одной истории несколькими парами одновременно. Одни делают пользовательский интерфейс, другие тем временем – серверную сторону. Так как разбивка на подзадачи и проектирование было совершено всей командой, все отлично знают что надо делать.

В разработке тоже происходит постоянная ротация – пары сходятся и расходятся, меняются заданиями. В результате все знают всё, и нужда в отдельных ревью кода исчезает. Кроме того, повышается доверие и улучшаются отношения в команде, потому что она просто работает как один организм.

Изменения постоянно отправляются в SVN, где подвергаются автоматическому тестированию.
Теоретически, система готова для запуска в любой момент времени. Посреди офиса висят мониторы, отображающие статус тестирования, скорость исполнения, латентность и прочие параметры.

Вот такой нетипичный для финансовых организаций процесс разработки используется в Лондонской Бирже Разнообразных Активов (LMAX). Все планирование выставленно на всеобщее обозрение, каждый разработчик знает работу всей системы и практически каждой конкретной функции. В результате «спаривания» и «столпотворения» спецификации не нужны, нету конфликтов между разными частями организации. Каждый всегда может предложить новое решение, ознакомившись с «настенной живописью» соседней команды. Документы отсутствуют как класс, электронная почта практически не используется. Нету комитетов принятия решения и скучных встреч обсуждения планов…

Кстати, нам всегда нужны талантливые тестеры и программисты Java.

P.S. работа в Лондоне
Tags:
Hubs:
+29
Comments 68
Comments Comments 68

Articles