GitHub для управления проектами

Примечание редактора: эта статья - отрывок из нашей недавно обновленной электронной книги: Управление проектами для Teams в GitHub. Чтобы получить полное руководство по созданию высокопроизводительной и гибкой команды разработчиков программного обеспечения, получите бесплатную копию!

Что такое Agile?

Гибкая разработка - или просто Agile - это итеративный подход к разработке программного обеспечения, который подчеркивает гибкость, интерактивность и высокий уровень прозрачности.

Agile-проекты включают в себя частый выпуск пригодного для использования кода, непрерывное тестирование (качество) и признание того, что все, что, как вы думаете, вы знаете сейчас, изменится (реальность!). С помощью нескольких настроек и некоторого базового понимания лучших практик вы можете превратить GitHub в мощную платформу Agile ... и пожинать приятные, приятные преимущества данных GitHub, которые ваша команда уже создает (Подробнее о работе GitHub на сайте: https://elbrusboot.camp/).

GitHub идеально подходит для управления проектами Agile

GitHub заново открыл, что значит совместная работа над кодом. Они выступили за новую эру разработки с открытым исходным кодом, которая естественным образом переросла в прибыльный бизнес, основанный с нуля разработчиками, любящими платформу.

Если у чего-то есть код, скорее всего, он был разработан или усовершенствован на GitHub. Именно здесь лучшие команды разработчиков программного обеспечения в мире пишут, сотрудничают и выпускают потрясающие продукты.

Проблема в фокусе: как большинство инструментов управления проектами терпят неудачу у разработчиков.

Когда GitHub захватил мир разработки, компании, управляющие проектами, поспешили интегрироваться с ним, пытаясь объединить команды управления и разработки. Но все решения имели одну и ту же проблему.

Все они «живут» за пределами GitHub, заставляя разработчиков переходить от инструмента к инструменту для обновления задач, заявок и отчетов. Результатом является «переключение контекста», и это намного дороже, чем мы ожидали.

Люди, как правило, ужасно многозадачны. Исследование, проведенное Журналом экспериментальной психологии, показало, что у людей, которые многозадачны, производительность падает на 40%. Если отвлечься от задачи, потребуется 20–30 минут, чтобы перефокусироваться. Переключение между задачами с низкой производительностью - например, отправка текстовых сообщений другу во время просмотра телевизора - не так уж и сложно. Вернуться туда, где вы были раньше (выйти из зоны перед Netflix), практически не требуется времени.

Но когда задачи сложные, стоимость переключения контекста стремительно растет. Представьте разработчика, который пишет новую функцию. Здесь пятиминутный перерыв занимает гораздо больше пяти минут.

Стив Фентон говорит об этом так:

«Если разработчика прерывают вопросом, он может откладывать свою работу на несколько часов для каждого прерывания. Это связано с тем, что они хранят в своей непосредственной памяти количество данных, пока они работают над функцией. Они проанализируют много кода в той области, над которой будут работать, и спроецируют свои изменения в своем уме, прежде чем они начнут кодировать, и прерывание повлияет на их внимание к этой информации. После прерывания разработчик может решить включить в него другие прерывания, такие как электронная почта, но это увеличивает разрыв и повышает вероятность того, что информация будет скопирована в более труднодоступные места».

Короче: переключение контекста - это плохо.

Ваша роль как руководителя группы должна заключаться в том, чтобы уберечь команду разработчиков от отвлечения внимания от кода. Ваш бизнес от этого будет лучше - доверьтесь нам.

«Важно понимать, что работа, которую мы ожидаем от разработчиков, требует некоторой степени повторяющейся изоляции, чтобы выполнять ее хорошо», - говорит Кристофер Хокинс, блогер по управлению проектами и основатель Cogeian Systems. «Хороший менеджер вмешивается во все, что может поставить под угрозу внимание разработчика, при этом активно запрашивая любые ресурсы, которые могут понадобиться разработчику».

Как помогает ZenHub

Есть причина, по которой мы создали ZenHub, и она связана с тем, почему мы написали эту книгу. Недостаточно наставлять, надеяться или молиться инженерам, чтобы они оставались сосредоточенными. Как компании, занимающиеся программным обеспечением, все - вплоть до инструментов, которые мы используем, - должно в первую очередь укреплять нашу приверженность программному обеспечению. Вот почему мы создали инструмент, который переносит процесс управления проектами и разработки дорожных карт в GitHub. Не близко, не «интегрировано с», а внутри.

Централизация вашей команды в одной системе дает и другие преимущества, например:

• Более точные показатели

Сторонние инструменты приводят к разрозненным хранилищам информации. ZenHub живет там, где живет код - внутри GitHub. Это дает вам наиболее точное представление о том, что на самом деле происходит в вашем рабочем процессе и о ходе выполнения проекта.

• Сосредоточьтесь на продукте, а не на процессе

Руководители проектов не должны тратить свой день на напоминание коллегам об обновлении заявок. Когда все централизовано, менеджеры проектов тратят больше времени на управление проектом и меньше - на людей, которые его создают.

Процессы важны для оптимизации коммуникации и повышения сплоченности команды, но слишком много процессов может похоронить вас в напряженной работе, в то время как важные задачи останутся без внимания. Автоматизированные функции ZenHub позволяют автоматизировать повторяющееся планирование и административную работу, чтобы вы могли сосредоточиться на своей реальной работе.

Использованные источники

На страницах сайта «Публикации государственного университета» вы найдете статьи о недавних научных открытиях и об истории науки, о новых технологиях и фундаментальных основах наук, о людях, посвятивших жизнь науке, и об исторических личностях, о вещах, которые нас окружают, и об удивительных местах на нашей планете.

Мы стремимся показать нашим читателям, которые интересуются наукой и хотят сделать ее своей профессией, возможные направления для исследований не как отвлеченные дисциплины, а как работу реальных людей.