Искусство Agile-разработки. Теория и практика гибкой разработки ПО
Шрифт:
Как сказал Мартин Фаулер [11] , «я вижу поразительную параллель между ДХХ (Давид Хейнемейер Ханссон, создатель Ruby on Rails) и Кентом Беком (создатель экстремального программирования). Любой из них, получив в подарок ограниченный мир, посмотрит на его ограничения, которые мы принимаем как должное, сочтет их несущественными и создаст новый мир без них… они просто подложат под них заряд интеллектуального динамита и двинутся дальше. Именно поэтому они могут создавать такие вещи, как экстремальное программирование и Rails, которые встряхивают всю индустрию».
11
Отрывок из статьи Мартина Фаулера Enterprise 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-коучей» текущей главы).
• Передайте каждой команде ответственность за ее бюджет, планы и результаты (см. раздел «Делегируйте полномочия и ответственность команде» текущей главы).
Найдите время на обучение
Изменения даются непросто, и нужно время, чтобы научиться чему-то новому. Освоение Agile поначалу замедлит работу ваших команд.
Насколько они замедлятся? Объективных критериев продуктивности в разработке программного обеспечения нет [Fowler2003], но, исходя из моего опыта, я бы предположил снижение на 10–20 % на первых порах. По мере освоения знаний и навыков Agile производительность команд будет расти. Она будет увеличиваться, пока команды не достигнут уверенного владения навыками, и тогда рост постепенно начнет выравниваться (рис. 4.1). Это называется J-кривой, и она характерна для всех значительных изменений. В главе 5 мы более подробно рассмотрим эти изменения.
Временные затраты обычно окупаются уже в первый год. Длительность изначального спада зависит от уровней свободного владения навыками, которые осваивает каждая команда, как объяснялось в предыдущей главе. Напомню:
• фокусировка – 1–4 месяца;
поставка – 2–6 месяцев;
• оптимизация – 1–3 месяца.
Рис. 4.1. Изменение производительности в Agile с течением времени
Эти периоды пересекаются, поэтому команда, обучающаяся навыкам фокусировки и поставки одновременно, будет менее продуктивна в течение 2–6 месяцев. Для сравнения: команда, которая сначала изучает фокусировку и позже переходит к обучению поставке, продемонстрирует два спада: 1–4 месяца – при обучении фокусировке и затем 2–6 месяцев – при обучении поставке.
Производительность команд Agile меняется и с других сторон. Команды Agile фокусируются на том, чтобы полностью завершить разработку одной функциональности, прежде чем переходить к следующей. Это особенно верно в отношении команд поставки, которые предпочитают создавать качественный продукт с самого начала, а не исправлять баги в конце. Это улучшает продуктивность и производительность, но (как ни странно) выглядит как замедление работы для людей, которые привыкли видеть одновременно несколько функциональностей в разработке.
В результате стейкхолдеры могут быть разочарованы темпом Agile-разработки, особенно в течение первого года, когда им приходится справляться сразу с тремя ударами: с реальными задержками из-за обучения команд, с ощущением задержки, вызванной необходимостью последовательно фокусироваться на завершении задач, и с затратами на завершение работ, которые велись до эксперимента с Agile и были объявлены «выполненными», на самом деле не являясь таковыми.
Это может приводить к тому, что команды будут отвлекаться от изучения Agile и фокусироваться только на поставке программного обеспечения, не закончив обучение. Такая ситуация контрпродуктивна для всех: команды будут измучены и расстроены, а организация потеряет свои инвестиции. Перед тем как команды начнут внедрять Agile, убедитесь, что руководители и все стейкхолдеры отдают себе отчет в том, что в первый год производительность снизится.
У вашей организации есть возможность купить время за деньги, наняв людей, которые помогут командам. Это не устранит полностью спад производительности, но сделает его менее значительным. Варианты такой помощи весьма разнообразны: периодическое наставничество, тренинги, помощь в разработке и имплементации процессов, каждодневный коучинг. Эффективнее всего нанять опытных специалистов-практиков, которые будут на постоянной основе тренировать каждую команду.
Решая, кого нанять, лучше игнорируйте бесчисленные схемы сертификации Agile. Многие из них – пустая трата денег. Большинство просто в течение нескольких дней переливают из пустого в порожнее, читая лекции «капитана Очевидность». Другие если даже и считаются отличными обучающими программами, то лишь благодаря конкретному преподавателю, а не самой сертификации. Поэтому оценивайте курсы независимо от сертификации, которую они рекламируют. Это относится и к найму консультантов и коучей. Попросите свою сеть контактов предоставить рекомендации, просмотрите общедоступные материалы, изучите отзывы.
Начав применять практики из этой книги, вы, вероятно, столкнетесь со специфическими проблемами и задачами. Найдите наставника, к которому сможете обратиться с вопросами. Эта услуга не обязательно должна быть платной: уважаемый коллега из компании, проходившей через подобное, местное сообщество пользователей, интернет-форум – все это будет подходящими вариантами.
Если нет времени на обучение…
Вы можете сделать спад производительности менее заметным за счет увеличения общих затрат, если начнете только с одного уровня фокусировки и постепенно переведете фокус на завершение задач.
Если ваша организация вообще не приемлет снижения производительности, значит, сейчас не лучшее время инвестировать в изменения. Если кажется, что подходящее время никогда не придет, – это предупреждающий сигнал. Вам нужно убедить руководство найти время для изменений, прежде чем продолжать.
Если нет средств на финансовую помощь…
С помощью этой книги, множества бесплатных онлайн-ресурсов и при наличии стремления к новым знаниям ваши команды могут самостоятельно научиться всему, что им нужно знать. Помощь извне, конечно, полезна, но не обязательна.