Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.
Разделение ответственности
в заказной разработке
Максим Цепков
Главный архитектор
дирекции развития решений
18 апреля 2015...
 Разделение ответственности в проекте –
популярная тема холиваров
 Многие уверены, что знают «правильный способ»
 Часто...
1. Схема для разделения ответственности
2. Простой кейс: разработка по спецификациям
3. Заказчик и компания-разработчик: р...
Схема для разделения
ответственности
4/37
 Возьмем схему процесса – и разметим
 Используем стандартную схему – V-модель
Визуальное представление
V-Model (Wikipedi...
Водопадная модель на схеме
ВнедрениеБизнес-
аналитики
Системные
аналитики Тестировщики
Разработчики
Заказчик
Concept
Requi...
Простой кейс:
разработка по спецификациям
7/37
Компания
Заказчик
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verific...
Разработчики
Заказчик
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Ver...
 По разным технологиям
 Java и СУБД
 Дизайнер и разработчик в web
 Выделение «дешевых» специализаций,
например тестиро...
Разрыв между заказчиком и компанией
Компания
Заказчик
Concept
Requirements
and Architecture
Detailed
Design
Implementation...
Почему плохо работает? Мешает природа
ИТ-разработки
Jack W. Reeves «What is software design» (1992; перевод)
Конструирован...
ПО ПО
ТЗ
ТЗ
Решение – коммуникация
Поставки ПО
и участие во
внедрении
Это фишка Agile
Компания
Заказчик
Concept
Requiremen...
Заказчик и компания-разработчик:
разделение ответственности и
взаимодействие
14/37
У заказчика есть свой ИТ…
ИТ Заказчика
Заказчик
Компания
Бизнес-подразделения
Заказчика
Concept
Requirements
and Architect...
Операционная работа и развитие
Заказчик
Компания
Технологи и руководители,
проектный офис
Concept
Requirements
and Archite...
ИТ-проект – часть бизнес-проекта
Concept Maintenance
ИТ-проект
Бизнес-проект
Conc
Concept
Requirements
and Architecture
De...
Заказчик
Компания
Concept
Requirements
and Architecture
Detailed
Design
Implementation
Integration
and Test
System
Verific...
А пусть будет Product Owner
Заказчик
Компания
Product Owner ?
Concept
Requirements
and Architecture
Detailed
Design
Integr...
Заказчик
Product Owner
Concept
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Main...
Ответственность
в компании-разработчике
21/37
Заказчик
Product Owner
Concept
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Main...
Заказчик
Concept
Product Owner
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Main...
Тестировщик: младший аналитик
или отдельная позиция?
Заказчик
Product Owner
Concept Maintenance
Implementation
Разработчик...
А можно и без аналитиков
Заказчик
Product Owner
Concept
Requirements
and Architecture
Detailed
Design
Integration
and Test...
Артефакты на проекте
Заказчик
Concept
System
Verification
Maintenance
Implementation
Разработчики
Компания
ТестировщикиАна...
Архитектор, он же Techlead
Заказчик
Concept
Integration
and Test
System
Verification
Maintenance
Implementation
Разработчи...
Еще есть внедрение и поддержка
Заказчик
Concept
Integration
and Test
System
Verification
Maintenance
Implementation
Разраб...
Простое управление:
за все отвечает менеджер
Менеджер
Concept
Integration
and Test
System
Verification
Maintenance
Impleme...
Разделение управления:
менеджер и Product Owner
Менеджер
Concept
Integration
and Test
System
Verification
Maintenance
Impl...
OMG Essence: объекты процесса
31/37
Области управления
Менеджер
Product Owner
Разделение облегчило поиск
управленческого персонала и
обеспечило успех Agile
32...
Области технологизации
Product Owner:
технологии
взаимодействия
с заказчиком
и работы
с требованиями
Архитектор:
технологи...
Размер команды – 7 ± 2
Concept
Requirements
and Architecture
Detailed
Design
Integration
and Test
System
Verification
Main...
А если проект большой?
7±2 мини-группы
одного ведущего и
1-2 подчиненных
Несколько команд,
общий Product Owner
и (или) мен...
 Если проекты достаточно однородны,
можно передавать одной команде
без специализации
 Можно делать мини-группы по каждом...
 Разделение ответственности зависит
от взаимоотношений с заказчиком
 От характера вашего проекта
 И от традиций компани...
Upcoming SlideShare
Loading in …5
×

Разделение ответственности в заказной разработке

1,005 views

Published on

Доклад Максима Цепкова на конференции Analyst Days-4,
17-18 апреля 2015 г., Минск
www.analystdays.com

Published in: Education
  • Be the first to comment

Разделение ответственности в заказной разработке

  1. 1. Разделение ответственности в заказной разработке Максим Цепков Главный архитектор дирекции развития решений 18 апреля 2015 года
  2. 2.  Разделение ответственности в проекте – популярная тема холиваров  Многие уверены, что знают «правильный способ»  Часто выдают претензии смежникам, что те не делают положенное или, наоборот, лезут на чужую поляну  Однако единственной схемы не существует, это пережиток эпохи «правильного процесса»  Разделение ответственности нужно конструировать в проекте, с учетом его особенностей и интересов участников О чем будет доклад 2/37
  3. 3. 1. Схема для разделения ответственности 2. Простой кейс: разработка по спецификациям 3. Заказчик и компания-разработчик: разделение ответственности и взаимодействие 4. Ответственность в компании-разработчике Содержание доклада 3/37
  4. 4. Схема для разделения ответственности 4/37
  5. 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/37
  6. 6. Водопадная модель на схеме ВнедрениеБизнес- аналитики Системные аналитики Тестировщики Разработчики Заказчик Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance 6/37
  7. 7. Простой кейс: разработка по спецификациям 7/37
  8. 8. Компания Заказчик Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance Уместен при высокой стандартизации продукта, позволяет создать задание и определить результат Аутсорсинг кодирования ТЗ ПО 8/37
  9. 9. Разработчики Заказчик Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance В компании – только разработчики Компания Менеджер Работает, если проекты небольшие или имеют типовую декомпозицию, а также в случаях, когда применяются только типовые решения. Организация – одна команда или мини-группы Менеджер или Teamlead управляет процессом работ 9/37
  10. 10.  По разным технологиям  Java и СУБД  Дизайнер и разработчик в web  Выделение «дешевых» специализаций, например тестировщиков  Работа может быть организована последовательно или параллельно  При последовательной работе возможно выделение отделов  Например, дизайн – разработка – тестирование Специализация в команде 10/37
  11. 11. Разрыв между заказчиком и компанией Компания Заказчик Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance ТЗ ПО Спецификация недостаточно определяет продукт ПО не может выполнять ожидаемые функции Просто отказ Новый цикл? 11/37
  12. 12. Почему плохо работает? Мешает природа ИТ-разработки Jack W. Reeves «What is software design» (1992; перевод) Конструирование системы Обычный НИОКР ПроизводствоПроект ИТ-разработка Архитектура и дизайн ТЗ Кодирование Вещь ПО Архитектура и дизайн КодКодиро- вание ПО Компиляция (build) 12/37
  13. 13. ПО ПО ТЗ ТЗ Решение – коммуникация Поставки ПО и участие во внедрении Это фишка Agile Компания Заказчик Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance ТЗ ПО Так работает Коммуникации Заказчик ставит задачу в терминах бизнеса, компания осуществляет разработку и внедрение вплоть до перестройки бизнес-процессов. Большая зона совместной ответственности обеспечивает успех проекта 13/37
  14. 14. Заказчик и компания-разработчик: разделение ответственности и взаимодействие 14/37
  15. 15. У заказчика есть свой ИТ… ИТ Заказчика Заказчик Компания Бизнес-подразделения Заказчика Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance ИТ заказчика часто стремится изолировать компанию от бизнес-подразделений заказчика, однако для успеха проекта взаимодействие необходимо 15/37
  16. 16. Операционная работа и развитие Заказчик Компания Технологи и руководители, проектный офис Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance ИТ-отдел(ы) новых разработок и проектов Операционные сотрудники Эксплуатация ИТ (админы) Постановку задачи на разработку и эксплуатацию созданного приложения осуществляют разные группы стейкхолдеров заказчика Но это еще не все 16/37
  17. 17. ИТ-проект – часть бизнес-проекта Concept Maintenance ИТ-проект Бизнес-проект Conc Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance Implementation Ответственность стейкхолдеров заказчика – относительно бизнес-проекта, а не ИТ-проекта 17/37
  18. 18. Заказчик Компания Concept Requirements and Architecture Detailed Design Implementation Integration and Test System Verification Maintenance Где ответственность за целое? ТЗ Процессный ответ – обеспечим через согласование артефакта Артефакт – не работает 18/37
  19. 19. А пусть будет Product Owner Заказчик Компания Product Owner ? Concept Requirements and Architecture Detailed Design Integration and Test System Verification Maintenance Implementation Только у заказчика он не всегда есть 19/37
  20. 20. Заказчик Product Owner Concept Requirements and Architecture Detailed Design Integration and Test System Verification Maintenance Implementation Заказчик часто не готов к такой области ответственности Разработчики Компания Ответственность компании надо расширять, частью ее становится Product Owner, он же менеджер  Об этом будет подробнее 20/37
  21. 21. Ответственность в компании-разработчике 21/37
  22. 22. Заказчик Product Owner Concept Requirements and Architecture Detailed Design Integration and Test System Verification Maintenance Implementation Разработчики Компания Аналитики тоже устраняют разрыв Аналитики Вопрос: Насколько аналитики заняты в тестировании и сдаче системы? Вариант 1: Сдают разработчики Вариант 2: Аналитики тестируют и сдают (модель внутреннего заказчика) 22/37
  23. 23. Заказчик Concept Product Owner Requirements and Architecture Detailed Design Integration and Test System Verification Maintenance Implementation Разработчики Компания Аналитики Менеджер, Product Owner, аналитик Аналитик: преобразование требований в модель системы Роли, а не должности Менеджер Менеджер, или Teamlead, или Scrum Master: организация процесса работ и управление им Product Owner: управление целостностью и порядком разработки системы 23/37
  24. 24. Тестировщик: младший аналитик или отдельная позиция? Заказчик Product Owner Concept Maintenance Implementation РазработчикиКомпания Аналитики Тестировщики Requirements and Architecture Detailed Design Integration and Test System Verification Зависит от проекта: каков характер и объем тестирования 24/37
  25. 25. А можно и без аналитиков Заказчик Product Owner Concept Requirements and Architecture Detailed Design Integration and Test System Verification Maintenance Implementation РазработчикиКомпания Тестировщики Часто именно эта картина складывается исторически 25/37
  26. 26. Артефакты на проекте Заказчик Concept System Verification Maintenance Implementation Разработчики Компания ТестировщикиАналитики Requirements and Architecture Detailed Design ПО Требования Модель системы Тест-кейсы Версия на тестирование Версия заказчику Product Owner Backlog Integration and Test 26/37
  27. 27. Архитектор, он же Techlead Заказчик Concept Integration and Test System Verification Maintenance Implementation Разработчики Компания Тестировщики Аналитики Архитектор 29/41 Requirements and Architecture Product Owner Detailed Design Кто главный: аналитик или архитектор? 1. Построение начальной архитектуры 2. Проектирование типовых решений Это – разные задачи и позиции 27/37
  28. 28. Еще есть внедрение и поддержка Заказчик Concept Integration and Test System Verification Maintenance Implementation Разработчики Компания Тестировщики Аналитики Requirements and Architecture Detailed Design Product Owner Архитектор Внедрение и поддержка Разделение работ с заказчиком может быть различным и часто – неявным 28/37
  29. 29. Простое управление: за все отвечает менеджер Менеджер Concept Integration and Test System Verification Maintenance Implementation Компания Requirements and Architecture Detailed Design Менеджер перед компанией может отвечать за весь процесс работ на проекте, включая область ответственности заказчика 29/37
  30. 30. Разделение управления: менеджер и Product Owner Менеджер Concept Integration and Test System Verification Maintenance Implementation Компания Requirements and Architecture Detailed Design Product Owner Product Owner: управление целостностью и порядком разработки системы Менеджер или Teamlead: управление процессом работ У Scrum Master’а область та же, отличается способ управления На V-модели разделение не видно – меняем схему 30/37
  31. 31. OMG Essence: объекты процесса 31/37
  32. 32. Области управления Менеджер Product Owner Разделение облегчило поиск управленческого персонала и обеспечило успех Agile 32/37
  33. 33. Области технологизации Product Owner: технологии взаимодействия с заказчиком и работы с требованиями Архитектор: технологии разработки Менеджер или Teamlead: организация процесса работ 33/37
  34. 34. Размер команды – 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/37
  35. 35. А если проект большой? 7±2 мини-группы одного ведущего и 1-2 подчиненных Несколько команд, общий Product Owner и (или) менеджер 35/37
  36. 36.  Если проекты достаточно однородны, можно передавать одной команде без специализации  Можно делать мини-группы по каждому проекту  Решение зависит от равномерности потока работ по проектам А если проекты маленькие? 36/37
  37. 37.  Разделение ответственности зависит от взаимоотношений с заказчиком  От характера вашего проекта  И от традиций компании Не существует общепринятого или единственно правильного способа Его надо проектировать! Подводя итоги Спасибо! Вопросы? Максим Цепков mtsepkov.org Спасибо, кэп! 37/37

×