- PVSM.RU - https://www.pvsm.ru -
Во первых перестать паниковать! Если процесс уже налажен, очень важно не наломать дров. Но с другой стороны, как новоиспеченный лид, неплохо бы разобраться в том, как и что устроено на проекте и постараться изменить к лучшему то, что считаешь неверным.
В данной статье (точнее ее первой части) я поделюсь своим видением того, что необходимо внедрить на проекте и какие ключевые правила стоит соблюдать, что бы разработка была максимально быстрой и эффективной.
Небольшое отступление для троллей
Много сказанного тут относится к разным областям, не все считают уместным писать об этом в одной статье. Некоторые вещи я буду называть неправильными терминами, так как, возможно, не во всех аспектах моя теоретическая база достаточна. Так же я не претендую на то, что это панацея и результаты на каждом проекте повысятся подобно моим. Само собой есть множество более удачных примеров и решений, я лишь надеюсь, что моя статья может послужить для многих путеводной звездой, особенно, если они хотят что-то изменить в своем процессе разработки.
Исходные данные
Предположим, что Вы руководитель небольшой группы разработчиков (5-7). По-моему субъективному мнению, именно такая самостоятельная единица в количестве до 7 девов и одного тим лида, является наиболее удачной. Так же считаем, что Вашей непосредственной задачей является разработка с момента получения первой документации и заканчивая поддержкой уже вышедшего продукта.
Система контроля версий проекта
Считаю одним из наиболее важных моментов, который отразиться на производительности — это система контроля версий. При выборе оной предлагаю особый упор сделать на легкость бранчевания и мержа веток, а так же на то, что бы она была распределенной. Думаю все уже поняли о чем я =). Само собой рекомендованной я назову git или mercurial. Так, как первый немного более взрослый, то и информации на разных языках больше, а значит этот вариант предпочтительнее, если у Вас в команде те, кому нужно будет осваивать новую систему (а если это еще и джуны с невысокой скоростью освоения англоязычных источников то тем более). Сходу можно назвать ресурс [1], который на 99% покроет первоначальные нужды. Прелесть сего источника в наличии русской версии.
Система контроля версий выбрана, но это лишь инструмент, а документация — это лишь информация об его использовании. Но имея инструмент и умение его применить, необходимо еще и знать, что надо с его помощью делать. Так что рассмотрим основные бранчи, которые необходимо создать на проекте. Приведенная схема не нова, не мною придумана, однако мною прекрасно заюзана. И так:
Теперь давайте немного уточним, что здесь что. Главные два бранча, которые могут быть ( в некоторых случаях, вообще, независимыми друг от друга): Relise и Stable Next Version. Все остальные — это ответвления от этих двух.
Relise – последняя зарелизеная версия. Именно эта версия сейчас должна находиться в пользовании. Разумеется, если таковой еще не было, то и эта ветка будет отсутствовать или пустовать.
Hot Fix – бранч от ветки Relise для фикса какой либо баги, которая всплыла в финальной версии программы и требует фикса. Как правило, эти фиксы делаются ASAP, но тем не менее очень важно выполнять каждый фикс в отдельной ветке и не вмерживать в основную ветку Relise до момента окончания работы над фиксом. О том, что считать окончанием работы мы еще поговорим.
Stable Next Version – ветка, которая содержит стабильный код следующей версии. Следующая версия еще находиться в разработке, поэтому эта ветка НЕ содержит всего функционала, однако в ней размещаются части кода, которые уже считаются стабильными.
Development Version – ветка кода, в которой происходит разработка: отличие данной ветки от стабильной лишь в том, что она не проходила процедуру оценки стабильности, поэтому ее код не может считаться стабильным.
New Feather – именно в этих бранчах происходит разработка нового функционала и при окончании разработки, они вмерживаются в основную для них ветку «Development Version».
Итого, процесс выглядит следующим образом:
Рассмотрим теперь еще более пристально, что происходит в каждом из бранчей
New Feather
Работа по реализации функционала считается законченной не тогда, когда программист бьет себя в грудь и кричит, что оно уже работает, а когда выполнены такие требования:
Первый пункт позволяет удостоверится, что задача выполнена корректно, в соответствии с документацией; второй же больше направлен на написание тестов и является одним из строжайших правил, обходить которое могут очень малое число лиц или при особых обстоятельствах.
При выполнении всех выше указанных требований, код перемещается в бранч:
Development Version
При уже упомянутом соблюдении требований прошлого уровня, живучий код попадает сюда, но пока это происходит локально: на машине девелопера, который посмел думать, что его код уже заслуживает права быть влитым в бурную стаю его старших собратьев. Тут действуют уже другие, более взрослые законы стаи. После локального мержа своей ветки в ветку разработки, программист обязан выполнить все Unit-тесты проекта, дабы удостовериться, что его код НЕ ломает ничего в чужом коде. Тут действуют такие законы выживания кода:
Жесткое соблюдение этих правил показывает существенное повышение качества кода, так как нежелание исправлять за других их ошибки, разработчики начинают активно выделять ключевые участки своего кода и покрывать его тестами. Введение этих правил позволило мне, уже не на одном проекте, существенно уменьшить количество багов найденных на стадии активного тестирования. Особенно эффективно правила показали себя в командах, где 50 или более процентов составляют джуны.
Раз в два три дня на этой ветке выполняется Small Test Suite, а так же интеграционные тесты, по результатам чего, код перемещается в стабильную ветку или отправляется на доработку.
Stable Next Version
Именно эта ветка отправляется тестерам для Full Test Suite: иногда от нее стоит ответвлять небольшие бранчи для мелких фиксов.
Continues integration
Само собой, все описанное выше должно быть МАКСИМАЛЬНО автоматизировано. Я в своей практике привык использовать для большинства задач TeamCity, чего и Вам желаю. Чего именно с ее помощью можно добиться:
А что же касательно людей
Мы как-то отдалились от главного эпицентра событий – работника. По большому счету в команде все делятся на исполнителей и лида команды (который по мере возможности так же вступает в игру, как исполнитель, если того требуют обстоятельства). И самой интересной фигурой в команде, разумеется, является лид проекта.
Интересанта эта фигура по нескольким причинам: во-первых у него есть основное право определять срок разработки или способ определения срока разработки. Так же этот человек осуществляет разделение работы. Но, не смотря на все права, разумеется, он ответственный за разработку продукта в целом и от его видения картины целиком и умения мыслить стратегически, зависит судьба всей команды.
Любопытно, но некоторые менеджеры не осознают своей ответственности за происходящее, но благо — это не относиться к серьезным командам. Чаще всего на моей практике менеджер не совсем свободен выбирать себе команду, а лишь, как максимум, добирать потом самостоятельно новых сотрудников, но первичный костяк ему, скорее всего, будет предоставлен. Стоит понимать, что это, в некотором роде, как ноутбук предоставленный программисту для работы: если программист не выполнит ключевую задачу, ссылаясь на не стабильность ОС на его казенном ноутбуке, вряд ли такой программист в обозримом бедующем получит хороший результат. Так же и менеджер, который в некотором роде способен выжимать максимум из той команды, которая ему досталась, в идеале он находит прекрасное взаимное понимание с командой и держателем бизнеса. Хороший менеджер незаметен, а его команда постоянно приносит результат.
Вернемся к праву определения времени — есть, как минимум, четыре распространенных подхода к решению проблемы определения времени, которое необходимо на решение той или иной задачи.
Разумеется грамотный лид всегда после выяснения времени умножит его на мифическое число Пи, тогда получит уже более менее объективную картину происходящего.
Нужно четко понимать, что в обязанности лида входит донести простую мысль о том, что данное время весьма условно. Так же особенно важно уяснить — лид отвечает за ВСЕ, что делает команда! Эта мысль достаточно проста. На каждое право есть и обязанность — если лид имеет право назначать задачи, то он обязан контролировать их исполнение, а значит и вина на нем. С другой стороны лид, который не нашел взаимного понимания с командой, скорее всего не найдет его и с другой командой, в то время как к программисту, который подвел очень может быть найдет подход другой лид, или же его попросту могут перевести на неответственную позицию, где он по-прежнему будет полезен, а вот найти неответственную позицию для лида — довольно сложно.
В следующей статье расскажу о том, какие еще правила важно соблюдать на проекте, что бы увеличить КПД коллективного труда, а так же небольшие правила которые важны для лида что бы быть успешным.
Автор: b0noII
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/git/15182
Ссылки в тексте:
[1] ресурс: http://git-scm.com/book/ru
Нажмите здесь для печати.