Мы не смогли пройти мимо крутейшей статьи по Agile от главы проектов Toptal. А чтобы было легче ей поделиться, мы ее перевели. Просим любить и жаловать!
Одна из самых сложных вещей при разработке программного обеспечения – определить, как долго потребуется работать над новым продуктом и сколько это будет стоить. Почему это так сложно? Ответ не слишком очевиден.
Оценка стоимости нового продукта в принципе сложна, а люди не слишком хороши в точном предсказании событий. Ни один проект не повторяет другой, каждый уникален не только в своих целях, но и в бесчисленных особенностях, которые его формируют. Часто простая на первый взгляд проблема оказывается намного сложнее изнутри, а порой требует серьезных технических доработок для своего решения. И, несомненно, в любом проекте всегда есть множество неизвестных, которые возникают уже в процессе работы над ним.
К тому же и одинаковых людей не бывает – ни заказчиков, ни разработчиков, ни пользователей. Мы все приступаем к работе со своим багажом знаний, опыта, ценностей, ожиданий, готовности к риску и способности адаптироваться.
Написание качественного ПО – это хлеб с маслом для разработчиков; создание же классного программного продукта – намного более сложное предприятие для всех, кто в него вовлечен.
Разработка крутого ПО требует идеального баланса
Однако, когда мы говорим о ПО, понимание сроков и стоимости является ключевым для принятия стратегических бизнес-решений. Это верно и для стартапов, и для сложившихся бизнес-проектов, и для оптимизации бизнес-процессов. Затраты времени, возврат инвестиций и полученные преимущества могут помочь бизнесу или разрушить его. Логичны вопросы: что мы получим за наши деньги? Можем ли мы предсказать издержки? Сколько будет стоить создание продукта, который мы хотим? Когда мы его запустим? Получим ли мы качественный продукт в результате? Поможет ли он развитию бизнеса? Принесет ли он нам дополнительную ценность?
Итак, как же быть с оценкой масштабов, сроков и стоимости проекта? Давайте исследуем возможности Agile, и то, что делаем мы в Toptal.
Традиционный подход к цене договора и оценке
Традиционно, если вы не используете Agile и создаете ПО с определенным функционалом, для определенной сферы, то допускаете вариабельность сроков и затрат. Это приводит к проблемам:
1. Как вы можете понять, что создаваемый в рамках проекта функционал – именно тот, который наилучшим образом подходит вашему бизнесу или заказчику? Чаще, чем можно представить, требования к функционалу и области применения меняются, а требования к результату определяются уже в процессе работы над проектом, причем это касается необходимых и обязательных компонентов.
2. Когда затраты не определены, мы теряем контроль над возвратом инвестиций, к которому стремимся. Рост стоимости часто возникает из-за не просчитанных рисков или изменивших требований, что заставляет разработчиков расширять команду, чтобы уложиться в заданный срок, или увеличивать затраты времени на разработку. Ни то, ни другое нежелательно.
3. Когда не определено время, мы не можем контролировать свою позицию на рынке. Возможно, мы пропустим важную для индустрии дату или конкуренты запустят аналогичный продукт раньше нас – в любом случае мы теряем конкурентное преимущество, которое могло быть у нашего продукта.
Все следствия вариативных сроков и стоимости отрицательные и нежелательны.
Конечно, большинство заказчиков пытаются решить все эти проблемы. Однако вероятность этого близка к нулю.
Попытка зафиксировать начальные требования приводит к тому, что продукт не соответствует задачам, разрабатывается слишком долго или стоит слишком дорого для конкретного заказчика.
Подход к проектам разработки в Agile
Стоимость – это производное времени и людей (участников команды). Добавьте время, и стоимость вырастет за счет того, что вы дольше задействуете специалистов. Добавьте участников команды, и стоимость вновь вырастет, при этом ценность для бизнеса – нет. Это то, чего мы стремимся избежать. Поэтому принципы Agile предполагают фиксированные затраты времени и размер команды при вариабельности масштабов.
Что лучше звучит и вызывает больше доверия у заказчика – фиксированная или переменная стоимость? При этом важно, чтобы продукт исполнял свое предназначение и удовлетворял нуждам заказчика. Нет никакого смысла в том, чтобы потратить точное количество времени и денег и получить инструмент, который невозможно эффективно использовать.
Поэтому контракты, созданные по методологии Agile, предполагают следующие опции:
– Этапы работы с фиксированной стоимостью. Большой проект разбивают на логические мини-релизы, каждый из которых вносит определенный вклад в конечный результат. Каждый релиз оценивается отдельно. По мере завершения одного этапа, оценка будущих может меняться в зависимости от того, какие новые факторы появились при работе над предыдущим. Это позволяет избежать ненужных непредвиденных расходов и при необходимости менять приоритеты и требования к функционалу в зависимости от требований заказчика.
– Ранняя остановка разработки. Это позволяет заказчику остановить работу над проектом на любой стадии, если результат уже получен и дальнейшая разработка не ускорит возврат инвестиций, а только увеличит затраты на работу команды. Преимущество для покупателя в этой ситуации заключается в скорейшем завершении работы над проектом, если он имеет весь необходимый функционал и вполне жизнеспособен. Чаще всего, разработчик получает при этом компенсацию рисков, например, в размере 20% от оставшейся стоимости договора.
– Гибкие изменения. Изменения заложены в ДНК разработки по методологии Agile. Мы ожидаем, что в самом начале не знаем всего необходимого для успеха проекта. Поэтому мы поощряем изменения, основанные на релевантных данных и обратной связи. Они помогают убедиться в том, что мы работаем в правильном направлении. В конце каждой итерации мы можем отказаться от функционала, который больше не нужен или не является приоритетным, или заменить его. И если новый имеет ту же стоимость, то это не повлияет на цену договора. Если же стоимость будет ниже, то мы сможем добавить что-то, от чего ранее решили отказаться. Это возможно в любое время, если команда проекта и заказчик поддерживают тесные и доверительные рабочие взаимоотношения.
– Дополнительные работы. В жизненном цикле проекта часто выявляются опции, которые невозможно реализовать в рамках фиксированной стоимости контракта. В таком случае возможно добавить новые этапы работы над проектом, каждый из которых получит отдельную оценку стоимости и времени.
– Гибкие сметы. В рамках работы по Agile можно создать два варианта гибкой сметы проекта: с гибкими сроками или с гибким функционалом. Первый позволяет сказать, к примеру, что работа над проектом или его частью с указанным списком опций займет от 12 до 16 недель. Однако, увеличение сроков приводит к росту затрат на работу команды, которая не может в это время приступить к работе над новыми проектами. Поэтому мы в Toptal предпочитаем использовать гибкий список опций. Мы гарантируем, что продукт будет иметь определенный минимум функционала, достаточный для достижения целей заказчика, и будет разработан строго в указанные сроки.
Стоит помнить, что функционал всегда можно расширить позже. Например, когда вы начнете получать прибыль, увеличите количество пользователей или снизите издержки использования. В любом случае гораздо проще обосновать затраты ресурсов и времени, если проект уже показал возврат инвестиций и свою ценность для бизнеса.
Наш подход к стоимости ПО и ценообразованию
Мы в Toptal очень тесно работаем как с заказчиками, так и с разработчиками. Это помогает нам использовать техники, которые поддерживают у заказчика уверенность в соблюдении сроков и точной оценке стоимости проекта. Мы постоянно работаем над планированием и адаптацией проекта с начального общего уровня и до мельчайших деталей, если это позволяет избежать ненужных затрат и внедрять управляемые изменения.
Чтобы произвести оценку и зафиксировать стоимость проекта, мы предпринимаем следующие шаги:
1. Начальная общая оценка
На этой стадии мы очень мало знаем о том, каким получится проект. Было бы крайне самонадеянно считать, что уже в начале работы мы точно знаем, какие опции нужны нашим заказчикам и пользователям.
Поэтому мы начинаем с общего документации проекта и общего набора эпиков (основных крупных опций), определяя его специфику, исходя из целей и нашего видения.
А. Постановка целей и задач. Что нам нужно разработать? Чего необходимо достичь и какие решить бизнес-задачи? Понимание ответов на эти вопросы позволяет нам оценить масштаб проекта. Нужен ли нам прототип, чтобы протестировать исходную идею, концепт или технологию? Есть ли у заказчика готовое предложение, которое было протестировано на конкретном рынке и готов ли он запустить первый минимально жизнеспособный продукт? Или речь идет о расширении существующего бизнеса или улучшении существующего продукта?
Б. Набор эпиков(epic). Не углубляясь в детали, определите функционал, который необходим для продукта. Это будет структурированный «список покупок», который станет скелетом вашего продукта.
В. Анализ MoSCoW. Это техника, которая позволяет определить, что именно делает продут жизнеспособным, а что необязательно, но просто хочется в нем реализовать. Функции, которые вы определяете как Must – то, что будет привлекать и удерживать пользователей продукта. То, что вы обозначите как Should, будет радовать и удивлять покупателей, однако это можно будет добавить и позже. Функции Could не добавляют значительной бизнес-ценности и не ускоряют возврат инвестиций, поэтому будут в наименьшем приоритете. Наконец, Won’t могут стать важными в один прекрасный день, но на этой стадии развития проекта они не нужны. Таким образом, вы можете заодно определить и потенциал продукта.
2. Предложение
Чтобы решить, стоит ли запускать проект, важно иметь всю необходимую информацию о стоимости и длительности. Поэтому вы должны задать себе как минимум два (а лучше три) вопроса. Что потребуется для запуска этого продукта? Когда мы можем его запустить? Как это соотносится с нашей бизнес-стратегией и финансовым положением?
Зная ответы на эти вопросы, мы будем готовы сделать предложение. Мы сможем собирать команду разработчиков с учетом специальных требований проекта и объединить их как минимум с одним проектным менеджером, чтобы создать техническое решение в установленный срок, с обозначенным функционалом по указанной стоимости.
Как мы уже упоминали, в начале работы над проектом мы очень мало знаем о том, что должно получиться в итоге. Мы осознанно размываем описание функционала и масштабов, в противном случае мы должны точно знать, что от нас требуется. Оценка стоимости и сроков на этом этапе будет наименее точной, но она уже позволит понять, стоит ли связываться с проектом.
Предложение – это первый инструмент определения продолжительности и стоимости работы. Как только оно принято, мы можем двигаться дальше к фиксированной цене.
3. Планирование релизов
Следующий этап составления сметы – это разработка плана релизов, который распределит работу над функционалом во времени. Мы создаем его с учетом списка функций, размеров проекта, скорости, с которой наша команда может разрабатывать качественное ПО, отвечающее ожиданиям заказчика, и техник, снижающих риски неопределенности.
А. План продукта (product backlog). Это список пользовательских историй, основанный на уже существующем списке эпиков. На этом этапе работу ведет уже выделенная команда проекта, проектный менеджер и заказчик, и в результате они получают более значимый документ. Каждая история в новом списке представляет некоторую часть бизнес-ценности, которая заключается в продукте. На этом этапе мы по-прежнему не слишком углубляемся в детали, нам не нужны какие-либо качественные критерии, мы не хотим знать, будет ли кнопка синей или зеленой. Нам просто нужно знать: будет кнопка, которая запускает выполнение определенной задачи.
Б. Оценка. Когда у нас есть список пользовательских историй, команда проводит его оценку, используя технику «Покер-планирование» (Planning Poker). Это очень полезная техника, гарантированно дающая быстрый и надежный результат, основанный на экспертном мнении и оценке аналогов. Каждой истории в списке присваивается определенное число очков в зависимости от масштабов и сложности реализации. Доступны и другие техники оценки Agile, например «Идеальные дни» (Ideal Days).
В результате этой процедуры мы получим точную оценку масштабов проекта и установим зависимости между опциями. Масштаб – это сумма очков всех пунктов, например, 120.
В. Расстановка приоритетов. Теперь, когда у нас есть журнал продукта и оценка масштабов проекта, мы готовы вместе с заказчиком расставить приоритеты. Это касается того, какие элементы продукта наиболее значимы для заказчика с точки зрения желаемых результатов. Самый первый элемент будет наиболее важным, второй – чуть менее, и так далее. Нет двух одинаково значимых элементов, каждый из них имеет меньшую или большую значимость относительно других.
Такой подход крайне важен для грамотного планирования проекта разработки. Теперь мы точно знаем, что важно для нашего клиента и в каком порядке мы должны работать, с учетом всех зависимостей, чтобы создать продукт, соответствующий ожиданиям.
Г. Планирование релиза. К этому моменту мы определили, каким должен стать наш продукт и каких он масштабов.
Теперь нам нужно понять, сколько времени займет создание проекта, готового к релизу. Заказчик и команда, включая дизайнеров, инженеров, тестеров, скрам-мастера и проектного менеджера, вместе определяют, чего можно достичь и как быстро может выполняться работа – в результате мы получаем план релиза.
Он дает, в том числе, понимание того, как проект соотносится со стратегическими планами заказчика. Наконец, этот план подтверждает, что у команды проекта есть маяк, на который она будет ориентироваться, и определяет логическое завершение процесса разработки.
Прежде чем начать, мы должны удостовериться, что все одинаково понимают, что значит «готово». Это некий набор критериев, который является полным для заказчика и одновременно определяет требования к продукту для релиза.
Для начала, мы берем общее количество очков проекта, определенное на стадии журнала продукта, и делим его на скорость работы команды. Обычно скорость определяют как диапазон, но мы для простоты используем одно число. В работе мы используем двухнедельные итерации, поэтому наша скорость определяется как количество работы, которую мы можем выполнить существующей командой за две недели. Если наш проект имеет 120 очков, а мы ожидаем, что за две недели выполним 20 очков, то общее время разработки будет равняться 12 неделям, или шести итерациям. К этому мы добавляем нулевой спринт в две недели и еще один спринт на подготовку релиза. Итого, наш проект будет длиться 16 недель. Есть техники, которые позволяют создать достаточный буфер для рисков при планировании, и их мы обсудим ниже. Но если коротко, то буфер мы используем, чтобы управлять рисками неопределенности и прийти к соглашению о том, какое количество очков проекта мы обязаны предоставить. Итог может варьироваться от 90 до 150 очков, при этом 90 – это тот минимум, который необходим для жизнеспособности продукта.
Когда проект должен быть завершен к конкретной дате, например, за 10 недель, команда должна определить, какой объем журнала продукта можно реализовать за это время. Если мы ожидаем разработку 20 очков за этап, плюс нулевой спринт и релиз, то будем стремиться к реализации 60 очков к концу работы над проектом. И вновь мы должны учесть возможные риски, создав для них разумный буфер, что в итоге выльется в диапазон от 45 до 75 очков выполненной работы к моменту релиза. В 45 очков мы должны уложить минимальный функционал, необходимый для ценного и жизнеспособного продукта. Возможно, при таком сценарии вы сочтете разумным расширить команду, чтобы увеличить скорость разработки.
Конечно, для всего описанного выше необходима качественная коммуникация и совместная работа всех вовлеченных сторон. Только тогда возможно разработать достижимый, реалистичный и приемлемый для заказчика план релиза.
4. Фиксированная цена договора
Как только мы достигли согласия относительно сроков, мы можем назвать стоимость договора. Как уже говорилось, крайне рекомендуется сохранять неизменными срок разработки проекта и размер команды и варьировать функционал продукта.
Цена договора предоставляется вместе с графиком работ и согласованным графиком платежей.
Если мы готовы следовать духу разработки по Agile – доверять, общаться, сотрудничать, то все перечисленные выше шаги позволят нам создать условия, в которых проект будет с максимальной вероятностью разработан в указанное время в рамках бюджета. Конечно, нельзя исключать случаи, когда разработка займет больше или меньше времени, и в этих ситуациях важно сохранять максимальную прозрачность процессов.
Техники оценки
Для планирования и оценки по Agile есть множество техник, которые команда разработки может использовать для уверенности в объемах, сложности, продолжительности и стоимости проекта. Вот некоторые из них, которые используем мы для наших разработок программных продуктов.
Оцениваем масштаб
Масштаб проекта указывает на его область применения, сложность, габариты, риски и значимость. Если проводить аналогии, то нам нужно понять, что мы строим – Эйфелеву башню или Великую китайскую стену. Эйфелева башня – это высокая, тяжелая и сложная структура, созданная в тесной городской среде. А Великая китайская стена – сравнительно простая, но длинная и устойчивая структура, которая тянется на многие мили по холмистой местности. И хотя оба проекта можно назвать большими, их назначение, сложность, габариты и значимость различны.
Очень важно управлять ожиданиями при оценке. Она не является предсказанием, обещанием или гарантией. Когда речь идет об общем масштабе, продолжительности и стоимости, мы всегда работаем с диапазонами, чтобы учесть риски, неопределенность и неизвестные.
Описания, которые представляют функционал вашего продукта, по отдельности измеряются и оцениваются с помощью очков или идеальных дней. Общее количество очков или дней определяет масштаб проекта.
Очки
Очки – это единицы измерения, демонстрирующие общий объем пользовательских историй. Этот размер при оценке включает все аспекты дизайна, разработки, тестирования, ревью кода, интеграции, и так далее.
Размер каждой истории соотносится с размером всех других. Например, опция А «стоит» 1 очко, опция Б – два, а опция В – три. Таким образом, опция В в три раза масштабнее, чем А, и в полтора раза, чем Б.
Из суммы очков всех историй в журнале продукта мы получаем общее число очков проекта.
Идеальные дни
Эта технология оценивает масштаб в днях. В ней исключены любые отвлекающие процессы – перерывы, планирование, чтение почты и все, что не имеет отношения непосредственно к созданию проекта. Она концентрируется на сроках выполнения задачи при постоянной и непрерывной над ней работе.
Обычно при первичной оценке, когда мы знаем о проекте меньше всего, мы используем идеальные дни, так как эта технология лучше коррелирует с прошлым опытом, чем абстрактные цифры пользовательских историй. Особенно когда эти истории имеют мало деталей, а дополнения с большой степенью вероятности появятся позже.
Когда оценка проводится на более поздней стадии, после разработки журнала продукта, можно использовать любой подход на усмотрение команды разработчиков. Преимущества есть у каждого, и все зависит от предпочтений.
Способы оценки
Совместная оценка. Процесс не проходит в изоляции. Над оценкой совместно работает вся команда разработчиков с привлечением экспертов, и она включает дизайн, создание баз данных, серверную часть, фронтэнд и пользовательский интерфейс, тестирование и другие возможные аспекты. Это позволяет избежать проблем, связанных с тем, что не были учтены все необходимые работы, и удостовериться в том, что масштаб каждой опции не будет недооценен или, наоборот, переоценен.
Оценка по аналогии. Мы берем две отдельных опции и решаем, что одна из них больше или меньше, чем другая. Мы можем взять отдельную историю и согласиться, что она невелика, и если мы используем очки историй, то назначим ей два очка. Следующая может быть больше предыдущей, и ей мы дадим пять очков, если решим, что она больше в два с половиной раза.
То же самое нужно продолжить со всеми оставшимися историями. Закончив, мы распределим все маленькие, средние и большие истории и проверим их размеры, чтобы убедиться, что ни одна из них не выбивается из произведенной оценки.
Покер-планирование. Об этой технологии писали немало. Я упоминал ее в своем блоге. Один из лучших ресурсов для ее понимания вы найдете также по ссылке.
Если коротко, то она комбинирует экспертные мнения, аналогии и командную работу в одном простом, быстром и надежном процессе.
Скорость
Скорость – это оценка способности команды выполнять некоторый объем работы в течение заданной итерации (спринта).
Она выражается с помощью диапазона, например, 23-32 очка историй на спринт, особенно на начальных стадиях работы над проектом. В основном это потому, что даже если та же самая команда раньше работала над похожей задачей, всегда сложно точно предсказать скорость работы. Обратите внимание, мы говорим именно о скорости команды, а не отдельного человека!
Мы используем скорость, чтобы планировать релиз и адаптировать планы и отрезки работы по мере развития проекта. Таким образом, мы регулярно улучшаем наши прогнозы по завершению проекта по ходу его действия.
Когда мы запускаемся, то вынуждены определять диапазон скорости, располагая небольшим количеством данных. Мы можем использовать исторические данные, если совпадают команда и проблематика, что случается весьма редко. Мы можем провести тестовую итерацию с помощью команды проекта, но это весьма затратно и не работает, если решение о начале работы еще не принято. Или же мы можем прогнозировать.
Прогноз скорости включает оценку отдельных спринтов с помощью очков историй и разбивку их на отдельные задачи, необходимые для реализации истории. Мы оценим количество часов, которые нужны для завершения каждой задачи, включая дизайн, разработку, тестирование, и так далее, и предположим, какую работоспособность будет иметь команда на протяжение отдельного спринта. Работоспособность в 70% в случае свободной от других задач команды подойдет для начальных расчетов. Поэтому, в простых ситуациях, мы рассчитаем количество часов для команды следующим образом:
- 4 участника команды * 2 недели * 40 часов в неделю = 320 часов
- Умножаем на 70% = 224 часа
- Добавляем все задачи, нужные для реализации, пока не дойдем до 224 часов
- Суммируем очки историй для выбранных задач и получаем скорость, например, 36
- Применяем коэффициент в 20% в обе стороны и получаем оценочный диапазон скорости в 29-43 очка
Скорость обычно варьируется в течение первых 2-4 итераций, а затем стабилизируется в рамках небольшого диапазона очков. И если наш начальный диапазон был 29-43 очка, то к четвертой итерации он выйдет на плато, например, 34-38. Это позволит нам с большей точностью предсказать дату завершения проекта.
Планируем буферы для рисков и неопределенности
Все проекты разработки сопряжены с некоторой неопределенностью. Она уменьшается по мере того, как продвигается работа над проектом, по мере роста знаний о технологиях, окружении, производительности и потребностях заказчика и пользователей.
Мы учитываем эту неопределенность, или риски, с помощью буфера в графике работы. Он соотносится с вероятностью ошибки при оценке и неизвестными, которые мы не можем предвидеть, начиная работу.
Обычно буфер бывает двух видов: функциональный и временной. И так как мы чаще всего обозначаем фиксированную стоимость и срок релиза, то предпочитаем использовать функциональный буфер.
Такой подход дает нам надежную стратегию управления рисками и вызывает доверие у заказчиков. Они имеют точные ожидания относительного того, что получат по завершению проекта.
Функциональные буферы
Используя такой буфер, мы прогнозируем, что предоставим определенный набор опций, но в идеале завершим большее количество работы. Набор отражает минимальный функционал, который заказчик считает необходимым для запуска жизнеспособного продукта, но позволяет нам при возможности сделать больше, если внешние и внутренние факторы нам это позволят.
Таким образом, заказчик решает, какие приоритетные опции из журнала продукта наиболее важны – например, на общую сумму до 100 очков историй. Затем он может добавить дополнительный функционал еще на 30 очков. Таким образом, команда будет планировать разработку «весом» в 130 очков, с обязательным минимумом в 100, к установленной дате релиза и по фиксированной цене договора.
Некоторые мысли в завершение
Agile может оказаться довольно сложной для полного принятия и использования методологией. Особенно это касается чувствительных тем, таких как цена, сроки и размеры проектов. К сожалению, я из первых рук знаю, что некоторые клиенты хотят сначала зафиксировать абсолютно все, а потом только рады обвинять поставщиков, когда проект выходит из заданных рамок. В равной степени есть и разработчики, которые упираются в землю, принимают жесткую позицию и отказываются что-то менять в ответ на запрос заказчика. Agile основана на доверии, хороших взаимоотношениях и бесперебойной коммуникации. Эти ценности должны разделять все стороны, и тогда они смогут работать над проектом, получая взаимную пользу, удовлетворение и успех. Открытость, конструктивное отношение к сотрудничеству и переговорам – это лучший способ не испортить партнерство.
Я работал с клиентами, которым было тяжело воспринимать адаптивную природу Agile и отказаться от отношений командования и контроля. Непросто отпустить ситуацию и по-настоящему довериться команде, которую ты не знаешь. Часто клиенты просят нас создать спецификацию со всеми требованиями к продукту, который они получат. Это дает им уверенность в том, что масштаб проекта определен. Но такой подход не оправдал себя. Если мы фиксируем свойства продукта и включаем в договор нереалистичные требования, быстро возникают проблемы.
Мы знаем, что объем работы меняются, возникают новые ранее неизвестные факторы или то, чего изначально хотел заказчик, изменилось, порой радикально. Адаптивный подход к ценообразованию, планированию и оценке позволяет клиентам получить именно такой продукт, который требует их рынок. А разработчику он позволяет быть гибким, креативным и одновременно эффективным. Ключ ко всему – максимальное взаимодействие между заказчиком и разработчиком при переговорах.
Поставщики должны быть честными, а заказчики реалистичными относительно того, чего они могут достичь в результате работы. Разработчик, который обещает заоблачный результат, а в процессе увеличивает цену, может выиграть контракт, но вскоре потеряет расположение рассерженного клиента. Слишком часто отношения рушатся из-за нехватки доверия между сторонами. Его нужно строить с самого начала и поддерживать на протяжение всего проекта. Стороны должны обменяться равными и необходимыми ценностями: заказчики хотят получить пользу для своего бизнеса, а поставщики могут создать дополнительную ценность, длительные отношения с заказчиком.
Заключение
Я надеюсь, что этот материал поможет вам при планировании, оценке и определении стоимости проекта разработки по Agile. Все перечисленные подходы и техники созданы, чтобы построить доверие в команде и вселить в заказчика уверенность относительно сроков и цены его будущего продукта. И, конечно же, чтобы уверенно принимать решение о начале работы.
Следуя этим методам, вы будете знать, что находитесь на верном пути при работе над своим программным продуктом.
Автор материала – Paul Barnes, глава проектов Toptal
Оригинал был опубликован в блоге Agile-Nightmare.
