Введение
Чрезмерное постоянное расширение или добавление функций в продукт. В управлении проектами "разрастание функциональности" – это чрезмерное постоянное расширение или добавление новых функций в продукт, особенно в компьютерном программном обеспечении, видеоиграх (где его не следует путать с усилением характеристик) и потребительской и деловой электронике. Эти дополнительные функции выходят за рамки основной функциональности продукта и могут привести к раздуванию программного обеспечения и излишней сложности, вместо простого и понятного дизайна. Определение того, что считается "разрастанием функциональности", варьируется среди конечных пользователей: то, что одни пользователи воспринимают как проблему, другие могут считать полезной функциональностью. Разрастание функциональности – одна из наиболее частых причин превышения бюджета и срыва сроков. Это ставит под угрозу и может даже привести к провалу продуктов и проектов.
the project management conceptFeature creep is the excessive ongoing expansion or addition of new features in a product, especially in computer software, video games (where it should not be confused with Power creep) and consumer and business electronics. These extra features go beyond the basic function of the product and can result in software bloat and over complication, rather than simple design. The definition of what qualifies as "feature creep" varies among end users, where what is perceived as such by some users may be considered practical functionality by others. Feature creep is one of the most common sources of cost and schedule overruns. It thus endangers and can even kill products and projects.
Причины
Разрастание функциональности может возникать из-за стремления предоставить потребителю более полезный или востребованный продукт с целью увеличения продаж или расширения распространения. Когда продукт выполняет все свои запланированные функции, производитель может добавить возможности, которые некоторые пользователи сочтут излишними (иногда в ущерб эффективности), или же оставить исходную версию без изменений (что может восприниматься как отсутствие прогресса). Разрастание функциональности также может быть следствием компромисса, достигнутого группой разработчиков, реализующих различные точки зрения или сценарии использования в одном продукте, в том числе и из соображений выгоды. По мере добавления новых функций для поддержки каждого подхода, функции взаимной конвертации между различными подходами могут еще больше усложнить общую функциональность.
Контроль
Существует несколько способов борьбы с разрастанием функциональности, включая: строгие ограничения на допустимые функции, создание нескольких вариантов и удаление избыточных функций.
Разделение
Позже можно избежать разрастания функциональности, основывая первоначальный дизайн на надежных принципах разработки программного обеспечения, таких как логическое разделение функциональности и доступа к данным, например, посредством использования подменю, которые доступны продвинутым пользователям по желанию и предоставляют расширенную функциональность и более подробную информацию. Это можно активно контролировать с помощью строгого управления изменениями и откладывания изменений на более поздние этапы поставки проекта.
Варианты и варианты
Другой способ борьбы с разрастанием функциональности – это поддержка нескольких версий продуктов, в которых количество функций ограничено и сокращено в более простых вариантах, например, в редакциях Microsoft Windows. Для программных пользовательских интерфейсов можно использовать режимы просмотра или режимы работы (например, базовый и экспертный режим), между которыми пользователи могут переключаться в соответствии со своими потребностями. Как в графических, так и в интерфейсах командной строки пользователи могут вручную включить более подробный вывод информации. В последнем случае, во многих программах командной строки, добавление опции "v" или "verbose" вручную позволяет увидеть более детальную информацию, которая может быть менее важна для начинающих пользователей, но полезна для опытных пользователей, а также для отладки и устранения неполадок. Поскольку постоянное добавление новых функций может превысить доступные ресурсы, можно отдельно поддерживать минимальную основную версию продукта, чтобы обеспечить его работу в ограниченных операционных средах. Руководствуясь "правилом 80/20", более простые версии продукта могут удовлетворить потребности большинства (например, около 80%) пользователей, избавляя их от сложности (или дополнительных затрат), связанных с функциями, востребованными лишь 20% продвинутых пользователей. Дополнительные функции остаются доступными, но являются необязательными и могут быть использованы по запросу, однако они не включены в базовые версии продуктов.
Модульность
Еще одно решение проблемы разрастания функциональности — модульность. Продвинутые пользователи, которым требуется больше возможностей, могут расширить функционал, загружая программные модули, плагины, дополнения (также известные как аддоны) и пользовательские темы, соответствующие их индивидуальным потребностям.
Обрезка
В какой-то момент стоимость поддержки определенного набора функций может стать чрезмерно высокой, и тогда можно применить отказ от части функциональности. Новая версия продукта может не включать дополнительные функции, либо может быть использован переходный период, в течение которого старые функции будут объявлены устаревшими перед их окончательным удалением из системы. Если существует несколько вариантов продуктов, некоторые из них могут быть сняты с производства. Ярким примером является Samsung Galaxy S6, выпущенный в марте 2015 года, из которого было значительно сокращено количество функций программного обеспечения и меню, а также некоторых аппаратных возможностей. Более продвинутая версия этого устройства не была выпущена.
Расширение сферы применения
Иногда неконтролируемое добавление новых функций может привести к созданию продуктов, выходящих за рамки первоначального замысла; это известно как разрастание области применения. Распространенным последствием добавления новых функций является задержка или отмена продукта, который может оказаться дороже, чем планировалось изначально.
Задержки
Часто достаточно полнофункциональный проект программного обеспечения, или проект с умеренным разрастанием функциональности, может выжить и даже преуспеть в течение многих итераций, но его последующий релиз может столкнуться со значительными задержками, если принято решение о полной переработке кодовой базы в дополнение к внедрению новых технологий. Например, Windows Vista от Microsoft изначально планировалась как незначительный релиз между Windows XP и её преемником под кодовым названием Windows "Blackcomb" (выпущенной как Windows 7), но после адаптации всё большего количества функций из Blackcomb (многие из которых в конечном итоге были отменены), Vista превратилась в крупный релиз, разработка которого заняла пять лет. Подобная участь постигла и Netscape 6, которая изначально должна была быть Netscape 5. Решение Netscape Communications в 1998 году открыть исходный код браузера Netscape Navigator и интернет-пакета Communicator (оба под кодовым названием Mozilla) вскоре показало, что лежащий в основе код был слишком сложным и требовал полной переработки Mozilla, что способствовало созданию фреймворка приложений Mozilla. Это привело к значительным задержкам, Netscape 5 был пропущен, и компания была приобретена AOL. Последующий релиз Netscape 6.00 в 2000 году подвергся широкой критике как код альфа-уровня, а стабильность проект достиг с Netscape 6.1 в 2001 году, спустя три года после решения о переработке интернет-пакета. К тому времени браузер Internet Explorer от Microsoft уже давно обогнал Netscape по доле использования, которая снизилась до однозначных значений. Даже после достижения стабильности и добавления некоторых необходимых новых функций, open source Mozilla Application Suite (тогда просто Mozilla), на которой AOL построила Netscape, считалась "раздутой". Всего через год группа разработчиков Mozilla решила выделить компонент браузера, который в итоге стал Firefox. Проект Broken Age от Double Fine Adventures на Kickstarter – ещё один пример проекта, задерживаемого из-за разрастания функциональности. Изначально предполагалось, что дата релиза – октябрь 2012 года, первая половина игры вышла в январе 2014 года, а вторая половина – в конце апреля 2015 года, и потребовала два отдельных раунда финансирования для завершения.
Кормление существ
Разрастание функциональности в сочетании с жесткими сроками часто приводит к "костыльному решению". Желаемое изменение может быть настолько значительным, что потребует переработки фундамента существующего проекта, но давление сроков вынуждает разработчиков спешить и выпускать менее отлаженный продукт. Спунизм "feeping creaturism" (произносится как "пипинг криэтуризм") был придуман, чтобы подчеркнуть неприязнь разработчиков к этой ситуации, олицетворяя продукт с разросшейся функциональностью как "уродливое существо, слепленное из костылей, бродящее в темноте" и предвещающее дальнейшее разрастание. ("Feeping" – это жаргонный синоним слова "beeping".)