Роль аналитика в негибких методологиях разработки

Ирина Сурова для DEVDAY

Роль аналитика в «негибких» методологиях разработки

Обо мне

В продуктовой разработке 12 лет, из них: в системном анализе 5 лет в тестировании 7 лет опыт создания и поддержки процессов разработки 2 года

соавтор клуба прикладного системного анализа проекта Stratoplan.ru

участник сообщества аналитиков uml2.ru

Аналитик проецирует образ решения от Заказчика в команду Исполнителя

Какие бывают методологии?

Методология 2009 2011 2012

Scrum 14 18 21

XP 3 1 1

Agile-based (не Scrum, не XP) 11 18 27

RUP-based 5 5 5

CMM/CMMI 2 1 -

Как получится 21 18 15

Через %опу 35 30 18

MSF 1 1 1

Водопад/Waterfall - 5 8

Другое 8 3 4

Голосов 122 913 850

Результаты опросов Happy-PM http://www.happy-pm.com/blog/?p=6559

Методологии в картинках

Водопадный процесс / ГОСТ 34Бизнес-

требования

Бизнес-правила

Пользовательские требования

Ограничения

Атрибуты качестваФункциональные

требования

Системные требования

Rational Unified Process

RUP. Точки принятия решений Завершение Начальной стадии — сформировано видение и

границы проекта, риски сформулированы и оценены

Концепция/Vision (содержит ключевые бизнес-требования, пользовательские требования, бизнес-правила, ограничения и атрибуты качества, ключевые системные и функциональные требования)

Завершение итерации Уточнения — уточнены оценки сроков и рисков, построена исполняемая архитектура

ТЗ/ЧТЗ/SRS (Бизнес-требования, пользовательские, системные, функциональные требования, ограничения, атрибуты качества, прототипы GUI по функционалу итерации)

Завершение фазы Уточнения

Все требования

Как получится и Через %опу. Точки принятия решений

Надо сделать! Быстро!

Постановка задачи разработчику

Обмен ценностями в ходе разработки

Бизнес передает технологам плату или инвестиции

Технологи поставляют Технологию Потребителю в виде продукта/сервиса

Потребитель использует Технологию и платит плату Бизнесу

class Обмен ценностями

Бизнес

Потребитель Технологии

$$$

Продукт

$$$

Источник модели - презентация Дениса Бескова «4 производственных контекста»

Внутренняя разработка и внедрение (in-house)

Типовые цели: смесь бизнеса / потребителя / технологии

class Внутрення разработка

Организация

Бизнес

ПотребительТехнологии

$$$

Продукт

$$$

Заказная разработкаТиповые цели: • Заказчик - Получение ПО, позволяющего добиться бизнес-целей• Подрядчик - исполнение контракта с сохранением рентабельности

class Заказная разработка

ПодрядчикЗаказчик

Бизнес

ПотребительТехнологии

Бизнес

Продуктовая разработка

class Продуктовая разработка

Покупатель

ПроизводительПокупатель

Бизнес

ПотребительТехнологии

Бизнес

Типовые цели: • Производитель — успех продукта на рынке• Покупатель — быстрое получение ПО, позволяющего добиться бизнес-целей

Системная интеграция/внедрениеТиповые цели: • Заказчик: получение ПО, позволяющего добиться бизнес-целей• Подрядчик: соблюдение контракта с сохранением рентабельности• Производитель: Успех продукта на рынке

class Внедрение

ПроизводительПодрядчикЗаказчик

Бизнес

ПотребительТехнологии

Бизнес Бизнес

Технологии

Продукты для массовой аудиторииТиповые цели: • Производитель: достижение бизнес-показателей при росте количества/активности пользователей• Бизнес-пользователь: привлечение аудитории/увеличение узнаваемости своего бренда за счет рекламы в сервисе• Пользователь: получение нужного и удобного сервиса бесплатно или дешево.

deployment Продукты для массовой аудитории

Пользователи

Бизнес-потребителиПроизводитель

Бизнес

Технологии Потребитель

Бизнес

Потребитель

Итоги:

Аналитик: Делает задачу понятней — программисты

делают быстрее, тестеры понимают, что является багой — повышает качество.

Но удорожает продукт и является передаточным звеном (формально не приносит ценности в продукт)

Самая главная картинка

Спасибо за внимание!

Вопросы? Ирина Сурова Mailto:irr.suri@gmail.com