Аннотация
- Докладчик
- Сергей Евтушенко
Это рассказ об опыте применения agile техник и практик в крайне динамичных условиях инвестмент банкинга. Отчет основан на опыте выполнения проектов и руководства рядом проектных команд Luxoft.
В своем докладе я расскажу о:
- опыте применения agile практик (история нескольких команд)
- как внедрять agile на уже «бегущем» проекте
- «боевой» набор инженерных практик
- как внедрять agile в распределенных средах
- что помогает формировать команды
Видео
Для этого доклада нужен подкаст (аудиозапись)?
Примечания и отзывы
Название надо немного уточнить — конечно, речь не идет о том, чтобы гонять на скрам-митинги самих банкиров,
речь идет о разработке систем для инвестиционного банкинга, это корпоративная разработка характеризуемая:
- высокими
- нагрузками (а вообще, финансовый highload не так часто встречается в корпоративщине), т.е. и быстрые очереди сообщений, и хитрая бизнес-логика, и мощное железо, и критичность ошибок и все это в одном флаконе.
- зарплатами. Причем при наборе разработчиков очень требуют опыт разработки приложений для инвестбанкинга.
В этой области работает широко известный в узких кругах Умпутуном,
и работал печально известный Сергей Алейников, который променял ежегодние $400×10³ на 8 лет тюрьмы.
Т.е. в целом, это достаточно элитные проекты, и для тех, кто продумывает карьеру типа «хорошие деньги и программирование», это один из таких вариантов, и послушать полезно (особенно если нет своих знакомых из этой области).
Так вот, там не работает стандартный Agile-Парето-подход, когда идет размен scope на сроки — тут требуется все и сразу (full scope/fixed deadline).
Плюс заказчики далеко за океаном (аутсорсинг на Украину), большие лаги в коммуникации.
Не самая хорошая позиция для игры в аджайл.
В результате, из процессных практик там постепенно выкинуто почти все — и двухнедельные итерации, и демонстрации.
Особенно то, что завязано на заказчика, например автотесты с Fitness (подразумевается, что их пишут-проверяют аналитики заказчика).
Остались добротные инженерные практики, такие как Continuous Integration, нотификация о коммитах и кодревью, метрики покрытия интеграционными тестами — в общем, максимум проверок на своей стороне,
ибо на таких заказчиках не поотлаживаешься.
Распределенные совещения удалось улучшить с помощью софта:
В общем — резюме, не пытайтесь применять все SCRUM-практики, если вы попали в такую плохую ситуацию.
Внимание! Эта статья была создана путем автоматического реплицирования из внутренней базы знаний компании Заказные Информ Системы. Любые правки этой статьи могут быть перезаписаны при следующем сеансе репликации. Если у вас есть серьезное замечание по тексту статьи, запишите его в раздел «discussion».
