Предоставление оценок крупномасштабных проектов в Agile Environment

Ответ 1

Вот основной вопрос.

Когда клиент подумает, что они сделаны?

Если они думают, что они будут сделаны к июню, тогда вы ставите команду Agile на место. Это 4-6 человек в течение 6 месяцев. Это бюджет. По сути, вы делаете умножение для них. команда * ставка * 6 месяцев.

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

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

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

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

В конце концов, они увидят фундаментальную истину.

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

Готово - относительный термин. Некоторые проекты "сделаны", потому что денег больше нет. Другие делаются потому, что больше нет времени. Редко (по крайней мере, в разработке программного обеспечения) - это проект, который когда-либо делался, потому что у нас не хватало вещей.

Ответ 2

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

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

Изменить: Прохладный. Отлично! Из того факта, что вы продали их на Agile-подход, BTW хороший!, скорее всего, вы сможете увидеть их при приближении к нему с гибкой точки зрения с точки зрения функций, которые будут реализованы. Возможно, послушайте этот "" Intro to Scrum" подкаст. Возможно, вы сможете продать их на том факте, что им, вероятно, не понадобится иметь все колокола и свистки, которые, по их мнению, сейчас нужны.

НТН

веселит,

Rob

Ответ 3

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

Вы не можете сделать все три.

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

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

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

Ответ 4

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

Это не отвечает на ваш вопрос, но стоит вспомнить. Если они не встанут наверху без номера спереди (а они не будут), вы должны дать им номер.

Любой, кто спонсирует проект программного обеспечения, должен иметь представление о том, какой доход они получат от своих инвестиций, чтобы они могли оценить, стоит ли делать инвестиции. Проект может стоить того, если он стоит 1 млн долларов и занимает 12 месяцев. Это не стоит делать, если он стоит 2 миллиона долларов и занимает 24 месяца.

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

Если ваш текущий ответ на этот вопрос "мы еще не знаем", тогда они не должны нанимать вас для выполнения проекта. Но это не означает, что они не должны нанимать вас, чтобы узнать, стоит ли делать проект. Хорошим модным словом для консалтинговой фирмы является "предварительное исследование".

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

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

Но сначала вы должны заставить их подняться наверх.

Ответ 5

Эти ответы действительно велики. У меня нет большого опыта, чтобы поделиться, но я подумал об аналогии:

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

Напротив, мой двоюродный брат жены также реконструирует свой дом. Он врач ER, и он не доступен на месте во время ремоделирования. Поэтому он описал, что он регулярно удивляется, что подрядчики принимают важные решения, не посоветовавшись с ним ( "Что? Я не хотел, чтобы окно с картинками было заблокировано! Вырвите стену и перефразируйте окно так, как было!" ). Это, конечно, больно дорого и удаляет график из воды. Определенно не Agile.

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

В качестве отдельного ресурса я искал и нашел книгу на эту тему: " Agile Estimating and Planning от Майка Кон. Прочтите похвальные цитаты на этой странице, из впечатляющего набора экспертов Agile.

Ответ 6

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

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

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

Ответ 7

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

Ответ 8

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

Например, дайте оценку от 6 месяцев до 2 лет (если вы уверены, что это займет меньше времени, чем 2 года. По мере того как вы разбиваете ее на функции, планируете эти функции, вы придумываете лучшие и более высокие оценки, так что после 6mos вы можете с уверенностью сказать (без каких-либо других изменений), мы закончим через 2-3 месяца (всего 8-9 месяцев). В конце концов, вы доберетесь до точки, где вы можете сказать, мы будет сделано после следующей итерации (2 недели до 1 месяца).

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

Ответ 9

Это очень сложная проблема. Посмотрите, что Роберт Стекло должен сказать по этому поводу в своей книге " Факты и ошибки разработки программного обеспечения". (Обратите внимание, что у Amazon есть книги, доступные для новых, меньше, чем они доступны из вторых рук! [По состоянию на 2009-01-05 12:20 -08: 00], а также в книгах Google.)

Ответ 10

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

Пример: общая оценка в размере 10 000 долларов США, но поскольку требования являются неопределенными, и проект может легко изменить курс, существует опция корректировки цены +/- 30%.

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

Ответ 11

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

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

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

Ответ 12

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

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

Убедить

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

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

Помещение очков в отставание

Этот шаг выполняется при участии всей команды схватки.

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

Теперь настало время поставить очки на эти истории. Лично я использую шкалу планирования покера (1/2,1,2,3,5,8,13,20,40,100), так что это то, что я буду использовать для этого примера. В нижней части этого списка вы, вероятно, будете иметь микро задачи (вещи, которые занимают 4 часа или меньше). Дайте каждому микро заданию значение 1/2. Затем продолжите список, указав значение 1 (следующее в шкале) в истории, пока не станет ясно, что история намного больше (2 вместо 1, поэтому вдвое больше). Теперь, используя значение "2", продолжайте список до тех пор, пока не найдете историю, в которой должно быть явно 3, а не 2. Продолжите этот процесс вплоть до верхней части списка.

ПРИМЕЧАНИЕ. Старайтесь сохранить подавляющее большинство очков между 1 и 13. В первый раз, когда у вас может быть множество больших историй (20, 40 и 100), и вам придется их затормозить в куски, меньшие или равные 13.

То есть для точек и первоначального отставания. Если у вас когда-либо была новая история, сравните ее с этим списком, чтобы увидеть, где она подходит (больший/меньший процесс) и придать ей значение ее соседям.

Скорость и оценка (макропланирование)

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

Эта скорость изменится и опустится в течение первых 2-3 спринтов, поэтому всегда хорошо следить за этим значением