Соучредитель и главный архитектор компании CUSTIS. Работаю в компании со дня основания (то есть с 1996 года). С отличием окончил факультет управления и прикладной математики Московского физико-технического института.
Я верю, что автоматизация дает новые возможности для развития. Создавая автоматизированные системы, мы открываем путь прогрессу и делаем мир лучше. Проектирование архитектуры реальных систем, особенно в заказной разработке, — интереснейший процесс поиска баланса между общими архитектурными подходами и реализацией специфических требований конкретного проекта. Я участвовал во множестве проектов и в разработке нескольких фреймворков компании.
Я верю в эффективность командной работы и профессиональных сообществ и категорически не согласен рассматривать людей как ресурсы. Командная работа необходима и в проектировании архитектуры, вопреки распространенному мнению, что этим должен заниматься единоличный творец. По моему опыту, лучшие архитектуры создавались совместно сильными архитекторами, хотя договариваться было не просто. Я делюсь своими взглядами как в профессиональных сообществах, выступая на конференциях и работая в программных комитетах конференций SECR и Analyst Days, так и в компании, активно участвуя во внутренних проектах развития.
Сталкивались с тем, что требования сложно формализовать и поддерживать актуальность?
Есть много подходов - user story, use case и т.д., но все они описывают в основном поведенческие аспекты. А что делать, если мы работаем в сфере, где бизнес-требования достаточно сложны и объекты меняют поведение в зависимости от контекста?
DDD - подход, позволяющий превратить предметную область из темного леса в настоящего друга человека. Единый язык устраняет трудности перевода между заказчиками, аналитиками, командой разработки и тестировщиками и дает возможность верификации модели заказчиком.
Многие думают, что есть какой-то эталонный, правильный способ разделения ролей в разработке. Однако в конкретной ситуации начинают влиять как особенности людей - участников проекта и представителей заказчика, - так и самого проекта - решаемой задачи, процессов в компаниях исполнителя и заказчика.
Основные активности - управление, аналитика, разработка, тестирование - никуда не уходят, но можно по разному делить между людьми ответственность за них.
В докладе я покажу разные варианты распределения ролей и ответственности в команде в зависимости от исходных условий и личностных особенностей участников проекта.
