- PVSM.RU - https://www.pvsm.ru -
Холодными осенними вечерами мы с разработчиками приложений 3D визуализации собирались на кухне… пили кофе… и думали о ней… об эталонной организации разработки.
— У меня знакомые по agile работают: спринты, стори поинты, все дела…
— Да нам бы хотя бы ревью…
Дело в том, что в те времена, у нас с этим было не очень гладко. Например, хранение проектов в git осуществлялось весьма необычно:
Поскольку мы работаем с 3D графикой и тогда использовали концепцию «контролы + шаблоны (расположение элементов на экране, логика переходов)», то, если быть конкретнее, дела обстояли так:
При таком подходе ревью кода было непозволительной по затратам роскошью:
Как следствие, из-за отсутствия возможности «учиться на ошибках», обмениваться опытом, анализируя код друг друга во время ревью, разработчики не могли совершенствовать свои навыки достаточно быстро. А разрабатывать приложения «побыстрее» — было нужно. И чтобы поддерживать скорость разработки на допустимом уровне, на каждом новом проекте люди занимались теми задачами, которые были аналогичны их задачам на предыдущих проектах. Т.е. если кто-то ранее работал с 3D картой, ему снова и снова доставались задачи, связанные с картами, или если кто-то однажды разработал компонент «график», он был обречен на графики. И в этом есть своя логика, т.к. быстрее задачу реализует тот, кто сталкивался с аналогичными или идентичными ей. В итоге получилось, что разработчики специализируются на конкретных вещах и не взаимозаменяемы.
Что касается методологий разработки и четкого workflow — они тоже не применялись по ряду причин. Начиная от того, что для этого нужно было выделить значительное количество времени на продумывание всех концепций и процессов разработки, заканчивая тем, что это просто некому было привнести. Ни у меня, как у совсем недавно пришедшего сотрудника, ни у ребят не было полномочий на реорганизацию. И оставалось только ворчать и мечтать.
Конечно, для меня, как для человека небезразличного к своей работе, стало целью ситуацию изменить. Иначе, в чем смысл моей деятельности, если я никак не могу положительно повлиять на существующие процессы и обеспечить такие условия работы для людей, при которых они могли раскрывать свои способности и совершенствоваться? Развитие тех, кто создает приложение, кто воплощает идею, спроецированную на бумагу, в жизнь — это развитие и проектов, и компании в целом.
Хорошим шансом для осуществления поставленной цели стал аппрув на разработку нового модуля визуализации нашей платформы. Этот проект был не похож на другие, т.к. представлял собой не разработку приложения на платформе, а реализацию части самой платформы. Поэтому здесь мы не были привязаны к той странной концепции хранения и работы с проектами во множестве git-репозиториев, что показалось мне замечательной возможностью ввести ревью кода.
[2]
Вот, кстати, что у нас получилось
И вот одним прекрасным зимним утром я атаковала архитектора проекта с предложением ввести Gitflow. Сначала он мою идею воспринял противоречиво, но на то были причины: не всегда подходит какая-то стандартная модель. Однако, в процессе общения был придуман наиболее подходящий для данного проекта вариант, который мы теперь успешно используем.
Наш модифицированный Gitflow представляет собой следующую схему:
Когда все задачи закрыты, мы выходим на стадию релиза:
На случай, если баги будут обнаружены в продакшене тоже есть договоренность:
Итак, почему именно Gitflow и именно такой?
Как вы, наверное, уже заметили, мы стали потихоньку приближаться к agile scrum принципам разработки, начав с разбиения задач на спринты по микро-целям.
Далее были введены Planning Poker, Story Points, анализ скорости команды, ретроспектива.
Участие в Planning Poker и присвоение Story Points задачам позволяют команде иметь более целостное представление о проекте, об устройстве его архитектуры, о том, к чему вообще стремимся и что должно получиться в итоге. Люди получают возможность мыслить системно, а не только в рамках своих задач. Это благоприятно отражается и на их развитии как профессионалов, и на самом проекте:
Благодаря наличию данных о количестве завершенных в спринте задач и соответствующих им Story Points появляется возможность проанализировать скорость команды разработки, чтобы в дальнейшем осуществлять более грамотные планирование и оценку сроков.
Правда, есть и некоторое огорчение в рамках нашего проекта в этом плане: состав команды очень часто меняется, потому что некоторых разработчиков периодически забирают на срочные проекты, заменяя их освободившимися от задач. Из-за этого оценка скорости каждый раз обнуляется. Ее практически невозможно посчитать в таких условиях. Единственный выход, который придумали — это собирать данные о каждом составе по 3-4 спринта, а потом пробовать выявить среднее значение.
Конечно, разработку приложений никто не отменял. Особенно, если они необходимы для выхода к глобальным целям компании. Особенно, если очень срочно необходимы. И в последнее время необходимость в скоростной реализации демо-приложений для показов сильно возросла.
Разумеется, поработав в новой парадигме, возвращаться к старым разговорам совсем не хотелось. Тогда мы решили использовать части нового модуля визуализации (как целостная система он еще не был до конца подготовлен для тех задач), взяв в качестве ориентира принципы его разработки.
Поскольку пока не все разработчики были в теме workflow, а адаптировать ребят к новому устройству разработки было большим риском в плане сроков наших «горящих» демок, мы попытались найти некую «золотую середину» между прошлым и, надеюсь, будущим. В итоге, вот, что получилось при частичном использовании принципов нового модуля визуализации на демках:
Таким образом, в течение месяца мы реализовали 3 полноценных демо-приложения, о которых получили положительные отзывы и которые продолжают быть полезными. Ранее нам не удавалось реализовать подобный функционал столь быстро и при таком количестве людей в команде.
Что думаю об этом всем лично я?
Несмотря на вышеперечисленные выводы, и еще кое-что стало очевидным для меня:
— Не все готовы к тому, о чем они мечтают.
Порой, когда мы наблюдаем за чем-то со стороны, нам кажется, что это что-то хорошее, полезное, необходимое для успеха, правильное и эталонное. Но стоит мечте стать реальностью, как мы понимаем: «Это не то, что я себе представлял». Так и в работе: кажется, что вот дай тебе такие условия, в которых работают «нормальные компании», и ты расцветешь. Но, увы. И бывает, что ты, не жалея сил, стараешься дать людям то, о чем они грезили как о залоге успеха, а чуда не происходит: работа все равно выполняется не достаточно качественно, и ты понимаешь, что, возможно, принял чьи-то типичные слова поддержки кухонного разговора за реальные стремления и мечты.
Так что в процессе введения новых правил и принципов мы столкнулись не только с положительными откликами и результатами, но и с негативным восприятием происходящего. Кому-то работа с Jira и Gitlab казалась лишней возней, и изменить это восприятие было крайне сложно, пока люди не сталкивались с проблемной ситуацией, произошедшей из-за игнорирования общепринятого workflow. Некоторые задачи все равно выполнялась халтурно, описания в Story и постановки задач не брались во внимание или воспринимались как «личные просьбы» и не выполнялись, несмотря на регистрацию в Jira с четкой постановкой. В общем, билды с некачественной или несоответствующей постановке реализацией все равно появлялись на свет, а некоторые баги переоткрывались из билда в билд. Хотя итоговый результат получился положительным во всех демках, я все равно задумалась над тем, что с ребятами, кто ответственно подходит к работе, кому важно выдать максимально высокий результат, мы успевали не только реализовать необходимый функционал, но и ввести новые фичи, оптимизировать приложение и «добавить рюшечек». А с командами, где кто-то мог позволить себе полениться или был менее заинтересован в достижении максимально качественного результата, мы реализовали только основной функционал и пару небольших фич по дополнительному требованию заказчика уже после сдачи.
Тут-то ко мне и пришел, возможно, самый главный мой вывод:
— Не процесс, не технологии — истинные залоги успеха, а те, кто творит, создает, воплощает в реальность идею, — люди и их отношение к своей работе.
Музыкант, который вкладывает душу в свое произведение, затронет слушателей, играя даже на самом дешевом и неудобном инструменте. А дай ему Страдивари — он сведет аудиторию с ума. И есть те, кому хоть Страдивари, хоть последнюю разработку передовых производителей инструментов предоставь — все звучать будет неважно.
Можно обеспечить людей комфортными условиями и топовыми технологиями, но в итоге получить неудовлетворительный результат их деятельности, потому что «и так сойдет». А можно при наличии не самых удачных, а порой даже препятствующих грамотной реализации, технологий получить достойный результат, потому что те, кто его добивался — не могут позволить себе сдать недоделанную или плохо сделанную работу. И очень важно именно таких участников команды разглядеть, поддержать, именно к ним уметь прислушаться и создать для их деятельности благоприятные условия.
Технологии и организация процессов действительно имеют влияние на результат и очень важны, но главный залог успеха — в талантливых, ответственных и стремящихся к развитию людях.
Автор: mimila
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/3d/281687
Ссылки в тексте:
[1] Image: https://habrastorage.org/webt/rm/00/ck/rm00ckupk_ujqwvyb67trgsuoho.png
[2] Image: https://habrastorage.org/webt/_s/w_/a1/_sw_a1c_qe13aopjzqk4ywvwqqy.png
[3] Image: https://habrastorage.org/webt/yu/op/tl/yuoptlkujmmptndxhjinc1ekyf4.jpeg
[4] Image: https://habrastorage.org/webt/u1/s_/hi/u1s_hiaeainwj8hcozdq-6ivyt0.jpeg
[5] Image: https://habrastorage.org/webt/m-/mp/wi/m-mpwis3dsb8yijvc45irqk4gwe.jpeg
[6] Источник: https://habr.com/post/413025/?utm_source=habrahabr&utm_medium=rss&utm_campaign=413025
Нажмите здесь для печати.