Вдохновленные

Если идея попала в верхнюю часть списка, менеджер продукта первым делом проводит беседу с заинтересованными сторонами, в результате чего замысел, так сказать, обрастает плотью, и «вырисовывается» ряд основных «требований», или технических условий. Иногда эти требования представлены в виде пользовательских историй (user stories), а иногда больше напоминают по форме техническое задание или функциональное описание. Их цель – донести до дизайнеров и инженеров, что именно им нужно создать.

Как только требования собраны в пакет, команде дизайнеров пользовательского опыта (если таковая имеется) предлагают спроектировать взаимодействие, разработать графический дизайн и, если речь идет о физическом устройстве, промышленный дизайн. И наконец, требования и спецификации по дизайну передаются инженерам-программистам. Тут-то на сцену обычно выходит методология Agile.

В любом случае инженеры, как правило, разбивают работу на итерации – отрезки времени, которые в процессе Scrum называются спринтами.

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

Как только компания получает зеленый свет от команды тестировщиков, начинается релиз новой идеи для реальных клиентов.

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

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