Во первых перестать паниковать! Если процесс уже налажен, очень важно не наломать дров. Но с другой стороны, как новоиспеченный лид, неплохо бы разобраться в том, как и что устроено на проекте и постараться изменить к лучшему то, что считаешь неверным.
В данной статье (точнее ее первой части) я поделюсь своим видением того, что необходимо внедрить на проекте и какие ключевые правила стоит соблюдать, что бы разработка была максимально быстрой и эффективной.
Небольшое отступление для троллей
Много сказанного тут относится к разным областям, не все считают уместным писать об этом в одной статье. Некоторые вещи я буду называть неправильными терминами, так как, возможно, не во всех аспектах моя теоретическая база достаточна. Так же я не претендую на то, что это панацея и результаты на каждом проекте повысятся подобно моим. Само собой есть множество более удачных примеров и решений, я лишь надеюсь, что моя статья может послужить для многих путеводной звездой, особенно, если они хотят что-то изменить в своем процессе разработки.
Исходные данные
Предположим, что Вы руководитель небольшой группы разработчиков (5-7). По-моему субъективному мнению, именно такая самостоятельная единица в количестве до 7 девов и одного тим лида, является наиболее удачной. Так же считаем, что Вашей непосредственной задачей является разработка с момента получения первой документации и заканчивая поддержкой уже вышедшего продукта.
Система контроля версий проекта
Считаю одним из наиболее важных моментов, который отразиться на производительности — это система контроля версий. При выборе оной предлагаю особый упор сделать на легкость бранчевания и мержа веток, а так же на то, что бы она была распределенной. Думаю все уже поняли о чем я =). Само собой рекомендованной я назову git или mercurial. Так, как первый немного более взрослый, то и информации на разных языках больше, а значит этот вариант предпочтительнее, если у Вас в команде те, кому нужно будет осваивать новую систему (а если это еще и джуны с невысокой скоростью освоения англоязычных источников то тем более). Сходу можно назвать ресурс, который на 99% покроет первоначальные нужды. Прелесть сего источника в наличии русской версии.
Система контроля версий выбрана, но это лишь инструмент, а документация — это лишь информация об его использовании. Но имея инструмент и умение его применить, необходимо еще и знать, что надо с его помощью делать. Так что рассмотрим основные бранчи, которые необходимо создать на проекте. Приведенная схема не нова, не мною придумана, однако мною прекрасно заюзана. И так:
- Relies
- Hot Fix #1
- Hot Fix #2
- Etc…
- Stable Next Version
- Development Version
- New feather #1
- New feather #2
- etc…
- Development Version
Теперь давайте немного уточним, что здесь что. Главные два бранча, которые могут быть ( в некоторых случаях, вообще, независимыми друг от друга): Relise и Stable Next Version. Все остальные — это ответвления от этих двух.
Relise – последняя зарелизеная версия. Именно эта версия сейчас должна находиться в пользовании. Разумеется, если таковой еще не было, то и эта ветка будет отсутствовать или пустовать.
Hot Fix – бранч от ветки Relise для фикса какой либо баги, которая всплыла в финальной версии программы и требует фикса. Как правило, эти фиксы делаются ASAP, но тем не менее очень важно выполнять каждый фикс в отдельной ветке и не вмерживать в основную ветку Relise до момента окончания работы над фиксом. О том, что считать окончанием работы мы еще поговорим.
Stable Next Version – ветка, которая содержит стабильный код следующей версии. Следующая версия еще находиться в разработке, поэтому эта ветка НЕ содержит всего функционала, однако в ней размещаются части кода, которые уже считаются стабильными.
Development Version – ветка кода, в которой происходит разработка: отличие данной ветки от стабильной лишь в том, что она не проходила процедуру оценки стабильности, поэтому ее код не может считаться стабильным.
New Feather – именно в этих бранчах происходит разработка нового функционала и при окончании разработки, они вмерживаются в основную для них ветку «Development Version».
Итого, процесс выглядит следующим образом:
- разработка нового функционала стартует в бранчах для нового функционала;
- результат работы вмерживается в бранч разработки;
- раз в три рабочих дня (можно реже или чаще, на усмотрение лида, то есть Вас) проводиться аудит ветки разработки, если ее признают на данном этапе стабильной, то текущий срез вмерживаеться в Stable Next Version;
- в один прекрасный день стабильная ветка становиться веткой Relise и все начинается снова.
Рассмотрим теперь еще более пристально, что происходит в каждом из бранчей
New Feather
Работа по реализации функционала считается законченной не тогда, когда программист бьет себя в грудь и кричит, что оно уже работает, а когда выполнены такие требования:
- Функционал проверен сотрудником QA, дабы удостовериться в правильности выполнения работы;
- Программист может предоставить по каждому компоненту своего кода (классу) следующие тестовые данные:
- В каком диапазоне входных данных компонент работает корректно;
- Сколько времени занимает выполнение каждой задачи компонентом и какое место является самым медленным.
Первый пункт позволяет удостоверится, что задача выполнена корректно, в соответствии с документацией; второй же больше направлен на написание тестов и является одним из строжайших правил, обходить которое могут очень малое число лиц или при особых обстоятельствах.
При выполнении всех выше указанных требований, код перемещается в бранч:
Development Version
При уже упомянутом соблюдении требований прошлого уровня, живучий код попадает сюда, но пока это происходит локально: на машине девелопера, который посмел думать, что его код уже заслуживает права быть влитым в бурную стаю его старших собратьев. Тут действуют уже другие, более взрослые законы стаи. После локального мержа своей ветки в ветку разработки, программист обязан выполнить все Unit-тесты проекта, дабы удостовериться, что его код НЕ ломает ничего в чужом коде. Тут действуют такие законы выживания кода:
- каждый код, который попадает в эту ветку должен быть покрыт тестами;
- если код был вмержен без прохождения всех тестов и вызывает сайд эффект, который мог быть отловлен тестом — то его исправление лежит на программисте, который не удосужился все протестировать!
- если код ломает чужой функционал, но при этом проходит все тесты, то такой баг должен исправлять тот, кто написал кривые тесты.
Жесткое соблюдение этих правил показывает существенное повышение качества кода, так как нежелание исправлять за других их ошибки, разработчики начинают активно выделять ключевые участки своего кода и покрывать его тестами. Введение этих правил позволило мне, уже не на одном проекте, существенно уменьшить количество багов найденных на стадии активного тестирования. Особенно эффективно правила показали себя в командах, где 50 или более процентов составляют джуны.
Раз в два три дня на этой ветке выполняется Small Test Suite, а так же интеграционные тесты, по результатам чего, код перемещается в стабильную ветку или отправляется на доработку.
Stable Next Version
Именно эта ветка отправляется тестерам для Full Test Suite: иногда от нее стоит ответвлять небольшие бранчи для мелких фиксов.
Continues integration
Само собой, все описанное выше должно быть МАКСИМАЛЬНО автоматизировано. Я в своей практике привык использовать для большинства задач TeamCity, чего и Вам желаю. Чего именно с ее помощью можно добиться:
- автоматизированное тестирование, при любых новых изменениях, а так же уведомления программистов почтой о том, что они что-то сломали;
- автоматические билды бранча стабильной версии для тестирования, а так же автоматизация других периодичных билдов (Nightly builds, etc…).
- интеграция системы с баг трекером (ну тут нужно искать связку, которая это позволяет, например TeamCity + YouTrack). Это особенно важно, так как существенно ускоряет взаимодействие между программистом и тестером позволяя:
- Автоматически закрывать баги, парся текст коммита из системы контроля версий;
- Автоматически устанавливать номер билда, в котором бага была закрыта;
- Автоматически устанавливать номер билда, в котором бага была открыта.
А что же касательно людей
Мы как-то отдалились от главного эпицентра событий – работника. По большому счету в команде все делятся на исполнителей и лида команды (который по мере возможности так же вступает в игру, как исполнитель, если того требуют обстоятельства). И самой интересной фигурой в команде, разумеется, является лид проекта.
Интересанта эта фигура по нескольким причинам: во-первых у него есть основное право определять срок разработки или способ определения срока разработки. Так же этот человек осуществляет разделение работы. Но, не смотря на все права, разумеется, он ответственный за разработку продукта в целом и от его видения картины целиком и умения мыслить стратегически, зависит судьба всей команды.
Любопытно, но некоторые менеджеры не осознают своей ответственности за происходящее, но благо — это не относиться к серьезным командам. Чаще всего на моей практике менеджер не совсем свободен выбирать себе команду, а лишь, как максимум, добирать потом самостоятельно новых сотрудников, но первичный костяк ему, скорее всего, будет предоставлен. Стоит понимать, что это, в некотором роде, как ноутбук предоставленный программисту для работы: если программист не выполнит ключевую задачу, ссылаясь на не стабильность ОС на его казенном ноутбуке, вряд ли такой программист в обозримом бедующем получит хороший результат. Так же и менеджер, который в некотором роде способен выжимать максимум из той команды, которая ему досталась, в идеале он находит прекрасное взаимное понимание с командой и держателем бизнеса. Хороший менеджер незаметен, а его команда постоянно приносит результат.
Вернемся к праву определения времени — есть, как минимум, четыре распространенных подхода к решению проблемы определения времени, которое необходимо на решение той или иной задачи.
- Время устанавливается монопольно лидом, на основании справочника «потолок», либо же после совещания с командой. Наиболее неверный способ определения времени;
- Опрос мнения экспертов, которые выполняли схожие задачи. Является довольно не точным, но более предпочтительным вариантом;
- Опрос экспертов, которые выполняли такие же задачи. Наверное самый точный вариант определения времени;
- Делегирование права определение времени от лида к исполнителю, который будет справляться с работой.
Разумеется грамотный лид всегда после выяснения времени умножит его на мифическое число Пи, тогда получит уже более менее объективную картину происходящего.
Нужно четко понимать, что в обязанности лида входит донести простую мысль о том, что данное время весьма условно. Так же особенно важно уяснить — лид отвечает за ВСЕ, что делает команда! Эта мысль достаточно проста. На каждое право есть и обязанность — если лид имеет право назначать задачи, то он обязан контролировать их исполнение, а значит и вина на нем. С другой стороны лид, который не нашел взаимного понимания с командой, скорее всего не найдет его и с другой командой, в то время как к программисту, который подвел очень может быть найдет подход другой лид, или же его попросту могут перевести на неответственную позицию, где он по-прежнему будет полезен, а вот найти неответственную позицию для лида — довольно сложно.
В следующей статье расскажу о том, какие еще правила важно соблюдать на проекте, что бы увеличить КПД коллективного труда, а так же небольшие правила которые важны для лида что бы быть успешным.
Автор: b0noII
