Некоторое время назад я решила получить дополнительное образование к уже имеющемуся и немного исчерпавшему себя магистру по Системной инженерии. Для поступления в выбранную школу мне надо было подготовить несколько эссе. Размышляя над ними я сильно превысила требуемые 400 слов, и чтоб добро не пропадало, решила их подправить и вывесить сюда.

Темы для эссе связаны с моей работой, поэтому далее я разберу некоторые аспекты бизнес анализа. Надеюсь, кому-нибудь будет интересно.

О системе

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

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

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

На прошлой неделе компания LMAX, где я работаю, получила приз Java Duke's Choice Award 2011 за фреймворк Disruptor. Ранее об этой технологии писал Martin Fowler, известный многим читателям публикациями об объектном программировании.

В этой статье я хотела бы вкратце рассказать об этой технологии, а так же о конкретной проблеме, которую эта технология решает в компании LMAX.

Хочу поделиться опытом разработки и введения ай-ти процессов в проекте. Зачем нужны процессы? Они, отвечают многим разным целям, но в нашем случае основной целью было разграничение ответственности.

Многие программисты согласятся, что когда находят баг в уже работающей системе, вина сваливается на них. А кого же ещё? Ведь они его допустили! В итоге, мотивация понижается, имидж портится, и вообще — те, кто больше всех работает, получает больше всех пинков. А признание получают менеджеры, отдел продаж и прочие…

Я расскажу о оценке работ(estimation) в скрам. Её рекомендуется проводить дважды — сначала в story points, на уровне user stories, а потом — в часах, на уровне заданий в текущей итерации. Так же я попытаюсь объяснить, почему это делается дважды.

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