Книга: Экстремальное программирование
Фиксированная цена
Фиксированная цена
Практика показывает, что наибольшие проблемы с использованием ХР возникают в случае, если работа идет над контрактом с фиксированной ценой. Можно ли играть в игру в планирование, если вы имеете дело с контрактом фиксированной цены/фиксированной даты/фиксированного объема работ? В результате получается контракт фиксированной цены/фиксированной даты/несколько варьируемого объема работ.
Каждый проект с фиксированной ценой и фиксированным объемом работ, с которым мне приходилось иметь дело, заканчивался тем, что обе стороны говорили друг другу: Требования неясны. В результате работы над проектом с фиксированной ценой и фиксированным объемом работ две стороны начинают двигаться в противоположных направлениях. Поставщик продукта желает сделать как можно меньше, а заказчик желает получить как можно больше. В условиях подобного трения обе стороны желают успешного выполнения проекта, поэтому они отказываются от своих изначальных целей, но трение остается.
В рамках ХР взаимоотношения меняются малозаметным, но важным образом. Изначально разговор об объеме работ обсуждается с использованием слова например. Например, за 5 000 000 немецких марок мы могли бы реализовать все эти истории за 12 месяцев. Заказчик должен решить, стоят ли эти истории пяти миллионов немецких марок. Если эти истории – это все, что должна реализовать команда, то это хорошо. Существует вероятность, что заказчик заменит некоторые из историй более полезными для него. Никто не станет жаловаться, если вместо чего-либо он получит что-либо другое, более ценное. Однако недовольство и жалобы возникают тогда, когда кто-либо получает что-либо, о чем он просил, но при этом оказалось, что это не то, что ему нужно.
Вместо фиксированных цены/даты/объема работ команда ХР предлагает нечто наподобие подписки. Команда обязуется работать на заказчика с максимальной скоростью в течение определенного промежутка времени. Они будут следить за мнением заказчика относительно направления развития разработки. В начале каждой итерации заказчик получает формальную возможность изменить направление развития разработки и добавить совершенно новые истории.
Еще одно различие, связанное с применением ХР, заключается в использовании небольших версий. Вы никогда не должны работать над проектом ХР в течение 18 или даже 12 месяцев, не внедрив его в производственных условиях. Когда команда заключает контракт на реализацию историй в течение 12 месяцев, они играют с заказчиком в игру в планирование для того, чтобы определить объем работ, связанных с первой версией. Таким образом, когда речь идет о 12-месячном контракте, система начнет эксплуатироваться в производственных условиях спустя три или четыре месяца после начала работ, после этого новые версии будут выпускаться с периодичностью в один или два месяца. Постепенное введение системы в эксплуатацию обеспечивает заказчику возможность расторгнуть контракт в случае, если процесс разработки идет медленнее, чем планировалось, или если в результате изменения бизнес-условий реализация всего проекта потеряла смысл. Кроме того, так как проект развивается от итерации к итерации, на шкале времени у заказчика появляются точки, в которых он получает возможность изменить направление развития проекта.
- Запуск сценариев на удаленных машинах. Контроль за ходом выполнения таких сценариев
- 7.2. Описание сценария rc.firewall
- 7.7. Безопасность сценариев
- Ограничение сценариев
- Листинг 9.2. Сценарий на языке Perl для подмены баннеров и закрытия всплывающих окон
- Документирование сценариев
- Глава 5 Доступ из сценариев к файловой системе
- Как работают сценарии. События
- Создание сценария
- Скрипты продаж. Готовые сценарии «холодных» звонков и личных встреч
- Ошибка пятая: не держитесь за каждую строчку в своем сценарии
- Глава 3 Как сделан классический сценарий