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

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

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

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

Чтобы получить этот организованный и всеобъемлющий JavaScript, любой разработчик должен следовать отличной практике — начать с псевдокодирования. Псевдокодирование в JavaScript необходимо для обеспечения организованного кода, и лучше всего начать с заполнения плана, подобного приведенному выше. После разработки наших пользовательских историй наша команда начала псевдокодирование взаимодействия с пользователем, чтобы охватить каждую функцию, которую мы планируем развернуть в нашем функциональном продукте. Тогда логически имеет смысл перейти к «Зависимостям» или элементам DOM. Затем проработайте данные, функции и инициализацию.

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