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

Question

Моя группа скоро переходит на Team Foundation Server. На самом деле, я возглавляю усилия.

Вам необходимо решить, какую методологию вы используете - Agile, CMMI и т. Д.

Дело в том - я понятия не имею, какую методологию мы используем. Под этим я подразумеваю, что мы не активно его используем. И я недостаточно знаком с Agile или другими методами, чтобы знать, какие из них, если таковые имеются, применимы к тому, что мы делаем.

Есть ли методология по умолчанию? Например, если мы пройдем через какой-то очень тупой процесс (получим требования, код, протестируем, отправим в QA, проведем тестирование QA, отправим в производство), есть ли даже название для него?

И в качестве бонуса, с TFS, каков штраф за выбор неправильного с самого начала? Насколько сложно переключать передачи позже, если мы решаем пойти Agile или что-то еще?

Answer 1

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

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

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

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

Answer 2

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

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

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

Answer 3

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