Выступление Максима Цепкова, нашего главного архитектора дирекции развития решений, на конференции Analyst Days (18 апреля 2015 года, Минск).

1. Разделение ответственности
в заказной разработке
Максим Цепков
Главный архитектор
дирекции развития решений
18 апреля 2015 года

2.  Разделение ответственности в проекте –
популярная тема холиваров
 Многие уверены, что знают «правильный способ»
 Часто выдают претензии смежникам, что те не делают
положенное или, наоборот, лезут на чужую поляну
 Однако единственной схемы не существует,
это пережиток эпохи «правильного процесса»
 Разделение ответственности нужно
конструировать в проекте, с учетом его
особенностей и интересов участников
О чем будет доклад
2/38

3. 1. Схема для разделения ответственности
2. Простой кейс: разработка по спецификациям
3. Заказчик и компания-разработчик: разделение
ответственности и взаимодействие
4. Ответственность в компании-разработчике
Содержание доклада
3/38

4. Схема для разделения
ответственности
4/38

5.  Возьмем схему процесса – и разметим
 Используем стандартную схему – V-модель
Визуальное представление
V-Model (Wikipedia)
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
Project
Definition
Project Test
and Integration
Time
Verification
and
Validation
5/38

6. Водопадная модель на схеме
ВнедрениеБизнес-
аналитики
Системные
аналитики Тестировщики
Разработчики
Заказчик
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
6/38

7. Простой кейс:
разработка по спецификациям
7/38

8. Компания
Заказчик
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
Уместен при высокой стандартизации продукта,
позволяет создать задание и определить результат
Аутсорсинг кодирования
ТЗ ПО
8/38

9. Разработчики
Заказчик
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
В компании – только разработчики
Компания
Менеджер
Работает, если проекты небольшие или имеют типовую
декомпозицию, а также в случаях, когда применяются только
типовые решения. Организация – одна команда или мини-группы
Менеджер или Teamlead
управляет процессом работ
9/38

10.  По разным технологиям
 Java и СУБД
 Дизайнер и разработчик в web
 Выделение «дешевых» специализаций,
например тестировщиков
 Работа может быть организована
последовательно или параллельно
 При последовательной работе возможно
выделение отделов
 Например, дизайн – разработка – тестирование
Специализация в команде
10/38

11. Разрыв между заказчиком и компанией
Компания
Заказчик
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
ТЗ ПО
11/38

12. Разрыв между заказчиком и компанией
Компания
Заказчик
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
ТЗ ПО
Спецификация недостаточно
определяет продукт
ПО не может выполнять
ожидаемые функции
11/38

13. Разрыв между заказчиком и компанией
Компания
Заказчик
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
ТЗ ПО
Спецификация недостаточно
определяет продукт
ПО не может выполнять
ожидаемые функции
Новый цикл?
11/38

14. Разрыв между заказчиком и компанией
Компания
Заказчик
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
ТЗ ПО
Спецификация недостаточно
определяет продукт
ПО не может выполнять
ожидаемые функции
Просто отказ
Новый цикл?
11/38

15. Почему плохо работает? Мешает природа
ИТ-разработки
Конструирование
системы
Обычный НИОКР
ПроизводствоПроект
ИТ-разработка
Архитектура
и дизайн
ТЗ Кодирование
Вещь
ПО
12/38

16. Почему плохо работает? Мешает природа
ИТ-разработки
Jack W. Reeves «What is software design» (1992; перевод)
Конструирование
системы
Обычный НИОКР
ПроизводствоПроект
ИТ-разработка
Архитектура
и дизайн
ТЗ Кодирование
Вещь
ПО
Архитектура
и дизайн
КодКодиро-
вание ПО
Компиляция
(build)
12/38

17. ПО ПО
ТЗ
ТЗ
Решение – коммуникация
Поставки ПО
и участие во
внедрении
Это фишка Agile
Компания
Заказчик
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
ТЗ
ПО
Так работает
Коммуникации
Заказчик ставит задачу в терминах бизнеса, компания осуществляет
разработку и внедрение вплоть до перестройки бизнес-процессов.
Большая зона совместной ответственности обеспечивает успех проекта
13/38

18. Заказчик и компания-разработчик:
разделение ответственности
и взаимодействие
14/38

19. У заказчика есть свой ИТ…
ИТ Заказчика
Заказчик
Компания
Бизнес-подразделения
Заказчика
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
ИТ заказчика часто стремится изолировать компанию
от бизнес-подразделений заказчика, однако для успеха проекта
взаимодействие необходимо
15/38

20. Операционная работа и развитие
Заказчик
Компания
Технологи и руководители,
проектный офис
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
ИТ-отдел(ы)
новых разработок
и проектов
Операционные
сотрудники
Эксплуатация ИТ
(админы)
Постановку задачи на разработку и эксплуатацию созданного
приложения осуществляют разные группы стейкхолдеров заказчика
Но это
еще не все
16/38

21. ИТ-проект – часть бизнес-проекта
Concept Maintenance
ИТ-проект
Бизнес-проект
Conc
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
Implementation
Ответственность стейкхолдеров заказчика – относительно
бизнес-проекта, а не ИТ-проекта
17/38

22. Заказчик
Компания
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
Где ответственность за целое?
ТЗ
Процессный ответ – обеспечим
через согласование артефакта
18/38

23. Заказчик
Компания
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verification
Maintenance
Где ответственность за целое?
ТЗ
Процессный ответ – обеспечим
через согласование артефакта
Артефакт –
не работает
18/38

24. А пусть будет Product Owner
Заказчик
Компания
Product Owner ?
Concept
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Maintenance
Implementation
Только у заказчика
он не всегда есть
19/38

25. Заказчик
Product Owner
Concept
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Maintenance
Implementation
Заказчик часто не готов
к такой области ответственности
Разработчики
Компания
Ответственность компании надо расширять,
частью ее становится Product Owner, он же менеджер 
Об этом будет
подробнее
20/38

26. Ответственность
в компании-разработчике
21/38

27. Заказчик
Product Owner
Concept
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Maintenance
Implementation
Разработчики
Компания
Аналитики тоже устраняют разрыв
Аналитики
Вопрос: Насколько аналитики заняты в тестировании и сдаче системы?
22/38

28. Заказчик
Product Owner
Concept
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Maintenance
Implementation
Разработчики
Компания
Аналитики тоже устраняют разрыв
Аналитики
Вопрос: Насколько аналитики заняты в тестировании и сдаче системы?
Вариант 1: Сдают разработчики
Вариант 2: Аналитики тестируют и сдают (модель внутреннего заказчика)
22/38

29. Заказчик
Concept
Product Owner
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Maintenance
Implementation Разработчики
Компания
Аналитики
Менеджер, Product Owner, аналитик
Аналитик:
преобразование требований
в модель системы
Роли,
а не должности
Менеджер
Менеджер, или Teamlead, или Scrum Master:
организация процесса работ и управление им
Product Owner: управление
целостностью и порядком
разработки системы
23/38

30. Тестировщик: младший аналитик
или отдельная позиция?
Заказчик
Product Owner
Concept Maintenance
Implementation
РазработчикиКомпания
Аналитики
Тестировщики
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Зависит от проекта:
каков характер
и объем тестирования
24/38

31. А можно и без аналитиков
Заказчик
Product Owner
Concept
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Maintenance
Implementation
РазработчикиКомпания
Тестировщики
Часто именно эта
картина складывается
исторически
25/38

32. Артефакты на проекте
Заказчик
Concept
System
Verification
Maintenance
Implementation
Разработчики
Компания
ТестировщикиАналитики
Requirements
and Architecture
Detailed
Design
ПО
Требования
Модель системы
Тест-кейсы
Версия
на тестирование
Версия
заказчику
Product Owner
Backlog
Integration
and Test
26/38

33. Архитектор, он же Techlead
Заказчик
Concept
Integration
and Test
System
Verification
Maintenance
Implementation
Разработчики
Компания
Тестировщики
Аналитики
Архитектор
Requirements
and Architecture
Product
Owner
Detailed
Design
Кто главный:
аналитик
или архитектор?
1. Построение начальной архитектуры
2. Проектирование типовых решений
Это – разные задачи и позиции
27/38

34. Еще есть внедрение и поддержка
Заказчик
Concept
Integration
and Test
System
Verification
Maintenance
Implementation
Разработчики
Компания
Тестировщики
Аналитики
Requirements
and Architecture
Detailed
Design
Product
Owner
Архитектор
Внедрение
и поддержка
Разделение работ с заказчиком может быть различным
и часто – неявным
28/38

35. Простое управление:
за все отвечает менеджер
Менеджер
Concept
Integration
and Test
System
Verification
Maintenance
Implementation
Компания
Requirements
and Architecture
Detailed
Design
Менеджер перед компанией может отвечать за весь процесс работ
на проекте, включая область ответственности заказчика
29/38

36. Разделение управления:
менеджер и Product Owner
Менеджер
Concept
Integration
and Test
System
Verification
Maintenance
Implementation
Компания
Requirements
and Architecture
Detailed
Design
Product
Owner
Product Owner: управление целостностью
и порядком разработки системы
Менеджер
или Teamlead:
управление
процессом работ
У Scrum Master’а
область та же,
отличается способ
управления
30/38

37. Разделение управления:
менеджер и Product Owner
Менеджер
Concept
Integration
and Test
System
Verification
Maintenance
Implementation
Компания
Requirements
and Architecture
Detailed
Design
Product
Owner
Product Owner: управление целостностью
и порядком разработки системы
Менеджер
или Teamlead:
управление
процессом работ
У Scrum Master’а
область та же,
отличается способ
управления
На V-модели
разделение
не видно –
меняем схему
30/38

38. OMG Essence: объекты процесса
31/38

39. Области управления
Менеджер
Product Owner
Разделение облегчило поиск
управленческого персонала
и обеспечило успех Agile
32/38

40. Области технологизации
Product Owner:
технологии
взаимодействия
с заказчиком
и работы
с требованиями
Архитектор:
технологии
разработки
Менеджер или Teamlead:
организация процесса
работ
33/38

41. Размер команды – 7 ± 2
Concept
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Maintenance
Implementation
Разработчики
Компания
Аналитики
Менеджер
Менеджер – один на несколько
команд или кто-то из команды
по совместительству
0.5
Product Owner
Product Owner – один
на несколько команд или аналитик
по совместительству
0.5
2
4
34/38

42. А если проект большой?
7 ± 2 мини-группы
одного ведущего
и 1-2 подчиненных
Несколько команд,
общий Product Owner
и (или) менеджер
35/38

43.  Если проекты достаточно однородны,
можно передавать одной команде
без специализации
 Можно делать мини-группы по каждому
проекту
 Решение зависит от равномерности потока
работ по проектам
А если проекты маленькие?
36/38

44.  Разделение ответственности зависит
от взаимоотношений с заказчиком
 От характера вашего проекта
 И от традиций компании
Не существует общепринятого
или единственно правильного способа
Его надо проектировать!
Подводя итоги
Спасибо, кэп!
37/38

45. Спасибо!
Вопросы?
Максим Цепков
M.Tsepkov@custis.ru
mtsepkov.org
38/38