Хотелось бы развенчать один миф и обозначить ценность инженерных практик в agile.
Этот миф, – что agile ускоряет разработку.
Он никогда не задумывался для того, чтобы ускорять разработку.
Этот миф идет из неверной трактовки (и перевода) первого принципа: «Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.»
Его часто трактуют как «быстрой» поставки, но раньше, – не равно быстрее.
Смысл agile в своевременном предоставлении менеджменту реальных данных о прогрессе для принятия управленческих решений.
Сейчас я сильно упрощу, буквально до двух метрик: объем проекта/релиза и скорость команды.
Мы оцениваем весь объем и двигаемся итеративно, измеряя свою скорость, уточняя оценки и скорость.
После 3-5 итераций мы уже можем на основе предыдущих данных о скорости дать прогноз о времени окончания всего объема (и принять управенческие решения). Или нет?
Вот тут как раз и проблема. Код меняется.
Если не применять практики парного программирования, рефакторинга, TDD и Simple Design (как минимум), то код усложняется. Усложняется он экспоненциально, запутывается. Экспоненциально растет время на ручное тестирование. И вот мы уже не можем использовать в прогнозах прошлые измерения. На момент 5-й итерации средняя скорость 30 стори поинтов (кода пока еще мало), а из-за того, что не поддерживается чистота кода на 10-й итерации скорость будет уже 10 стори поинтов, а на 20-й вообще не получится выполнить ни одной задачи и появится итерация разработки и итерация тестирования. А мы на пятой итерации планировали дату релиза исходя из скорости 30 стори поинтов. Знакомо?
«Agile processes promote sustainable development.» – ровно о том, что команда может поддерживать постоянный ритм, не деградировать. Деградация скорости команды, – это следствие деградации кода. Вот почему просто взять и сделать спринты – не рабочая схема. Agile не ускоряет, – он позволяет не замедляться.
Безусловно, даже применение части организационных практик в организации с множеством дисфункций, вроде близости бизнеса, кросс-функциональной команды, ускорят разработку, просто потому что так эффективнее работать. Но без инженерных практик код продолжит деградировать и в какой-то момент скорость снизится (а стоимость вырастет) до той же, что была до организационных изменений.
Как архитекторы мы должны доносить эту мысль, развивать ее, быть примером. Какой бы ни была хорошей архитектура, плохой код способен все испортить.
Этот миф, – что agile ускоряет разработку.
Он никогда не задумывался для того, чтобы ускорять разработку.
Этот миф идет из неверной трактовки (и перевода) первого принципа: «Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.»
Его часто трактуют как «быстрой» поставки, но раньше, – не равно быстрее.
Смысл agile в своевременном предоставлении менеджменту реальных данных о прогрессе для принятия управленческих решений.
Сейчас я сильно упрощу, буквально до двух метрик: объем проекта/релиза и скорость команды.
Мы оцениваем весь объем и двигаемся итеративно, измеряя свою скорость, уточняя оценки и скорость.
После 3-5 итераций мы уже можем на основе предыдущих данных о скорости дать прогноз о времени окончания всего объема (и принять управенческие решения). Или нет?
Вот тут как раз и проблема. Код меняется.
Если не применять практики парного программирования, рефакторинга, TDD и Simple Design (как минимум), то код усложняется. Усложняется он экспоненциально, запутывается. Экспоненциально растет время на ручное тестирование. И вот мы уже не можем использовать в прогнозах прошлые измерения. На момент 5-й итерации средняя скорость 30 стори поинтов (кода пока еще мало), а из-за того, что не поддерживается чистота кода на 10-й итерации скорость будет уже 10 стори поинтов, а на 20-й вообще не получится выполнить ни одной задачи и появится итерация разработки и итерация тестирования. А мы на пятой итерации планировали дату релиза исходя из скорости 30 стори поинтов. Знакомо?
«Agile processes promote sustainable development.» – ровно о том, что команда может поддерживать постоянный ритм, не деградировать. Деградация скорости команды, – это следствие деградации кода. Вот почему просто взять и сделать спринты – не рабочая схема. Agile не ускоряет, – он позволяет не замедляться.
Безусловно, даже применение части организационных практик в организации с множеством дисфункций, вроде близости бизнеса, кросс-функциональной команды, ускорят разработку, просто потому что так эффективнее работать. Но без инженерных практик код продолжит деградировать и в какой-то момент скорость снизится (а стоимость вырастет) до той же, что была до организационных изменений.
Как архитекторы мы должны доносить эту мысль, развивать ее, быть примером. Какой бы ни была хорошей архитектура, плохой код способен все испортить.