Читать книгу Искусство Agile-разработки. Теория и практика гибкой разработки ПО - - Страница 26

I
Улучшая гибкость
Глава 4. Инвестируйте в гибкость

Оглавление

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

Если это выглядит как очень трудозатратное дело… что ж, так и есть. Неужели эти инвестиции действительно настолько важны?

Да, действительно настолько.

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

Как сказал Мартин Фаулер[11], «я вижу поразительную параллель между ДХХ (Давид Хейнемейер Ханссон, создатель Ruby on Rails) и Кентом Беком (создатель экстремального программирования). Любой из них, получив в подарок ограниченный мир, посмотрит на его ограничения, которые мы принимаем как должное, сочтет их несущественными и создаст новый мир без них… они просто подложат под них заряд интеллектуального динамита и двинутся дальше. Именно поэтому они могут создавать такие вещи, как экстремальное программирование и Rails, которые встряхивают всю индустрию».

Делайте инвестиции – в них секрет успеха Agile.

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

Список необходимых инвестиций

Все команды Agile

• Получите поддержку руководства, команд и ключевых стейкхолдеров, как описано в главе 5.

• Создайте долговечные кросс-функциональные команды и все время назначайте людей только в эти команды (см. раздел «Выберите или создайте Agile-команды» текущей главы).

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

• Поручайте работу командам, а не отдельным людям. Ожидайте от команд самостоятельного выбора подхода к ежедневному планированию и распределению задач (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).

• Направьте усилия руководителей командного уровня на управление общей системой работы вместо управления отдельными людьми и задачами (см. раздел «Измените стиль управления командой» текущей главы).

• Организуйте физические или виртуальные рабочие помещения для каждой команды (см. раздел «Организуйте рабочие помещения» текущей главы).

• Для получения первого опыта работы в Agile выберите командам значимую, но несрочную задачу (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы).

• Замените водопадные политики управления на политики управления Agile (см. раздел «Смените водопадные подходы в управлении» текущей главы).

• Удалите, пересмотрите или научитесь обходить политики отдела кадров, препятствующие эффективной командной работе (см. раздел «Измените вредные кадровые политики» текущей главы).

Команды фокусировки

• Рассчитывайте на 1–4 месяца пониженной производительности каждой команды (см. раздел «Найдите время на обучение» текущей главы).

• Включите в команду людей, имеющих навыки в сфере деятельности пользователей и заказчиков (см. раздел «Выберите или создайте Agile-команды» текущей главы).

• Убедитесь, что в каждой команде есть тот, кто принимает решение, над чем команда будет работать, или команда имеет к нему свободный доступ (см. раздел «Выберите или создайте Agile-команды» текущей главы).

• Предоставьте каждой команде коуча, который сможет научить ее практикам фокусировки (см. раздел «Выберите Agile-коучей» текущей главы).

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

Команды поставки

• Рассчитывайте на 2–6 месяцев пониженной производительности каждой команды (см. раздел «Найдите время на обучение» текущей главы).

• Объедините в каждой команде все нужные навыки разработки, такие как тестирование и эксплуатация (см. раздел «Выберите или создайте Agile-команды» текущей главы).

• Предоставьте каждой команде коуча, который сможет научить ее практикам поставки (см. раздел «Выберите Agile-коучей» текущей главы).

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

• Для получения первого опыта работы в Agile выберите задачу, предполагающую написание кода с нуля (green-field codebase), если коуч не сочтет, что в этом нет необходимости (см. раздел «Выберите команде подходящую для обучения задачу» текущей главы).

• Разберитесь с вопросами безопасности, которые мешают коллективной разработке (см. раздел «Решите проблемы, связанные с безопасностью» текущей главы).

Команды оптимизации

• Рассчитывайте на 1–3 месяца пониженной производительности каждой команды (см. раздел «Найдите время на обучение» текущей главы).

• Включите в команду экспертов в области бизнеса, рынка и продукта (см. раздел «Выберите или создайте Agile-команды» текущей главы).

• Предоставьте каждой команде коуча, который сможет научить ее практикам оптимизации (см. раздел «Выберите Agile-коучей» текущей главы).

• Передайте каждой команде ответственность за ее бюджет, планы и результаты (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).

11

Отрывок из статьи Мартина Фаулера Enterprise Rails (http://martinfowler.com/bliki/EnterpriseRails.html).

Искусство Agile-разработки. Теория и практика гибкой разработки ПО

Подняться наверх