Почему качество не обсуждается

Почему качество не обсуждается

У нас сейчас есть проблема, которую я не знаю как решать. Один из заказчиков упорно не желает тратить время на refactoring и улучшение технического обеспечения проекта. В основном речь идёт о расширении функционала, остальное "not a priority".

Вот сейчас читаю книжку ("Scrum и XP - заметки с передовой")  и некоторые моменты очень даже в тему.

Почему качество не обсуждается

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

• Внешнее качество – это то, как пользователи воспринимают систему. Медленный и неинтуитивный пользовательский интерфейс – это пример плохого внешнего качества.

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

По правде говоря, у системы с высоким внутренним качеством иногда может быть довольно низкое внешнее. Но наоборот бывает крайне редко. Сложно построить что-то хорошее на прогнившем фундаменте. Я рассматриваю внешнее качество, как часть общего объема работ. Ведь с точки зрения бизнеса бывает весьма целесообразно как можно быстрее выпустить версию системы с немного корявым и медленным пользовательским интерфейсом, и лишь потом подготовить версию с доработками и исправлениями. Здесь право выбора должно оставаться за product owner'ом, так как именно он отвечает за определение объёма работ. И напротив – внутреннее качество не может быть предметом дискуссии. Команда постоянно должна следить за качеством системы, поэтому оно попросту не обсуждается. Никогда. (Ну ладно, почти никогда) Так как же нам различать задачи, связанные с внутренним и внешним качеством? Представьте, что product owner говорит: “Хорошо ребята, я понимаю, почему вы оценили эту задачу в 6 story point'ов, но я уверен, что, если вы чуточку помозгуете, то сможете по-быстрому “залатать” проблему”. Ага! Он пытается использовать внутреннее качество как переменную! Как я догадался? Да, потому что он хочет, чтобы мы уменьшили оценку задач, не уменьшив при этом объём работ. Слово “заплатка” должно вызывать у вас тревогу.

Почему же мы так жестко стоим на своем? По моему личному опыту, жертвовать внутренним качеством – это практически всегда очень и очень плохая идея. Сэкономленное время ничтожно мало по сравнению с той ценой, которую вам придётся заплатить как в ближайшем будущем, так и в перспективе. Как только качество вашего кода ухудшится, восстановить его будет очень тяжело. В этом случае я стараюсь перейти к обсуждению объема задач. “Раз вам так важно получить эту историю как можно раньше, тогда может быть стоит сократить объем задач, чтобы мы могли сделать её побыстрее? Возможно, стоит упростить обработку ошибок и сделать “Улучшенную обработку ошибок” отдельной историей оставив ее на будущее? Или может понизить приоритет остальных историй, чтобы мы могли сосредоточить все свои усилия на этой?”.

 

Глубоко согласен с Хенриком, автором книги. Сказанное, почти теми же словами не единоразово уже обсуждалось у нас в команде. Но всё равно, с достаточно большим упорством многие заказчики принципиально против улучшения внутреннего качества их продуктов. Они действительно не видят разницы между внутренним и внешним качеством, а мы часто не в состоянии им это внятно объяснить.

Ещё интересно:

 

Мы попробовали различные варианты работы с техническими историями. Мы пробовали считать их самыми обычными user story. Это была неудачная идея: для product owner'а приоритезировать их в product backlog'е было всё равно, что сравнить тёплое с мягким. По очевидным причинам технические истории получали самый низкий приоритет с объяснением: "Да, ребята, несомненно, ваш сервер непрерывной интеграции – очень важная штука, но давайте сперва реализуем кое-какие прибыльные функции? После этого вы можете прикрутить вашу техническую конфетку, окей?" В некоторых случаях product owner действительно прав, но чаще все-таки нет. Мы пришли к выводу, что product owner не всегда компетентен, чтобы идти на компромисс. И вот что мы делаем:

  1. Стараемся избегать технических историй. Ищем способ превратить

техническую историю в нормальную историю с измеряемой ценностью для бизнеса. В таком случае у product owner'а больше шансов найти разумный компромисс.

  1. Если мы не можем превратить техническую историю в обычную, смотрим

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

  1. Если оба подхода не прошли, отмечаем это как техническую историю и

храним список таких историй отдельно. Пусть product owner видит список, но не редактирует. В переговорах с product owner'ом используем параметры “фокус-фактора” и “прогнозируемой производительности” и выделяем время в спринте для реализации технических историй.

Пример (диалог очень похож на то, что случилось во время одного из наших планирований спринта).

Команда: “У нас есть кое-какие внутренние технические работы, которые должны быть сделаны. Мы бы хотели заложить на это 10% всего времени, т.е. снизить фокус-фактор с 75% до 65%. Это возможно?”

Product owner: “Естественно, нет! У нас нет времени!”

Команда: “Хорошо, давайте посмотрим на наш последний спринт (все бросают взгляд на график производительности на белой доске). Наша прогнозируемая производительность была 80, но реальная производительность оказалась 30, верно?”

Product owner: “Именно! У нас нет времени на внутренние технические работы! Нам нужен новый функционал!”

Команда: “Хорошо. Но причина ухудшения нашей производительность в том, что мы тратим слишком много времени на создание полной сборки для тестирования”.

Product owner: “Ну и что?”

Команда: “А то, что производительность и дальше будет такой низкой, если мы ничего не сделаем”.

Product owner: “Да … и что вы предлагаете?”

Команда: “Мы предлагаем выделить примерно 10% следующего спринта на установку билд сервера и другие вещи, чтобы сделать интеграцию менее болезненной. Это, скорее всего, увеличит производительность всех последующих спринтов как минимум на 20%!”

Product owner: “Серьёзно? Почему же мы это не сделали на предыдущем спринте?!”

Команда: “Хм… потому что вы не захотели, чтобы мы это сделали…”

Product owner: “О! Ммм…, ладно, тогда логично, если вы это сделаете сейчас!”

Конечно, есть и другой вариант: не вести переговоры с product owner'ом по поводу технических историй, а просто поставить его перед фактом, что у нас фокус-фактор такой-то. Но это не правильно даже не попытаться достичь компромисса. Если product owner оказался сообразительным и компетентным (нам в своё время с этим действительно повезло), я бы рекомендовал информировать его как можно лучше и дать ему возможность определять общие приоритеты. Ведь прозрачность – это один из основополагающих принципов Scrum'а, верно?

 

Comments

Comments powered by Disqus