Как быстрое прототипирование вписывается в гибкую методологию?

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

Специальная инженерная группа, в которой я работаю, традиционно не разрабатывает программное обеспечение (вместо этого мы помогаем управлять проектами с гораздо более широкой точки зрения), но это меняется. У нас есть широкий спектр предстоящих / планируемых программных проектов, которые в основном ориентированы на данные - например, мы будем заниматься мониторингом, сбором, агрегацией данных и некоторой отчетностью. Другие задачи включают автоматизацию со специализированным оборудованием и различными типами клиент-серверных (многоуровневых) архитектур. Я должен помочь в процессе найма нескольких человек и формулирования многих наших планов по продвижению вперед.

Мой вопрос заключается в том, вписывается ли быстрое создание прототипов (одноразовый код) в гибкую философию. Например, я люблю Python и его широкий ассортимент пакетов. Я вижу возможность очень быстро реализовать многие наши идеи с помощью рабочего процесса на основе Python. Тем не менее, я думаю, что будет много представлений о том, что Python не «корпоративного качества», и большая часть этой работы должна быть переписана на Java или, возможно, C ++.

Тем не менее, создание прототипов Python дало бы нам большую выгоду, позволив нам быстро добиться реальных результатов.

Удалось ли вам внедрить быстрое создание прототипов - надеюсь, в Python - в надежный гибкий рабочий процесс в корпоративной среде?

Концепция «прототипирования», как и предполагалось в RAD , немного чужда гибкой разработке. Это не значит, что это невозможно, но это необычно.

Существуют разные случаи, которые необходимо изучить:

1. Является ли прототип «пустой оболочкой», макетом или демонстрацией, созданной, чтобы дать представление о том, как будет выглядеть продукт? Безусловно, вы можете сделать это с помощью одной или нескольких историй - однако вы создаете что-то из своего собственного воображения, а не создаете продукт из реальной обратной связи. Люди не оценивают демо, как они оценивают продукт. Например, посмотрите отзывы о нашем прототипе верхней панели и нашей реальной реализации верхней панели .

2. Прототип - это что-то, что нужно построить, чтобы лучше понять проблемное пространство? Затем он должен быть покрыт как всплеск , и сохраняются только его результаты (исходный код временный).

3. Является ли прототип версией 0.x? Mininimum жизнеспособный продукт ? Затем воспользуйтесь гибким процессом по вашему выбору. Если вам нужно перестроить его на другом языке, вам, скорее всего, будет лучше, если вы отнесетесь к этому другому продукту. Обратите внимание, что иногда это рассматривается как способ быстрого написания спецификации («он должен делать то же, что и прототип!»). Это действительно плохой способ документирования продукта, но это, вероятно, лучше объяснить отдельным вопросом и ответом :-)

Разве быстрое прототипирование (то есть итеративное и инкрементальное развитие) не является суть Agile?

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

И Python не является (если он когда-либо был) игрушечным языком. НАСА и его подрядчики используют Python , и если он достаточно хорош для меня, то он достаточно хорош для меня.

В экстремальном программировании существует довольно устойчивая практика под названием « Спайк» . Это означает, что это одноразовый код. В этом нет ничего особенного. Это просто Спринт, в котором ожидаемый результат - знание об одноразовом коде.

Приведенная выше ссылка содержит достаточно информации о передовой практике, ловушках спайков.

Ваш конкретный пример использования кажется хорошим примером: может быть полезно разработать интерфейс, проверить утилиту и показать ее некоторым пользователям.

Вы собираетесь выбросить код и не запускать его в производство (сделайте это абсолютно понятным КАЖДОМУ), поэтому быть гибким или нет не имеет большого значения. Любые гибкие методы являются необязательными для прототипов: спринты, выгорания, тестирование, парное программирование или все, что вы планируете использовать.

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

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

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

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

Истинный дух Agile - это взаимодействие и общение. Я бы сказал, что если прототип работает как инструмент, помогающий общаться, нет ничего плохого в том, чтобы использовать его в Agile мире. В нашей команде (мы занимаемся Agile более 5 лет) мы время от времени использовали его. И есть некоторые преимущества, которые я вижу из этого

1) Помочь общению

2) Вовлеките пользователей в собеседования и получите раннюю обратную связь

Предостережение:

Прямая связь между UX и инженерами НИКОГДА не должна заменяться какими-либо артефактами прототипирования. Если возможно, соединение с инженером работает лучше, чем общение через посредника (прототип).

Другие уже упоминали цель обучения шипов. Чего не хватает, так это основного гибкого принципа, который быстро терпит неудачу .

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

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