Трудно утверждать, что методология Agile неэффективна. Практически все команды разработки программного обеспечения стараются ей следовать. Простой способ начать внедрять гибкую методологию — это добавить пару ее компонентов в рабочий процесс. Одним из самых популярных и при этом важных компонентов считается оценка в Story Points. Однако сколько команд оценивали ее реальное влияние? На самом ли деле оценка времени, затраченного на каждую задачу, приносит пользу? По моему опыту, это не так.
Чтобы оставаться гибкими, нам следует знать преимущества и риски используемых инструментов, в частности плюсы и минусы оценки в Story Points. В этой статье мы рассмотрим, возможно ли точное планирование итераций и гибкость без оценки времени каждой отдельной задачи.
Немного предыстории: как я начал работать с Agile
В каждом проекте, в котором я участвовал, гибкую методологию хвалили. Поэтому неудивительно, что мы всегда придерживались Scrum-подхода хотя бы частично: у нас были спринты, ежедневные стендапы и планирование с оценкой. В одной компании у нас даже был Agile-коуч. В результате планирования мы пытались вместить слабо связанные задачи в спринты, обычно двухнедельные. Все это проходило согласно цифрам, называемым оценками, которые на самом деле были просто догадками. Мы полагали, что по прошествии времени мы сможем определить производительность команды (Velocity), и с этого момента наши оценки будут правильными. Однако никто не знал целей этих оценок. Я не слышал ничего про доставку ценности или адаптацию к изменениям, которые являются изначальными концепциями Agile.
Мы понятия не имели, в чем заключалась дополнительная ценность работы (или имитации работы) с этим Agile-компонентом, но использовали его, поскольку альтернативой была методология Waterfall, с которой работать не хотел никто. Спустя какое-то время я стал задумываться о том, почему мы должны придерживаться тех процессов, которые не привносят в нашу работу существенных улучшений.
Несет ли оценка в Story Points какую-то ценность?
По моему опыту, команды, работающие по Scrum, оказывают значительное давление на оценку того, сколько задач команда сможет уместить в один спринт.
Обычно это происходит так:
Тимлид: Сколько времени потребуется для реализации X?
Разработчик: Предполагаю, дня три.
Тимлид: Как думаешь, что сможешь завершить за оставшиеся два дня?
Иногда оценку задач проводили в условных единицах (Story Point), а иногда в относительных (с помощью техники Planning Poker). Но в любом случае цель состояла в том, чтобы договориться, сколько задач человек может выполнить за спринт.
По моим наблюдениям, оценка задач не приносит никакой пользы, а наоборот, наносит большой вред производительности и даже может снизить качество конечного продукта.
Ожидаемые преимущества оценки задач включают:
возможность прогнозировать, когда фичи или баг-фиксы будут доставлены клиентам;
способность рассчитать производительность команды, что позволит точнее оценить возможности команды в будущем.
Влияет ли оценка в Story Points на пользователей?
Важно отметить, что разработчики обычно не могут реализовать полную, нетривиальную функцию за один шаг. Реализация фичи требует выполнения несколько задач, которые иногда делятся на компоненты. Результаты каждой конкретной задачи не видны до завершения реализации фичи. В этом случае пользователи не заметят разницы. Даже более того, если они заметят какие-то изменения в это время, это закончится багом.
Пользователи не узнают, что изменение, которое по плану должно было быть доставлено во вторник, было перенесено на пятницу. Обычно сдвиг на несколько дней не имеет существенного значения. Проблема возникнет, если сорвать дедлайн на несколько месяцев. Но за всю мою карьеру у меня не было проблем с задержкой сроков даже в несколько недель.
Почему производительность команды постоянно меняется
Мне кажется, что определить производительность команды — это высший уровень мастерства в Scrum, о котором мечтают многие менеджеры. Однако я считаю, что внимание стоит сосредоточить не на безукоризненном владении какой-либо методологией, а на эффективном создании ценности для клиентов.
Я могу понять, почему некоторых менеджеров тянет планировать каждый день спринта. Поначалу Story Points и производительность (velocity) могут показаться хорошими моделями для отражения фактической производительности команды. Однако мой опыт говорит об обратном. К сожалению, в долгосрочной перспективе оценки в Story Points не помогают менеджеру определить, сколько задач команда может закрыть за определенный период. У вас разные люди, инициативы, объемы задач и жизненные обстоятельства у каждого члена команды. Менеджеру не стоит ожидать, что команда сохранит свою производительность на одном уровне в течение длительного периода времени. Люди сталкиваются с различными ситуациями в своей жизни, которые влияют на их личную производительность и способность к корректной оценке.
Время от времени случается отпуск, рождение детей, изменение семейного статуса, повышение по службе, выгорание кого-то из команды и другие непредсказуемые события, которые неизбежно и значительно влияют на работу команды. Поэтому абстрактное число не будет постоянным в течение длительного периода.
Влияет ли оценка в Story Points на производительность?
До сих пор мы обсуждали, почему я считаю, что оценка в Story Points не оказывает позитивного влияния на продуктивность команды. Теперь я хочу пойти еще дальше и сказать, что она не только бесполезна, но и вредна. По моим наблюдениям, основная причина, по которой команда разработки должна выполнить ряд задач в течение двух недель, заключается в возможности руководства создавать такие стимулы, которые мотивируют нас выкладываться.
Это звучит разумно в соответствии с одной из теорий продуктивности, называемой законом Паркинсона. Идея состоит в том, что на выполнение задачи уходит ровно столько времени, сколько было выделено. Кажется, есть мнение, что постановка такого количества задач, сколько человек по его утверждению может выполнить, гарантирует, что его рабочее время будет полностью использовано и, как результат, обеспечит оптимальную отдачу от инвестиций.
Я не уверен, связано ли это с перегруженностью текущей реальности или это происходит из-за того, что люди, которые платят нам большие деньги, хотят, чтобы наше время было полностью занято работой.
У математиков даже есть отдельная область, которая называется теорией массового обслуживания. Даже в инфраструктуре, если использование ресурсов серверов превышает примерно 85%, время, необходимое для выполнения новых операций, увеличивается в геометрической прогрессии. Короче говоря, независимо от контекста, общая производительность снижается, когда все слишком заняты.
Обычно главной целью планирования было вместить как можно больше задач, чтобы все были достаточно заняты на протяжении итерации. Но высокая загрузка не полезна при творческом характере работы, из-за нее команде становится трудно реагировать на неизбежные изменения.
Негативные аспекты оценки спринта
Очевидно, что планирование — это форма обязательства. И нет ничего плохого в том, чтобы взять это обязательство, если оно достижимо и принесет достаточную ценность, которая будет стоить затраченных на нее усилий. Я заметил, что люди обычно нуждаются в выполнении своих обязательств, особенно когда они работают в командах, полных амбициозных личностей, как это часто случается среди разработчиков. Это может привести к ситуации, когда никто не захочет браться за срочную задачу, которая не была запланирована для спринта, помогать другим или даже начать халтурить при выполнении задач. И обычно это происходит после выяснения, что проблема, которую нужно решить, намного сложнее, чем они думали.
Мне даже не нужно искать примеры таких ситуаций в далеком прошлом, поскольку я оказался именно в таком положении всего несколько недель назад. Я занимался довольно агрессивным рефакторингом и за два дня до конца спринта понял, что не смогу закончить его вовремя. Со всеми моими знаниями, саморефлексией и опытом мне было трудно сопротивляться соблазну пропустить часть запланированной работы, чтобы минимизировать влияние потенциальной ошибки. К счастью, я этого не сделал. И знаете, что? Сразу после релиза мы получили уведомление об ошибке, но благодаря моим контрмерам устранение проблемы заняло всего 15 минут.
Это никогда не бывает легким решением. Многие разработчики стараются завершить задачу в заданные сроки любой ценой — из-за стремления уложиться в оценку. Так или иначе, оно того не стоит. Тем более, что оценки спринтов, как правило, являются необязательными и добровольно поставленными дедлайнами, нарушение которых не несет никаких последствий.
Не подводите своих пользователей
Я никогда еще не видел, чтобы команда выполнила все задачи, которые она взяла на себя во время спринта. Обычно задачи переносятся из одного спринта в другой без обсуждения, актуальны ли они и стоит ли браться за их выполнение. Мы обещали их выполнить и держим свое обещание. Из-за этого мы делаем одно и тот же спринт за спринтом, при этом с течением времени накапливается задержка. Люди настолько к этому привыкли, что не видят в этом никакой проблемы.
Одним из предполагаемых преимуществ оценки является возможность заранее уведомлять клиентов о том, когда функция будет реализована. Несмотря на это, мы видим, что наши оценки неверны. Перемещение задач из одного спринта в другой стало нормой, и команда даже и не пытается что-то предпринять, чтобы это исправить. Поэтому теперь мы должны сделать все, чтобы завершить задачи не только потому, что взяли на себя обязательство их выполнить, но и потому, что обещания оставляют клиентов в предвкушении. И если они не получат обещанного, они будут разочарованы. А все мы знаем, что лучше удивляться, чем разочароваться.
Я не припомню случая, чтобы софтверная компания заранее сообщала мне, что в течение определенного времени планирует внедрить новую функцию в продукт, которым я пользуюсь. Обычно новая фича просто появляется или просят обновиться, если я того хочу.
Scrum — не единственный способ быть Agile
Я все чаще чувствую, как распространяется негативное отношение к Scrum. На мой взгляд, такой спад происходит из-за того, что он не приносит пользы, и по моему мнению, планирование спринта, основанное на жесткой оценке, является самой вредной частью его процессов.
Проблема заключается в том, что со временем Scrum стал считаться единственной методологией Agile. Это вызывает негативное отношение к Agile в целом, несмотря на то, что настоящие принципы Agile полезны и заслуживают того, чтобы их соблюдали в современных организациях. Нам стоит сосредоточиться на правильной расстановке приоритетов и поиске способов параллельной работы над проектами, а не на оценке в Story Points, которая отнимает время и не повышает эффективность команды. Я призываю все команды, работающие по Scrum, подумать об изменении своего подхода. А пока оставлю пост от его создателя.
Перевод текста поста:
Оценка задач замедлит вашу работу. Не занимайтесь этим. Мы отказались от оценки еще 10 лет назад.
На сегодняшний день у нас есть достаточно данных от Rally по 60 тыс команд. Самые медленные из них оценивают задачи в часах. Отсутствие какой-либо оценки положительно повлияет на производительность команды по сравнению с часовой оценкой.
Лучшие команды работают с мелкими задачами и не ставят таски. Они переходят к разработке через приемочные тесты (Acceptance Test-driven development, ATDD).
Завтра состоится открытое занятие «Product и Project manager — в чем разница и какую роль выбрать?». На этом уроке изучим, чем отличается продукт от проекта и увидим разницу между проектным и продуктовым менеджером. Посмотрим, как между ними распределяются обязанности и поговорим про разницу soft-скиллов для этих ролей. Вторая часть занятия — практическая: будем раскладывать типичные рабочие задачи по ролям, к которым они относятся. Приглашаем всех желающих. Зарегистрироваться можно по ссылке.