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

Рассмотрим требования к этой функции:

  1. Пользователи могут искать магазин по почтовому индексу или городу и штату:
  2. Приложение отобразит пять ближайших магазинов с их адресом, номером телефона и временем работы магазина.
  3. На странице появится карта с пятью ближайшими магазинами, с возможностью увеличения и уменьшения.
  4. В результатах поиска также будет указано имя регионального менеджера, номер телефона, адрес электронной почты и фотография.
  5. Если пользователь вошел в систему, давайте предварительно заполним его адрес для поиска.

Слишком много сразу

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

Что ты можешь сделать?

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

Во-первых, будут ли модели, которые вы разрабатываете в течение первой недели, достаточно полно дополнять пользовательский интерфейс без изменений? Будет ли у них достаточно функционала, и будет ли функционал правильным?

Во-вторых, что вы скажете владельцу продукта, когда он спросит, как продвигается история? Будете ли вы сказать, что вы сделали 40%? Если вы сделали 40%, когда вы все сделаете? Что еще более важно, сможете ли вы продемонстрировать какую-либо функциональность на этом пути?

Наконец, если кто-то предложит помощь с этой историей, сможете ли вы передать какие-либо задания? Можно ли выполнять какую-либо работу параллельно?

Разделение вашей истории таким образом, фокусируясь сначала на моделях и сервисах, а затем на пользовательском интерфейсе, приводит к множеству сложных вопросов. Ответы, к сожалению, либо «нет», либо «не знаю».

Итак, что вы можете сделать, чтобы улучшить ситуацию?

Направления функциональности

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

Итак, что нам нужно сделать, чтобы дать нашей команде все эти возможности?

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

Мне нравится думать о функции как о единой сквозной части функциональности, которая добавляет ценность пользователю.

Итак, как мы можем разбить историю Store Locator на некоторые составные части? Вот один из способов:

  1. Пользователь ищет по почтовому индексу и видит список магазинов с адресами и часами работы.
  2. Пользователь ищет по адресу.
  3. Результаты отображаются на статической карте.
  4. Карта может увеличиваться, уменьшаться и панорамироваться.
  5. Отображение имен, телефонов и адресов электронной почты региональных менеджеров.
  6. Отображение изображений региональных менеджеров.
  7. Предварительно заполните поиск, когда пользователь вошел в систему.

Хорошо для всех

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

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

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

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

Нюансы

Разбить значимую историю на маленькие тонкие кусочки не всегда просто.

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

Этот пример не является выдуманным или теоретическим. Это пришло из реального проекта, над которым я работал. Мы часто ссылаемся на него как на отличный способ добавить функциональности нашей системе.

Еда на вынос

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

Сосредоточьтесь на тонких кусочках функциональности и постоянно оставайтесь в этом сладком месте ценности и инноваций.

👏🏻 Похлопайте мне и подпишитесь, если вам понравилась эта статья.

📋 О Майло

Я руководитель технического отдела, писатель, спикер, предприниматель, разработчик и изобретатель. Я занимаюсь разработкой программного обеспечения с 1995 года и последние десять лет разрабатываю команды. 🚀

Я пишу статьи о программном обеспечении, разработке, менеджменте и лидерстве.

Вы также можете подписаться на меня в Twitter. 🐦