Дэвид Андерсон - Канбан. Альтернативный путь в Agile

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

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

В «Манифесте гибкой разработки ПО» ничего не говорится о качестве, хотя в «Принципах манифеста» {12}ведется речь о мастерстве, что подразумевает концентрацию на качестве. Но если качество не фигурирует в «Манифесте», почему оно стоит на первом месте в моем рецепте успеха? Суть в том, что большое количество ошибок приводит к основным потерям времени в разработке ПО. Эти цифры просто невероятны, а их амплитуда может колебаться на несколько порядков.

Кейперс Джонс {13}сообщает, что в 2000 году во время пузыря доткомов он оценивал качество программ для североамериканских команд, и оно колебалось от шести ошибок на одну функциональную точку до менее чем трех ошибок на 100 функциональных точек – 200 к одному. Серединой будет примерно одна ошибка на 0,6–1,0 функциональной точки. Таким образом, для команд вполне типично тратить более 90 % своих усилий на устранение ошибок. Есть и прямое тому свидетельство: в конце 2007 года Аарон Сандерс, один из первых последователей Канбана, написал на листе рассылки Kanbandev, что команда, с которой он работал, тратила 90 % доступной производительности на исправление ошибок.

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

Улучшение качества программ – это всем хорошо понятная проблема.

И гибкая разработка, и традиционные подходы к качеству имеют свои достоинства.Их нужно сочетать. Тестированием должны заниматься профессиональные тестировщики. Они находят дефекты и предотвращают их попадание в готовый продукт. Если вы будете просить разработчиков писать модульные тесты и автоматизировать их для автоматизированного регрессионного тестирования, то это возымеет серьезный эффект. Казалось бы, если просить разработчиков сначала писать тесты, то это дает психологическое преимущество. Так называемая разработка через тестирование (Test Driven Development, TDD) действительно, судя по всему, помогает: тестовое покрытие выглядит более полным. Стоит сказать, что дисциплинированные команды, которые я возглавлял, писали тесты уже после функционального кодирования и демонстрировали качество на уровне лучших показателей индустрии. Однако очевидно, что у средней команды качество повысится, если тесты будут написаны до функционального кода.

Рецензирование кода повышает качество.Рецензирование кода работает и в случае парного программирования, и при экспертной оценке, анализе кода или полной инспекции по Фагану. Оно помогает повысить как внутреннее, так и внешнее качество кода. Рецензирование кода лучше всего проводить часто и небольшими порциями. Я предлагаю командам ежедневно рецензировать код друг друга как минимум по 30 минут.

Совместный анализ и проектирование улучшают качество.Когда команды просят работать вместе над анализом проблем и проектированием решений, качество обычно выше. Я предлагаю командам проводить сессии совместного командного анализа и проектирования. Проектирование должно проводиться ежедневно малыми порциями. Скотт Амблер называет это agile-моделированием {14}.