Используйте семинары по историям, чтобы довести понимание до совершенства и точно определить, что конкретно должна создать команда разработки. Семинар – это обсуждение продукта (поддерживаемое множеством данных и картинок), которое поможет команде принять необходимые решения и определить признаки готовности, то есть критерии приемки того, что было решено разработать.
Перед началом семинара нужно уведомить команду о историях, которые вы планируете обсуждать. Развесьте их на стенах или разошлите по электронной почте. Попросите команду проголосовать, учтите их мнение при окончательном выборе.
Небольшое количество людей – условие продуктивности семинара. От трех до пяти человек – наилучший вариант.
Тщательно подбирайте участников. Чтобы обсуждение было эффективным, включите:
• кого-то, кто хорошо понимает пользователей и пользовательские интерфейсы, их требования и возможности, – чаще всего это владелец продукта, специалист по пользовательскому взаимодействию или бизнес-аналитик;
• одного или двух программистов, имеющих представление о коде, который вы хотите добавить в продукт, и поэтому хорошо понимающих степень реалистичности разработки;
• тестировщика, отвечающего за качество продукта, потому что именно он задаст каверзные вопросы, известные как «Что, если», о которых не подумают остальные, обычно настроенные оптимистично.
Другие люди и другие роли тоже могут быть полезны, но не забывайте об оптимальном количестве участников дискуссии – не больше, чем в компании за обеденным столом.
Вы убедитесь, что один человек вполне может выступать в двух ролях, или, как говорят, носить сразу две шляпы. Например, во многих IT-организациях я встречал тестировщиков, одновременно исполняющих обязанности бизнес-аналитиков. Но если силами присутствующих не удалось преодолеть все камни преткновения, приостановите семинар и найдите кого-то еще, кто может помочь в решении трудного вопроса.
Тщательно анализируйте и рассматривайте варианты. Используйте обсуждения, чтобы детально проанализировать:
• кто конкретно ваши пользователи;
• как конкретно, по мнению команды, они будут использовать продукт;
• как конкретно будет выглядеть продукт, то есть его интерфейс;
• как конкретно ведет себя программный продукт внутри интерфейса – какие бизнес-правила действуют, как нужно валидировать данные;
• сколько времени потребует разработка продукта с учетом всех технических деталей (на этом этапе мы обсуждаем все настолько подробно, что оценки могут быть довольно точными).
Помните: пока еще ничего не решено окончательно. Если дискуссия приводит к решениям, которые слишком сложны или дороги, вернитесь на шаг назад и обсудите проблемы, которые вы решаете, а также альтернативные способы решения.
Придите к соглашению о том, что нужно разработать. После того как по результатам обсуждения вам удалось выработать одинаковое понимание, перейдите к поиску ответов на вопросы.
• По каким критериям можно будет определить, что работа над программным обеспечением закончена?
• Что будет происходить во время демонстрации программного обеспечения, когда мы будем оценивать его все вместе?
Говорите и записывайте. Используйте доски или большие листы бумаги, чтобы рисовать картинки, записывать примеры и рассматривать варианты. Не позволяйте своим решениям испариться. Записывайте их на досках или на бумаге, чтобы каждый мог их видеть. Сфотографируйте записи и картинки, чтобы позднее задокументировать информацию.
Оперируйте примерами. Где только возможно, используйте специфические примеры поведения пользователей: какие конкретно данные могут быть введены, что именно пользователи увидят в результате, – словом, любые примеры, которые лучше всего иллюстрируют вашу историю.
Разделяйте и уменьшайте. Обсуждая детали и думая о затратах на разработку, вы, возможно, обнаружите, что истории слишком велики, чтобы уместиться в стандартный цикл. Поработайте вместе с группой, чтобы разделить крупные истории или уменьшить их, удалив все лишнее.
Но все это не будет работать, если:
• нет совместной работы – кто-то один описывает, что нужно сделать, а все остальные слушают;
• разговор идет только о критериях приемки, но никто не вспоминает об истории и о «Кто?», «Что?», «Почему?»;
• не рассматриваются варианты реализации как с функциональной, так и с технической стороны.
Планирование спринта или итерации
Некоторые практики Agile воспринимают эти важнейшие обсуждения историй во время сессий планирования как планирование итерации или спринта. Это не так страшно, если вы имеете дело с командами, эффективно работающими вместе и начинающими дискуссию, хорошо понимая своей продукт. У команд, с которыми я работал на протяжении многих лет, это был устоявшийся способ работы.
Тем не менее самая частая жалоба, которую я слышу от команд, работающих по Agile, заключается в том, что эти совещания по планированию – зачастую долгие изматывающие мероприятия. В какой-то момент все соглашаются разработать то-то и то-то, даже если на самом деле никакого общего понимания нет, просто чтобы закончить это мучительное совещание.
Быть среди своихНикола Адамс и Стив Барретт, RAC Insurance (Perth, Australia)
Мой первый опыт работы в мире проектов Agile в роли бизнес-аналитика был тяжелым и горьким уроком о превосходстве командной работы над печатным словом.
Никола Адамс
Контекст
Историю трансформации от методологии водопада к Agile в компании RAC Incurance (Западная Австралия) рассказывает Никола, квалифицированный бизнес-аналитик с большим опытом в традиционном подходе к разработке программного обеспечения. В ее обязанности входило сотрудничество с бизнесом, понимание предметной области и составление функциональных спецификаций, в соответствии с которыми команда IT создавала продукт. Коммуникация происходила по следующей схеме.
Наибольшее внимание уделялось детальным спецификациям, где старались не пропустить ни одной детали. Поскольку было очевидно, что разработчики не читают документацию, были внедрены специальные стратегии смягчения проблемы (например, пошаговые руководства по спецификациям), но они не решали ее полностью. Как правило, между окончанием работы над спецификацией и моментом, когда ее нужно было использовать для поддержки разработки и тестирования, проходило довольно много времени.
С чего все началось?
Устоявшийся подход к письменным спецификациям не стали отменять в одночасье. Концепцию написания требований на обратной стороне карточки внедрить было нелегко. Как Никола могла ожидать, что разработчики и тестировщики внедрят необходимую функциональность, за которую она несла ответственность, если у них нет необходимой информации? Фокус просто переместился на создание последовательностей действий пользователя, почти ничем не отличающихся от традиционных функциональных требований, за исключением размера; схема коммуникации не изменилась.
Чтобы передать требования команде на сессиях разработки, Никола:
• собирала требования партнеров по бизнесу;
• глубоко анализировала требования и данные;
• создавала последовательности действий пользователя (каждая занимала от одной до пяти страниц), где описывались требования, дизайн решения и критерии приемки;
• излагала эти требования команде с использованием проектора и отвечала на вопросы присутствующих.
К несчастью, результаты не впечатляли. Подготовительные сессии были скучными и утомительными, большая часть команды никак не включалась в обсуждение. Кроме того, Никола чувствовала, что зря тратит время на подготовку историй, так как команда чаще всего игнорировала их во время разработки.
После одной из сессий Сэм, эксперт в предметной области, одновременно играющий роль владельца продукта, заметил: «Если это и есть проект Agile, я не желаю в этом участвовать!»
Нужно было что-то делать.
Что поменялось?
Менеджер проекта Стив собрал команду, чтобы обсудить проблему. В результате команда приняла несколько важных решений: исключить из процесса документы с историями, привлечь
