HappyDev’13
Действительно полезная конференция!
7–8 декабря 2013
Омск. База отдыха им. Стрельникова
Cepkov
Максим Цепков
CUSTIS, Главный архитектор, Москва

Соучредитель и главный архитектор компании CUSTIS. Работаю в компании со дня основания (то есть с 1996 года). С отличием окончил факультет управления и прикладной математики Московского физико-технического института.

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

Я верю в эффективность командной работы и профессиональных сообществ и категорически не согласен рассматривать людей как ресурсы. Командная работа необходима и в проектировании архитектуры, вопреки распространенному мнению, что этим должен заниматься единоличный творец. По моему опыту, лучшие архитектуры создавались совместно сильными архитекторами, хотя договариваться было не просто. Я делюсь своими взглядами как в профессиональных сообществах, выступая на конференциях и работая в программных комитетах конференций SECR и Analyst Days, так и в компании, активно участвуя во внутренних проектах развития.

Работа с требованиями

Сталкивались с тем, что требования сложно формализовать и поддерживать актуальность?

Есть много подходов - user story, use case и т.д., но все они описывают в основном поведенческие аспекты. А что делать, если мы работаем в сфере, где бизнес-требования достаточно сложны и объекты меняют поведение в зависимости от контекста?

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

Люди

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

Основные активности - управление, аналитика, разработка, тестирование - никуда не уходят, но можно по разному делить между людьми ответственность за них.

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