Проблемы со скоростью при разработке по Agile

The Problem with Velocity in Agile Software Development
Hayim Makabee
Перевод: Мадорская Ю.М.
переведено и опубликовано с разрешения автора.

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

Давайте обратимся к общему определению cкорости (применительно к разработке ПО):

«Скорость — это инструмент планирования пропускной способности команды, который иногда используется в разработке программного обеспечения по Agile. Скорость расчитывается как отношение объема работы к периоду, за который она была выполнена.

Основная идея измерения «скорости» — помочь командам оценить, какой объем работ они смогут выполнить в следующий период времени на основе их предыдущих результатов по выполнению схожих задач». [2]

По-моему, основная проблема со скоростью начинается когда она становится самоцелью. Как только команда разработчиков сосредотачивается на поддержании или даже увеличении их скорости, они сразу же готовы идти на жерты.

Восприятие скорости как цели заставляет все время выбирать:

  • Должны ли мы сделать это быстрее или лучше?
  • Есть ли у нас достаточно времени для рефакторинга?
  • Почему бы не подсобрать немного больше технического долга, чтобы повысить нашу скорость?

Обратите внимание, насколько отличается физическая концепция скорости от определения понятия скорости в Agile, насколько точнее она отражает суть движения [5]:

«Скорость — векторная физическая величина, характерирующая быстроту перемещения и направление движения…

Скалярная абсолютная величина, т.е. проекция этого вектора на касательную к траектории точки, называется модуль вектора скорости». Скалярная величина — точка — не отражает направление движения.

morkovka

Очевидно, что то, что мы называем скоростью в Agile  — это именно модуль вектора скорости, поскольку там нет явного определения измерений, которые позволяли бы контролировать направление движения. Конечно, User Story должны удовлетворять некоторым базовым характеристиками качества, например, быть корректными. Но что насчет других ожидаемых параметров качества — как функциональных, так и нефункциональных, например, таких как низкая связанность, эффективность и надежность. Кто их измеряет? Кто их отслеживает? К сожалению, я никогда не слышал об agile-команде, которая строила бы графики для отслеживания цикломатичной сложности их кода.

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

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

Жошуа Кириевский «Жертвуя качеством для обеспечения предсказуемости»

Жошуя Кириевский — это CEO компании «Industrial Logic»  и автор книги «Refactoring to Patterns». Ниже цитата из его статьи «Прекратите использовать Story Points»:

«Технические практики, такие как test-driven разработка и рефакторинг обычно отбрасываются первыми, когда кто-то пытается начать «делать оценку их скорости».

Мы видим, что это поведение возникает с самого начала, с обучения: команда, которая завершает всю работу в срок (например, два часа) часто достигает этого жертвуя качеством.

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

Мы объясняли как великие команды в конечном итоге научились поддерживать техническое совершенство, сохраняя при этом скорость (т.е. одинаковое количество story points, выполненных за спринт).

Тем не менее, факт остается фактом, такие команды — редкость и их техническое совершенство, основанное на согласованной работе, часто непродолжительно из-за изменяющихся размеров команды или другого давления со стороны.

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

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

Джим Хайсмит «Скорость убивает гибкость»

Джим Хайсмит — консультат руководителей в ThoughtWorks и автор нескольких книг по agile-разработке, включая “Agile Software Development Ecosystems” и “Agile Project Management: Creating Innovative Products“. Ниже приведена цитата из его статьи «Скорость убивает гибкость»:

«Если скорость начинает использоваться как мера производительности, то излишняя концентрация на ней неизбежно вызывает проблемы. Правильное использование скорости — только как инструмент калибровки, чтобы помочь планированию, основанному на оценке предыдущих возможностей. Именно так, как это описывает Кент Бэк в ‘Extreme Programming: Embrace Change‘. Измерение производительности в общем-то имеет мало смысла в работе, связанной со знаниями, но это тема для другой статьи. Скорость в agile, конечно,  очень привлекательная метрика — во многом потому, что ее легко измерить. Даже если story-points за итерацию вычисляются на основе выпускаемых «фич», то скорость по своей сути — это трудоемкость .

В то время как Agile-команды должны сфокусироваться на поставке ценной функциональности они начинают отвлекаться на отчеты о производительности. Раз за разом я слышу от менеджеров или владельцев продуктов: «Ваша скорость упала с 24-ех на прошлой итерации до 21 на этой интерации, что не так? Давайте вернемся к исходной скорости или даже выше». В этом случае скорость перестает быть полезным инструментом для калибровки (чтобы отвечать на вопрос «какие у нас возможности для следующей итерации?») и становится инструментом для измерения производительности. Это означает, что две вещи также скоро изменятся: качество взаимодействия пользователя с системой и техническое качество системы».

Литература

  1. Hayim Makabee “Real Danger of Quick-and-Dirty Programming“ http://effectivesoftwaredesign.com/2015/10/22/on-the-real-danger-of-quick-and-dirty-programming/
  2. https://en.wikipedia.org/wiki/Velocity_(software_development)
  3. https://en.wikipedia.org/wiki/Code_refactoring
  4. Hayim Makabee  «On Technical Debt and the Psychology of Risk Taking» http://effectivesoftwaredesign.com/2013/10/06/on-technical-debt-and-the-psychology-of-risk-taking/
  5. https://en.wikipedia.org/wiki/Velocity
  6. https://en.wikipedia.org/wiki/User_story
  7. https://en.wikipedia.org/wiki/Correctness_(computer_science)
  8. https://en.wikipedia.org/wiki/Cyclomatic_complexity
  9. Joshua Kerievsky «Refactoring to Patterns» ISBN-13: 078-5342213355
  10. Joshua Kerievsky «Stop Using Story Points» https://www.industriallogic.com/blog/stop-using-story-points/
  11. Jim Highsmith «Agile Software Development Ecosystems» ISBN-13: 978-0201760439
  12. Jim Highsmith  «Velocity is Killing Agility!» http://jimhighsmith.com/velocity-is-killing-agility/

Хотите сослаться на эту статью? Используйте правильную ссылку:

Hayim Makabee. Проблемы со скоростью при разработке по Agile. //Практика проектирования систем.-2015. [электронный ресурс] — Режим доступа: http://reqcenter.pro/velocity-in-agile/, свободный. — Загл. с экрана