Онлайн-Книжки » Книги » 👨‍👩‍👧‍👦 Домашняя » Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - Эдвард Скотчер

Читать книгу "Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - Эдвард Скотчер"

345
0

Шрифт:

-
+

Интервал:

-
+

Закладка:

Сделать
1 ... 24 25 26 ... 38
Перейти на страницу:

Все задачи, которые очень сложны, получают оценку 100, чуть менее сложные пользовательские истории – 55, а 34 – те, которые требуют особого внимания.

Начало спринта

Спринт всегда должен начинаться с планирования спринта. Это планирование отличается от планирования релиза и особенно от планирования проекта. Планирование спринта – очень важный шаг, на котором должна присутствовать вся команда. Именно планирование является залогом успеха спринта, но оно же нередко становится причиной неудачи.

Задача команды при планировании – убедиться в том, что она приступает к спринту с четким осознанием того, что его задачей является получение рабочего продукта, который можно предоставить владельцу продукта. Если команде не хватает времени на подготовку, то постарайтесь сделать так, чтобы планирование обязательно включило доработку и «причесывание» как подготовку продукта к реализации. Подобная ситуация далека от идеала, но даже она лучше, чем начинать спринт вслепую, руководствуясь надеждами на лучшее.


Блистательный совет для сохранения времени

Существует немало быстрых и легких способов потерпеть неудачу при планировании:

• Никто не знает, что делать дальше.

• Команда ходит по кругу.

• Все молчат и избегают смотреть друг на друга.

• Участники не доверяют друг другу.

• Не хватает прозрачности и базовой информации.

• Все переживают и злятся.

• Владелец продукта вышел за кофе и не вернулся.

• Команда не выдает результата!

Достойная реализация механик

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

• Логистика. Одна из основных задач Скрам-мастера во время планирования заключается в том, чтобы обеспечивать сотрудничество между участниками. Однако Скрам-мастер также должен позаботиться о вопросах логистики. На первый взгляд эти вопросы малозначительны, однако их важность сложно переоценить; примеры подобных вопросов включают в себя резервирование комнаты, пересылка приглашений Владельцу продукта и команде, проверка того, что пользовательские истории и цель спринта зафиксированы заранее и что Владелец продукта хорошо представляет себе, зачем он встречается с командой. В ходе самой встречи Скрам-мастер сосредоточивается непосредственно на переговорах.

• Продолжительность. Планирование – отличная возможность для прицельного обсуждения деталей проекта и поэтому требует особого внимания. Однако на практике невозможно поддерживать концентрацию участников на протяжении нескольких часов, поэтому с прагматической точки зрения лучше ограничить продолжительность встречи двумя часами. Если встреча подходит к концу прежде, чем команда добивается максимальной успешности, то не беда – в дальнейшем команда всегда сможет наверстать упущенное. На начальных этапах всегда лучше оставлять пространство для маневра и сохранять гибкость, вместо того чтобы чрезмерно фокусироваться на цели и терпеть неудачу.

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

Избегайте личностных конфликтов

Механики безусловно представляют собой важную часть подготовки спринта, однако гораздо большую угрозу представляют собой межличностные отношения. Планирование непосредственно связано с отношениями между членами команды, и всегда есть много моментов, которые могут пойти и, скорее всего, пойдут не так, как надо.



• Потеря интереса. Планирование должно быть быстрым, интересным и мотивирующим. Обычно если команде скучно, это значит, что команда либо не видит пользы в планировании, либо же Скрам-мастер не сумел заинтересовать ее участников. Несколько наиболее распространенных причин включают отсутствие понимания того, что требуется от команды, а также эгоистическое поведение отдельных участников, которые хотят, чтобы оставшиеся участники беспрекословно следовали их указаниям.

• Споры. Здоровое обсуждение – важная часть планирования, но споры исключительно контрпродуктивны и очень отвлекают от насущных задач. Не забывайте, что на этом шаге главное действующее лицо – это владелец продукта, от решений которого зависит то, как будет действовать команда.

• Фрустрация. Дайте команде возможность быть услышанной! Есть мало вещей, которые столь же контрпродуктивны и раздражающи, как игнорирование. Члены команды несут ответственность за реализацию проекта, и без них появление продукта будет невозможным. Поэтому, если любой из них хочет что-то сказать, лучше дать им такую возможность.

• Поиск решений. Если команда разработчиков начинает вдаваться в большое количество деталей при планировании, то существует вероятность того, что они пытаются найти решение. Задача планирования заключается в том, чтобы решить, что команда может выдать в конце спринта. Подробности того, как это сделать, лучше оставить для следующих этапов.

• Давление. Не стоит заставлять команду браться за большее количество работы, чем она может выполнить. Члены команды должны сами определить объемы работ. Это священное право членов команды, и его стоит беречь: если команда постоянно будет браться за слишком масштабные задачи или перетруждаться, последствия будут отрицательными.

Выработка хороших практик

Скрам-мастер несет ответственность за налаживание взаимоотношений между участниками и за формальные составляющие фазы планирования, но выработка хороших практик является коллективной задачей. Скрам-мастер должен стараться предотвратить возникновение плохих практик, но если это произойдет, то команде придется приложить усилия, чтобы преодолеть их. Один человек не может нести ответственность за работу всего коллектива.

1 ... 24 25 26 ... 38
Перейти на страницу:

Внимание!

Сайт сохраняет куки вашего браузера. Вы сможете в любой момент сделать закладку и продолжить прочтение книги «Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - Эдвард Скотчер», после закрытия браузера.

Комментарии и отзывы (0) к книге "Блистательный Agile. Гибкое управление проектами с помощью Agile, Scrum и Kanban - Эдвард Скотчер"