Scrum Master (курс) : Лекция 9

Цель

Понять зачем и как проводится sprint planning

Тезисы

Sprint Planning

• C него начинается спринт
• Длится до 4 часов для 1-месячного спринта
• Участвуют как минимум ПО и DevTeam
• SM может организовать и поддерживать митинг

Что должно произойти на во время планирования.

Команда и ПО совместно должны установить цели спринта.

Что такое цели спринта? Команда должна иметь четкое понимание как именно заказчик станет оценивать спринт на предмет “успешно” или “не успешно”.

Какие именно операции должны быть доступны? Кто/Зачем/Как ими воспользуется? Кто оценить? Как оценит (прямо acceptance сценарий!!!).

Какие свойства будут у продукта (например скорость, надежность), как будут проходить замеры и с чем будет сравниваться.

Важно - “не декларации благих намерений” - например “мы обеспечим защиту от DOS атаки”, а именно “устойчивая работа системы видимая на странице health monitoring в условиях когда происходит атака на отказ в обслуживании с ботнета размером 1000 узлов с трафиком не менее чем 10,000 в секунду.

Проверочный вопрос: как именно мы продемонстрируем успешность скрама, прямо озвучить сценарий.

Важно - если это все на что хватит времени - это уже хорошо. Понимание цели самое важное, это именно то, зачем тут сидит ПО. Остальное квалифицированные разработчики скорее сделают, чем нет.

Если после определения цели осталось время - можно сформировать spring log.

Бэклог и Sprint Planning

Для того чтобы это было возможно надо:

• Чтобы общий бэклог был
• Чтобы он был упорядочен так, что можно легко обнаружить PBI с максимальной ценностью
• Чтобы PBI были меньше размером чем спринт

ВАЖНО:

Если команда вынуждена делить или оценивать PBI прямо во время планирования - это очень плохо. Это значит мы ставим эксперимент не о том, как инкремент увеличивает ценность клиента, а о том как команда ловко играется с цифирьками. На самом деле разбиение PBI, их оценка и планирование должны происходить во время backlog refinement sessions (не менее 10% времени команды!!!)

PBI в данном случае не оцениваются, а просто набираются в спринтлог.

Моё мнение - игрища с velocity и story point - это полный булшит, можно с тем же успехом взять цифры из прогноза погоды на завтра. Это был буллшит в классическом подходе и это остается булшит в сейчас.

Есть хороший метод описанный в “Scrum & XP from the trenches” который называется “жопа говорит”.

Берется первая история и спрашиваем - что ваша жопа говорит? Если жопа говорит точно сделаем - добавляем. Берем вторую - повторяем вопрос. И так до тех пор, пока не дойдем до точки “жопа мнется”. Потом берем ОДНУ историю на которой жопа мнется и на этом отсекаем sprint backlog. Поскольку жопа девелопера это именно то что страдает если не сделать - то у опытного девелопера - это очень точный прибор.

Почему берем первую на которую жопа мнется? А чтобы поддерживать смелость в команде.

Другой вариант который я тоже часто использую это planning poker с 3 картами - 1 (можно сделать за день), TFB (too fucking big) и NFC (no fucking clue). "1" включаются в работу, "TFB" уходять на декомпозицию и "NFC" на уточнение.

Важные замечания

1) Почему цель спринта важна, а spring log не очень. a) Потому что успех будет оцениваться будет именно по цели спринта и для вовлечения заказчика важная именно цель. б) Потому что spring log МОЖЕТ меняться, например в силу вскрывшихся обстоятельств или потому что попросил заказчик. Хотя команда НЕ ОБЯЗАНА менять spring log, никто не говорит что она НЕ МОЖЕТ. Наоборот, это будет уважение к заказчику и поддержка практики Agile “мы приветствуем изменения на любом этапе”. Понятно что item не должен просто добавляться, команда вполне может поменять одну работу на другую, причем чем ближе к концу спринта, тем “дороже” изменение.

2)Technical dept - не ОТДЕЛЬНАЯ тема обсуждаемая в дополнение к целям спринта, а должен добавляться в product backlog и приоритизировать так же как все остальные задачи. Еще - technical debt это то, что именно МЕШАЕТ разработке, а не просто не нравится, т.е. устранение technical debt должно улучшать TTM или %C/A

3) Sprint 0.

В Scrum нет sprint 0, даже самый первый sprint должен иметь инспектируемую и прозрачную цель. Например наполнить изначально PB, провести его refinement, выработать архитектуру (в правильном понимании, как набор типовых решений-паттернов для типовых задач).

Чек-листы в помощь SM

Sprint Planning

[ ] Спринт начинается со sprint planning

[ ] На sprint planning присуствует вся команда и PO

[ ] Product Backlog уже упорядочен ДО начала planning и оценен разработчиками

[ ] Первым делом определяется кто именно и как именно будет оценивать результаты спринта

[ ] Эта информация документируется и делается видимой для всей команды

[ ] Происходит отбор PBI которые позволят достигнуть целей спринта

[ ] Команда не набирает больше PBI чем может сделать

[ ] Команда набирает достаточно PBI чтобы обеспечить оптимальный прирост ценности

Product Backlog Refinement

[ ] Команда участвует в работе на backlog не менее 10% времени спринта

[ ] В рамках Backlog Refinement PO помогает команде понять для кого и зачем нужен PBI

[ ] Неясности в целях PBI выделяются в Requirements/Transpancy Spikes

[ ] Команда вырабатывает понимание как именно будет делать PBI и сколько ресурсов потребуется

[ ] Технические неястности выделяются в Technology Spikes

[ ] Команда следит за тем, чтобы между PBI не было слишком много зависимостей (что может говорить что это задачи, а не business-items)