scrum в заказной разработке
DESCRIPTION
презентация доклада на Expert Labs в Омске 22 октября 2010TRANSCRIPT
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
• Учитель, а не менеджер • Исповедует философию
компании • Ориентирован на
долгосрочный успех • Умеет работать в команде • Умеет организовать работу
команды • Умеет организовать работу
заказчика • Разбирается в процессе
Вопросы ?
