Использование Scrum в проектах с фиксированной длиной/исправлением?

Question

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

Проблема в том, что 75% нашего дохода получено из проектов с фиксированной длиной/фиксированной ценой.

Кен Швабер в своей книге Agile Project Management с Scrum охватывает тему торгов по фиксированной длине/фиксированным ценам в приложении в конце книги.

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

Я не уверен, что это единственный способ реализовать Scrum в проектах с фиксированной длиной и фиксированной ценой.

Я хочу знать, как другие успешно участвуют в торгах и извлекают выгоду из проектов фиксированной длины и фиксированной цены.

Answer 1

Да. Думаю, что сможешь. См. The Waterfall's Not Working.

«Получение вне поля с фиксированной ценой» не так уж и сложна. Клиенты также видели сбои. Они видели длительные задержки, связанные с документом требований. Они видели бесконечные заказы на изменение. Им это тоже не нравится.

Но, если вы уверены, что клиент не хочет управлять вещами по-другому, вам нужно принять гибридный подход.

Составление цены не является гибким - этого не может быть. Вы должны, в целях умиротворения непримиримых клиентов, составить цену. Очевидно, у вас будет какой-то генеральный план, чтобы оправдать цену. В основном, все, что вы хотите от этого генерального плана, - это отставание. Другие детали - не что иное, как гипотетические предположения планирования. [Они всегда Предположения планирования, но некоторые PM думают, что первоначальный план - это божественный оракул, за которым следует следовать. Это не так.]

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

В конце каждого спринт изменения любых заметок потенциально могут быть областью проекта и изменениями контракта.

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

Answer 2

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