Download as PDF, PPTX
Uploaded byNikita Filippov
Scrum в Заказной разработке
Документ обсуждает применение Scrum в заказной разработке и выявляет проблемы, связанные с изменениями требований, согласованием и приемкой продукта. Основные аспекты включают использование итеративной разработки, оценку функциональности и управление изменениями через баклог. Также описаны роли участников Scrum и их ответственность для успешного достижения проектных целей.
More Related Content
Similar to Scrum в Заказной разработке
Scrum в Заказной разработке
- 1. PM Labs Омск, 22/10/2010 Scrumв заказной разработке Асхат Уразбаев Тренер и консультант по гибким методологиям
- 2. Асхат Уразбаев • ScrumTrek • Agile Coach • Управляющий партнер • В прошлом • Программист, менеджер проектов, методолог
- 3.
- 4.
- 5. Требования меняются ― Согласованиетакого контракта обычно занимает у нас около четырех месяцев. За это время со 100% вероятностью мы передумаем или вы прекратите использовать продукт. Может быть мы сэкономим время, объявим о провале и начнем обвинять друг друга? ― Я сдался еще до того, как отдал вам контракт
- 6.
- 7.
- 8.
- 9.
- 10. Заказчик меняет требования • Логичный вывод – требования зафиксировать
- 11.
- 12. Контрактные обязательства фиксируют… • Объемработ • Сумму контракта • Дату поставки
- 13. Проблема точки невозврата • Заказчик боится принимать окончательное решение (подписывать требования)
- 14. Заказчик • Заказчик –наемный менеджер • Если что – он тоже виноват Согласования, утверждения, совещания, рабочие группы и другие методы избегания ответственности
- 15. Сбор требований Разработка Тестирование Приемка у заказчика ПОЛЕЗНОЕ ВРЕМЯ Сроки реализации растут
- 16.
- 17. Полезное время итеративной разработки ПОЛЕЗНОЕВРЕМЯ Разработка требований Кодирование и тестирование Приемка
- 18. Оценка в Agile • Команда оценивает каждую фичу – Например, в условных единицах (story points) • Известна эмпирическая усредненная скорость команды (сумма условных единиц в итерацию)
- 19. Баклог – инструмент управлениятребованиями Функциональность Оценка
- 20. Баклог как способ управлениятребованиями • Заказчик может поменять любую несделанную фичу на эквивалентную по размерам • Фичи оценивает вендор • Заказчик может добавить или удалить фичу. • Заказчик может поменять порядок несделанных фич • В любой момент заказчик может принять решение остановить разработку • Заказчик формально принимает сделанные фичи
- 21. Фиксированный объем работ Фиксированный бюджет
- 22.
- 23.
- 24. Экономим трудозатраты Без автотестов С автотестами Поддержка (баги) Автотесты Функциональность
- 25.
- 27. Как вы делаетепредварительную оценку?
- 28.
- 29. Учет рисков • Традиционныйподход: накинем на оценку сверху: – Изменения требований – Проблемы при сдаче – Труднореализуемые Мегафичи • Scrum – Оценка более адвекватна (при условии согласовании с заказчиком правил Scrum)
- 30. Проблема приемки • Чтоесли заказчик будет менять фичи по ходу итерации или не принимать в конце итерации?
- 31. Приемочные тесты • Создаватьприемочные тесты • Приемочные тесты согласовывать с заказчиком до начала планирования итерации
- 32. Создание требований Демонстрация Приемка Ретроспектива Декомпозиция Оценка Таймбоксинг Фичи Фичи + приемочные тесты Фичи + задачи с оценкой Команда Команда Product Owner Команда
- 33. В сухом остатке • Работаем короткими итерациями • Сдаем заказчику результаты в конце каждой итерации • Требования фиксируются на следующую итерацию (например, в виде приемочных тестов) • Используем баклог для управления изменениями
- 34. Роли в Scrum: ScrumMaster Поддерживает«здоровье» команды, помогает команде стать самоорганизующейся Ответственность: • Фасилитирует (модерирует) митинги • Поддерживает прозрачность, доверие и взаимную ответственность • Устраняет внешние препятсвия • Отвечает за процесс
- 35. Роли в Scrum: TEAM • Самоорганизованная / самоуправляемая - Колективно принимают решения - Сами координируют и организуют свою работу • Кроссфункциональная
- 36. Роли в Scrum: ProductOwner • Задача: Добиться целей проекта • Ответственность: • Представляет интересы заказчика и заинтересованных лиц • Формирует и координирует Баклог • Отвечает за Концепцию • Управляет датой релиза и его содержанием
- 37.
- 38. Цель– максимизировать свою прибыль? • Даже если результат не нужен заказчику
- 39. Цель – максимальная удовлетворенностьзаказчика?
- 40. Сервис, который хочет заказчик Сервис, который нужен заказчику
- 41. Цель – максимальная ценностьбизнесу заказчика
- 42. Партнерство • Общие цели • Взаимная поддержка
- 43. Стратегия Win/Win • Прекраснодушиеили разумная бизнес стратегия?
- 44. Заказчики • Карьеристы • Жучилы • Пофигисты • Занятые
- 45. Воркшоп или как собратьтребования за 5 дней
- 46. Воркшоп • Длительное (отнескольких часов до нескольких дней) мероприятие • С заказчиком, заинтересованными лицами, конечными пользователями • Альтернатива долгим письменным согласованиям
- 47.
- 48. Концепция проекта aka ProjectCharter, паспорт проекта, план управления проектом и т.д. (короткий документ) • Бизнес-цели • Позиционирование • Критерии успеха • Правила взаимодействия • Заинтересованные лица и участники
- 49.
- 50. Федя Финдиректор Проблемы • Какснизить процент услуг, оказываемых «налево»? • Как обеспечить быстрый доступ руководства к данным по продажам? • Как получить консолидированные отчеты прямо в Cognos? Ценности • Минимальные затраты $ на внедрение • Отсутствие необходимости проводить тренинг, чтобы не останавливать работу Тип: Заказчик CFO Возраст: 30 лет Использует: офисные приложения, Cognos Пользователь Win7 на корпоративном ноутбуке
- 51.
- 52. Воркшоп по созданиюбаклога Активность Действие Дополнения
- 53.
- 54. Менеджер проекта в Scrum • Учитель,а не менеджер • Исповедует философию компании • Ориентирован на долгосрочный успех • Умеет работать в команде • Умеет организовать работу команды • Умеет организовать работу заказчика • Разбирается в процессе
- 55.
- 56. Асхат Уразбаев • askhat@scrumtrek.ru • Twitter: zibsun • Skype: askhatu • ЖЖ: zibsun.livejournal.com