Доклад сделан 18.04 на AnalystDays-4 в Минске
Презентация на slideshare
Видео на Vimeo (в статье тоже есть)

Аннотация

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

За время доклада мы попробуем разобраться, как могут быть распределены функции между ролями в компании-разработчике, между подрядчиком и заказчиком, между ИТ и бизнесом на стороне клиента, и каким образом этим можно управлять. А также обратимся к историческим корням вариантов разделения ролей, поговорим о ключевых особенностях проектов, которые нужно учитывать при проектировании ролевой структуры, и о «тонких местах», возникающих при том или ином разделении.

Annotation

Division of responsibilities in software development process is one of the most popular topics for discussions and chats. Participants are usually confident about other persons' misunderstanding of their responsibilities, although the issue of responsibilities division is certainly known. However, there's no the only true division of responsibilities in software development, because the boundaries depend on certain project aspects and special kinds of performed work: analysis, design, development, testing.

The presentation considers schemes of management and shared responsibility in software development: responsibilities and roles in the development team, division of responsibilities from the Company and the Customer and different stakeholders on the Customer's side. We are to discuss the origination of some schemes of shared responsibility, kinds of project characteristics, which affect design of project roles and those effects, which cause slack in different places of these schemes.

Краткое изложение доклада

1. Не существует единственно правильного разделения ответственности, его надо проектировать с учетом специфике проекта
2. Для проектирования разделения ответственности нужна схема.
   1. Используем V-диаграмму, так как на ней процесс изображен непрерывно - что позволяет двигать границы при проектировании.
   2. Принимать во внимание необходимо не только процесс в Компании-разработчике, но и Заказчика.
3. Простой кейс: разработка по спецификациям.
   1. Разделение ответственности и способы передачи между заказчиком и разработчиком
   2. Деление ответственности в компании-разработчике
   3. Проблемы в разработке по спецификациям: передача через артефакты не работает, необходимы перекрывающиеся зоны ответственности и коммуникации. Причина - в природе ИТ-разработки Jack W. Reeves «What is software design» (1992), перевод статьи
4. Заказчик и компания-разработчик: разделение ответственности и взаимодействие
   1. Для коммуникаций надо понимать структуру Заказчика.
      1. Разделение на Бизнес и ИТ.
      2. Проектированием и эксплуатацией занимаются разные подразделения.
      3. ИТ-проект, как правило, является частью бизнес-проекта.
   2. Передача ответственности от Заказчика к Компании выполняется не через артефакт - ТЗ, а через позицию Product Owner. Заказчик не всегда готов обеспечить эту позицию, в этом случае компании-разработчику надо быть готовой ее занять.
5. Ответственность в компании-разработчике
   1. Аналитики. Поддержка Product Owner, закрывают разрыв между Заказчиком и Разработчиками. В части работы с требованиями - всегда, а в части сдачи внедрения есть два варианта: может быть сдача разработчиками, особенно при хороших автотестах, или модель внутреннего заказчика в лице аналитиков.
   2. Разделение ответственности между ролями Аналитик, Product Owner и Менеджер (он же Team Lead или Scrum Master). Не забывать - это - роли, им не обязательно соответствуют позиции, возможно совмещение.
   3. Тестировщик - младший аналитик или отдельная позиция в зависимости от организации процесса. Работа с тестировщиками, но без аналитиков.
   4. Артефакты на проекте поддерживают коммуникации и передачу ответственности. Их тоже надо проектировать, разделяя долговременные и временные.
   5. Архитектор, он же TechLead. Поддержка и Внедрение.
   6. Ответственность за управление - Менеджер и Product Owner. Для описания удобно использовать не V-диаграмму, а альфы OMG Essence.
   7. Ответственность за технологизацию: Product Owner, Архитектор и Менеджер. Тоже на диаграмме альф OMG Essence.
   8. Размер команды. Варианты масштабирования на большие и малые проекты.

Официальная запись конференции. В статье некоторое время было другое видео, снятое сотрудником нашей компании Владом Марковым: оно появилось раньше? но в нем отдельной записи экрана.