Документ посвящен теории и практике методологии разработки Scrum, описывая её принципы, процессы и артефакты. Основное внимание уделяется итеративному подходу, который позволяет гибко управлять изменяющимися требованиями заказчика и минимизировать риски. Также рассматриваются проблемы, возникающие при использовании традиционных методологий, таких как 'водопад', и подчеркивается важность эффективного взаимодействия между командой и заказчиком.

1. Теория и практика методологии
разработки Scrum
Владислав Богатырёв

2. Разработка продукта это не только код
ТЗ на функционал и информационная архитектура
что сделать
Экранные формы
как выглядит
Начало
Информационная структура
проекта
как организовано внутри
Поверхностное проектирование
Ньюансы
аудитория, бизнес-процессы, наследование старых
технологий/контента, etc
Стоимость и сроки

3. Разработка продукта это не только код
Проектирование
Собственно, разработка
Документация
Дизайн
Середина
Верстка
Тестирование
проекта
Промежуточный контроль результата

4. Разработка продукта это не только код.
Приемка и доводка
Внедрение Конец
Инструкции
Поддержка проекта

5. Этапы разработки

6. Большие и средние проекты это вам не
малые
Малые Средние и большие
Заказчик это организация. Решения принимает
Заказчик это человек
комитет (долго и мучительно) или вечно занятый биг
Над проектом работает обычно 1-2
босс.
программиста, одинаковое понимание
Могут возникать проблемы с тем, что контактное лицо не
системы достигается легко, устно.
имеет полномочий или не хочет брать ответсвенность, а
Техзадание делается быстро
биг босс недоступен.
Многие стадии пропускаются или не
Большой объем предварительной работы по описанию
осознаются
системы, много коммуникации с заказчиком. Создание
Стадии легкие и быстрые,
ТЗ может тянуться месяцами.
последовательность не критична
Неправильная последовательность стадий или
Если что то забыли, можно быстро сделать
пропущенные/забытые стадии блокируют другие на
Изменения в ТЗ и переделки дешевы
недели и месяцы, затягивается весь проект
Ошибки архитектуры незаметны или
Изменения в ТЗ дороги, поиск компромисса тяжелый
дешевы
Архитектурные ошибки могут быть фатальны
Обычно затягивание сроков не так критично
Затягивание сроков чревато потерями прибыли для
для заказчика и разработчика
заказчика/гневом начальства, а для разработчика
Внедрение простое, часто делается
голодной смертью
заказчиком.
Над проектом работает команда, которой нужно единое
Приемка делается быстро
понимание системы
Практически любые проблемы могут быть
Сверхурочная работа не помогает
компенсированы сверхурочной работой.
Риск для вашей репутации и кошелька, ценность
Не получилось, ну и ладно.
заказчика.
От 1й встречи до оплаты недели/пара
От 1й встречи до оплаты месяцы
месяцев

7. Homo Заказчикус
Не знает точно чего хочет и как оно должно выглядеть
У него нет времени описывать будущую систему
Постоянно меняет требования
Обычно половину требований держит в тайне, чтобы потом
предъявить их на этапе сдачи
Хочет заранее знать сколько это стоит и сколько займет
времени
Хочет платить за готовый результат

8. Методология разработки "Водопад"
В классическом водопаде, следующие фазы идут примерно в таком
порядке:
1. Определение требований
2. Проектирование
3. Реализация
4. Интеграция
5. Тестирование и отладка (также «верификация»)
6. Инсталляция
7. Поддержка

9. Методология разработки "Водопад": есть
недостатки
Долго - пока не сформулированы все требования, а система
не спроектирована, работа не ведется.
Нельзя менять требования. (заказчик их все равно вынужден
менять и меняет, вероятность чего прямопропорциональна
длительности проекта)
Длительный и бюрократизированный подготовительный этап
(отдельно его заказчик не хочет оплачивать, не всегда проект
начинается, по крайней мере, с вами)
И заказчик, и разработчик заложники собственных планов.
Менять планы трудоемко.
...
Не решает проблем больших и средних проектов

10. Методология разработки "Scrum"
Итеративная и гибкая(agile) методология разработки.
Scrum — это набор принципов, на которых строится процесс
разработки, позволяющий в жёстко фиксированные небольшие
промежутки времени (спринты от 2 до 4 недель) предоставлять
конечному пользователю работающее ПО с новыми возможностями,
для которых определён наибольший приоритет.

11. Методология разработки "Scrum"
Использует артефакты:
Pruduct Backlog - содержит функциональные блоки(истории) для
реализации в проекте с приоритетами. Формируется всеми
участниками процесса. Приоритеты ставит заказчик.
Sprint Backlog - содержит уточненные задачи к реализации в
итерации (спринте), определяются заказчиком и командой.
Burndown Chart - индикатор прогресса, вместо диаграмм Ганнта

12. Методология разработки "Scrum"
История - задача на создание функционально завершенного, несущего пользу,
компонета системы или фичи. Содержит минимально необходимые для успешной
сдачи описание и "how to demo", и приблизительную оценку трудоемкости.
Приоритет историй определяет заказчик, принимая во внимание приблизительную
оценку команды трудоемкости
Спринт - итеративный, фиксированный период работы команды (2 - 4 недели) по
реализации взятых в работу историй. В период спринта, ТЗ на взятые в работу
истории замораживается. Спринт завершается внедрением реализованной истории в
текущую сборку системы.
Команда сама определяет, когда готова к следующему спринту
Команда сама определяет истории, которые готова взять в работу, руководствуясь
приоритетом.
Заказчик уточняет желаемый результат по заявленным к реализации историям,
формируя sprint backlog
Вместо PM Scrum-мастер. Следит за соблюдением методологии, но не управляет
вручную командой. Команда управляет собой сама

13. Методология разработки "Scrum": Решает
проблемы больших и средних проектов
Быстрый старт.
Поскольку разработка итеративна, перед каждой итерацией создается только
необходимый набор документации.
Поскольку разработка итеративна, а итерации коротки, заказчик может менять
функциональные требования к еще не реализованным историям.
Поскольку Product Backlog формируется динамически, заказчик может
добавлять истории по изменению реализованного функционала.
Поставка готового продукта происходит часто, что быстро выявляет проблемы
и минимизирует риски.
Частые итерации позволяют отказаться от ресурсоемких и сковывающих
календарных планов
Коммуникация с заказчиком более частая, более короткая, более
продуктивная. Всегда обсуждается то, что существенно в данный момент.
Любые ошибки и срывы сроков локальны и поэтому обходятся на порядок
дешевле и менее критичны. Могут быть исправлены сверхурочной работой.
Частые поставки снижают риск срыва проекта на порядок.
Заказчик совершает оплаты часто

14. О чем молчит "Scrum"
Как получить Product Backlog с историями, которые пойдут в
работу
Когда проектировать
Не говорит о обеспечении разработчиков всем необходимым
для спринта: достаточно точным ТЗ и дизайном
Когда делать приблизительные оценки историй
Что делать с ошибками
А как же поддержка внедренного функционала

15. О чем молчит "Scrum": нулевая
итерация и трек проектирования

16. О чем молчит "Scrum": нулевая итерация
Проектировщикам
Необходима для создания
приблизительной, высокоуровневой картины будущей
системы с точки зрения пользователя
Необходимо определить последовательность реализации
историй на несколько историй вперед.
Разработчикам
Необходима для минимально достаточного проектирования,
нужного для определения и оценки историй.
Прежде чем взять в работу 1ю историю, необходымы знания о
"стыковке" историй между собой

17. О чем молчит "Scrum": параллельный трек
проектирования
Идет впереди трека разработки хотя бы на одну итерацию
Высокая нагрузка на команду проектировщиков:
много взаимодействия с заказчиком,
консультации разработчиков по их текущей итерации
тестирование результата разработчиков по прошлой итерации
и его сдача заказчику
создание ТЗ, use case, прототипов и дизайна, etc для
следующей итерации разработчиков
Высокая нагрузка определяет необходимости:
делегирования проектирования реализации разработчикам.
быстрого прототипирования

18. Scrum good practicies
Проектировщикам:
Детализируйте прототипы итеративно, по мере назревающей
необходимости и доступных ресурсов. Если времени нет/мало,
лучше вначале решать задачи, блокирующие разработку.
Когда нет времени, прототипируйте на бумаге. Делайте быстрее и
проще, все что можете, без излишней детализации.
Используйте прототипы в качестве ТЗ, всегда, когда это
возможно.

19. Scrum good practicies
Разработчикам:
Управляйте конфигурацией и качеством поставок в угоду срокам.
Лучше не сделать фичи или сделать наполовину, или по
простому, чем сорвать дату поставки.
Неэффективный/некрасивый код/архитектуру можно рефакторить
в следующей итерации, если это оправдано.
Используйте магию проектирования гибких систем, дабы их
развитие не определялось их архитектурой. Откладывайте
реализацию определяющих архитектурное развитие компонент,
на сколько возможно. Уделяйте максимум внимания при
разработке фундаментальных компонент, которые не
поддадутся изменениям в будущем.

20. Резюме
Большие и средние проекты это вам не маленькие
Осознанно и правильно выбранная методология разработки это
необходимое условие успеха проекта
Scrum это гибкость и скорость
В эффективном Scrum, параллельно разработке существует трек
проектировщиков, идущий на опережение разработчиков на
несколько итераций.
В Scrum и разработчикам, и проектировщикам, и заказчику нужна
нулевая итерация.
Практикуйте хорошую практику: правильные шаги в правильной
последовательностью с правильной детализацией.

21. Теория и практика методологии
разработки Scrum
Владислав Богатырёв