Толпа в [закрытом] проекте фиксированных затрат

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

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

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

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

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

Okay, this will not be the ideal answer you are looking for, but may help non-the-less.

For your first point:

With agile, and Scrum in particular, the style is suited toward changing specifications and unfixed deadlines using iteration patterns. To be able to manage this in a fixed scope project will be a nightmare. What one would normally do is set a budget for the specified scope, and any addendum to this would produce billable hours above and beyond the scoped budget. To do this in Scrum would be pointless, as the product backlog will be continually filled by the stakeholders. If there is no "punishment" for scope changes in a fixed budget, there will be nothing holding people back from just loading on to you.

The alternative here is to have fixed scope sprint successions, so for instance:

5x Sprints = x Cost with minimal scope change.

For your second point:

The use of Analysis and Design is an invaluable tool. By using use cases, event tables, sequence diagrams, state machines and the like; you will be saving yourselves oceans of tears in the long run. Basically, once the planning has been done, any addendum to this that requires additional (please note additional, not things that have been overlooked) use cases and large code changes will be out of scope. In fact, anything that was not overlooked in the planning and is not in your specification, is out of scope.

In closing, you will need to have very well planned documentation as well as very solid agreements with your clients to be able to pull this off 100%.

I hope this helps.

I worked in a environment where we had fixed cost and fixed time projects. We has switched to a Scrum-esque methology from a Waterfall/VModel methology. Scrum can work very well in fixed cost/time projects as the concept is that the customer is put in control, however for this to work you have to be able to somewhat accuratly determine what work is required and what it will cost (time, money, resource). And this is a situtation where Scrum in an ideal candidate.

You break down the wishy-washy wish list/requirements/screenshots into tagiable deliverables. E.g. a customer may say "I want ecommerce, with Paypal", you need to break this down into actual deliverables e.g. "1. Customer Registration and Login, 2. Product Catalogue, 3. Shopping Bag, 4. Payment, 5. Order Acknowlegment". At this stage, it's still impossible to determine how long it will take, and ofc we need to deliver all of the above in order to complete the project (i.e. you can't have Ecommerce without Payment). So break them down again, and again, until you have granular deliverables, genreally delverable within hours, maybe days, but certainly not weeks e.g.

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
...

And so on, it can be done very quickly, and you can now probably guesstimate how long it would take todo x (ofc, I might break the above down even further, add more descriptive text to describe the work required, such as what persistant data stuctures Ill might need, the data in those structures, how data will be added, going further you might even desribe the required the begin and exit states).

Once you've go this, you'll notice that some features and depenant on others, e..g you can't have paging feature on a catalogue unless you have a catalogue to start witj, and the catagloge will require the CMS screesn to add and edit items etc etc. Highlight these 'can't live without feature' in whatever tool you using and this forms the core project, and within a day or two you have a bunch of features that can be developed somewhat standalone, with costs, which when added up make the cost of the project. And now the customer is in charge, they decide thay want to added a feature and increase the cost, cool, its up to them afterall.

All the above is obviously only a small portion of what scrum or any agile process is.

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

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

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

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

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

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

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

Изменение объема может привести к добавлению элементов невыполненной работы и удалению других. Это баланс между ROI и фиксированным бюджетом.

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

Помните, что фиксированная стоимость не означает фиксированной длины.

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

Помните, что фиксированная стоимость не означает фиксированной длины.

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

Помните, что фиксированная стоимость не означает фиксированной длины.