Scrum и XP: заметки с передовой

Чаще всего product owner начинает планирование следующего спринта с описания основных целей и наиболее значимых историй. После этого команда производит оценку трудозатрат всех user story, начиная с самой важной. В процессе у команды возникают очень важные вопросы по поводу объёма предстоящих работ. Например, «Подразумевает ли история „удалить пользователя“ удаление всех его незавершённых транзакций?». Иногда ответ на этот вопрос будет большим сюрпризом для команды и потребует пересмотра всех оценок для данной user story.

В некоторых случаях время, которое понадобится на выполнение user story, не будет совпадать с ожиданиями product owner’а. Следовательно, он захочет пересмотреть приоритет для story или изменить объём работы. Это, в свою очередь, заставит команду выполнить переоценку и так далее, и так далее.

Такая взаимная зависимость является основой Scrum'а, да, в принципе, и всего Agile’а.

Но что если product owner всё-таки упорно отказывается выделить пару часов на планирование спринта? В таком случае я обычно пытаюсь последовательно применить следующие стратегии:

• Попытайтесь донести до product owner’а, почему его участие крайне важно — а вдруг до него дойдёт.

• Попробуйте найти в своих рядах добровольца, который смог бы стать представителем product owner’а. Скажите своему product owner’у: «У вас нет времени на планирование, Джеф будет исполнять вашу роль. У него будут все полномочия на изменение приоритетов и объёмов работ. Советую вам обсудить с ним как можно больше нюансов до начала планирования. Если вы против Джефа, тогда выберите кого-то другого, но только с условием, что он будет присутствовать на планировании от начала до конца».

• Попробуйте убедить менеджмент найти вам нового product owner’а.

• Отложите начало спринта до того момента, пока у product owner’а не появится свободная минутка для совместного планирования. А пока не берите на себя никаких новых обязательств. Пусть в это время ваша команда займётся любой другой полезной работой.

Почему качество не обсуждается

В предыдущей главе я намеренно не показал на треугольнике четвертую переменную — качество.

Попытаюсь объяснить разницу между внутренним качеством и внешним качеством.

• Внешнее качество — это то, как пользователи воспринимают систему. Медленный и не интуитивный пользовательский интерфейс — это пример плохого внешнего качества.

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

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

Я рассматриваю внешнее качество, как часть общего объема работ. Ведь с точки зрения бизнеса бывает весьма целесообразно как можно быстрее выпустить версию системы с немного корявым и медленным пользовательским интерфейсом, и лишь потом подготовить версию с доработками и исправлениями. Здесь право выбора должно оставаться за product owner'ом, так как именно он отвечает за определение объёма работ. И напротив — внутреннее качество не может быть предметом дискуссии. Команда постоянно должна следить за качеством системы, поэтому оно попросту не обсуждается. Никогда.

(Ну ладно, почти никогда)

Так как же нам различать задачи, связанные с внутренним и внешним качеством?

Представьте, что product owner говорит: «Хорошо ребята, я понимаю, почему вы оценили эту задачу в 6 story point’а, но я уверен, что, если вы чуточку помозгуете, то сможете по-быстрому „залатать“ проблему».

Ага! Он пытается использовать внутреннее качество как переменную! Как я догадался? Да, потому что он хочет, чтобы мы уменьшили оценку задач, не уменьшив при этом объём работ. Слово «заплатка» должно вызывать у вас тревогу.

Почему же мы так жестко стоим на своем?

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

В этом случае я стараюсь перейти к обсуждению объема задач. «Раз вам так важно получить эту историю как можно раньше, тогда может быть стоит сократить объем задач, чтобы мы могли сделать её побыстрее? Возможно, стоит упростить обработку ошибок и сделать „Улучшенную обработку ошибок“ отдельной историей оставив ее на будущее? Или может понизить приоритет остальных историй, чтобы мы могли сосредоточить все свои усилия на этой?».

Планирование спринта, которое никак не заканчивается

Самая большая сложность при планировании спринта состоит в следующем:

1. Люди не расчитывают, что это займёт так много времени