День ото дня мы приближаемся к Agile-трансформации. Одна из самых важных целей для нас увеличить velocity команд на X %. Слышали об этом? Слова Марка Андрессена о том, что программное обеспечение пожирает мир, становятся отличительной чертой отраслей, которые раньше были менее автоматизированными.
Компания, занимающаяся разработкой Agile-продуктов, опросила более 18000 клиентов и специалистов по разработке программного обеспечения.
77% практикуют Agile
Опрос Atlassian, 2016 год
Известный вклад в эту игру вносит Scrum фреймворк, с помощью которого люди могут решать сложные адаптационные проблемы, эффективно и творчески обеспечивать продукты максимально возможной ценностью.
Velocity это дополнительная и необязательная часть практики Scrum.
Когда вы начинаете применять Scrum, вся работа, которую нужно выполнить для достижения цели, может быть подытожена в любой момент. Для прогнозирования прогресса используются разные проективные практики, например диаграммы сгорания задач или накопительные диаграммы потока. Они оказываются весьма полезными. Однако они не оспаривают важность эмпирической оценки. В частности, Agile-фреймворки, такие как Scrum, не требуют использования каких-то практик. Однако эти дополнительные практики зачастую полезны. Все эти методы используются для построения дашбордов, которые помогают принимать решения.
Но Agile-разработка не обязательно должна отвечать таким дашбордам и отчетам, которые так любят менеджеры. Те немногие показатели, которые она выдает, имеют мало смысла вне контекста планирования работы команды. Если учесть получившуюся нехватку информации, может возникнуть соблазн переиспользовать velocity для измерения производительности. В конце концов, это же показатель потенциала команды, из чего следует, что его изменение с течением времени можно использовать для определения изменения производительности, не так ли?
Velocity это способ измерения прогресса, а не конкретная величина!
Наряду с взаимодополняющими практиками, самый большой риск в таком подходе заключается в том, что velocity это инструмент планирования, а не конкретная величина. Это оценка относительной эффективности, которая имеет тенденцию меняться с течением времени, но эти изменения не обязательно указывают на изменение производительности. В целом это условная величина, которая сильно варьируется между организациями, командами и продуктами. Нет надежного способа представить этот показатель в виде нормализованного числа, которое можно было бы использовать в конструктивном сравнении.
Тогда что же такое velocity?
Velocity это показатель способности превратить бэклог продукта в работоспособный функционал за отрезок времени или определенную стоимость.
Моя цель увеличить velocity команды.
Если учитывать, что velocity это условный показатель, с ним легко играть, раздувать и сдувать его. Приравнивая velocity к производительности, вы создаете искаженный стимул для оптимизации velocity за счет разработки качественного программного обеспечения. Сознательно или нет, но команды будут пытаться продемонстрировать увеличение производительности, поднимая velocity. Если будет поставлена такая цель, то velocity станет пропорционально производительности. Но команды начнут срезать углы, чтобы быстрее доставить функционал. В свою очередь это приведет к увеличению технического долга, а продукт, который команды развивают, будет становиться все более и более хрупким.
Волшебный момент: откройте диаграмму сгорания задач команды
Допустим, ваша задача показывать диаграммы сгорания задач руководству. В течение каждого спринта линия прогресса начнет магическим образом пересекаться с целью по доставке продукта. Форма линии может сильно варьироваться, но каким-то образом будет происходить ускорение или замедление во второй половине спринта, чтобы соответствовать ожиданиям.
Velocity это мера объема работы, которую может выполнить команда. Это не то же самое, что мера ценности или влияние этой работы. Velocity действительно может быть относительно стабильной в успешной слаженной команде, поскольку количество усилий, требуемых в каждом спринте, остается неизменным. В таком случае искусственное давление на velocity приведет лишь к искажению картины.
Как же тогда измерить производительность?
Производительность определяется путем анализа входов и выходов из деятельности. Достаточно легко измерить входные данные для процесса разработки ПО, но сложнее измерить выходные данные каким-либо логичным способом.
Итоговый результат важнее выходных показателей.
Грубая количественная мера, такая как количество строк кода, не даст никакой рациональной информации. Она слишком сильно зависит от изменчивых факторов, таких как стиль написания кода, язык разработки и подход к реализации. Этот показатель может оказаться контринтуитивным, поскольку хорошо написанный код, который долго разрабатывался, часто занимает меньше строк.
Как измерить ценность?
Если вы будете выводить производительность из velocity, то увидите статистическое улучшение. Но оно не будет означать успешное развитие.
В конечном итоге, такие Agile-фреймворки как Scrum, опираются на эмпирический подход. Эмпирический подход в свою очередь опирается на проверку, адаптацию и прозрачность, обеспечивая непрерывный цикл обратной связи между командами разработчиков и бизнесом. Более значимая мера успеха должна фокусироваться на реальной выгоде, а не на абстрактных нормализованных показателях.
Помните, что релиз нужен для понимания ценности.
Говорю ли я, что метрики это плохо? Ни в коем случае. Я не говорю, что метрики бесполезны. Они помогут вам собрать информацию, принять решение о корректирующих действиях, и самое главное, понять, в какую сторону развиваться. Если вы склонны удовлетворять постоянный голод руководства отчетами, этим вы в итоге просто создаете бессмысленные накладные расходы. В конце концов, программное обеспечение это сложно, его развитие нельзя предсказать, но можно спрогнозировать!
Тогда что же измерять?
Одна из идей Кена Швабера называется Evidence-Based Management или Доказательное управление. Он говорит, что управление на основе фактических данных организации, занимающейся разработкой ПО, является самым полезным способом преобразования ПО из издержек в прибыльные активы.
Рассказ о EBM выходит за рамки этой статьи, поэтому я порекомендую вам перейти по этой ссылке, если вы хотите получить дополнительную информацию по этой теме.
В преддверии старта курса Agile Project Manager приглашаем всех желающих на бесплатный демо-урок по теме: Техники оценки Agile проектов для различных контекстов.
Участники вместе с преподавателем-экспертом разберут виды оценок проектов и задач в зависимости от срочности, размера и сложности объёма работ.
