Структурирование команды разработчиков программного обеспечения - по специализации или по задаче?

Question

Будучи разработчиком программного обеспечения в течение 6 лет, у меня был целый ряд опытов с разными командами, от отрицательных до положительных.

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

Существовал ряд факторов, которые сделали проект успешным, но я думаю, что структура команды была ключевым аспектом этого.

Резюмируя:

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

• Код был строго разделен на слои презентации, бизнеса и данных.

• У каждого разработчика был базовый знание всей системы. Даже если они не были экспертами во всем, у них было общее представление о том, как все висит вместе и может писать код в любом слое, если это необходимо.

• Некоторые задачи включали разработчика во весь вертикальный срез функциональности (включая работу на всех уровнях).

• Другие задачи касались только области приложения, в которой разработчик специализировался (например, просто задача пользовательского интерфейса или просто задача базы данных).

Я думаю, что это хорошо работает, потому что:

• Разработчики смогли узнать всю систему и перейти в другой слой, если это необходимо.

• Разработчики сохранили специализацию, и если разработчику нужна была помощь с чем-то, с чем он не знаком, всегда был человек.

• архитектура был жестким, но людей были гибкими, так как они должны быть.

Существует ли формальный термин для такого рода структуры команды? Это звучит как Agile/SCRUM?

(Это не похоже, полностью планируется в то время.)

Есть мысли?

Answer 1

Я не думаю, что для такого рода команды есть официальное название - отличное от разумного! :) С этой целью я, безусловно, согласен с Робертом Харви.

Каждое решение будет (обычно) охватывать общие области, такие как пользовательский интерфейс, BL, данные; вы также, как правило, охватываете сквозные проблемы, такие как каротаж, упаковка для развертывания и т. д .; и все это будет использовать определенные технологии. Таким образом, для того, чтобы команда была подходящей для проекта, она должна будет хорошо охватить все эти вещи - в начале.

Это горизонтальный вид, которым позаботятся, вертикальный вид (реализующий кусочки функциональности) - это то, где эти люди должны взаимодействовать - и именно здесь возникают практики XP, такие как программирование на основе сверстников, и где перекрестное обучение может действительно начнутся.

В отличие от этого, вас может заинтересовать подход «Хирургическая команда», как описано Фредериком Брукс в его знаменитой книге «The Mythical Man-Month».

На этой странице есть ссылка на "Organization and Team Patterns", что может представлять интерес.

Answer 2

Чем больше навыков, позволяющих вашим разработчикам учиться, тем сильнее, разнообразнее и счастливее будет ваша команда.

Перекрестная подготовка очень важна. Что произойдет, если ваш пользовательский интерфейс будет запущен автобусом? Может ли кто-то еще в команде взять на себя его обязанности?

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