Мечты, мечты
Холодными осенними вечерами мы с разработчиками приложений 3D визуализации собирались на кухне… пили кофе… и думали о ней… об эталонной организации разработки.
— У меня знакомые по agile работают: спринты, стори поинты, все дела…
— Да нам бы хотя бы ревью…
Дело в том, что в те времена, у нас с этим было не очень гладко. Например, хранение проектов в git осуществлялось весьма необычно:
- было несколько репозиториев и в каждом хранился какой-то кусочек проекта;
- какие-то репозитории были общими, какие-то относились только к некоторым проектам, какие-то только к одному;
- чтобы получить рабочую копию, нужно было скачать содержимое всех репозиториев и положить в определенные папки.
Поскольку мы работаем с 3D графикой и тогда использовали концепцию «контролы + шаблоны (расположение элементов на экране, логика переходов)», то, если быть конкретнее, дела обстояли так:
- при работе над контролами коммиты шли в репозиторий с базовыми контролами и, возможно, в репозиторий с ресурсами (если уже используемые трехмерные модели нужно было бы использовать в другом месте);
- при работе и с контролами, и с шаблонами (например, если требовалось заменить в приложении фон под панелью со справкой), картинки надо было заливать в репозиторий с ресурсами, а верстку править в репозитории с шаблонами. Если фон был сделан скином (единым стилем), то могло быть задействовано 3 репозитория.
При таком подходе ревью кода было непозволительной по затратам роскошью:
- разработка велась в одной единственной ветке;
- изменения по одной задаче затрагивали несколько репозиториев и отследить, какие коммиты к какой задаче относятся, было очень проблематично.
Как следствие, из-за отсутствия возможности «учиться на ошибках», обмениваться опытом, анализируя код друг друга во время ревью, разработчики не могли совершенствовать свои навыки достаточно быстро. А разрабатывать приложения «побыстрее» — было нужно. И чтобы поддерживать скорость разработки на допустимом уровне, на каждом новом проекте люди занимались теми задачами, которые были аналогичны их задачам на предыдущих проектах. Т.е. если кто-то ранее работал с 3D картой, ему снова и снова доставались задачи, связанные с картами, или если кто-то однажды разработал компонент «график», он был обречен на графики. И в этом есть своя логика, т.к. быстрее задачу реализует тот, кто сталкивался с аналогичными или идентичными ей. В итоге получилось, что разработчики специализируются на конкретных вещах и не взаимозаменяемы.
Что касается методологий разработки и четкого workflow — они тоже не применялись по ряду причин. Начиная от того, что для этого нужно было выделить значительное количество времени на продумывание всех концепций и процессов разработки, заканчивая тем, что это просто некому было привнести. Ни у меня, как у совсем недавно пришедшего сотрудника, ни у ребят не было полномочий на реорганизацию. И оставалось только ворчать и мечтать.
«Там, где есть мечта, всегда есть шанс»
Конечно, для меня, как для человека небезразличного к своей работе, стало целью ситуацию изменить. Иначе, в чем смысл моей деятельности, если я никак не могу положительно повлиять на существующие процессы и обеспечить такие условия работы для людей, при которых они могли раскрывать свои способности и совершенствоваться? Развитие тех, кто создает приложение, кто воплощает идею, спроецированную на бумагу, в жизнь — это развитие и проектов, и компании в целом.
Хорошим шансом для осуществления поставленной цели стал аппрув на разработку нового модуля визуализации нашей платформы. Этот проект был не похож на другие, т.к. представлял собой не разработку приложения на платформе, а реализацию части самой платформы. Поэтому здесь мы не были привязаны к той странной концепции хранения и работы с проектами во множестве git-репозиториев, что показалось мне замечательной возможностью ввести ревью кода.
Вот, кстати, что у нас получилось
И вот одним прекрасным зимним утром я атаковала архитектора проекта с предложением ввести Gitflow. Сначала он мою идею воспринял противоречиво, но на то были причины: не всегда подходит какая-то стандартная модель. Однако, в процессе общения был придуман наиболее подходящий для данного проекта вариант, который мы теперь успешно используем.
Наш модифицированный Gitflow представляет собой следующую схему:
- есть основная ветка (мы назвали ее master, но можно дать любое название, чтобы не сбиваться с толку);
- есть спринт в Jira, сформированный из задач бэклога, которые объединены одной микро-целью;
- разработчик берет задачу из списка открытых в рамках спринта в прогресс и создает feature-ветку от master, указав в наименовании своей feature-ветки код задачи (например, PLAYER-55);
- как только работа над задачей завершена, разработчик отправляет свою работу на ревью: через Gitlab создает merge request в master и переводит задачу в Jira на Review с указанием в комментарии ссылки на merge request;
- если ревью пройдено и все дискуссии закрыты, то задача в Jira закрывается, feature-ветка вмерживается в master и удаляется;
- если после ревью есть замечания — в Jira задача переоткрывается с Review и проходит алгоритм с начала, за исключением того, что feature-ветка уже создана.
Когда все задачи закрыты, мы выходим на стадию релиза:
- от master отбранчевывается release-ветка, которая именуется двумя цифрами, например, release-3.0, где 3 — это номер версии проекта, а 0 — номер release-ветки (соответственно, следующая release-ветка будет называться release-3.1 и т.д.);
- далее проводится тестирование release-кандидата (обычно это разработка небольших демок);
- если в процессе тестирования дефектов не обнаружено, то release-кандидат готов к продакшену: последний коммит в release-ветке помечаем тэгом продакшена, состоящим из 3-х цифр (например, prod-3.0.0, где 3 — это номер версии проекта, 0 — номер release-ветки, 0 — номер продакшн версии), далее release-ветка вмерживается в master и не удаляется, в отличие от классического Gitflow;
- если дефекты все-таки обнаружены, то они регистрируются в Jira как Bug и далее процесс исправления бага аналогичен работе с задачей в feature-ветке (только отбранчевывается она от release, а не от master) и когда все баги закрыты, мы проставляем тэг продакшена, версия выводится в прод и release-ветка вмерживается в master, не удаляясь.
На случай, если баги будут обнаружены в продакшене тоже есть договоренность:
- работа над такими багами также ведется в release-ветке данной версии прода, если правки критически срочные, они помечаются как hot fix и осуществляются прямо в release-ветке тимлидами;
- в остальном работа над такими багами аналогична работе над багами, обнаруженными в release-кандидате.
Итак, почему именно Gitflow и именно такой?
- Ввод feature-веток — способ ввести ревью, что позволяет обмениваться опытом, повышать общий уровень квалификации команды, и, самое главное, как следствие — избежать попадания в готовый продукт некачественного кода, который не имеет общего стиля, сложен для восприятия и полон багов.
- Думаю, многим знакома ситуация, когда проект оценен по ТЗ и спецификациям, на него выделен бюджет, вы реализовываете функционал согласно требованиям в документации, но тут за спиной, откуда ни возьмись, спавнится кто-нибудь из начальства и вы слышите: «О, а давай ты еще добавишь сюда пару единорогов, заказчику понравится», «А ты можешь сделать возможность по нажатию на регион на карте звонить другу в этом регионе? Это будет бомба, приступай», «Нужно добавить легенду», «Теперь легенду нужно убрать, и подписи тоже», «Удаление подписей было лишним, верни». И все это «бесплатно без регистрации и смс». А потом, при подсчете фактических затрат, выясняется, что больно уж много ушло на разработку при таком небольшом количестве задач (ведь «просьбы» в Jira обычно не регистрируются, т.к. не каждый разработчик может отказать начальнику или послать его регистрировать свою «просьбу», и это можно понять). Ввод правила о наименовании индивидуальных веток кодом Jira и невозможности вмержить в master ветки без привязки к Jira, исключает наличие незарегистрированных работ и возникновение конфликтов, которые могут появиться, если разработчик «начнет качать права», требуя оформить «просьбу» в качестве задачи в Jira, а также позволяет иметь четкое представление о том, какой объем работы был проделан на самом деле (задачи в Jira подтверждаются связанным с ними кодом, написанный код — связью с зарегистрированной задачей).
- Связь Gitflow с Jira в плане актуализации статусов задач помогает избежать ситуации, когда несколько человек делают одну и ту же задачу. В случае с актуализацией статусов согласно своему этапу Gitflow всем будет видно, что такие-то задачи уже в прогрессе или на ревью, соответственно, под них уже есть feature-ветки, в которых пишется код, и за них браться не нужно. Также наглядно видно, кто что делает, и какие работы могут друг на друга повлиять, кому из ребят стоит чаще контактировать и договариваться о той или иной реализации, чтобы при мерже не пришлось долго и мучительно разруливать конфликты их кода.
- Поскольку мы разрабатываем платформу для создания приложений, то стоит задуматься о том, что чьи-то готовые продукты будут зависеть от нашей политики поддержки старых версий платформы и введения новых. Не исключены ситуации, когда кто-то из пользователей платформы по каким-либо причинам будет использовать не последнюю версию платформы и обнаружит баг, связанный с работой платформы. Если мы будем удалять release-ветки, мы не сможем помочь нашим пользователям в такой ситуации, тем более, если функции, которые они используют в своей версии, удалены или модифицированы в новой реализации платформы. Соответственно, сохранение release-веток позволяет оказать поддержку пользователям, которые работают не с последней версией платформы.
Что насчет Agile?
Как вы, наверное, уже заметили, мы стали потихоньку приближаться к agile scrum принципам разработки, начав с разбиения задач на спринты по микро-целям.
Далее были введены Planning Poker, Story Points, анализ скорости команды, ретроспектива.
Участие в Planning Poker и присвоение Story Points задачам позволяют команде иметь более целостное представление о проекте, об устройстве его архитектуры, о том, к чему вообще стремимся и что должно получиться в итоге. Люди получают возможность мыслить системно, а не только в рамках своих задач. Это благоприятно отражается и на их развитии как профессионалов, и на самом проекте:
- предлагаются новые полезные фичи, потому что разработчикам становится яснее, что и где можно улучшить в целом;
- чаще обнаруживаются ошибки и недоработки, которые могли бы стать явно заметны лишь в момент эксплуатации платформы.
Благодаря наличию данных о количестве завершенных в спринте задач и соответствующих им Story Points появляется возможность проанализировать скорость команды разработки, чтобы в дальнейшем осуществлять более грамотные планирование и оценку сроков.
Правда, есть и некоторое огорчение в рамках нашего проекта в этом плане: состав команды очень часто меняется, потому что некоторых разработчиков периодически забирают на срочные проекты, заменяя их освободившимися от задач. Из-за этого оценка скорости каждый раз обнуляется. Ее практически невозможно посчитать в таких условиях. Единственный выход, который придумали — это собирать данные о каждом составе по 3-4 спринта, а потом пробовать выявить среднее значение.
«А давайте по-быстрому» или 3 полноценных демо-приложения за месяц
Конечно, разработку приложений никто не отменял. Особенно, если они необходимы для выхода к глобальным целям компании. Особенно, если очень срочно необходимы. И в последнее время необходимость в скоростной реализации демо-приложений для показов сильно возросла.
Разумеется, поработав в новой парадигме, возвращаться к старым разговорам совсем не хотелось. Тогда мы решили использовать части нового модуля визуализации (как целостная система он еще не был до конца подготовлен для тех задач), взяв в качестве ориентира принципы его разработки.
Поскольку пока не все разработчики были в теме workflow, а адаптировать ребят к новому устройству разработки было большим риском в плане сроков наших «горящих» демок, мы попытались найти некую «золотую середину» между прошлым и, надеюсь, будущим. В итоге, вот, что получилось при частичном использовании принципов нового модуля визуализации на демках:
- Маленькие команды. 2-3 разработчика, дизайнер, тестер и управленец.
- Параллельная разработка (раньше сначала создавались контролы, потом шаблоны с внешностью и логикой приложения).
- Использование задач типа Story в Jira. Четких спецификаций и ТЗ не было, поэтому я собирала всю имеющуюся информацию по ожидаемому поведению и внешнему виду приложения и оформляла все это в Story. По ним же потом проводилось тестирование, что у тестеров вызвало положительную реакцию, ведь вся информация была собрана в одном месте, но при этом разбита на функциональные части, что облегчало проверку. Да и команде в целом не пришлось вычитывать кучу официального текста, чтобы правильно понять и выполнить задачу. Также, в отличие от вордовских документов со спецификациями, Story быстрее актуализировались, люди быстрее получали описания с новыми уточнениями и, соответственно, быстрее приступали к их реализации.
- Gitflow с develop и master ветками, но без feature:
- вся разработка велась в develop-ветке, но чтобы исключить наличие незарегистрированных задач, каждый коммит обязательно должен был отмечаться кодом задачи из Jira, в рамках которой он осуществлялся;
- когда все задачи, запланированные в релиз, были отрезолвлены, собирался новый билд: тимлидом проводилось код-ревью develop-ветки и, если там все было ок, изменения вмерживались в master с присвоением тэга с номером билда. Если в процессе ревью выявлялись грубые ошибки и нарушения — код отправлялся на правки и только после их внесения и повторной проверки вмерживался в master.
- билды нумеровались двумя цифрами, например, 0.1 — это всегда номер первого тестового билда, где 0 — обозначает принадлежность к продакшн-версии, 1 — номер сборки. И так, в номере каждого следующего тестового билда увеличивалась последняя цифра, до тех пор, пока тестировщик и управленец не дадут заключение о том, что билд готов к выводу в продакшн. Соответственно, если таковым являлся четвертый тестовый билд (0.4), то он становился первым продакшн билдом (1.0) и в master-ветке проставлялся соответствующий тэг. Если в продакшене обнаруживаются дефекты, и продакшн билд отправлялся на правку, то при нумерации всех последующих билдов также увеличивается вторая цифра (1.1, 1.2 и т.д.).
Таким образом, в течение месяца мы реализовали 3 полноценных демо-приложения, о которых получили положительные отзывы и которые продолжают быть полезными. Ранее нам не удавалось реализовать подобный функционал столь быстро и при таком количестве людей в команде.
In my humble opinion
Что думаю об этом всем лично я?
- Что организация процессов действительно влияет на результат и что прислушиваться к мировым практикам разработки, придуманным самими разработчиками и ориентированными на них, не просто «стильно, модно, молодежно», а необходимо (после сдачи демок, впервые за несколько лет практики, мы продолжили заниматься остальными проектами, а не сидели до ночи еще 2 недели после сдачи, в поте лица правя кучи обнаруженных заказчиком позорных дефектов).
- Уровень хаоса, недопонимания и стресса на проектах с четким workflow ниже (люди лучше оснащены актуальной информацией, знают, где ее достать при необходимости).
- Грамотное использование инструментов организации проектов влияет на развитие самих проектов и их участников (благодаря оптимизации ведения разработки в Gitlab, Jira, введению принципов agile scrum, появилась возможность обмена опытом в команде, прокачивания навыков работы в команде, чаще стала осуществляться передача знаний и опыта тимлидов junior и middle разработчикам).
Вот, в чем секрет
Несмотря на вышеперечисленные выводы, и еще кое-что стало очевидным для меня:
— Не все готовы к тому, о чем они мечтают.
Порой, когда мы наблюдаем за чем-то со стороны, нам кажется, что это что-то хорошее, полезное, необходимое для успеха, правильное и эталонное. Но стоит мечте стать реальностью, как мы понимаем: «Это не то, что я себе представлял». Так и в работе: кажется, что вот дай тебе такие условия, в которых работают «нормальные компании», и ты расцветешь. Но, увы. И бывает, что ты, не жалея сил, стараешься дать людям то, о чем они грезили как о залоге успеха, а чуда не происходит: работа все равно выполняется не достаточно качественно, и ты понимаешь, что, возможно, принял чьи-то типичные слова поддержки кухонного разговора за реальные стремления и мечты.
Так что в процессе введения новых правил и принципов мы столкнулись не только с положительными откликами и результатами, но и с негативным восприятием происходящего. Кому-то работа с Jira и Gitlab казалась лишней возней, и изменить это восприятие было крайне сложно, пока люди не сталкивались с проблемной ситуацией, произошедшей из-за игнорирования общепринятого workflow. Некоторые задачи все равно выполнялась халтурно, описания в Story и постановки задач не брались во внимание или воспринимались как «личные просьбы» и не выполнялись, несмотря на регистрацию в Jira с четкой постановкой. В общем, билды с некачественной или несоответствующей постановке реализацией все равно появлялись на свет, а некоторые баги переоткрывались из билда в билд. Хотя итоговый результат получился положительным во всех демках, я все равно задумалась над тем, что с ребятами, кто ответственно подходит к работе, кому важно выдать максимально высокий результат, мы успевали не только реализовать необходимый функционал, но и ввести новые фичи, оптимизировать приложение и «добавить рюшечек». А с командами, где кто-то мог позволить себе полениться или был менее заинтересован в достижении максимально качественного результата, мы реализовали только основной функционал и пару небольших фич по дополнительному требованию заказчика уже после сдачи.
Тут-то ко мне и пришел, возможно, самый главный мой вывод:
— Не процесс, не технологии — истинные залоги успеха, а те, кто творит, создает, воплощает в реальность идею, — люди и их отношение к своей работе.
Музыкант, который вкладывает душу в свое произведение, затронет слушателей, играя даже на самом дешевом и неудобном инструменте. А дай ему Страдивари — он сведет аудиторию с ума. И есть те, кому хоть Страдивари, хоть последнюю разработку передовых производителей инструментов предоставь — все звучать будет неважно.
Можно обеспечить людей комфортными условиями и топовыми технологиями, но в итоге получить неудовлетворительный результат их деятельности, потому что «и так сойдет». А можно при наличии не самых удачных, а порой даже препятствующих грамотной реализации, технологий получить достойный результат, потому что те, кто его добивался — не могут позволить себе сдать недоделанную или плохо сделанную работу. И очень важно именно таких участников команды разглядеть, поддержать, именно к ним уметь прислушаться и создать для их деятельности благоприятные условия.
Технологии и организация процессов действительно имеют влияние на результат и очень важны, но главный залог успеха — в талантливых, ответственных и стремящихся к развитию людях.
Автор: mimila
