Книга Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - Эдвард Скотчер
Шрифт:
Интервал:
Закладка:
Блистательная мысль
Необновляющийся журнал требований продукта – однозначный признак того, что что-то идет не так; изменения естественны и более чем ожидаемы. Но и другая крайность – когда журнал обновляется излишне часто – тоже указывает на проблемы.
Блистательная мысль
Когда вы обновляете статус выполненных в спринте работ, реальный прогресс будут отображать только полностью завершенные задачи. Те, что закончены на 25 %, 50 % или 75 %, в данном случае не учитываются.
Особенно будьте внимательны в случае задач, которые завершены на 99 %.
Переход на Agile похож на обучение вождению. Пока вы на пассажирском сиденье, все выглядит довольно просто; если вникнуть в основы, главные принципы тоже будут для вас ясны. Но только сумасшедший запрыгнет за руль и устремится на улицу с интенсивным движением после того, как прочтет несколько статей в интернете. Разумный человек сначала как минимум разберется с теорией. Эта книга – как правила дорожного движения.
Прежде чем применять Скрам, нужно не только разобраться в его основах, но и понять, как именно все элементы методологии работают вместе. Можно встретить так называемые Скрам-команды, работающие без каких-то ключевых ролей или артефактов; некоторым из них это даже вполне удается. Но для стабильного успеха необходимо предварительно всесторонне изучить теорию. Не забывайте: причина номер один всех аварий на дорогах – неопытные водители.
Блистательный итог
• Скрам популярен, потому что он работает. Не думайте, что вы можете игнорировать важные составляющие и все еще добиваться нужного результата.
• Вам нужны четкое видение и журнал требований проекта; убедитесь в том, что только Владелец продукта определяет их содержание и расставляет приоритеты.
• Выпускайте продукт с бизнес-ценностью в конце каждого спринта. Единственное мерило успеха – работающий продукт.
• Разрабатывайте рабочие практики, требования, критерии успеха как одна команда. В идеале эта команда должна состоять из специалистов различных профилей.
• Избегайте чрезмерного давления на команду разработки продукта. Команда, работающая в щадящем режиме, выдает лучшие результаты, чем команда, находящаяся в постоянном напряжении.
• Лучший способ начать – это просто начать!
Скрам – отличный инструмент, но все же это лишь инструмент. Все его достоинства проявляются тогда, когда он в работе. И как с любым инструментом, чем больше вы им пользуетесь, тем более искусно его применяете. Мастерство приходит с практикой, и Скрам очень соответствует этому утверждению – ведь он ориентирован на постоянное повторение циклов.
Доведение до совершенства не способствует прогрессу, так что не стоит планировать применение Скрама до мелочей еще до того, как вы начали его использовать. Намного лучше изменять тактику на ходу. Вы можете столкнуться с чем-то, что кажется не совсем очевидным, и придется подстраиваться уже в процессе. Или не совсем правильно будет составлена команда, или скептично настроенные коллеги будут излишне мешать. Со временем большие проблемы будут решены, и на их место придут меньшие, но решаемые куда легче.
Если вы не будете привносить свои изменения, пусть даже небольшие, то вы не поняли сути. Случается так, что желание менять что-то отступает, сменяясь готовностью принимать неудобный статус-кво. Иногда боязнь раскачивать лодку препятствует даже незначительным изменениям. Иногда, что может показаться абсурдным, люди даже считают текущее положение дел близким к идеальному!
Примите цикл жизни Скрама, но не идите ради этого на компромиссы или отказ от изменений. С одной стороны, этапы Скрама очень легко предсказать, так как в теории они остаются одними и теми же, но в то же время на практике они всегда очень сильно различаются.
Нет! Не пробуй. Сделай.
Часто люди, не понимающие гибкого способа мышления, считают, что в Agile не предполагается никакого планирования. Но это не касается ни гибких подходов в целом, ни Скрама в частности. Планирование имеет первостепенное значение, и это справедливо не для единичных случаев, а постоянно. Скрам-мастер и владелец продукта определяют, что нужно сделать, а что реализовать будет невозможно. Все эти обсуждения отражены в журнале требований продукта. Он является самым важным артефактом, основой работы над любым проектом. Часто наполнение журнала напрямую отражает то, как идет работа над проектом, и наоборот. Даже самые лучшие команды не смогут добиться впечатляющих результатов без журнала требований продукта, и он постоянно пересматривается и обновляется в зависимости от актуальной информации.
Блистательная мысль
Девяносто девять из ста Скрам-команд начинают свой первый спринт на излишне оптимистичной ноте и не особенно уделяют внимание планированию. Либо пользовательские истории не до конца проработаны, либо не сформирован план действий, либо не хватает критериев принятия – а то и все вместе. Девять из десяти команд повторят те же ошибки и на втором спринте.
Избегайте такого.
Раньше доработку или уточнение журнала называли «причесыванием» (grooming) по аналогии с причесыванием волос, но со временем термин сменился по очевидным причинам. Кто-то продолжает использовать это старое название, но вне зависимости от этого сама практика поддержания журнала требований продукта в актуальном состоянии только положительно сказывается на бизнесе и впоследствии на конечном пользователе.
Окончательное решение насчет распределения приоритета задач принимает владелец продукта, поэтому, так как это творческий процесс, точные рекомендации тут дать сложно. Не пытайтесь расположить все в идеальном порядке. Куда важнее поддерживать актуальность бизнес-требований, например пользовательских историй. Встречи с обсуждением всех доработок журнала и подготовки пользовательских историй для спринта должны проходить регулярно, и в идеале на них должны присутствовать по одному представителю каждой дисциплины из команды.
Некоторые команды просматривают журнал на предмет возможных обновлений каждый день, другие – намного реже. Но отсутствие доработки, без сомнений, приведет к проблемам на ближайшем спринте. Постоянная работа над журналом обязательно принесет свои плоды, но тут необходимо достичь определенного равновесия. Некоторые спринты будут посвящены реализации необходимых функций, а не тому, что полагают важным на данный момент бизнесмены.
Блистательная мысль
Владелец продукта отвечает за качество пользовательских историй и состояние журнала требований продукта. Если он делает свою работу хорошо, планирование спринта пройдет гладко. Если нет, то в ходе встречи по планированию скрипта постоянно нужно будет отвлекаться на уточнения.
