Scrum в проекте с фиксированной стоимостью [закрыто]

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

Я знаю, что некоторые люди скажут "Это неправда, мы делаем это

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

Я недавно ответил аналогичный вопрос о SO. Вы можете найти этот ответ полезным.

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

для вашего первого пункта:

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

альтернативой здесь является фиксированная последовательность спринта области, например:

5x Sprints = x Cost with minimal scope change.

для второго пункта:

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

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

надеюсь, это поможет.

Я работал в среде, где у нас были проекты с фиксированной стоимостью и фиксированным временем. Мы переключились на Метологию Scrum-esque из Метологии водопада/VModel. Scrum может очень хорошо работать в проектах с фиксированной стоимостью / временем, поскольку концепция заключается в том, что клиент находится под контролем, однако для этого вы должны быть в состоянии несколько точно определить, какая работа требуется и что это будет стоить (время, деньги, ресурс). И это место, где Scrum в идеале кандидат.

вы сломать невыразительный список пожеланий/требований/скриншоты результатов tagiable. Например. клиент может сказать :" я хочу электронную коммерцию с Paypal", вам нужно разбить это на фактические результаты, например " 1. Регистрация и логин клиента, 2. Каталог Продукции, 3. Хозяйственная Сумка, 4. Оплаты, 5. Acknowlegment Порядка". На этом этапе все еще невозможно определить, сколько времени это займет, и ofc нам нужно доставить все вышеперечисленное, чтобы завершить проект (т. е. вы не можете иметь электронную коммерцию без оплаты). Поэтому разбейте их снова и снова, пока у вас не появятся гранулированные результаты, которые можно будет обрабатывать в течение нескольких часов, может быть, дней, но, конечно, не недель, например

1 Catalogue
1a View all Items
1ai    View all items on 1 page with an image and item name underneath in a grid, 4 items per row
1aii   View 10 items per page with paging
1aiii  View a user slected number of items per page, with paging
1aiiii View all items on 1 page with an image and item name, descriptioon and price on the same line, 1 item per row

1b View by Category
...
1c Search
...
1d Attribute Filter
...

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

Как только вы это сделаете, вы заметите, что некоторые функции и depenant на других, e..g вы не можете иметь функцию подкачки в каталоге, если у вас нет каталога для запуска witj, и catagloge потребует CMS screesn для добавления и редактирования элементов и т. д. Выделите эти "не могу жить без функции" в любом инструменте, который вы используете, и это формирует основной проект, и в течение дня или двух у вас есть куча функций, которые могут быть разработаны несколько автономно, с затратами, которые при сложении составляют стоимость проекта. И теперь клиент отвечает, Они решают, что хотят добавить функцию и увеличить стоимость, круто, это до них в конце концов.

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

Я не думаю, что контракт с фиксированной ценой с ползучестью области и процессом Scrum несовместимы. Вам просто нужно заранее договориться со своим клиентом, как это будет работать. Если вы создаете первоначальное отставание с вашим клиентом, оценивая по мере продвижения, вы можете использовать его в качестве основы для фиксированной цены и графика. Вы даже можете согласиться со ставкой" X "сюжетных точек, равной" Y "стоимости и" Z " графика в начале.

затем вы делаете обычную вещь scrum, имея клиента выделите истории для текущей итерации и т. д.

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

трюк, конечно, должен быть хорош в оценке стоимости и графика для каждой истории / задачи ; -)

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

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

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

изменение области может привести к добавлению элементов отставания и удалению других. Его баланс ROI против предоставленного фиксированного бюджета.

Если область увеличивается (и add value), и стоимость фиксирована, тогда тройное ограничение (стоимость, время и область) должно управляться соответствующим образом.

помните, что фиксированная стоимость не означает фиксированную длину.