Итерационный подход к разработке требует на выходе каждой итерации логически законченный продукт, который замыкает на себе весь основной бизнес процесс.
Если нас просят, например, сделать автомобиль, то мы сначала делаем тележку из проволоки и деревянных колесиках, удостоверяемся что она едет и показываем заказчику. Заказчик может сразу отреагировать, мол, он хотел, вообще-то, двухколесный вариант. Таким образом мы на каждой итерации проверяем правильность того, чем мы занимаемся.
Обе картинки в этом посте максимально понятно это иллюстрируют.
Как видно из изображения с машинками, на каждой итерации сохранена и достигнута основная цель — передвижение. Чтобы не путаться, я заменю слово цель в этом контексте, на слово “скелет”. Помним, что скелет тут — это концептуальное понятие, а не физическое.
Итак, в вашем случае скелет чуть сложнее, чем катание, но его тоже можно формализовать. Предположим, что это “заказ такси через мобильное приложение”. В какой бы стадии мы ни находились, этот скелет всегда у нас в наличии.
Следовательно, цель первой итерации реализовать этот скелет в самом простом варианте, прям такой, какой он и есть — без мяса. Однако, мы пойдем чуть дальше (у нас ведь сжатые сроки и большая конкуренция), и распараллелим процесс. Мы будем делать скелет и параллельно попробуем разрабатывать какую-нибудь боковую фичу (side feature), которая, кстати, не сильно влияет на сам скелет. Боковая фича — это клевая шапка на скелете. Или перст. Или ярко накрашенный ноготь.
Эффектом боковой фичи для скелета “заказ такси через мобильное приложение” для первой итерации может быть пуш-уведомление о взятии заказа (тригерится пока что фейково). Или это может быть прикольно заанимированный пин на карте.
Делать боковую фичу можно одним девелопером/дизайнером, который только на ней и сосредоточен во время итерации. Право делать боковую фичу может переходить между девелоперами от итерации к итерации.
Ничего страшного, если эти фичи не успеют сделаться, это никак не повлияет на велосити и на восприятие продукта заказчиком или юзерами. Но делать их прикольно, процесс не становится таким скучным и позволяет не приунывать в рутине, даря себе и юзерам классные штуки (креатив, хааа). Иногда в процессе работы над боковыми фичами в продуктах появляются пасхальные яйца.
Главное, не пожениться на боковых фичах. Юзеры могут их не принять, так что нужно смочь “взять и выбросить”. Я рассматриваю боковые фичи как венчурное инвестирование софта фичами, которые идут from the bottom of your heart. Одна из сотни выстрелит и станет unicorn-фичей.
Ранее статья была опубликована тут.