Искусство Agile-разработки. Теория и практика гибкой разработки ПО. Шэйн Уорден
Чтение книги онлайн.
Читать онлайн книгу Искусство Agile-разработки. Теория и практика гибкой разработки ПО - Шэйн Уорден страница 17
Эти периоды пересекаются, поэтому команда, обучающаяся навыкам фокусировки и поставки одновременно, будет менее продуктивна в течение 2–6 месяцев. Для сравнения: команда, которая сначала изучает фокусировку и позже переходит к обучению поставке, продемонстрирует два спада: 1–4 месяца – при обучении фокусировке и затем 2–6 месяцев – при обучении поставке.
Производительность команд Agile меняется и с других сторон. Команды Agile фокусируются на том, чтобы полностью завершить разработку одной функциональности, прежде чем переходить к следующей. Это особенно верно в отношении команд поставки, которые предпочитают создавать качественный продукт с самого начала, а не исправлять баги в конце. Это улучшает продуктивность и производительность, но (как ни странно) выглядит как замедление работы для людей, которые привыкли видеть одновременно несколько функциональностей в разработке.
В результате стейкхолдеры могут быть разочарованы темпом Agile-разработки, особенно в течение первого года, когда им приходится справляться сразу с тремя ударами: с реальными задержками из-за обучения команд, с ощущением задержки, вызванной необходимостью последовательно фокусироваться на завершении задач, и с затратами на завершение работ, которые велись до эксперимента с Agile и были объявлены «выполненными», на самом деле не являясь таковыми.
Это может приводить к тому, что команды будут отвлекаться от изучения Agile и фокусироваться только на поставке программного обеспечения, не закончив обучение. Такая ситуация контрпродуктивна для всех: команды будут измучены и расстроены, а организация потеряет свои инвестиции. Перед тем как команды начнут внедрять Agile, убедитесь, что руководители и все стейкхолдеры отдают себе отчет в том, что в первый год производительность снизится.
У вашей организации есть возможность купить время за деньги, наняв людей, которые помогут командам. Это не устранит полностью спад производительности, но сделает его менее значительным. Варианты такой помощи весьма разнообразны: периодическое наставничество, тренинги, помощь в разработке и имплементации процессов, каждодневный коучинг. Эффективнее всего нанять опытных специалистов-практиков, которые будут на постоянной основе тренировать каждую команду.
Решая, кого нанять, лучше игнорируйте бесчисленные схемы сертификации Agile. Многие из них – пустая трата денег. Большинство просто в течение нескольких дней переливают из пустого в порожнее, читая лекции «капитана Очевидность». Другие если даже и считаются отличными обучающими программами, то лишь благодаря конкретному преподавателю, а не самой сертификации. Поэтому оценивайте курсы независимо от сертификации, которую они рекламируют. Это относится и к найму консультантов и коучей. Попросите свою сеть контактов предоставить рекомендации, просмотрите общедоступные материалы, изучите отзывы.
Начав применять практики из этой книги, вы, вероятно, столкнетесь со специфическими проблемами и задачами. Найдите наставника, к которому сможете