scrum в заказной разработке

PM Labs Омск, 22/10/2010

Scrum в заказной разработке

Асхат Уразбаев Тренер и консультант по гибким методологиям

Асхат Уразбаев

•  ScrumTrek •  Agile Coach •  Управляющий партнер

•  В прошлом •  Программист, менеджер

проектов, методолог

h"p://scrumtrek.ru/company/clients/  

Проблемы в разработке ПО

Требования меняются

―  Согласование такого контракта обычно занимает у нас около четырех месяцев. За это время со 100% вероятностью мы передумаем или вы прекратите использовать продукт. Может быть мы сэкономим время, объявим о провале и начнем обвинять друг друга?

―  Я сдался еще до того, как отдал вам контракт

Почему требования меняются?

Недостаток информации

Недостаток фантазии

Избыток фантазии

Заказчик меняет требования

•  Логичный вывод – требования зафиксировать

Каскадная модель (Waterfall)

Контрактные обязательства фиксируют…

•  Объем работ •  Сумму контракта •  Дату поставки

Проблема точки невозврата

•  Заказчик боится принимать окончательное решение (подписывать требования)

Заказчик

•  Заказчик – наемный менеджер •  Если что – он тоже виноват

Согласования, утверждения, совещания, рабочие группы и другие методы избегания ответственности

Сбор  требований   Разработка     Тестирование     Приемка  у  

заказчика  

ПОЛЕЗНОЕ ВРЕМЯ

Сроки реализации растут

Итеративная разработка

Полезное время итеративной разработки

ПОЛЕЗНОЕ ВРЕМЯ

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

Кодирование и тестирование

Приемка

Оценка в Agile

•  Команда оценивает каждую фичу – Например, в условных единицах (story

points) •  Известна эмпирическая усредненная

скорость команды (сумма условных единиц в итерацию)

Баклог – инструмент управления требованиями Функциональность   Оценка  

Баклог как способ управления требованиями •  Заказчик может поменять любую

несделанную фичу на эквивалентную по размерам

•  Фичи оценивает вендор •  Заказчик может добавить или

удалить фичу. •  Заказчик может поменять порядок

несделанных фич •  В любой момент заказчик может

принять решение остановить разработку

•  Заказчик формально принимает сделанные фичи

Фиксированный  объем  работ  

Фиксированный  бюджет  

Почему итеративная разработка дешевле?

Отмененная функциональность

Новая функциональность

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

Не делаем лишних фич

Экономим трудозатраты

Без  автотестов   С  автотестами  

Поддержка  (баги)  

Автотесты  

Функциональность  

Descoping

Как вы делаете предварительную оценку?

Старинные методы оценки

Учет рисков

•  Традиционный подход: накинем на оценку сверху: – Изменения требований – Проблемы при сдаче – Труднореализуемые Мегафичи

•  Scrum – Оценка более адвекватна (при условии

согласовании с заказчиком правил Scrum)

Проблема приемки

•  Что если заказчик будет менять фичи по ходу итерации или не принимать в конце итерации?

Приемочные тесты

•  Создавать приемочные тесты •  Приемочные тесты согласовывать с

заказчиком до начала планирования итерации

Создание  требований  

Демонстрация  Приемка  

Ретроспектива  

Декомпозиция  Оценка  

Таймбоксинг  

Фичи  

Фичи  +  приемочные  

тесты  

Фичи  +  задачи  с  оценкой  

Команда  

Команда  

Product  Owner  

Команда  

В сухом остатке

•  Работаем короткими итерациями •  Сдаем заказчику результаты в конце

каждой итерации •  Требования фиксируются на следующую

итерацию (например, в виде приемочных тестов)

•  Используем баклог для управления изменениями

Роли в Scrum: ScrumMaster Поддерживает «здоровье» команды, помогает команде стать самоорганизующейся Ответственность: •  Фасилитирует (модерирует) митинги •  Поддерживает прозрачность, доверие и

взаимную ответственность •  Устраняет внешние препятсвия

•  Отвечает за процесс

Роли в Scrum: TEAM •  Самоорганизованная / самоуправляемая

-  Колективно принимают решения -  Сами координируют и организуют свою

работу •  Кроссфункциональная

Роли в Scrum: Product Owner •  Задача: Добиться целей проекта •  Ответственность: •  Представляет интересы заказчика и

заинтересованных лиц •  Формирует и координирует Баклог •  Отвечает за Концепцию •  Управляет датой релиза и его

содержанием

Цель проекта?

Цель– максимизировать свою прибыль?

•  Даже если результат не нужен заказчику

Цель – максимальная удовлетворенность заказчика?

Сервис,  который  хочет  заказчик  

Сервис,  который  нужен  заказчику  

Цель – максимальная ценность бизнесу заказчика

Партнерство

•  Общие цели •  Взаимная поддержка

Стратегия Win/Win

•  Прекраснодушие или разумная бизнес стратегия?

Заказчики

•  Карьеристы •  Жучилы •  Пофигисты •  Занятые

Воркшоп или как собрать требования за 5 дней

Воркшоп

•  Длительное (от нескольких часов до нескольких дней) мероприятие

•  С заказчиком, заинтересованными лицами, конечными пользователями

•  Альтернатива долгим письменным согласованиям

Концепция проекта

Концепция проекта aka Project Charter, паспорт проекта, план управления проектом и т.д.

(короткий документ) •  Бизнес-цели •  Позиционирование •  Критерии успеха •  Правила взаимодействия •  Заинтересованные лица и участники

Персоны

Федя Финдиректор

Проблемы •  Как снизить процент услуг,

оказываемых «налево»? •  Как обеспечить быстрый

доступ руководства к данным по продажам?

•  Как получить консолидированные отчеты прямо в Cognos?

Ценности •  Минимальные затраты $

на внедрение •  Отсутствие необходимости

проводить тренинг, чтобы не останавливать работу

Тип:  Заказчик  

  CFO    Возраст:  30  лет    Использует:  офисные  приложения,  Cognos    Пользователь  Win7  на  корпоративном  ноутбуке  

Story Mapping

Воркшоп по созданию баклога

Активность  

Действие  

Дополнения  

Innovation Games

Менеджер проекта в

Scrum

•  Учитель, а не менеджер •  Исповедует философию

компании •  Ориентирован на

долгосрочный успех •  Умеет работать в команде •  Умеет организовать работу

команды •  Умеет организовать работу

заказчика •  Разбирается в процессе

Вопросы ?

Асхат Уразбаев

•  askhat@scrumtrek.ru •  Twitter: zibsun •  Skype: askhatu •  ЖЖ: zibsun.livejournal.com