Должны ли мы организовать несколько agile-подгрупп по группам клиентов или по программным компонентам?

Эксперимент.

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

Имея это в виду, мы можем рассмотреть некоторые ключевые моменты, которые следует учитывать при экспериментировании:

• Почему меняется? Уточните проблемы, которые команда намеревается решить, применив эти изменения. Изменение ради изменения «чтобы стать более гибким» не является реальной целью. Ваша настоящая цель — приносить пользу чаще и предсказуемее. Agile — это инструмент, который может помочь вам в этом.

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

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

Фон знаний — одно из самых сложных изменений для полнофункциональных agile-команд. Если ваша команда опирается на знания конкретных людей, перед изменением структуры команды я бы посоветовал:

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

Помните, что не обязательно быть экспертом во всех областях (в большинстве случаев я по-прежнему считаю, что «разработчик с полным стеком» — это заблуждение). Вместо этого нужно иметь Т-образный набор навыков , позволяющий каждой подгруппе выполнять задачи с минимальной зависимостью от других команд.

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

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

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

Если сделать наоборот: несколько команд работают над одним и тем же компонентом с разными клиентскими входными данными, может возникнуть вероятность наступить друг другу на пятки.

Вам необходимо принять во внимание следующее:

• Как вы измеряете успех? Как вы думаете, что будет после замены?
• Не могли бы вы сделать постепенные «пилоты» и посмотреть, действительно ли они приносят пользу? (пример: начните перемещать команду, работающую над одним программным компонентом, и посмотрите, улучшит ли это каким-либо образом производительность)