Об улучшении управленческих навыков с помощью повседневных инструментов
Недавно я пытался резюмировать свои старые мысли об управлении рабочим процессом в команде разработчиков. Совершенно очевидно, что управление ИТ-проектами - это вопрос, который достаточно хорошо обсуждается и обрабатывается миллионом (примерно) различных способов. Вероятно, большинство из вас во время работы знакомо с множеством различных программ, таких как Jira или Trello. Я не пытаюсь убедить вас, что с ними что-то не так. Это очень сложные программы, которые могут легко улучшить ваш рабочий процесс. Основная проблема - это скорее отношение, чем инструменты.
В случае небольших начинающих стартапов это тема, которая может вызвать довольно широкое обсуждение в команде. Для многих разработчиков важнее всего просто написать код, а не беспокоиться о том, как правильно отслеживать прогресс. Часто кажется, что мы уделяем время решению таких формальных вопросов, вместо того, чтобы вкладывать их во множество других вещей. На этом начальном этапе развития компании нет времени или людей, которые могли бы сосредоточиться только на управлении. В этой статье я представлю некоторые из своих идей, которые могут улучшить коммуникацию и отслеживание задач в команде разработчиков.
Стоит упомянуть одну вещь. Управление командой - это концепция, которая очень часто глубоко связана с философией компании. Это вещь, которую довольно сложно изменить. У каждой команды свой паттерн и разные инструменты. В то же время стоит отметить, что даже с помощью простых инструментов вы можете очень эффективно автоматизировать командное общение. Возможно, некоторые из вас сочтут это интересным путем, ведущим к изменению отношения. Надеюсь, это поможет вам открыть для себя новые способы общения и оптимизации работы.
Основная идея - адаптировать некоторые шаблоны к повседневному рабочему процессу. Используя такой образ мышления, вы не будете заставлять себя управлять своей работой вне естественного окружения.
Комментарии
Начнем с простого. Все мы используем комментарии в коде. Как правило, они выполняют самые разные функции - от вспомогательных сообщений и подсказок до исчерпывающей документации. Частота и качество их использования сильно различаются в зависимости от команды и подхода. Их качество особенно высоко в портфельных проектах, используемых в процессе набора. Это заставляет меня задаться вопросом, не используем ли мы их слишком часто только как форму демонстрации способности понимать ваш собственный код. С другой стороны, это может показать некоторые опасения, что наш код может быть неправильно понят. Очень часто во время реальной работы мы не уделяем так много внимания.
Я не хочу, чтобы меня воспринимали саркастически, я также являюсь ярым противником мысли, что код должен быть самодокументированным. Да, очень важно сделать ваш код максимально читаемым, но мы никогда не должны предполагать, что это всегда так. Нам часто приходится работать в другой среде, с другими технологиями, а иногда и в другой среде.
Я не хочу подробно останавливаться на том, как и когда мы можем использовать комментарии в качестве документации. Это идея для совершенно отдельной статьи. А пока остановимся на одном, на мой взгляд, самом важном варианте использования. Вы знаете, что важнее документации? Знания! Я имею в виду… общение.
Комментарии следует использовать для общения. Это их основная функция. Таким образом, наши товарищи по команде могут легко читать между строк кода. Как и ваш код, комментарии должны быть прозрачными. Они должны быть написаны в коммуникативной, понятной форме, часто со ссылками на конкретного члена команды, описывающего конкретные проблемы. Особенно полезны для этого расширения редакторов кода, которые предлагают большее визуальное разнообразие комментариев. В случае VS Code мы можем использовать Better Comments. Благодаря этому инструменту мы можем определить любое количество красочных комментариев, и в то же время мы можем увеличить их потенциал. Разные цвета могут отвечать за разные типы сообщений, которые мы хотим доставить остальной части команды.
Делать
Еще один действительно полезный и простой в адаптации инструмент, который поддерживает и автоматизирует общение в команде, - это дерево / список TODO. Опять же, я буду придерживаться расширения VS Code, но многие популярные редакторы кода имеют похожие инструменты (Atom, Sublime, Brackets, WebStorm). Идея состоит в том, чтобы вставить в разные части нашего кода комментарии с префиксом TODO:, а затем они автоматически перейдут в отдельное каталогизированное представление. Таким образом, мы можем определить список задач на определенные дни для себя, а также для других членов команды.
На мой взгляд, это очень мощный инструмент, который может ускорить ваш повседневный рабочий процесс.
Недавно сделал быстрый тест. Я решил открыть расширение Todo Tree внутри папки node_modules.
Как видите, большинство пакетов используют эту методологию. Я не знаю, действительно ли они используют это расширение в своем повседневном рабочем процессе, а если нет, то определенно должны. Кроме того, это действительно отличный способ узнать о различных подходах к написанию значимых комментариев (по крайней мере, с некоторыми из них… Webpack, пожалуйста 😂).
Хорошая идея - сохранять последовательность в комментариях. Используйте тот же шаблон, например:
TODO: (version)[category]<assignee>: description
Другой вариант использования - упрощение определения задач в случае новых, неопытных программистов (или небольших стартапов). Возможность полностью сосредоточиться на исходном коде во время управления задачами может повысить производительность и ускорить процесс разработки.
Git
Мы, разработчики, люди простые. В большинстве случаев мы используем всего пару команд:
git add git clone git commit git push
и, конечно же, один-единственный:
git push -f
Кстати, я настоятельно рекомендую вам попробовать git-flow. Это действительно может ускорить процесс разработки, особенно если у вас нет большого опыта в управлении изменениями.
Как вы думаете, какой из них можно использовать для общения?
git commit
Верно. Давайте найдем способ использовать сообщения коммитов для улучшения наших управленческих способностей.
Недавно я прочитал классную статью Дэна Гослена о написании содержательных сообщений о фиксации. Я рекомендую вам это проверить.
Я не хочу повторять эти аргументы и идеи, поэтому постараюсь изложить другую точку зрения.
Давайте подумаем минутку о причине, по которой мы пишем сообщения о фиксации. После прочтения разделов «Комментарий» и «Задача» вы уже должны знать, к чему это приведет. Правильно - общение. Это может показаться чем-то очевидным, но иногда большинство из нас забывает об использовании этой идеи для создания полезной истории коммитов.
Когда мы пишем комментарии, мы сосредотачиваемся только на эффективном изложении нашей проблемы вне контекста разработки. Конечно, основное использование сообщения фиксации - резюмирование изменений. На самом деле, однако, мы должны помнить, что наше сообщение в конечном итоге попадет в стек других сообщений, создав некую документацию по нашему проекту. Документация сосредоточена на представлении изменений, но если задуматься, разработка программного обеспечения - это всего лишь серия изменений.
Теперь посмотрим на это с другой точки зрения. Поручает ли хороший писатель каждому случайному человеку написать отдельный абзац в своем романе? Как вы можете себе представить, в результате получится настоящий хаос.
Сообщения фиксации могут использоваться для вызова некоторых действий в сторонних сервисах. Например, в Jira вы можете оставить комментарий к своей задаче с помощью одной простой команды:
JRA-34 #comment corrected indent issue
Мне лично не очень нравится эта концепция использования сообщений коммитов в качестве инструмента только для контроля. Хотя эта концепция автоматизации вашего рабочего конвейера звучит интересно, я думаю, что мы должны использовать инструменты в первую очередь для их основных целей. Любые дополнительные функции, например, поддержка автоматизации, должны быть реализованы путем «присоединения» их к основному рабочему процессу. Только если не беспокоить основной вариант использования.
Выводы
Спасибо, что нашли время прочитать эту статью. Даже если вы не почувствовали некоторых идей и мыслей, описанных в нем, я надеюсь, это вдохновило вас в некотором роде подумать о других, необычных способах развития своих управленческих навыков.
