Download as PDF, PPTX
Uploaded byCUSTIS
Разделение ответственности в заказной разработке
Доклад обсуждает разделение ответственности в заказной разработке, подчеркивая, что единой схемы не существует и ее необходимо адаптировать к особенностям проекта и интересам участников. Приводятся схемы взаимодействия между заказчиком и разработчиками, а также различные модели работы, способствующие успешной реализации проектов. Важно отметить, что успешное сотрудничество требует взаимопонимания и совместной ответственности между всеми участниками процесса.
More Related Content
Similar to Разделение ответственности в заказной разработке
Разделение ответственности в заказной разработке
- 1. Разделение ответственности в заказнойразработке Максим Цепков Главный архитектор дирекции развития решений 18 апреля 2015 года
- 2. Разделение ответственностив проекте – популярная тема холиваров Многие уверены, что знают «правильный способ» Часто выдают претензии смежникам, что те не делают положенное или, наоборот, лезут на чужую поляну Однако единственной схемы не существует, это пережиток эпохи «правильного процесса» Разделение ответственности нужно конструировать в проекте, с учетом его особенностей и интересов участников О чем будет доклад 2/38
- 3. 1. Схема дляразделения ответственности 2. Простой кейс: разработка по спецификациям 3. Заказчик и компания-разработчик: разделение ответственности и взаимодействие 4. Ответственность в компании-разработчике Содержание доклада 3/38
- 4.
- 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 andTest System Verification Maintenance Implementation Заказчик часто не готов к такой области ответственности Разработчики Компания Ответственность компании надо расширять, частью ее становится Product Owner, он же менеджер Об этом будет подробнее 20/38
- 26.
- 27. Заказчик Product Owner Concept Requirements and Architecture Detailed Design Integration andTest System Verification Maintenance Implementation Разработчики Компания Аналитики тоже устраняют разрыв Аналитики Вопрос: Насколько аналитики заняты в тестировании и сдаче системы? 22/38
- 28. Заказчик Product Owner Concept Requirements and Architecture Detailed Design Integration andTest System Verification Maintenance Implementation Разработчики Компания Аналитики тоже устраняют разрыв Аналитики Вопрос: Насколько аналитики заняты в тестировании и сдаче системы? Вариант 1: Сдают разработчики Вариант 2: Аналитики тестируют и сдают (модель внутреннего заказчика) 22/38
- 29. Заказчик Concept Product Owner Requirements and Architecture Detailed Design Integration andTest 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 andArchitecture 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.