Разработка бизнес приложений (3)

Обзор scrum. Product owner

Разработка бизнес приложений Лекция 3

AGILE & SCRUM

Откуда все пошло

• В классическом контракте фиксируется все (пожалуй, кроме качества)

Что делать (SCOPE)

Время Деньги

Качество

Результат

• Разработчик ждет change-request’а как манны небесной

• Итог – все страдают все– 60% - проваленных проектов– >50% превышение бюджета в два раза– Только 16% проектов уложились в бюджет и ср

оки• Было обнаружено – 49% фичей не используется никогда– 19% используются очень редко

Логичный вывод

Что делать (SCOPE)

ВремяДеньгиКачество

В чем сложность

• Сложно сформулировать в юридическом контракте, нужно доверие– Отсюда очень много идеологии, т.к. доверие – это

сложно. Доверие – это ответственность.• Два крайних случая контакта

– Fixed cost (scope) (ответственность на разработчике)– Time & Material (ответственность на заказчике)

• А между ними – масса сложных вариантов– Fixed cost (scrope) -> Fixed budget– MultiStage, TargetCost / Budget– Pay for done

И придумали - Scrum

• Единственный реально описанный и продуманный agile процесс, о котором мы и будем говорить

Общая картина

Почему это работает

• Приветствуются изменения• Частые поставки продукта• Бизнес и разработка работают вместе• Поощряет общение• Ответственность, самоорганизация,

доверие встроены в процесс• Просто* и очень прозрачно• Обратная связь встроена (PDCA)

Еще одна аналогия

$ $ $

Водо

пад

Роли в скраме

• Команда (team)• Скрам мастер (scrum master)• Product owner

Команда

• Кроссфункциональная (Dev*, QA, BA, UI, …)• Самоорганизуемая (ответственная)• 7 +/- 2 человека• Принимает обязательства достичь цель

спринта (итерации)• Отвечает за процесс• Владеет планом итерации• Работает вместе

Ответственная

• Способы ухода от ответственности– Игнорирование– Отрицание– Оправдание– Обвинение– Стыд– Обязательство

• Ответственность – это действие• www.christopheravery.com

Scrummaster (тимлид)

• Член команды (не начальник, не PO):– Защитник– Инициатор изменений (инициативен)– Помогает внедрять scrum– Учитель / Наствник– Модератор– Устраняет помехи– Эскалирует проблемы– Мотиватор

Product owner

• Видение продукта• Бэклог продукта• Приоритеты• Прямой контакт с разработчиками• Единый голос заказчика• Инспекция (иногда приемка) готового• Планирование релизов, ROI и все остальное

Люди севера и югаЗаказчикBusiness Owner

(BO)

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

Маркетинг

АутсорсFreelance

ПродажиSales

Product OwnerМенеджер продукта

Команда

Люди севера

Люди юга

Переводчик!

АЛЬТЕРНАТИВНЫЙ ВЗГЛЯД

Joel, MS, program manager

• Что делает:– UI– Функциональные спецификации– Координирует команды– Служит адвокатом клиента

• Тоже не начальник программистов• Существенно ближе к традиционному

подходу, проще начать с этого

Функциональная спецификация

• Один владелец (ответственный), дисклеймер

• Что делаем, что не делаем• Общее описание на полстранички• Сценарии (обычно по ролям) + UI + детали• Общие для сценариев вещи• Открытые вопросы• Заметки для разных аудиторий

Joel Test• Используете ли вы сорс контроль?• Можете ли вы сделать билд в один шаг?• Есть ли дневные билды?• Есть ли база данных багов?• Исправляются ли баги до написания нового кода?• Есть ли актуальный график разработки?• Есть ли спецификация?• Программисты работают в тишине?• Используете ли вы лучшие инструменты которые можно купить?• Есть ли у вас тестеры?• Пишут ли код программисты на собеседовании?• Проводите ли вы коридорное тестирование юзабилити?

РАБОТА МЕНЕДЖЕРА ПРОДУКТА (PO)

Лук планированияСтратегия

Портфолио

Продукт

Релиз

Итерация

Ежедневное планирование

Стратегия. Заинтересованные лицаВласть

СтепеньЗаинтересованности

Стараемся удовлетворить

Минимальныеусилия

Регулярно информируем

Ключевыеигноки

Стратегия. Видение продукта

• 1-2 странички:– Цель / проблема (в чем)– Заинтересованные лица (на кого влияет)– Позиционирование продукта (как решает)– Ключевые возможности (с помощью каких

фичей)• Problem statement -> product statement

Одним абзацем

Для (целевой клиент), Который (потребности), Наш продукт (название), Это (категория продукта), Который (ключевая причина купить), В отличии от (альтернатива), Наш продукт (ключевое отличие)

Джеффри Мур

Требования. User Stories

• Как [роль пользователя]• Я хочу [функция]• Что бы [преимущество]

• + приемочные тесты (как проверить)• Книга: Mike Cohn -> User stories applied

Какие должны быть истории

• Specific• Measurable• Attainable• Relevant• Time-bound• И не только истории

Story Mapping.

• Как структурировать требования (истории) с чего начать?

• Выделить роли (из стейкхолдеров)– Выделить персоны

• Для каждой роли выделить крупные эпики (epics), цели

• Делить эпики на активности

Выделим роли (персоны)

• Роль• Описание (соц. дем)• Ценности и

глобальные цели по отношению к проекту

• Напр. преподаватель– хочет оценить мои

знания

Выделим активности

• По возможности, в хронологическом порядке ([персона] может сделать [что-нибудь] с нашей системой)

• Например:– Смотреть на результаты деятельности– Убеждаться что мыслительный процесс

действительно случился

Выделим активности

• А потом [персона] делает [юзер историю]• Например, что бы посмотреть результаты– Смотрит на работающую программу и код– Смотрит на документацию

• Формулируем в самом простом возможном виде

Добавляем детали

• Более продвинутые варианты каждой истории• Например:– Выложить код на github– Сделать доклад / презентацию– Выложить проект в веб

Как делить истории

• Минимальная необходимость что бы продемонстрировать в простейшем виде

• Гибкость, дополнительные возможности• Безопасность, защита от дурака, обработка

ошибок• «Фенечки»: юзабилити,

производительность, внешний вид

Или по другому

• Happy path (успешный вариант)• По качеству (сервиса)• По деталям (усложнение)• По ролям• По поддерживаемым данным• По операциям (CRUD)• По шагам исполнения (самое плохое)

Планируем релиз

• Цель – получить ходячий скелет– Словить все риски сразу– Максимально погрузиться в проект

BacklogДеталиЦенностьПриоритет

100-

150

шту

к

2-3

спри

нта

Мес

яцы

Год(

ы)

Backlog как айсбергРазработка

Итерация

Релиз

Будущее

Приоритезация. Факторы

• Бизнес ценность (новый доход, +доход, экономия, эффективность)

• Цена задержки• Снижение рисков• Стоимость• Приобретение знаний• Зависимости

Планирование

• Встреча планирования спринта– Planning poker– Обсуждение – Несколько минут на дообсуждение истории и

игру в покер• Постоянная детализация• Оптимальный размер задач <1-3 дней.– Слишком маленькие – тоже плохо

А дальше работы команды

• Scrummaster– Оценка– Burndown chart– Daily scrum– DoD– Демо– Ретроспективы

• Об этом много говорить смысла нет, т.к. нужен практический опыт

Читаем

• Джоел Спольски (JoelOnSoftware.com)– http://www.joelonsoftware.com/items/2009/03/09.html– http://www.joelonsoftware.com/articles/fog0000000036.html (4 части)– Переводы: http://local.joelonsoftware.com/wiki/Russian

• Making things happen (Искусство управления IT проектами), Скотт Беркун

• Преодоление пропасти. Маркетинг и продажа хайтек-товаров массовому потребителю (Джеффри Мур)

Темы для докладов

• AOP• MSF, Kanban / Lean• SCRUM: Team / ScrumMaster – подробнее

про процесс (DS, Retro, SprintPlan, Demo…)• Portfolio management, BMG (Alex Ostervald),

Scrum of Scrum

Лабы

• Открытые данные– http://www.apps4russia.ru/– http://apps4russia.reformal.ru/– http://data.worldbank.org/

• Готовое:– http://minenergo.gov.ru/activity/statistic/ – http://www.fms.gov.ru/about/ofstat/– http://www.federalspace.ru/main.php?id=10

• Повышенный балл:– Или наличие БД– Или наличие веб интерфейса– Индивидуальное задание (для тех, у кого уже есть что показать)