Оценка стоимости программного обеспечения в гибком управлении проектами

Введение

Одна из самых сложных задач в разработке программного обеспечения — определить, сколько времени и сколько потребуется для выпуска нового программного продукта. Это должно быть так сложно? Ответ неоднозначен.

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

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

Написание программного обеспечения хорошего качества — хлеб с маслом для старших инженеров; создание потрясающих программных продуктов может быть гораздо более сложной задачей для всех участников.

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

Итак, как вы оцениваете размер, продолжительность и стоимость проекта? Давайте рассмотрим оценку Agile-проектов и затраты на разработку программного обеспечения, а также то, как мы это делаем в Toptal.

Традиционное ценообразование и оценка контрактов

Традиционно, используя методы, отличные от Agile, проекты программного обеспечения стремились зафиксировать функциональность или объем, а время и стоимость были переменными. Это вызывает проблемы:

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

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

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

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

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

Гибкие контракты для программных проектов

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

Что звучит лучше и повышает доверие заинтересованных сторон, фиксированные затраты или переменные затраты?

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

Таким образом, Agile-контракты сосредоточены на следующем:

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

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

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

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

• Ранжированные оценки . Существует два способа ранжирования оценок в контракте проекта Agile: диапазон продолжительности или диапазон функций. Диапазон продолжительности позволяет оценить, что проект или пакет работ займет от 12 до 16 недель для данного набора объемов. Однако добавление продолжительности увеличивает затраты, поскольку вы дольше сохраняете членов проектной группы или означает, что они не могут быть освобождены для работы над другими проектами разработки. В Toptal мы предпочитаем ранжировать функции по разным сюжетным точкам, сохраняя объем как переменную, но обещая предоставить клиенту минимальный уровень ценности в течение фиксированного периода времени рабочего пакета или всего проекта.

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

Наш подход к стоимости программного обеспечения и ценообразованию

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

При разработке сметы и проекта с фиксированной ценой предпринимаются следующие шаги:

1. Начальный масштаб высокого уровня

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

Итак, мы начинаем с устава проекта и высокоуровневого набора «эпических» функций, которые определяют направление проекта на основе здравого видения и целей.

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

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

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

2. Предложение

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

С подробностями выше, мы в состоянии предоставить предложение. Наши инженеры выбираются для конкретных требований проекта и работают вместе с руководителем проекта, чтобы найти по крайней мере одно техническое решение, расчетную продолжительность, обеспечивающую известный объем, и ориентировочную стоимость для завершения проекта.

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

Предложение является первым инструментом в разработке продолжительности и стоимости проекта. Как только предложение будет принято, мы можем перейти к предоставлению фиксированной цены.

3. Планирование выпуска

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

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

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

Конец этого процесса определит размер проекта и зависимости между функциями. Размер определяется путем сложения всех пунктов истории из элементов в бэклоге продукта. Если это число равно 120, то размер нашего проекта составляет 120 стори-пойнтов.

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

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

д. Планирование релиза На сегодняшний день мы определили, каким, по нашему мнению, будет продукт и насколько он велик.

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

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

И, наконец, этот план гарантирует, что у проектной группы есть путеводная звезда, которая указывает путь и определяет логическую конечную точку разработки.

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

Чтобы взять базовый сценарий, мы берем общее количество очков истории, которые мы получили от определения размера нашего невыполненного задания, и делим его на ожидаемую скорость нашей команды. (Скорость NB обычно выражается в виде диапазона, но для простоты мы будем использовать здесь одно число.) Мы работаем двухнедельными итерациями, поэтому наша скорость будет отражаться тем, сколько мы можем выполнить за двухнедельный цикл с доступными дееспособность команды. Если бы наша история набрала 120 баллов, и мы рассчитываем завершить 20 баллов за итерацию, общая продолжительность разработки составила бы 12 недель или 6 итераций. Мы добавляем к этому двухнедельный спринт 0 и двухнедельный спринт подготовки к выпуску. В общей сложности продолжительность нашего проекта составляет 16 недель. Есть методы, которые мы можем использовать, чтобы создать соответствующий буфер риска в нашем планировании, который мы обсудим позже. Короче говоря, мы используем буфер, чтобы управлять риском неопределенности и прийти к минимальному соглашению об ожидаемых сюжетных очках. Результатом может быть диапазон от 90 до 150 поставленных историй, 90 — это минимум, который будет приемлем для создания жизнеспособного продукта.

В качестве альтернативы, если проект должен быть завершен к определенной дате, скажем, за 10 недель, команда должна определить, какая часть незавершенной работы может быть завершена за это время. Если мы ожидаем 20 баллов за спринт, плюс спринт 0 и спринт релиза, мы должны нацелиться на 60 баллов, завершенных к концу проекта. Опять же, мы хотели бы управлять рисками, добавляя соответствующий буфер, что могло бы привести к цели от 45 до 75 пунктов истории, завершенных и готовых к выпуску. 45 сюжетных пунктов соответствуют минимуму, приемлемому для создания жизнеспособного и ценного продукта. Это один из сценариев, в котором вы можете ожидать добавления члена команды для увеличения скорости, если это необходимо.

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

4. Контракт с фиксированной ценой

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

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

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

Методы оценки

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

Оценка размера

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

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

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

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

Очки истории

Story Points — это единица измерения, которая выражает общий размер пользовательской истории. Размер истории, когда он оценивается, включает в себя все аспекты проектирования, разработки, тестирования, проверки кода, интеграции и т. д.

Каждый размер истории связан с другой историей. Так, например, история A может быть оценена в один балл, история B — в два балла, а история C — в три балла. Здесь история C по крайней мере в три раза больше истории A и по крайней мере вдвое меньше истории B.

Если следующие истории в нашем бэклоге продукта имеют соответствующие размеры:

Общий размер проекта составляет 12 стори пойнтов.

Идеальные дни

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

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

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

Методы оценки

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

Аналоговые оценки Здесь мы рассматриваем две дискретные функции и решаем, что одна относительно меньше или больше другой. Мы можем посмотреть на данную историю и согласиться с тем, что она небольшая по размеру, и если использовать очки истории, мы можем присвоить ей размер два. Следующий рассказ может считаться большим по сравнению с первым, и мы присвоим ему размер пять. Это говорит о том, что крупная функция как минимум в два раза больше мелкой.

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

Планирование покера Много было написано о планировании покера; Я также упоминал об этом в моем предыдущем блоге. Один из лучших ресурсов для понимания этого здесь.

По сути, он сочетает в себе экспертное мнение, аналогию и совместную работу команды в одном простом, быстром и надежном процессе.

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

Скорость

Скорость — это мера способности команды выполнить работу за данную итерацию (или спринт).

Он выражается в виде диапазона, например, от 23 до 32 пунктов за спринт, особенно в начале жизни проекта. Как правило, это связано с тем, что если одна и та же команда ранее не работала над одной и той же проблемой, трудно точно изобразить, какой будет скорость команды. Обратите внимание, мы имеем в виду скорость команды, а не отдельного человека!

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

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

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

• 4 члена команды * две недели * 40 часов в неделю = 320 часов
• Умножить на нашу 70-процентную мощность = 224 часа.
• Сложите все функциональные задачи и перестаньте считать на 224.
• Возьмите все завершенные функции, добавьте их очки истории, и вы получите скорость, скажем, 36.
• Примените 20 процентов в обе стороны, чтобы получить диапазон от самого низкого до самого высокого, чтобы получить расчетную скорость от 29 до 43 пунктов.

Скорость обычно меняется на первых двух-четырех итерациях, а затем стабилизируется в небольшом диапазоне точек. Таким образом, если перед первым спринтом наш первоначальный диапазон был от 29 до 43, то к четвертому спринту он может стабилизироваться с 34 до 38. Это дает нам большую уверенность в прогнозировании окончательной даты завершения.

Планы буферизации для риска и неопределенности

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

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

Как правило, существует два типа буферов: Feature и Schedule. Поскольку мы часто определяем фиксированную цену для фиксированной даты поставки, предпочтительнее использовать буфер функций.

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

Буферы функций

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

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

Некоторые заключительные мысли

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

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

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

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

Резюме

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

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