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

Книга Scrum авторства Джеффа Сазерленда, соавтора одноимённой методологии, в российском переводе имеет следующий подзаголовок: «Революционный метод управления проектами». В оригинале подзаголовок отличается: The Art of Doing Twice the Work in Half the Time. Что-то похожее на «Искусство делать вдвое больше работы за половину времени». Нельзя быть уверенным, что вдвое больше сделанной работы принесёт вдвое больше пользы, поэтому это слово в заголовке статьи я деликатно опустил.

Теоретический менеджмент полон дедушек. Я читал работы Деминга (William Deming), Голдратта (Eliyahu Goldratt), Оно (Taiichi Ohno) и Друкера (Peter Drucker). Слышал о работах Акоффа (Russell Ackoff) и Джурана (Joseph Juran). Во всём прочитанном мне понравилось человечное и заботливое отношение к работающим людям. Тайити Оно был, пожалуй, строже остальных, но всё ещё очень человечен. Его можно понять, ведь он практиковал, ходил и убеждал людей, а нервы для этого иногда заканчиваются. Ни в одной из книг не было ничего похожего на «эксплуатируйте людей каждый день всё пуще, пока они не упадут без сил». Питер Друкер в своей книге Management Rev Ed даже дал нам, менеджменту 21-го века, подсказку, чем нужно заниматься:

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

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

Более двадцати лет прошло с начала века. Как близко мы подошли к достижению этой амбициозной цели? Мне видится, что мы ещё далековато. Давайте посмотрим, где мы сейчас находимся, какие у нас есть проблемы, и что с ними можно сделать.

Разбор широко распространённого подхода к эффективности процесса разработки ПО

Чем мне нравится выражение «вдвое больше за половину времени», так это тем, что оно ёмко описывает, насколько более эффективной может стать наша работа. Это приятное чувство достаточно быстро упирается в вопрос, а что вообще такое эффективность в разработке ПО? Да и как понять, что со временем мы становимся эффективнее?

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

Люди, практикующие Скрам, предлагают в качестве мерила сложности задачки и требуемых на неё затрат использовать story points. Несмотря на всю распространённость термина, какого-то внятного и легко соскальзывающего с языка перевода мне найти не удалось. В уже упомянутой книжке Scrum используется слово «очки». Переводчики предлагают «относительные единицы сложности». К счастью, надолго на них мы останавливаться не будем. Вот мой перевод определения этого термина со scrum.org:

Story Point — относительная единица измерения, установленная и используемая скрам-командой для оценки относительной сложности требований.

Оценка задачи в SP — это такой множитель сложности относительно базовой задачки. То есть вы и я примерно представляем, сколько усилий потребовалось для реализации той самой не очень сложной задачки. Если я говорю, что новая задачка будет стоить 3 SP, то значит мне она кажется втрое более сложной, чем предыдущая. Тем не менее это всего лишь предположение, и кто знает, что там впереди.

Снова вернёмся к эффективности. Если мы разработаем за спринт задач на 25 SP, будем ли мы лучше, чем спринт назад, когда было вышло 15 SP? Или же мы просто были поосторожнее и поставили оценки повыше для такого же объёма работ? А что это такое за «такой же объём работ», как мы их сравниваем? У нас в разработке ПО нет повторяющейся в промышленных масштабах одинаковой работы. Мы проектируем и реализуем фабрики по преобразованию информации, а вот они уже предоставляют нужные услуги. Так как мы вообще можем говорить об эффективности в нашей индустрии?

Говорить об эффективности можно осторожно начать от обратного. Мы намеренно можем замедлить решение поставленной задачи. Можем попрокрастинировать, а можем прыгать от одной задачи к другой, замедляя тем самым выполнение каждой отдельной задачи. Если вы любите псевдопараллелизм, то вам сейчас хорошо. Итак, если что-то можно делать менее эффективно, то есть надежда, что и более эффективно это что-то можно делать. Но будут ли полезны в нашем путешествии стори поинты? Я не вижу их пользы для дальнейшего рассмотрения. При желании или же ненамеренно их можно совершенно легко исказить. Нам нужно меру получше.

Определяем объект измерения

Давайте пока не будем спешить с измерением. Ведь надо сначала выяснить, что измерять. Какой-то внятной единицы работы для всей индустрии программного обеспечения я предложить не могу. К счастью, этого и не требуется. Достаточно той самой идеи относительности, которую мы встретили выше. Но только не в том разнообразном виде, ведущему к множителям, а в более простом: «мы здесь занимаемся похожими вещами». Этот осмысленный шаг в развитии программного продукта может быть эпиком, задачей, новой функциональностью или чем-либо ещё, характеризующим однократное движение в развитии разрабатываемой системы.

Вот пример трёх уровней шагов:

Ценная для пользователя функция ПО:
 ⎿ Её часть, удобная кроссфункциональной команде разработки:
   ⎿ Конкретная задачка внутри этой части (например, доработка сервера)

Чтобы доработка была улучшаемой, ей достаточно обладать всего лишь двумя свойствами:

1. Иметь конкретное время начала и завершения;

2. Случаться регулярно.

Для простоты в оставшейся части статьи я буду использовать слово «доработка». Не все доработки одинаковы. Выше я привёл пример существования доработок трёх различных типов.

Доработка должна происходить регулярно. Не могу назвать какую-либо конкретную частоту, но важность повторяемости будет видна позже. Требование к её наличию исходит из того, что нельзя быть максимально эффективным с самого начала, но можно становиться эффективнее со временем по мере новых итераций. Так работает Скрам, так работает производственная система «Тойоты», так работает наука. Нам нужна повторяемость для того, чтобы уловить доработку и последовательно её улучшать.

Сделать сразу что-то наиболее эффективным образом можно лишь случайно. Чем больше составных частей содержит определённое действие, тем меньше вероятность такой случайности. Можно подготовиться заранее. Но сама возможность подготовиться заранее свидетельствует, что доработка или её части уже когда-то ранее случались, и имеется некоторое знание. К абсолютно новым явлениям нечего готовить. С другой стороны, едва ли мы встречаемся с такими явлениями в нашей жизни. Часть предыдущего опыта так или иначе всегда остаётся востребованной.

Объект нашего измерения и улучшения — доработка определённого типа.

Как измерить доработку определённого типа?

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

Но название — это не единственное наше приобретение. У доработки есть также две временные метки, и нам доступна её продолжительность. Продолжительность — это потрясающее приобретение. Во-первых, она относится к понятному для очень многих языку:

— Сколько потребовалось времени, чтобы сделать эпик?
— 39 дней.

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

Получаем ли мы что-нибудь ещё?

Второе предъявленное к доработке требование, регулярность, даёт нам так много, что непросто в это поверить. Во-первых, мы получаем поток доработок определённого типа. Вот мой перевод определения интересующего нас значения слова «поток» из прекрасной книги Actionable Agile Metrics for Predictability Даниэля Ваканти (Daniel Vacanti):

Проще говоря, поток — это движение и доставка потребительской ценности через процесс.

Наличие у доработки временных меток начала и конца даёт нам несколько новых метрик. Вот они, из той же книги:

Незавершённое производство (work in progress, WIP) — количество элементов, над которыми идёт работа в рассматриваемый момент.

Время цикла (cycle time) — количество времени, потребовавшееся элементу для прохождения процесса.

Пропускная способность (throughput) — количество элементов, проходящих через процесс за единицу времени.

Могу заинтриговать вас, если вы думаете, что на этом всё. Мы только начинаем подходить к самым приятным инструментам. Поток доработок оставляет за собой след с течением времени. Этот след служит ключом для понимания системы и оценки её преобразований. След выражается через различные виды диаграмм, и одна из них — диаграмма рассеяния времени цикла (Cycle Time Scatterplot).

Особое удовольствие от этой диаграммы приходит от осознания того, что она запечатлевает «как дела делаются» вне зависимости от того, какие это дела и как они делаются. Ей не нужен какой-либо особый процесс или методология. Хотите с её помощью запечатлеть чистку зубов? Пожалуйста. А хотите понять, сколько времени занимает построение одноэтажных домов? Пользуйтесь. Хотите зафиксировать процесс разработки фич с последующим A/B-тестированием? Делайте.

На изображении выше видны также горизонтальные пунктирные линии подписанные справа: 50%, 70%, 85%, 95%. Это процентили. Что они обозначают? На левой части они тоже подписаны. Та линия, у которой справа 85%, а слева — 16 дней может быть прочитана следующим образом:

Для 85% доработок потребовалось 16 дней или меньше на полное осуществление системой.

Слово «система» в этом разделе статьи я использовал дважды. В оставшейся части его стоит понимать следующим образом:

Система — это нечто, осуществляющее доработки определённого типа.

Доработкой определённого типа в гипотетической системе строительства домов будет строительство одного дома. Сделать километр дороги в данном случае не будет считаться доработкой, так как эта деятельность слишком отличается. Для дороги можно сделать другую систему, в которой доработкой будет являться укладка того самого километра. Впрочем, дома бывают разные, какого-то однозначного разделения здесь нет. Основное наше желание состоит в том, чтобы доработки были похожи друг на друга: похожие дома, похожая чистка зубов, похожая разработка фич с A/B-тестированием.

Ещё одно приобретение

Пора обсудить ещё один эффект, который поможет нам улучшать то, что действительно нужно. Давайте представим ситуацию, когда есть команда разработки, и ей нужно разработать программное обеспечение. Доработкой будем считать пользовательскую историю (user story). Представим, что первая история успешно завершена и вы собираетесь с командой, чтобы обсудить прошедшее на ретроспективе. Делается это, чтобы дальше было лучше.

Есть ли в происходящем какой-нибудь подвох? Давайте присмотримся к ретроспективе повнимательнее.

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

Обыкновенно библиотеки после выбора остаются надолго, и вряд ли в следующий раз команда будет занята их обсуждением также интенсивно. Установка программного обеспечения также вряд ли будет волновать участников команды, ведь у них же всё уже установлено. Другое дело, что разумному предприятию нужно будет позаботиться о последующем приёме новичков и их включении в работу. Но это уже не процесс разработки пользовательских историй, а процесс приёма человека в команду.

Давайте посмотрим на это славное и известное высказывание Дональда Кнута (Donald Knuth) (или Тони Хоара, Tony Hoare).

Преждевременная оптимизация — корень всех зол.

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

Заставь это работать, сделай это правильно, сделай это быстрым. (Make it work. Make it right. Make it fast).

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

Статистическая причина не срываться с места для улучшения системы

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

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

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

Причина из теории ограничений не срываться с места для улучшения системы

Что нам говорит теория ограничений? Она говорит, что система, производящая доработку будет не более производительна, чем наименее производительная её подсистема. То есть по аналогии с тем, что караван идёт со скоростью самого медленного верблюда. Помните пропускную способность? Речь о ней.

Рассмотрим ещё один гипотетический пример. Представим, что у нас есть компания по строительству одноэтажных домов, и в ней есть три команды: строители фундаментов, возводители стен, кровельщики. Производительности наших команд следующие:

• 6 фундаментов в год,

• 24 набора стен в год,

• 52 крыши в год.

Сколько домов эта команда успеет построить за год? Можно было бы сказать, что шесть, но точнее будет: не более шести. Строительство здесь последовательно: фундамент → стены → крыша. Завершение строительства последнего шестого дома окажется уже за пределами года.

Если наши кровельщики произведут чудеса совершенствования и сумеют увеличить свою производительность, изменит ли это положение дел для компании? К сожалению, нет, в течение года мы так и продолжим возводить не более шести домов. Заливка фундамента всё ещё является нашим ограничением.

Числа, описывающие производительность вымышленной компании, даже к ней пришли с опытом. После того как описанная ранее команда разработки завершила свою первую пользовательскую историю, какой-то опыт появился, но этот опыт предоставляет нам лишь частичную информацию. Даже если мы и угадаем системную часть и начнём применять к ней улучшения, не факт, что именно она окажется ограничением. Собранной статистики на этот момент недостаточно, нам требуется больше.

Как много доработок нужно произвести, чтобы начать улучшать систему?

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