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

1,153 views

Published on

Почему Srum выгоден в аутсорсе, как продать заказчику идею, на чем фокусироваться при работе с заказчиком?

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

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

×