Как я могу выяснить, какую методологию программирования (если есть) мы используем?

Нет серьезных штрафов за переключение методологий — вы просто выбираете метод по умолчанию при установке, и вы можете выбрать тот, который вы будете использовать для любого проекта. На самом деле это связано только с тем, как TFS изначально настраивает страницу проекта Sharepoint — вы можете добавить все, что хотите, на свою страницу после ее создания, поэтому, если вы решите изменить методологию проекта, это несложно сделать.

Для двух, которые TFS дает из коробки (Agile и SCCM/Waterfall), это действительно вопрос вашего процесса — вы выпускаете «рано и часто», с меньшими выпусками пакетов по мере появления ошибок, или вы запускаете свои проекты. в больших итерациях, с релизом гораздо реже, но с явными промежуточными релизами?

Вопрос, который следует задать (хотя и не совсем точный, но всегда мне помогает): есть ли у продукта номера версий, которые будут понятны конечным пользователям? Например, многие веб-сайты являются гибкими, поскольку они постоянно выпускают улучшения и исправления и не часто вносят значительные улучшения/капитальные изменения, в то время как такой продукт, как MS Office, имеет значимый номер версии (2003, 2007 и т. д.), т. е. скорее всего SCCM.

Если у вас нет заявленной методологии, самое время ее разработать — решите, какой цикл выпуска имеет для вас смысл, создайте проект в каждом из них и просмотрите, что TFS автоматически настраивает для вас — помогают ли индикаторы выполнения и страницы Sharepoint? смысл? Чего-то очевидного не хватает?

Если вы не можете различить методологию, значит, вы используете методологию ad-hoc. Это может быть похоже на существующую методологию (случайно). Обратите внимание, однако, что следование методологии не равносильно успеху. Я видел множество неудачных проектов с тяжелой методологией, и множество проектов «сиденья штанов» были оглушительно успешными (если, возможно, нуждались в небольшом рефакторинге, когда пыль улеглась).

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

Некоторые методологии «тяжелее», чем другие: их труднее изменить. Даже разработка через тестирование является «тяжелой» в том смысле, что принятие ее постфактум будет означать добавление множества тестов к старому коду. Большинство реальных переходов просто добавляют тестирование, поскольку файлы редактируются по другим причинам. Аналогичным образом, переход от TDD к каскадному стилю потребует документирования много кода в больших заброшенных папках.

Самый простой метод — это итеративный или «метод водопада», потому что вы просто идете от шага к шагу. Хотя, похоже, он уже не очень популярен.