Это перевод статьи Барри Оверима, которая разрушает самый радикальный миф о Scrum: убеждение в том, что в этом фреймворке нет далеко идущих планов и планирования.
Этот миф проявляется по-разному.
Один из примеров — scrum-команда, которая ни в каком виде не принимает слово «план» и «планирование», с гордостью заявляя: «Мы не создаем планы в Scrum».
Другим примером является scrum-мастер, который не даёт команде даже подумать, что может быть в будущих спринтах.
Ещё один пример — убеждение, что команды бесцельно создают продукты, не имея цели или ориентиров.
В Scrum Guide содержится 19 упоминаний слова «планирование» и 9 раз слова «план». Ни одно из этих появлений не имеет значения «ты не должен». На самом деле, после прочтение гайда ясно понимаешь, что в Scrum много планирования, а во время разработки даётся множество прогнозов:
- во время события «Планирование спринта» команда закладывает работу, которая будет выполняться в следующем спринте. Полученный план фиксируется в бэклоге и цели спринта.
- во время ежедневного стендапа команда планирует работу в течение следующего дня. Как они будут работать? Над чем? Какие вопросы необходимо решить? Полученный план отражен в том, как команда распределяет работу. На scrum-доске это визуализируется с помощью переноса карточки в графу "In Progress" и подобную.
- во время обзора спринта команда и стейкхолдеры проверяют работу, которая была проделана за последний спринт. Исходя из инкремента продукта, участники совместно отвечают на вопрос «Что делать дальше?» Этот план фиксируется в обновлении бэклога.
- во время ретроспективы команда проверяет, как участники работали вместе. Основываясь на полученных результатах, команда планирует потенциальные улучшения и то, как их достичь. Этот план отражен в командных договорённостях и карточках, которые попадут в следующий спринт.
- владелец продукта несёт ответственность за ведение бэклога. Приоритеты расставляются с учётом того, насколько элемент бэклога добавляет ценность продукту. Те функции, которые требуют меньше усилий, но являются более приоритетными для бизнеса, быстрее попадут в разработку. Они находятся на вершине списка всех задач по продукту. Бэклог обычно открыт для всех стейкхолдеров. Он является планом ожидаемых работ.
- команда разработчиков планирует, как наилучшим образом предоставлять высококачественное, работающее программное обеспечение. Они делают это, учитывая технологии, инфраструктуру, архитектуру, дизайн, производительность и удобство использования. Это обязательно требует, чтобы команда предвидела вероятное (ближайшее) будущее. Полученный в результате план отражен в бэклоге спринта, DoD и плане релиза.
Этот довольно длинный список примеров планирования в Scrum. Он подчеркивает ряд выводов:
В Scrum планирование не является обязанностью отдельного человека. Владелец продукта, scrum-мастер и команда разработчиков вовлечены в планирование. Но они делают это с разных сторон. Вот почему в Scrum нет места менеджерам проектов. Традиционно роль менеджера заключается в планировании работы, процесса, бюджета и исполнения. Вместо этого Scrum признает, что разработка — это сложная задача, поэтому планирование должно быть совместным усилием всех участников. Только используя коллективные знания, опыт и креативность людей, выполняющих работу, мы сможем работать эффективнее.
В Scrum планирование — совместный процесс
Всякий раз, когда мы говорим о планах в Scrum, мы больше имеем в виду «общее понимание», а не «документы». Например, план в результате стендапа нигде не отражается как документ, если этого не хочет сама команда. Максимум, это может быть визуализировано на доске. То же самое касается других планов, которые мы упомянули. Цель планов в Scrum — привлечь всех к единому пониманию, а не делиться этими знаниями в форме документа.
Scrum выступает за общее понимание, а не документы.
Scrum-команды думают о будущем проекта. Хотя они делают это с полным осознанием того, что (даже в ближайшем) будущем очень трудно что-то предсказать наверняка. Работа строится так, чтобы предвидеть и быстро реагировать на то, что может произойти. Чем дальше и непонятнее элемент бэклога, тем меньше времени команды тратят на детализацию плана.
Разработка продукта — крайне непредсказуемый процесс. Это означает, что он требует много планирования и «перепланирования». Некоторые до сих пор думают, что в Scrum много ненужных событий, но они являются минимальными точками в спринте, когда проводится планирование.
События Scrum — это минимальные точки, когда происходит планирование.
Scrum — это простая, но достаточная структура для комплексной поставки продукта. Фреймворк описывает только минимальные границы. Хотя Scrum не описывает, насколько подробно должно быть сделано планирование продукта, это не означает, что в Scrum нет планирования.
Первые соображения исходят из видения компании и бизнес-стратегии. Они говорят владельцу продукта о том, какой продукт нужен, какие функции должны быть и как он будет создавать ценность для организации. Поскольку мы не поставляем продукт за один раз, владельцу продукта нужно подумать о стратегии продукта: в каком (приблизительном) порядке функции должны быть предоставлены заинтересованным сторонам, чтобы как можно скорее получить ценность?
Если Scrum-команда не может поставлять работающее программное обеспечение в конце каждого спринта, то владелец делает дорожную карту или план релиза. Они нужны для стейколдеров, чтобы те имели представление о будущем проекта.
Порядок и содержание бэклога продукта являются результатом планирования. Это постоянная деятельность, которая продолжается, пока продукт разрабатывается.
Давайте еще раз подчеркнём, что мы не говорим о здоровенных документах, когда говорим о планах. У большинства scrum-команд есть планы релиза, которые состоят из пары дюжин наклеек на стене. То же самое касается видения продукта, дорожных карт и стратегий продукта. Часто хорошая дорожная карта — это не более чем последовательность целей для будущих спринтов. В сложной среде разработки продукта, где изменения непрерывны, детальные планы будут растратой. Поэтому мы должны тратить на них как можно меньше времени.
Советы
- Не пропускайте второй вопрос на планировании спринта — «Как?» Именно здесь команда создает план того, как она будет выполнять работу из бэклога спринта.
- Используйте «доски видения продукта» Романа Пихлера как простой способ продумать и отразить концепцию продукта. Нам нравится заполнять холст всей командой (часто с участием заинтересованных сторон).
- При работе с отделами или командами, которым требуются планы, например, маркетинговый план или план тестирования, не игнорируйте их, прикрываясь Scrum. Помогите им понять, что разработка продукта крайне непредсказуема, и постарайтесь вместе найти самый простой способ планировать заранее.
В этом посте мы разрушили миф о том, что в Scrum нет планирования и нет планов. Как выясняется, здесь много планирования. Различные scrum-события также генерируют целый ряд планов, выраженных в разных артефактах. Планы, которые мы создаем в Scrum, отличаются от планов, которые мы традиционно понимаем. Таким образом, это не здоровенные документы, которые предоставляют подробные, пошаговые инструкции, а наброски для общего понимания.
