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

Question

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

При просмотре всех сообщений в блоге и информационных выпусков Agile проповедников вы просто слышите об открытых масштабах или открытых проектах «времени». Как вы примените это к проекту затрат на исправление?

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

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

Таким образом, вопросы будут:

• Как управлять сферы в проекте затрат исправить?
• Как вы определяете, хотите ли функции, вне рамки оригинала?

Answer 1

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

Фактически, одним из самых больших преимуществ гибкого процесса, такого как Scrum, является то, что он заставляет вас «терпеть неудачу быстро и громко» в проблемных областях вашего проекта. Если после нескольких спринтов ваша команда все еще не может эффективно оценить время и ресурсы, необходимые для реализации конкретной функции, может быть стоит вернуться к требованиям в этой области - их, возможно, необходимо будет уточнить, упростить, или вообще отказаться. Однако в традиционном процессе водопада эти «проблемные функции» часто можно отбросить до последней возможной минуты, в результате чего обычный deathmarch и недопоставка, в которые переходят большинство проектов.

Однако роль Владельца Продукта еще более важна в командах, использующих Scrum, у которых есть большой набор требований. Выйдя на свои собственные устройства, большинство команд разработчиков сосредоточат внимание на наиболее интересных/забавных/geeky-функциях (API-интерфейсах служб, кэшировании, поиске), и оставим «грязные» вещи, такие как процесс оплаты, дизайн UX и i18n до последней минуты , Сильный голос пользователя необходим для обеспечения того, чтобы те функции, которые были важны для конечного пользователя, получили свою долю внимания.

Answer 2

Я недавно ответил similar question on SO. Вы можете найти этот ответ полезным.

Answer 3

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

Для вашей первой точки:

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

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

5x Sprints = x Cost with minimal scope change.

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

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

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

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

Answer 4

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

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

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

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

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

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

Answer 5

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

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

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

Хитрость, конечно, должно быть хорошо оценить стоимость и график для каждого

Answer 6

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

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

Answer 7

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

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

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

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

В любом случае, хорошая компиляция различных гибких контрактов: 10 Contracts for your next Agile Software Project, которые могут быть полезны. Но я думаю, что все они требуют некоторого образования клиентов, особенно тех, которые используются для фиксированной цены с фиксированным объемом (и поздними поставками).

Answer 8

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

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

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

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