Анна Обухова, Exigen Services (Санкт-Петербург)
Должность:
Project Group Manager
О себе:
официальная биография для доклада:
Обухова Анна - имеет биологическое, Computer Science и управленческое образования. В данный момент учится на EMBA в Manchester Business School по направлению Global Business.
В IT более 10 лет, работала в области тестирования, потом менеджером по разработке ПО. С 2005 года руководила несколькими Agile (XP and SCRUM) проектами для заказчиков из производственных, банковских, социальных сетей и медиа отраслей.
Также Анна является экспертом Agile Center of Excellence в Exigen Services, объединяя лучшие практики накопленные в индустрии и используемые в компании.
В данный момент работает Руководитем Проектов на стороне заказчика управляя несколькими Agile командами в разных странах а так же является Quality Program Manager создавая единую систему обеспечения качества процесса и продукта в программе с около 70 Agile проектами.
Профессиональный бизнес-тренер, ведущая ряда тренингов проводящихся внутри компании, а так же авторского курса по тестированию ПО в Политехническом университете. Выступает на конференциях и публикует материалы по Agile тематике.
Выступает с докладом
Scrum давно используется для разработки программного обеспечения в распределенном режиме и когда речь заходит о проекте с участием нескольких распределенных команд, то понятно что проект будет непростым. Но насколько непростым и как четко и грамотно построить взаимодействие между заказчиком, командами и руководством проекта? Каков на самом деле уровень риска такого проекта? Проанализировав личный опыт разработки распределенных Agile проектов и опыте Exigen Services, я выделила несколько факторов влияющих на такие проекты что позволило сформулировать Agile Distribution Risk Score как четкую метрику сложности распределенного проекта. Пользуясь этой формулой любой руководитель проекта сможет наглядно в цифрах увидеть сложность проекта и работая над факторами входящими в рассчет Distribution Risk Score сделать проект более грамотно организованным. Этот подход позволяет рассчитать когда распределенная команда будет эффективна, а когда стоит настаивать чтобы проект не был распределенным.