Kitabı oku: «Agile: оценка и планирование проектов», sayfa 6

Идеальное время и разработка программного обеспечения

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

• поддержка текущего релиза;

• отсутствие из-за болезни;

• совещания;

• демонстрации продукта;

• работа с персоналом;

• телефонные переговоры;

• специальные проекты;

• повышение квалификации;

• электронная переписка;

• анализ сделанного и прогоны;

• собеседования с кандидатами;

• переключение на другие задачи;

• устранение ошибок в текущих релизах;

• управленческий анализ.

Кроме того, при выяснении причин, по которым идеальное время не соответствует общему затраченному, учтите, что руководители могут непрерывно работать от одного отвлекающего события до другого не более пяти минут (Hobbs, 1987). Даже если типичный разработчик отвлекается в три раза реже, время его непрерывной работы составляет всего 15 минут.

Проблемы могут возникать, когда руководитель задает члену команды неизбежный вопрос: «Сколько времени на это потребуется?» Член команды отвечает «Пять дней», а руководитель отсчитывает пять дней в своем календаре и помечает срок окончания работы жирным красным знаком Х. Член команды, однако, на самом деле хотел сказать: «Пять дней, если я буду заниматься только этим, но у меня полно других дел, поэтому примерно две недели».

В софтверном проекте многозадачность еще больше увеличивает разрыв между идеальным и общим затраченным временем. Тренер никогда не скажет футболисту: «Поскольку ты занят не в каждой игре, сыграй-ка еще в этом очень важном хоккейном матче». Разработчик программного обеспечения, которого заставляют работать в многозадачном режиме, в значительной мере теряет свою эффективность в результате переключения между двумя (или более) задачами.

В софтверном проекте мы можем оценивать пользовательские истории или другую работу в идеальных днях. При оценке в идеальных днях следует исходить из следующего:

• оцениваемая история – это единственная задача, над которой вы работаете;

• все, что вам необходимо, есть под рукой в момент начала работы;

• перерывы и отвлечения отсутствуют.

Идеальные дни как показатель размера

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

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

Одна оценка, а не множество

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

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

Хотя на это редко когда стоит тратить силы, иногда такой подход просто необходим. Не так давно у меня был клиент, работающий с тремя версиями продукта – одна для Macintosh, другая для Windows и третья для карманных компьютеров. В этом случае критически важно обеспечить абсолютно одинаковую функциональность. Более того, члены команды на тот момент не могли переключаться с разработок для Mac на разработки для Windows и карманных компьютеров. В такой ситуации оценка идеального времени для каждой роли по каждой истории может быть полезна. Следует, однако, учитывать, что это увеличивает бремя администрирования.

Резюме

Идеальное время и общее затраченное время – не одно и то же. Идеальное время игры в американский футбол составляет 60 минут (четыре 15-минутных периода). Вместе с тем для завершения 60-минутного матча обычно требуется около трех часов. Такая разница объясняется наличием перерывов в игре.

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

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

Вопросы для обсуждения

1. Если идеальный день – это восемь часов непрерывной, целенаправленной работы, то какое общее затраченное время в часах соответствует одному идеальному дню в ваших условиях?

2. Можно ли как-то улучшить ситуацию?

Глава 6
Методы оценки

Давать предсказания очень трудно, особенно когда они касаются будущего.

Нильс Бор, датский физик

Чем больше сил и средств мы вкладываем во что-то, тем лучше результат. Верно? Возможно, но нередко для получения приемлемых результатов требуется лишь часть этих затрат. Например, моя машина грязная и ее нужно помыть. Если я займусь этим сам, то потрачу на мойку около часа – этого достаточно, чтобы вымыть машину снаружи, пропылесосить салон и протереть окна. Затратив один час, я получу сравнительно чистый автомобиль.

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

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

Для лучшего понимания этой взаимосвязи предположим, что вы решили оценить, сколько печенья я съел за прошлый год. Вы можете без особых усилий просто назвать какое-нибудь число наугад. Отметим его на рис. 6.1 – ваша оценка окажется очень близкой к левому краю оси усилий и вряд ли будет точной. Можно пойти вправо по оси усилий и потратить хотя бы полчаса на поиски данных о среднем потреблении печенья по стране. Это повысит точность по сравнению с оценкой наугад. Если нужна еще более высокая точность, можно провести исследовательскую работу – обзвонить моих друзей и родственников, запросить мои прошлые заказы на печенье в ближайшем магазине и т. д. Можно также последить за мной в течение дня, а лучше месяца, а потом экстраполировать полученные результаты по съеденному печенью на годовой период.

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

Посмотрите повнимательнее на рис. 6.1 и обратите внимание на следующие моменты. Во-первых, не важно, сколько затрачивается усилий, – оценка никогда не достигает максимума по оси точности. Не имеет значения, ценой каких затрат получена оценка, – как ни крути, это не более чем оценка. Никакие дополнительные затраты сил и средств не сделают оценку идеальной. Во-вторых, заметьте, как мало усилий требуется для кардинального повышения точности по сравнению с нулевой линией. Из рис. 6.1 следует, что всего 10 % усилий обеспечивают достижение 50 % от потенциально возможной точности. Наконец, обратите внимание на то, что в конечном итоге точность оценки падает. Не исключено, что при чрезмерно больших затратах сил и средств на оценку результат будет менее точным.

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

Agile-команды предпочитают держаться ближе к левому краю графика на рис. 6.1. Они признают невозможность устранения неопределенности оценок, однако считают, что небольшие усилия приносят большой результат. Хотя agile-команды не так далеко продвигаются по осям точности/усилий, их планы более надежны, поскольку они часто поставляют полностью работоспособные, протестированные, интегрированные программы с небольшими дополнениями.

Оценки – продукт совместной работы

Оценкой занимается не какой-то один представитель команды. Agile-команды не полагаются на оценку единственного эксперта. Несмотря на хорошо известный факт, что оценка, подготовленная тем, кто выполняет работу, лучше оценки, данной кем-то другим (Lederer and Prasad, 1992), наилучшими являются коллективные оценки членов команды, которые участвуют в работе. Это объясняется двумя причинами.

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

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

Шкала оценки

Исследования показывают, что мы лучше всего оцениваем величины в пределах одного порядка (Miranda, 2001; Saaty, 1996). В своем городе вы должны довольно хорошо оценивать относительные расстояния до таких объектов, как ближайший продовольственный магазин, ближайший ресторан и ближайшая библиотека. Например, библиотека может находиться в два раза дальше ресторана. Результаты будут намного менее точными, если вас попросят оценить относительное расстояние до Луны или до столицы соседнего государства. Поскольку мы лучше всего оцениваем величины в пределах одного порядка, большинство оценок должны укладываться именно в такой диапазон.

Я использую следующие две шкалы оценки:

• 1, 2, 3, 5 и 8;

• 1, 2, 4 и 8.

В основе каждой из этих последовательностей лежит своя логика. Первая – последовательность Фибоначчи⁴. Я считаю эту последовательность очень полезной, потому что шаг в ней повышается соответствующим образом с ростом величины чисел. Шаг в один пункт между числами 1 и 2, а также между числами 2 и 3 выглядит подходящим, как и шаги между 3 и 5 и между 5 и 8. Во второй последовательности каждое число определяется путем умножения предыдущего числа на два. Эти нелинейные последовательности работают хорошо, поскольку отражают повышение неопределенности, связанной с оценками более крупных элементов работы. В принципе, данные последовательности равноценны, но лично я предпочитаю первую.

Каждое из этих чисел следует рассматривать как емкость, в которую «выливают» объекты соответствующего размера. Работу лучше представлять как текущий песок, а не воду, льющуюся в емкость. Если вы используете ряд 1, 2, 3, 5 и 8, а оцениваемая история чуть больше, чем другие оцененные в пять пунктов истории, то ее можно поместить в 5-пунктовую емкость. Понятное дело, что история, которую вы оцениваете на семь, для 5-пунктовой емкости не подходит.

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

Если команда решит не включать ноль в шкалу оценки, то все участники проекта (особенно владелец продукта) должны ясно понимать, что 13 × 0 ≠ 0. У меня никогда не было проблем с объяснением этого владельцам продукта, которые понимали, что 0-пунктовая история – эквивалент бесплатного сыра. Однако они также понимали, что в одной итерации количество ломтиков бесплатного сыра не может быть безграничным. Альтернативой использованию нуля является группирование очень маленьких историй и их оценка как отдельный элемент работы.

Некоторые команды предпочитают работать с большими числами, такими как 10, 20, 30, 50 и 100. Это нормально, поскольку они представляют диапазон одного порядка. Вместе с тем, если вы имеете дело с большими числами в диапазоне от 10 до 100, я настоятельно рекомендую заранее определить используемые числа в этом диапазоне. Не допускайте, например, оценки одной истории в 66 пунктов или идеальных дней, а другой – в 67. Это ложный уровень точности, так как невозможно уловить 1,5 %-ную разницу в размере. Разница в один пункт приемлема для таких величин, как 1, 2 и 3. В процентном выражении она значительно больше разницы между 66 и 67.

Пользовательские истории, эпопеи и сюжеты

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

Помимо этого, ряд взаимосвязанных пользовательских историй можно объединить (обычно с помощью скрепки, если в работе используются карточки) и работать с ними как с единым объектом в целях оценки или планирования релиза. Такой ряд пользовательских историй называют темой. Эпопея в силу своего размера нередко является темой.

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

Пользовательские истории, подлежащие реализации в ближайшем будущем (в следующих нескольких итерациях), должны иметь не очень большой размер, чтобы работу над ними можно было завершить за одну итерацию. Такие объекты следует оценивать в пределах одного порядка. Я использую для этого последовательность 1, 2, 3, 5 и 8.

Пользовательские истории или другие объекты, работа с которыми, скорее всего, не будет осуществляться в ближайших итерациях, можно представить в виде эпопей или тем. Такие объекты можно оценивать в единицах за пределами рекомендуемого мною диапазона от 1 до 8. Чтобы оценивать крупные объекты, я добавляю 13, 20, 40 и 100 к своей любимой последовательности 1, 2, 3, 5 и 8.

Получение оценки

Наибольшее распространение получили следующие три метода оценки:

• экспертная оценка;

• оценка по аналогии;

• разбивка на более мелкие части.

Каждый из этих методов может применяться индивидуально, однако для получения наилучших результатов их следует комбинировать.

Экспертная оценка

Если вы хотите знать, сколько времени займет то или иное дело, спросите эксперта. Именно таков один из подходов. При оценке на основе экспертных заключений эксперта спрашивают, сколько времени потребуется на что-то или насколько большим это окажется. Эксперт дает оценку, опираясь на свою интуицию или чутье.

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

Большим плюсом экспертной оценки является то, что она, как правило, не занимает много времени. Обычно разработчик читает пользовательскую историю, задает пару-тройку уточняющих вопросов и дает оценку, опираясь на свою интуицию. По некоторым данным, такой вид оценки даже более точен, чем другие, более аналитические подходы (Johnson et al., 2000).

Оценка по аналогии

Альтернативой экспертной оценке является оценка по аналогии. Именно к ней мы прибегаем, когда говорим: «Эта история немного больше, чем та история». При оценке по аналогии оценщик сравнивает оцениваемую историю с одной или несколькими другими историями. Если данная история превышает другие по размеру в два раза, то говорят, что она в два раза больше. Существуют явные свидетельства того, что мы оцениваем относительные размеры лучше, чем абсолютные (Lederer and Prasad, 1998; Vicinanza et al., 1991).

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

Разбивка на более мелкие части

Разбивка предполагает разделение истории или функции на более мелкие, легче поддающиеся оценке части. Если большинство пользовательских историй, включаемых в проект, требуют для реализации от двух до пяти дней, крайне трудно оценить историю, для реализации которой нужно, скажем, 100 дней. Дело не только в том, что крупные объекты труднее поддаются оценке, в этом случае просто очень мало сходных историй для оценки. Спросить «действительно ли эта история в 50 раз сложнее, чем та?» – совершенно иное дело, чем спросить «действительно ли на эту историю нужно в полтора раза больше времени, чем на ту?».

Для решения подобной проблемы нужно разбить большую историю или функцию на несколько более мелких объектов, а затем провести их оценку. Вместе с тем применять такой подход следует осмотрительно, чтобы не зайти слишком далеко. Наиболее наглядно эту проблему демонстрирует следующий, не относящийся к программному обеспечению пример. Воспользуемся методом разбивки для оценки моего счета в гольфе в эти выходные. Будем считать, что на поле, где я играю, 18 лунок, каждая из которых классифицируется как «пар 4». (Если вы не знакомы с правилами подсчета очков в гольфе, то замечу, что пар – это количество ударов, которые должен сделать игрок, чтобы загнать мяч в лунку.)

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

Чрезмерная разбивка приводит не только к повышению вероятности пропуска задачи, суммирование оценок по множеству мелких задач также ведет к проблемам. Например, для каждой из 18 лунок я могу оценить свой результат в диапазоне от 3 до 8. Умножение оценок на 18 дает мне полный диапазон от 54 до 144. Вряд ли я пройду все лунки так хорошо или так плохо. Если меня попросят оценить общий результат, то я, скорее всего, назову диапазон от 80 до 120, что меньше полного диапазона и ближе к реальности.

Конкретная рекомендация по разбивке пользовательских историй приведена в главе 12 «Разбивка пользовательских историй».