Дэн Олсен – MVP. Как выводить на рынок товары и услуги, которые нравятся покупателям (страница 51)

Я упоминал выгоды концепции бережливого производства небольших партий в главе 6, но давайте рассмотрим, почему она так полезна при разработке программного обеспечения (или при любой другой разработке, осуществляемой в условиях с высокой степенью неопределенности). Когда разработчики оценивают количество времени, которое им потребуется для создания новой функции, в их оценке присутствует некоторая неопределенность. Наличие такой неопределенности приводит к тому, что произведенная оценка затрат оказывается ошибочной и фактическая продолжительность разработки отличается от расчетной. Хороший способ сравнения фактической и расчетной продолжительности разработки заключается в количественном измерении их соотношения. Если реализация проекта заняла в два раза больше времени, чем ожидалось, величина такого соотношения будет равна 2x; если же на реализацию ушло вдвое меньше расчетного времени, соотношение будет равно 0.5x.

Стив Макконнелл[23] создал диаграмму под названием «Конус неопределенности», которая характеризует диапазон величины ожидаемой ошибки при оценке затрат на протяжении всего срока реализации проекта. На его диаграмме верхняя и нижняя границы ошибки оценки представляют собой симметричные кривые, которые начинаются с уровней 4x и 0.25x, соответственно, в начале проекта, и плавно опускаются по мере продвижения разработки, сходясь в конце на нулевой отметке. Это иллюстрирует интуитивно понятный и подтвержденный практическим опытом факт, что в начале разработки величина ошибки при оценке затрат потенциально выше, чем ближе к завершению проекта.

Однако на практике я не сталкивался с тем, чтобы подобные ошибки оказывались симметричными. Другими словами, я не замечал, чтобы разработчики с одинаковой вероятностью опаздывали и завершали задачи раньше намеченного срока. В большинстве случаев задачи по разработке программного обеспечения занимают больше времени, чем предполагалось изначально. И хотя некоторые действительно выполняются досрочно, количество сэкономленного времени, как правило, оказывается намного меньшим, чем масштабы отрицательных сюрпризов. Почему так происходит? Чтобы объяснить асимметричную природу ошибок в оценке затрат на создание программного обеспечения, я процитирую эпистемолога и бывшего министра обороны США Дональда Рамсфелда:

«Существуют известные нам известные. Это вещи, о которых мы знаем, что мы о них знаем. Мы также знаем о существовании известных нам неизвестных. То есть мы знаем, что есть некоторые вещи, о которых мы не знаем. Но есть и неизвестные нам неизвестные. Это то, о чем мы не знаем, что мы о них не знаем».

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

Допустим, я подсчитал, что выполнение задачи A займет у меня пять минут, а выполнение задачи B – пять месяцев. С обеими задачами могут быть связаны неизвестные мне неизвестные. Однако неопределенность не является линейной при увеличении масштаба задачи, о чем свидетельствует верхняя кривая конуса неопределенности. Вероятность того, что пятиминутное задание выйдет из-под контроля, довольно мала. В отличие от нее, пятимесячная задача, которая более чем в 30 000 раз масштабнее, имеет гораздо больше шансов на то, что с ней могут быть связаны неизвестные нам неизвестные факторы.

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

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

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

Основные принципы гибкой разработки были изложены в «Манифесте Agile», который был написан в 2001 году (вы можете ознакомиться с Манифестом и принципами Agile по ссылке: http://agilemanifesto.org). Agile поощряет раннюю и непрерывную поставку работающего программного обеспечения с ориентацией на создание ценности для потребителей. Ключевой частью Agile является определение продукта с точки зрения потребителя и использование с этой целью пользовательских историй. Как уже было сказано в главе 6, история пользователя – это краткое описание преимуществ, которые должен предоставлять конкретный функционал. Это описание включает как самого персонажа – для которого предназначены эти преимущества, так и его цели. Хорошо написанные пользовательские истории обычно соответствуют шаблону:

Я как [тип пользователя]

хочу [что-то сделать],

чтобы [получить желаемую пользу].

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

Существует несколько различных разновидностей Agile-разработки, включая экстремальное программирование (сокращенно XP) и бережливую разработку программного обеспечения. Далее я приведу краткий обзор двух наиболее часто используемых методологий Agile: Scrum и Канбан.

Scrum

Scrum является наиболее популярной методологией Agile. Ее относительно легко внедрить, благодаря существованию множества предписывающих руководств о том, как практиковать Scrum. Ключевым аспектом Scrum является то, что команда работает в условиях строгого соблюдения фиксированных временных интервалов. Каждый рабочий интервал, называемый спринтом или итерацией, представляет собой заранее спланированный промежуток времени. Особенно распространены двухнедельные спринты, но есть команды, использующие недельные, трехнедельные и четырехнедельные спринты.

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