На моей первой работе в качестве разработчика программного обеспечения моя команда использовала Agile / Scrum для управления рабочим процессом нашего проекта, и это работало довольно хорошо. У меня были опытные наставники, которые поставили меня на правильный путь - я в долгу перед ними. Я работал там несколько лет, а затем перешел к новой возможности пару месяцев назад.
Перенесемся в мою текущую работу. Я работаю в университете под руководством профессора. Поскольку я учусь в университете, почти каждый программист является студентом (они дешевы и многочисленны!) Мой начальник имеет опыт управления, но не в области разработки программного обеспечения, и команда разработчиков программного обеспечения не всегда находится в центре внимания моего босса , Эти условия создали идеальную среду для создания программного обеспечения очень низкого качества. Похоже, что программные проекты немного неконтролируемы, у них нет мысли о дизайне и используются действительно пугающие методы. Я знаю, что все может быть лучше.
Я хочу внедрить процесс разработки, чтобы помочь всем собраться, повысить качество кода и развернуть более стабильное программное обеспечение. Я просто не уверен, с чего начать.
Я не ищу, скажем, ответов типа «Используйте Scrum», «Настроить доску канбан» или «Взгляните на Agile!» (хотя идеи ценятся). В частности, я надеюсь получить представление о том, как реализовать процесс разработки для этой рабочей среды. Сотрудники обычно работают от 1 до 2 лет, прежде чем уйти, как правило, неопытны, и ежедневные встречи с участием каждого из них почти невозможно запланировать.
Как повысить качество, эффективность и коммуникацию на таком рабочем месте?
Обновление: после прочтения некоторых ответов и комментариев я подумал, что предоставлю дополнительную информацию.
Я не считаю себя мастером в искусстве разработки программного обеспечения, но я являюсь достаточно опытным , чтобы распознать плохое программирование , когда я это вижу. Я могу определить, талантлив ли разработчик, потратив всего пару минут на работу с ними. Я комфортно с моими собственными способностями , чтобы найти способ решить проблему бойко , однако, область , где я действительно не хватает опыта является управление проектом , в котором участвуют и другие разработчики (именно поэтому я здесь спрашиваю всех вас , замечательных людей , для совет).
Я сделал так, чтобы каждый студент, который приходит в этот кабинет, был полным дураком. Здесь было несколько плохих яиц, но большинство студентов, которых я встречал, умны, хотят учиться и увлечены работой. Некоторые только начинают, хотя, и они не знают, чего не знают. И это нормально. Когда я впервые начал программировать, мне было не лучше!
Ответы:
Требуется больше времени, чтобы очистить ошибочное, чем предварительно проверить. Если вы имеете дело с разработчиками, которые (возможно) неквалифицированны или не знают о хорошей практике, это означает, что они не должны быть в состоянии изменить (основную) кодовую базу, пока их код не будет проверен кем-то опытным.
Вы не хотели объяснения методологий, поэтому позвольте мне перейти к этой части: использовать гибкие задачи для настройки различных функций, которые можно разрабатывать независимо.
Начните использовать функциональные ветви, чтобы каждый работал в отдельной ветви. Когда задача завершена, разработчик не может объединить свой код с главной веткой. Если вы используете Git, они все еще могут запустить запрос на получение. В противном случае используйте любой метод отслеживания завершенных задач (/ веток), который вам по вкусу.
Тогда мы перейдем к процессу проверки . Ваш вопрос немного расплывчат в том, есть ли опытные разработчики, которым можно доверять больше, чем студентам. Итак, позвольте мне уточнить в любом случае:
Если есть опытные разработчики, задайте им обзор готовых задач. Если это хорошо, они могут объединить его с основной веткой. Если это не так, они могут либо рефакторировать его самостоятельно, либо дать разработчику понять, что нужно улучшить.
Если нет опытных разработчиков, то у вас всегда будут проблемы. Если некому найти хороший код по плохому, невозможно поддерживать качество кода.
Лучшее, что вы можете сделать, это провести обзорные встречи, на которых разработчики представляют и объясняют свою реализацию перед другими разработчиками. Хотя это не может гарантировать предотвращение каждой проблемы (например, если все разработчики имеют одинаковое неправильное представление о надлежащей практике, это все равно предотвратит большинство проблем (например, если хотя бы один разработчик имеет правильную идею и может сформулировать ее; или когда проблема связана с от разработчиков понимание проблемы отличается друг от друга)
источник
Самая большая вещь для такого рода среды, где люди являются новыми и могут покинуть это обязательные проверки кода.
Они помогают распространять знания о том, что должно быть сделано. Они помогают предотвратить попадание худшего кода в базу кода. Они способствуют последовательности в реализации.
Потому что с таким большим оборотом и неопытностью, коммуникация важнее, чем обычно.
источник
Это скорее идея, чем решение, но найдите один критический раздел кодовой базы, который содержит функции и элементы, аналогичные проектам, которые могут сделать ваши учащиеся-разработчики, и ОЧЕНЬ хорошо его очистите. Одна большая проблема с новыми разработчиками состоит в том, что они не знают норм и соглашений кодовой базы, и они будут смотреть на другой код, чтобы получить представление о том, как настроить свой собственный. Наличие большого количества новых разработчиков, работающих в грязной кодовой базе, означает, что они увидят беспорядок и подумают, что это приемлемо или лучший способ сделать что-то. Плохие практики увековечивают себя даже в условиях сильного переворота.
Имея по крайней мере один чистый, хорошо написанный раздел кода (или даже один файл), вы можете сказать своим студентам-разработчикам использовать это в качестве примера передового опыта. Скажите им, что вы будете в восторге, если они смогут написать код, подобный этому, и что большая часть другого кода может не быть хорошим примером правильного способа сделать что-то.
Добавление комментариев или другой документации с объяснением того, почему что-то делается определенным образом, также поможет новым разработчикам быстрее освоиться с улучшенными методами работы с кодом.
источник
Непрерывная интеграция -
Это практическая и концептуальная основа для постепенного и гибкого внедрения инструментов, навыков и процессов команды.
CI - это идея рабочего процесса от написания кода до развертывания. Эти задачи концептуально и фактически независимы.
КИ, в частности, автоматизация. Это имеет большое значение для качества и производительности, начиная с того момента, когда код вводится на экране.
Ожидайте быть постоянным агентом изменений. Стать лидером; не просто менеджер, не просто старший кодер.
Быть стратегическим
Будь тактическим
Дорога к качеству
Модульное тестирование
Управление версиями
Кодовые обзоры
Рефакторинг
Захват вашей среды
Слово о процессе
Agile (и его поджанры, такие как Scrum): забудьте об этом. «Ты проворен, ты не проворен». Посмотрите их Дэйвом Томасом, одним из первых подписантов Agile Manifesto .
Учитывая небольшие, неопытные команды, мое чувство паука исчезает, когда я вижу инструменты групповой интеграции, такие как Visual Studio Team Services. Мой опыт здесь ограничен, но я чувствую тупое, излишнее, жесткое навязывание процесса. Я знаю, что многие используют эти вещи с большим эффектом, но остерегайтесь потенциальной покупки решения в поисках проблемы.
Слово об инструментах
Просто я. Не из тех «Лучших программных инструментов сейчас ...».
Дженкинс
Инструмент интеграции CI. Сетевой, широко используемый. По сути, через веб-интерфейс пользователя вы настраиваете и автоматизируете различные задачи и порядок выполнения, такие как компиляция, запуск модульных тестов, обновление контроля версий. Это очень A-La Carte, так что он подходит для вашей зарождающейся среды CI.
Управление версиями
Я предпочитаю Mercurial, а не Git. Именно из этого поста в блоге я и выбрал Mercurial: Git - это MacGyver, Mercurial - это Джеймс Бонд
Subversion это хорошо. Mercurial & Git имеют другую архитектуру, которая превосходит Subversion.
Интегрированная среда развития
Вот большое веское соображение, если все используют разные инструменты кодирования: нет такого понятия, как обычный текст
Слово о профессиональной библиотеке
Интернет широкий, неглубокий и неорганизованный.
источник
Я предлагаю использовать другую методологию для управления вашим процессом, поскольку, как вы говорите, невозможно запланировать встречи (что абсолютно важно для схваток!). Нет ничего плохого в том, чтобы создать хорошую концепцию, чтобы все знали, что происходит (возможно, с помощью прототипа vert) и использовали модель водопада. В любом случае, общение является самой большой частью работы.
источник
Я бы посоветовал вам использовать систему контроля версий, если вы еще этого не сделали. Это позволяет вам видеть, что было зарегистрировано каждым разработчиком, и позволяет регрессировать, где была введена ошибка.
Я бы настроил какой-нибудь набор тестов. Это может быть управляемая тестами разработка, в которой вы пишете тесты для каждой выполняемой вами функции, или это может быть автоматический способ запуска ваших приложений и их вывода результатов в файл, который можно сравнить с желаемым вывод. Если он запускается после каждого коммита или запускается хотя бы раз в ночь, вы быстро найдете регрессии.
Последнее, что я хотел бы сделать, это реализовать 2 политики: 1) во всех сборках должны быть установлены предупреждения об ошибках, и все ошибки должны быть включены 2) Весь код должен проходить через статический анализатор без каких-либо ошибок или предупреждений перед его фиксацией. Я бы даже сделал это предварительным действием. Эти две вещи будут препятствовать тому, чтобы код быстро становился ужасным по нескольким распространенным причинам. (Они не все ловят, но они много ловят.)
Это также подготовит ваших учеников к тому, на что будет похожа работа в «реальном мире», и привит им достаточно хорошие привычки.
источник