44051

Часть 1 Методология Scrum

Timeline
Жизненный цикл продукта
сокращение времени создания продукта
увеличение количества новых продуктов на рынке

Эстафета
Каскадная модель создание продукта
длительность цикла создания
требования проекта статичны

Схватка
1986 г. , Хиротака Такеучи,
Икуджиро Нонака
1995 г. ,Кен Швабер,
Джеф Сазерленд
*Object-Oriented Programming, Systems, Languages & Applications

Элементы SCRUM

Схема SCRUM
Скрам использует итеративно-инкрементальный подход

Владелец продукта
Владелец-продукта
упорядовачивание бэклогом (StoryMap)

Беклог продукта
Беклог продукта состоит из бизнес-требований, которые обычно оформляются в виде историй пользователей
Уникальный числовой идентификатор истории
Название истории пользователя
Важность
Оценка

Scrum мастер
Новый тип управления в самоорганизовывающей команде
никаких директив
коуч команды
фасилитатор (способствовать)

Команда разработчиков
самоорганизованные. Никто (даже Скрам Мастер) не может указывать Команде, каким образом создавать Инкременты работающей функциональности из Беклога Продукта.
кросс-функциональны, обладают всеми навыками, необходимыми для разработки Инкремента продукта.
Скрам не признает никаких других должностей в Команде Разработки, кроме как Разработчик, невзирая на вид работы, выполняемой человеком; у этого правила нет исключений.
У Команды Разработки нет подкоманд, которые бы выполняли отдельные функции, как, к примеру, команда тестирования или бизнес-анализа.
Отдельные члены Команды Разработки могут владеть специализированными знаниями в различных областях, однако ответственность лежит на всей Команде Разработки в целом.

Размер команды разработчиков
менее трех человек. Снижается производительность.
более 10 человек. Создает слишком большие сложности в управлении эмпирическим процессом.

Планирование спринта
длительность спринта (от двух недель до месяца)
состав спринта (Planning poker)
ежедневный скрам (BurnDown)

Trend of Agile

Agile in the World

Часть 2 Практика использования методологии Scrum

Состав команды
Разработчики, один из которых Лид
Тестировщики
Product-owner
Системный аналитик - на каких этапах и кем подключается?
Системный администратор, архитектор, верстальщики, дизайнеры и иные специалисты - в каких случаях привлекаются?

Планирование времени
Когда планируется спринт?
Аналитика задач
Привлечение аналитика, архитектора
Время между спринтами
Когда планируется тестирование?
Аналитика задач следующего спринта
Привлечение аналитика, архитектора
Написание сценариев
Когда завершается разработка?
1-2 дня на регрессионное тестирование
Демонстрация

User Story

Backlog

Tasks

Agile Board

Burndown

Cumulative Flow

Недостатки методологии
Требуются навыки самоорганизации на очень высоком уровне
Оптимистичные оценки могут превалировать над реальными
Отсутствие планирования могут приводить к рискам в узких местах (нехватки какого-то ресурса)
Внешнее окружение может отрывать команду по консультациям по предыдущим решениям (в том числе багов), срочным доработкам, параллельным проектам
Не понятна критичность нарушения спринта (или отдельных частей его доработок) так как нет критического пути для решения задач

Делим требования на три группы:
Полезные: security testing, configuration guides и т..д.
Выполнимые: репортинги, шаблоны, требования к оформлению кода
Не применимые
Первое превращаем в таски, добавляем в backlog, оцениваем, вздыхаем, что внезапно слегка вырос скоуп, и радуемся, что вытащили это на свет, и теперь примерно понятно, что делать.
Насчет вторых вступаем в переговоры с теми, кто за них отвечает в компании. Можно попробовать найти компромисс: согласовать более удобный шаблон или договориться о более подходящих KPI.
Третье нужно менять - если зафиксированы какие-то жесткие рамки, надо собирать заинтересованные стороны, включая заказчиков, и договариваться на допсоглашение, которое изменит скоуп и сроки на те, что получились в итоге.
Внешняя среда

Начать с высокоуровневого целеполагания — убедиться, что команда, и пользователи понимаем однозначно критерии успеха проекта (не в срок поставить весь скоуп по оговоренной цене, а «пользователям очень надо, чтобы решилась вот эта проблема, для чего мы хотим сделать возможными вот эти use case»).
Показать, как ежедневное честное обновление статуса помогает в достижении глобальных целей проекта.
Убедиться, что не забыты acceptance criteria, early demos, ретроспективы и обратная связь.
“Это неправильная команда, и она делает неправильный Agile”