Привет, Хабр! Представляю вашему вниманию перевод статьи «Рой agile: как организовать совместную работу для команд разработчиков программного обеспечения» Стивен Фрейн.
Фото: Фликр Успешные agile-команды склонны ограничивать незавершенную работу (WIP, незавершенная работа).
Независимо от того, предпочитают ли они Scrum, Kanban или какую-либо другую гибкую методологию, эти команды отдают приоритет быстрой разработке полезных функций превыше всего.
Их больше беспокоит праздная работа (давние незаконченные истории), чем праздные руки (есть ли у людей свободное время, не связанное с запланированной работой).
Соответственно, они определяют высокоприоритетные истории и «роятся» вокруг них, так что вся команда или многие из них сосредоточены на одной истории до ее завершения.
Вместо того, чтобы делить бэклог на несколько отдельных частей, которые каждый член команды может выполнять индивидуально, высокопроизводительные agile-команды предпочитают работать семейным стилем — они делают все возможное, чтобы завершить самые важные элементы бэклога.
Преимущества ограничения незавершенного производства хорошо известны, включая большую концентрацию, более быстрое выполнение, меньшее время цикла и меньшие потери.
Эти преимущества делают практику «роения» широко распространенной.
Однако, хотя многие авторы отмечают необходимость организации работы таким образом, чтобы обеспечить возможность роения, найти конкретные указания, как это сделать, сложно.
Первый шаг — понять, как организовать работу так, чтобы она была разделена между членами команды.
К счастью, существует ряд конкретных подходов, которые можно использовать, чтобы сделать работу более доступной.
Разложить работу на архитектурные слои Работа становится более делимой, когда она разложена на архитектурные слои.
Отдельные пользовательские истории должны быть представлены как тонкие вертикальные срезы функциональности, проходящие через все уровни приложения, от пользовательского или программного интерфейса, через бизнес-логику до уровня базы данных.
Нам нужны пользовательские истории, позволяющие преодолеть все архитектурные уровни, потому что мы хотим предоставить владельцам продукта работающее программное обеспечение, а не изолированные технические компоненты, которые еще не отвечают потребностям бизнеса и не могут быть оценены нетехническими людьми.
Несмотря на это, нам не нужен один и тот же человек для реализации всех этих слоев.
Например, пользовательскую историю, позволяющую создавать элементы в каталоге продуктов, можно разумно разделить между несколькими разработчиками по архитектурным уровням, где один разработчик создает интерфейс, другой работает с базой данных, а третий разрабатывает необходимые контроллеры и бизнес-логику.
для передачи данных между ними.
Сборка кода с использованием интерфейсов Работа становится более доступной, если она построена с использованием интерфейсов.
В базе кода интерфейсы создают интерфейсы для автотестирования, внедрения зависимостей и гибкости архитектуры.
Внутри команды интерфейсы создают зоны ответственности, которые можно поручить одному из разработчиков.
Например, если наш каталог продуктов разделен на две базы данных, часть продуктов находится в реляционной базе данных, а часть в документно-ориентированной, мы можем использовать шаблон проектирования DAO, определяя единый интерфейс для доступа к данным о продуктах и создавая отдельные реализации для каждой базы данных.
Создавайте фрагменты кода параллельно Работа также становится более доступной, когда она распараллелена.
Хотя логично, что некоторые задачи выполняются раньше других (например, мы должны определить интерфейс перед его реализацией), мы должны быть осторожны и не устанавливать зависимости для всех задач от начала до конца (одна задача завершается до начала следующей), когда определяем зависимости запуска задач (одна задача запускается раньше запуска следующей).
При итеративном подходе к разработке мы принимаем меняющиеся требования и поэтому не должны бояться создавать зависимые вещи частично параллельно.
Например, мы могли бы начать реализацию нашего интерфейса доступа к данным о продукте до того, как интерфейс будет полностью доработан, понимая, что мы не сможем полностью завершить реализацию, пока интерфейс не будет готов.
Такое распараллеливание позволит большему количеству людей работать одновременно и создаст ценные циклы обратной связи между спецификацией и реализацией.
Отделите основную разработку от вспомогательной деятельности.
Другой способ повысить степень разделения — отделить основную разработку от вспомогательной деятельности.
Например, пока один член команды работает над кодом функции, другой может генерировать тестовые данные, разрабатывать комплексные сценарии с использованием дополнительных систем или собирать недостающие требования.
Даже если код, необходимый для пользовательской истории, настолько мал, что его лучше всего может выполнить один человек, гибкая группа может помочь справиться со всеми другими частями успешной разработки программного обеспечения, которые лежат за пределами кода, что в противном случае привело бы к ненужным переключениям.
их исполнял всего один человек.
Используйте скоординированные пары Независимо от того, как организована наша работа, мы можем сделать ее общедоступной, если попрактикуемся в работе в парах.
То есть вместо того, чтобы делить работу на отдельные участки, мы могли бы координировать пары людей, выполняющих ту или иную задачу.
Обмениваясь идеями и просматривая работу друг друга в режиме реального времени, члены парной команды максимизируют обучение и минимизируют ошибки.
Этой парой может быть парное программирование, как это принято в методологии экстремального программирования, но это также может быть пара инженера по тестированию и разработчика (или любые другие две роли), которые работают бок о бок, чтобы выйти за рамки того, что каждый из них может выполнять индивидуально.
.
Сделайте работу достаточно большой, чтобы ею можно было поделиться.
Крайне важно, чтобы работа, подходящая для роения, была достаточно большой, чтобы ее можно было разделить.
Некоторые куски работы могут быть настолько малы, что их невозможно выгодно разделить между членами команды даже при парной разработке.
Если вы столкнулись с такой ситуацией, спросите, действительно ли рассматриваемая работа является пользовательской историей, имеющей независимую бизнес-ценность, или это на самом деле техническая задача, замаскированная под пользовательскую историю.
В последнем случае вам следует обернуть его в какую-нибудь существующую пользовательскую историю или заполнить остальную часть подразумеваемой пользовательской истории.
Даже если члены команды разделят пользовательскую историю на задачи реализации, они все равно не должны работать изолированно.
Независимо от того, является ли объединение формальным или нет, все люди, работающие над историей, должны регулярно общаться друг с другом и постоянно интегрировать свои результаты, чтобы избежать ненужных недоразумений и связанных с ними переделок.
И последнее: крапивница процветает благодаря общению.
Фундаментальным условием такого движения является разделение.
Работа команды «роением» взаимосвязана.
Чтобы ваши группы двигались в одном направлении, научитесь делать свою работу более общей.
Теги: #Управление разработкой #agile #перевод
-
Будущее Портативных Планшетов
19 Oct, 24 -
Первый «Мир» Для Настоящих Женщин
19 Oct, 24 -
Новые Наушники Sony: Непонятно И Дорого
19 Oct, 24 -
История Аркадного Джойстика
19 Oct, 24
