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

vypolnite eti klyuchevye shagi chtoby nachat uspeshnyj proekt razrabotki programmnogo?v=1656630132

Андрей Данчу

Tw1UouYr272jOrBYiMcw4jrurVb2453h0gSk

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

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

Если это звучит слишком знакомо, это статья для вас. Следуйте этим указаниям, начиная проект, и настройтесь на успех.

Установите четкие пути общения

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

Определите лучшие практики и условности

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

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

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

Создайте содержательное определение Готово

Сколько раз перед демонстрацией вы узнавали, что вы не можете продемонстрировать функцию, потому что чего-то не хватает? Я знаю слишком часто.

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

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

Следующим шагом является добавление шагов развертывания, чтобы вы могли выпустить функцию в демонстрационную среду. Вы должны объединить эти шаги в определении Готово вместе с любым другим соответствующим шагом.

После этого убедитесь, что ваша команда использует определение готового в качестве контрольного списка, прежде чем выполнить задание. Это придаст вам гораздо больше уверенности в том, что решенная заявка отвечает вашим ожиданиям.

Выберите подходящую систему непрерывной интеграции

Постоянная интеграция имеет решающее значение для каждого проекта. Вы хотите убедиться, что вы можете производить новые разработки с минимальными усилиями. К счастью, на рынке доступен широкий выбор вариантов, два из которых – Jenkins и TeamCity. Но есть несколько очень важных факторов, которые следует учесть, делая этот выбор.

Одно из них – преимущество команды, а другое – цена инструмента. Всегда разумнее использовать инструмент непрерывной интеграции, которым ваша команда пользовалась раньше. Это означает, что все знакомы с инструментом, и вам не нужно будет прилагать дополнительные усилия, чтобы изучить новую систему.

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

Существует множество бесплатных мощных инструментов непрерывной интеграции. Найдите время, чтобы проверить их и выбрать наиболее подходящий для вас.

Выберите инструменты и приложения

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

Одному из менее опытных членов вашей команды Джону нужна помощь, чтобы проверить конечную точку для создания пользователя. Он просит помощи у Алекса, которая очень хочет помочь, пока она не понимает, что Джон использует SOAP UI для тестирования своих конечных точек.

Алекс, большой поклонник Postman, тратит несколько минут, пытаясь понять, как пользоваться инструментом, но без особого успеха. После нескольких попыток она кажется, поэтому они решают обратиться к Джорджу, опытному парню в команде.

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

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

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

Разумно используйте системы контроля версий

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

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

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

Избегайте использования нескольких систем управления документами

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

Когда ваш DevOps парень хочет найти IP-адрес QA сервера, он должен искать в одном месте. Чтобы это произошло, следует выбрать одну хорошую систему управления документами и соблюдать ее.

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

Определите среды, необходимые для вашего решения

Мы все знаем, что разработчики, тестировщики и бизнес не должны использовать одну среду. Однако этот аспект обычно игнорируется на начальном этапе проекта.

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

Как правило, у вас должно быть, по крайней мере, четыре среды: разработка, тестирование приемлемости пользователя (UAT), постановка и производство.

Среда развития

Среда разработки будет песочницей для команды разработчиков. Вот почему он не всегда будет стабильным и вы можете ожидать несоответствия данных.

Среда тестирования приемлемости пользователя

UAT предназначен для одобрения пользователями, поэтому бизнесмены будут проводить тестирование здесь.

Постановочная и производственная среда

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

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

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

Подготовьте кодовую базу и структуру проекта

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

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

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

Создайте документ для локальной настройки проекта

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

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

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

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

Подведению

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

Это несколько ключевых вещей, которые вы можете сделать, чтобы настроить следующий проект на успех. Что бы вы добавили в этот список? Пожалуйста, оставьте свои мнения ниже.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *