Удовлетворять потребности пользователей и ожидания менеджеров будет проще простого
В гибкой разработке мы с самого начала не знаем, как будет выглядеть конечный продукт.
Итак, мы зависим от наличия последовательной обратной связи. Эта обратная связь может поступать от заинтересованных сторон (в первую очередь от пользователей), телеметрии (автоматически собираемые данные о том, как люди используют продукт, например о кликах или посещениях страниц) или владельцев продукта.
Чем раньше мы сможем понять реакцию на новую разработку, тем больше мы сможем избежать траты ресурсов на функции, которые в конечном итоге будут отброшены, потому что они окажутся неважными или даже вредными.
Мы так часто ассоциируем гибкое управление с людьми, работающими над продуктом, но то, как разработчики подходят к внедрению новых функций, напрямую влияет на скорость этого цикла обратной связи.
Если они сделают это правильно, цикл будет быстрым; если они сделают это неправильно, это будет медленно. Давайте рассмотрим два подхода на примере.
Пример использования: панель инструментов Blog Analytics
Допустим, вы создаете платформу для ведения блогов и хотите реализовать панель аналитики для своих пользователей. Вы все это планируете:
Вы думаете, что вашим пользователям будут полезны три основные функции панели инструментов.
- Количество просмотров страницы с течением времени (зеленый).
- Географические местоположения посетителей (синие).
- Деньги, заработанные по партнерским ссылкам (красный).
Большинство приложений многоуровневые. У вас может быть серверная часть, интерфейсная часть и многоуровневая архитектура внутри каждого из них. Я думаю об этой архитектуре как о слоеном тесте или пироге.
То, как вы разрезаете пирог (заказываете свои разработки для этой истории), ускоряет или замедляет цикл обратной связи.
Медленно: мини-водопады
Вы хорошо понимаете, как должна выглядеть панель управления, поэтому приступайте к ее созданию:
- Бэкэнд - вы начинаете с бэкенда, создавая все сервисы и конечные точки, которые вам понадобятся для предоставления данных панели мониторинга для всех трех функций. Уф, это было много работы!
- Внешний интерфейс - вы создаете все необходимые средства взаимодействия с клиентом (выборки, модели, бизнес-логика).
- Пользовательский интерфейс - наконец, вы создаете пользовательский интерфейс приборной панели.
Вы могли подумать, что это был эффективный подход! В конце концов, вы выполнили отличное архитектурное планирование и прекрасно его выполнили. Вы определенно приняли во внимание потребности пользователя… или… ?
Не так хорошо, как могли бы!
Вы ждали до самого конца, чтобы показать свою работу пользователям или даже владельцу продукта. Не задумываясь, вы снова вернулись к разработке в стиле водопада, только в меньшем масштабе.
Поступая так, вы подавили петлю обратной связи и, возможно, потратили зря на внедрение функций, которые нужно будет изменить или даже отказаться.
Быстро: истинная ловкость
Итак, давайте дадим вам второй шанс. На этот раз нарежьте пирог вот так:
Вы реализуете каждую подфункцию на панели инструментов полностью.
- Количество просмотров страницы с течением времени.
- Географические местоположения посетителей.
- Деньги, заработанные на партнерских ссылках.
Поскольку вы включили слой пользовательского интерфейса в каждый фрагмент, вы быстро получите обратную связь от владельца продукта и ваших пользователей при развертывании.
Эта обратная связь - гений гибкой разработки. Он будет направлять вашу работу даже в рамках одной средней и крупной задачи разработки. Включив его, вы можете избавить себя от боли, связанной с созданием неправильной вещи.
При правильном подходе к разработке вы обнаружите, что удовлетворение потребностей пользователей и ожиданий руководителей проектов станет намного проще - осмелюсь сказать, проще простого.
