Постигая Agile

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

После встречи Эрик, Роджер и Ави собрались, чтобы подвести итоги. Роджер и Ави поздравили друг друга с тем, что наконец получили команду, умеющую совместно размышлять над проблемами. И опять они были весьма удивлены реакцией Эрика: тот выглядел обеспокоенным.

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

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

«Да, похоже, над этим изрядно потрудились, – сказал один аккаунт-менеджер. – Послушай, для чего ты это сделал?»

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

Это было совсем не то, что ожидалось от разработчиков!

После встречи Роджер и Ави вернулись к Эрику, который совершенно не был удивлен. «Как же нам все исправить?» – спросил Роджер.

Ави заявил, что и так старался изо всех сил, стремясь дать другим менеджерам то, чего они хотели. Он поддерживал бэклог, приоритизируя его по ценности функций и передавая в команду. Что еще он мог сделать? Роджер даже не знал, с чего начать, но понимал: если они не внесут какие-либо изменения, то продолжат получать не совсем нужные результаты. Кроме того, произнеся зажигательную речь, Роджер и Ави заставили команду поверить в Scrum, и теперь ее постигло жестокое разочарование. Ави сообразил, что если не изменить что-то прямо сейчас, то команду можно потерять навсегда.

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

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

Он спросил: «Как нам научиться угадывать их мысли?»

Пользовательские истории, скорость работы команды и общепринятые практики Scrum

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

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