|
 Исследования показали, что большинство успешных проектов - это те, которые следовали гибким принципам разработки. Это ещё раз доказывает, что методы, основанные на моделях, не всегда являются наилучшими, в частности, при управлении изменениями, быстрой реализации проекта или даже удовлетворении потребностей рынка.
Принцип гибкой разработки достаточно нов. Тем не менее многие техники все еще придерживаются старых понятий о том, что разработка ПО может быть с легкостью выполнена, и результат можно предсказать, не задумываясь над более динамичными (ескими) факторами проектов, такими как каналы сообщения, люди и изменения. Руководители проектов со временем осознали, что многие проекты терпели крах из-за строгих требований, неправильного планирования, неспособности команды адаптироваться к изменениям. По большей части, требования клиентов и пользователей менялись на протяжении цикла разработки, таким образом, к моменту выпуска приложения товар значительно отличался от того, что было запланировано. Вдобавок, к концу процесса разработки было затрачено временных и финансовых ресурсов, больше запланированных в самом начале. Вместо того, чтобы кивать на команды разработчиков или клиентов, руководители проектов научились допускать адаптацию в своих методологиях. В частности, многие исследования показали, что большинство успешных проектов - это те, которые следовали гибким принципам, доказывая при этом, что методы, основанные на моделях, не всегда являются наилучшими (в частности, при управлении изменениями, срочной реализации проекта или даже удовлетворении потребностей рынка.) Но до того, как вы начнете применять на практике гибкие методы, спонсоры проектов и руководители должны узнать, как эти методы будут влиять на товар, внутренние операции и людей. Влияние на людей и их роли Ключевой принцип гибкой разработки - "люди и их способность к общению важнее процессов и инструментов" - делает акцент на общении и сотрудничестве членов проектной команды. Вместо того, чтобы давать роли членам команды, больше внимания нужно обратить на то, насколько хорошо они смогут выполнить задание по созданию рабочей версии ПО в команде. Командная работа не может быть переоценена при гибком процессе, так как каждый член может быть частью группы пользователей, лидеров и разработчиков. Для того, чтобы действительно добиться успеха, руководители проектов должны разрешать членам команды быть причастными к различным ролям, спокойно общаться и концентрироваться на целях команды, а не на индивидуальных, основанных на ролях функциях. Хотя изначально было установлено, что гибкие методы дают лучшие результаты тогда, когда команды находятся рядом, опыт аутсорсинговых провайдеров показал, что и в их бизнесе нашлось применение данным методам (особенно в случае с оффшорными аутсоринговыми моделями). Нормой является сотрудничество и доступное общение, а не дислокация места работы. Влияние на процесс Процессы имеют второстепенное значение в случае с гибкими методами. Вместо того, чтобы проходить через этапы цикла разработки, быстрые и короткие итерации двигают проект вперед, тем самым позволяя получить высокий уровень гибкости при изменении курса проекта. Более того, вместо тонны документаций, диктуемых требованиями и планами, большая часть документации заключается в обмене информацией между членами команды. Разработка плана и конечный продукт зачастую подвергаются изменениям до этапа выпуска. Влияние на товар и его качество Вместо предоставления ПО, которое имеет все винтики и болтики строго там, где они должны быть согласно первоначальному плану, высшим приоритетом является удовлетворение потребностей клиента с предоставлением простой, но работающей версии продукта. Программное обеспечение улучшается с каждой итерацией до того момента, как вся желаемая функциональность будет там, где она должна быть. Простота предоставляет больше гибкости при запросах к изменению, особенно потому, что пользователи и спонсоры со временем выдвигают новые требования.
Newer news items:
Older news items:
|
