Как аналитик может помочь в планировании выпуска версий
•Als PPTX, PDF herunterladen•
0 gefällt mir•663 views
Доклад Александра Прокудина на конференции Analyst Days-5, 22-23 апреля 2016 г., Санкт-Петербург www.analystdays.com
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Andere mochten auch
Andere mochten auch (8)
Ähnlich wie Как аналитик может помочь в планировании выпуска версий
Ähnlich wie Как аналитик может помочь в планировании выпуска версий (20)
Mehr von SQALab
Mehr von SQALab (20)
Как аналитик может помочь в планировании выпуска версий
- 1. Прокудин Александр АО InfoWatch Как аналитик может помочь в планировании выпуска версий
- 2. Компания InfoWatch • Продуктовая разработка • Сфера деятельности – информационная безопасность • Основной продукт – система защиты от утечек данных Traffic Monitor
- 3. О чем доклад? • Какие проблемы возникают при планировании выпуска версий? • Как правильно оценивать трудозатраты? • Нужен ли аналитик на этапе планирования? • Чем он может помочь?
- 4. Проектная команда 33 разработчика 30 тестировщиков 4 аналитика + дизайнер Product manager Проектный менеджер
- 5. Контекст разработки • Выпуск версий раз в 6-9 месяцев • Значительное расширение функционала • Классическая каскадная модель
- 6. Как было: Отбор функций Релиз Фича 3 Фича 2 Фича 1 Product manager
- 7. Как было: Оценка Руководители разработки и тестирования Фичи Оценка
- 8. Как было: План Проектный менеджер Оценка Срок выпуска
- 9. Проблема • Нет единого понимания функционала • Позднее выявление рисков • Проблемы с интеграцией • Неадекватная оценка трудозатрат
- 10. И в итоге… Регулярное несоблюдение сроков выпуска
- 11. Что делать? • Раннее снижение неопределенности • Формирование единого понимания • Выявление рисков • Адекватная оценка трудозатрат
- 12. Что делать? Новый этап •Первичное уточнение требований •Разработка архитектуры
- 13. Что делать? Модель решения • Потребности пользователей • Основной сценарий использования • Ключевые особенности Аналитик • Макеты интерфейсовДизайнер • Архитектурное решение • Технологические риски Архитектор
- 15. Как стало: Модель решения Аналитик Архитектор Дизайнер интерфейсов Фичи-кандидаты Модель решения
- 16. Как стало: Согласование и оценка Руководители разработки и тестирования Модель решения Оценка + Риски
- 17. Оценка + Риски Как стало: Состав релиза Product manager Состав релиза
- 18. Как стало: План Проектный менеджер Состав релиза + Оценка Срок выпуска и план
- 19. Результат • Адекватные сроки выпуска версии • Единое понимание функционала и целей проекта • На старте проекта уже есть: • Верхнеуровневые требования • Архитектура
Hinweis der Redaktion
- Немного о себе и нашей компании.
- Перед многими командами разработки встает вопрос о планировании выпуска версий продукта. Какие функции включать в версию? Как правильно оценивать трудозатраты? Как учитывать технологические риски? В нашей компании подобные вопросы до недавнего времени решались не слишком эффективно, что часто приводило к проблемам со своевременным выпуском новых версий. В своем докладе я расскажу о нашем подходе к решению данной проблемы. для чего и как нужно привлекать аналитика на самом раннем этапе планирования выпуска, какие документы аналитик может подготовить на этом этапе и как они помогут в оценке трудозатрат на разработку.
- Проектная команда: Менеджер по развитию продукта (Product manager) – отвечает за стратегию развития продукта, формирование состава очередной версии Проектный менеджер – отвечает за формирование плана работа по выпуску очередной версии, контроль выполнения работ по плану, соблюдения сроков Аналитики Разработчики Тестировщики
- Выпуск мажорных версий осуществляется приблизительно раз в 6-9 месяцев – это не обязательно, зависит от включаемого в релиз функционала. Рассказать два слава о каскадной модели.
- Product manager выбирает новые функции, которые должны войти в релиз, на основании: потребностей рынка, нужд ключевых клиентов Данный набор фактически является финальным и уже не будет изменен в дальнейшем
- Руководители разработки и тестирования оценивают трудозатраты Минимальная информация – о фичах почти ничего не известно Оценка делается быстро, между делом Аналитики не привлекаются
- Проектный менеджер: составляет план выпуска версии Озвучивает срок выпуска: Он принимается за истину На него ориентируются все: тех деп, продуктовый отдел, коммерческий отдел Стартует цикл разработки.
- У команды нет единого понимания функционала очередной версии Вопросы, требующие исследования, возможные технологические риски выявляются слишком поздно Исследования проводятся уже в процессе разработки и непредсказуемо изменяют скоуп/сроки Интеграция не продумывается заранее Как следствие, неадекватная оценка трудозатрат
- Озвученные ранее 6-9 месяцев в итоге легко могут превратиться в 12-13
- В итоге были поставлены следующие цели для улучшения процесса планирования
- Введение нового этапа
- Введение нового документа – «Модель решения» Состав документа: От аналитика Бизнес-потребности пользователей Основной высокоуровневый сценарий использования для нового функционала От архитектора: Основные архитектурные решения Перечень технологических рисков и вопросов, требующих исследования От обоих: Ключевые особенности нового функционала От дизайнера Макеты Модель решения != Требования Модель решения ~ Границы проекта
- Аналогично, как раньше. Но! Теперь это не финальный набор, он может быть изменен после оценки
- Совместная разработка модели. Аналитик ответственный за функц. Область Назначенный архитектор – кто-то из старших разработчиков Дизайнер Совещания/обсуждение Привлечение других специалистов Разработчики Тестирование Внедрение/сопровождение Продуктовый отдел Модель разрабатывается для каждой новой фичи.
- Согласование: Продукт менеджер Проектный менеждер Лиды разработки/тестирования Оценка: Разработка Тестирование Аналитики Тех. Писатели Перед согласованием проводится презентация нового функционала.
- Product manager на основании предоставленных оценок выявленных технологических рисков выбирает функции, входящие в версию и формирует окончательный состав релиза.
- Проектный менеджер на основании оценок формирует план разработки по выбранным функциям и объявляет срок выпуска версии. Стартует стандартный цикл разработки. Перед стартом проводится презентация функционала всей команде.
- В разработке первая версия продукта, спланированная подобным образом. Результаты уже сейчас: более адекватные сроки - НАДЕЕМСЯ, будут соблюдены. Уже на старте проекта у команды имеются верхнеуровневые требования и архитектура, Возможно, тестовая модель что ускоряет и упрощает разработку. У команды сформировано единое понимание нового функционала, поэтому: аналитикам легче писать детальные требования – СНИЖЕНИЕ ЗАТРАТ у разработчиков и тестировщиков возникает намного меньше вопросов при чтении требований Наблюдение: Модель наглядна, имеет малый объем Легче воспринимается сама Облегчает дальнейшее восприятие требований Разработка модели улучшает коммуникации
- У команды сформировано единое понимание нового функционала, поэтому: аналитикам легче писать детальные требования – СНИЖЕНИЕ ЗАТРАТ у разработчиков и тестировщиков возникает намного меньше вопросов при чтении требований Наблюдение: Модель наглядна, имеет малый объем Легче воспринимается сама Облегчает дальнейшее восприятие требований Разработка модели улучшает коммуникации
- Надеемся на дальнейшее подтверждение эффективности нашего подхода, Что он принесет плоды уже скоро. Возможно, наш опыт будет полезен вам.