Решения по разработке программного обеспечения обычно очень легко принимать, когда в команде работают 1–3 человека. Это означает просто быстро поговорить, принять решение и двигаться вперед. Но как насчет того, когда у вас есть 9 человек или, может быть, 15 человек или больше? Каждый раз, когда в вашей команде разработчиков программного обеспечения больше нескольких человек, возникают дополнительные расходы, возникающие всякий раз, когда разработчик в команде принимает повседневные решения. Каждый раз, когда вы добавляете кого-то нового в команду или разработчик начинает работать над новой функцией, возникают дополнительные расходы, которые могут утомить команду, если нет согласованности или четкого понимания.
Когда разработчики программного обеспечения в команде борются со знанием того, как сделать что-то вроде развертывания новой версии кода или что от них ожидается, когда они хотят объединить некоторые изменения в основную ветку, есть возможность достичь согласия со всей командой. . Когда все согласны с тем, как команда хочет обрабатывать такие вещи, как отправка запроса на слияние, команда может быстро двигаться вперед и часто и уверенно вносить новые изменения.
Ниже приведены 7 стратегий, которые могут быть полезны каждой команде разработчиков программного обеспечения, чтобы обеспечить согласованность между всеми членами команды в команде.
1. Стратегия тестирования
Каждый серьезный разработчик программного обеспечения тестирует написанный им код. Иногда это означает запуск приложения и выполнение его вручную. В других случаях это в форме автоматических тестов. Поскольку каждой команде, вероятно, необходимо протестировать приложение, которое они доставляют своим клиентам, важно, чтобы все в команде хорошо понимали, в чем заключается стратегия тестирования. Потратьте некоторое время на то, чтобы обсудить с командой, что команда ожидает от типов тестов, процессов, уровней и т. д., — это хороший способ обеспечить последовательное применение тестирования.
2. Стратегия запроса на слияние
Разработчик начинает работу над новой пользовательской историей. Этот разработчик думает, что с историей покончено, и хочет объединить эти изменения в основную ветку. Что они должны делать? Нужно ли проверять весь новый код? Кто-нибудь может оценить новые изменения? Команда должна иметь хорошее представление о том, что такое стратегия запроса на слияние, чтобы все были согласованы и могли быстро принимать решения относительно того, что им следует делать.
3. Стратегия развертывания
Как мы внедряем новые функции для наших клиентов? Что должно произойти, прежде чем новый код станет доступен нашим клиентам? Ответы на вопросы такого типа иногда бывают сложными и имеют несколько циклов обратной связи. Знание того, как ориентироваться в решениях по развертыванию изменений, может означать разницу между быстрой доставкой ценности и отказом системы.
4. Стратегия управления репозиторием
Командные репозитории для программного обеспечения могут быть дорогими с точки зрения накладных расходов на ясность вокруг репозитория. У некоторых команд есть только один репозиторий, у некоторых — 400 репозиториев, а у большинства — где-то посередине. Каждый раз, когда кто-то присоединяется к команде, репозитории будут одними из первых вещей, к которым они пытаются получить доступ, чтобы они могли получить представление о разработке и о том, как выглядит технический стек. Если разработчик присоединяется к новой команде и начинает просматривать репозитории, но не может быстро определить, для чего предназначен репозиторий, как он настраивает репозиторий, как создает код, как тестирует код и т. д., тогда это информация, которой кто-то должен их научить. Другие вопросы, такие как, когда мы должны создавать новые репозитории или почему у нас есть отдельные репозитории для связанных компонентов системы, должны быть тем, на что все согласны. Стратегия управления репозиториями может гарантировать, что команда упростит себе жизнь и особенно всех, кто присоединяется к команде.
5. Стратегия управления невыполненными работами
Многие команды используют тот или иной тип отставания от предстоящей работы. Иногда команды используют владельца продукта, который «владеет» бэклогом. Разработчики программного обеспечения постоянно узнают что-то новое о своей работе. Это означает, что они находят ошибки, определяют, что нужно добавить что-то новое, или хотят решить некоторые технические проблемы. Хранение невыполненной работы организованной, свежей и расставленной по приоритетам может помочь командам убедиться, что они приносят пользу своим клиентам. Члены команды должны иметь четкое представление о том, каковы их роли и обязанности в бэклоге команды. Как разработчик, я хочу знать, как мне следует подходить к добавлению или обновлению карточек в нашем невыполненной работе. Убедившись, что это хорошо известно и ясно, этот процесс проходит гладко.
6. Стратегия управления дефектами/ошибками
Если разработчик работает над новой функцией в приложении и сталкивается с ошибкой, не связанной с функцией, над которой он работает, что ему делать? Они сразу исправляют это и идут дальше? Они бросают карту в бэклог и уведомляют команду? Есть ли шаги, которые они должны предпринять для сортировки ошибки? Если они создают карточку в бэклоге, есть ли конкретная информация, которую команда ожидает получить в каждой карточке? Самый большой вопрос может заключаться в том, в чем разница между дефектом и ошибкой или есть ли разница? Все эти вопросы должны быть определены в Стратегии управления дефектами/ошибками, чтобы у каждого в команде были некоторые рекомендации о том, как быстро устранять любые ошибки, когда они их обнаруживают, а не в случае их обнаружения.
7. Стратегия поддержки производственной системы
Хотя это последняя стратегия в этом списке, она также обычно является самой важной. Если у вашей команды есть приложение или система приложений в производстве, это обычно означает, что если что-то пойдет не так с какой-либо частью этой системы, ваши клиенты обычно заметят это и пострадают. Каждый раз, когда у клиентов возникают проблемы с приложением, доверие клиента к этому приложению подрывается. Иногда эта уверенность теряется быстро, а иногда требуется время, но ее трудно вернуть, когда она начинает разрушаться. Вот почему важно, чтобы команды обращались с производственными системами так, как будто они являются производственными системами. Это означает, что у команды должен быть надежный подход к мониторингу системы и приложений. Они должны пытаться решать проблемы до того, как они повлияют на клиентов. Когда клиенты затронуты, команда должна решить проблему быстро и с ограниченным риском. Это стратегия, в которой должен быть уверен каждый член команды. Любые сомнения в этой стратегии могут привести к системе, которую никто не захочет использовать, к системе, от которой клиенты не хотят обновлений, или к системе, которую скоро заменят.
Не каждой команде нужно тратить время на согласование этих стратегий. Многие команды работают на полную мощность, и каждый член команды прекрасно понимает, чего команда ожидает друг от друга. Эти команды также находятся в положении, когда адаптация новых членов команды является плавным процессом, когда новый участник может быстро перейти от ходьбы к бегу. Однако, если ваша команда в настоящее время борется с согласованностью или ясностью в отношении какой-либо из рассмотренных стратегий, было бы неплохо уделить некоторое время всей команде и определить стратегию того, как команде следует двигаться вперед. Создайте живой документ для этой стратегии, сделайте его большим и заметным и пересматривайте его каждый раз, когда к команде присоединяется новый член команды. Обязательно повторите его и внесите изменения по мере необходимости. Это гарантирует, что все будут знать и продолжать согласовать то, что команда ожидает друг от друга.
Это вводная статья об этих стратегиях. Я намереваюсь, чтобы это была серия, в которой более подробно рассказывается о том, что такое стратегия, какие цели должны быть перед командой и как лучше всего облегчить обсуждение стратегии. Я также планирую углубиться в каждую стратегию и определить вопросы с примерами ответов, которые являются хорошей отправной точкой для рассмотрения командами. Оставайтесь с нами!
