Насколько значительны различия между Visual Studio Scrum 1.0 и MSF для шаблонов процессов Agile Software Development v5.0?
Кто-нибудь использовал один над другим?
В настоящее время мы используем внешние инструменты (TRAC) для реализации Scrum в нашем процессе разработки, поскольку MS разработала дополнительные инструкции по процессу в TFS2010, эти две вещи путают меня в ядре!
Не уверен, какой из них принять!
Ты не один! Мы использовали оба варианта, ошибочно начиная с шаблона MSF Agile 5.0. Если вы используете Scrum специально, я бы использовал шаблон Scrum 1.0. Шаблон Scrum 1.0 был создан с Кеном Швабером, одним из основателей Scrum.
Шаблон MSF Agile 5.0 содержит книги, которые позволяют контролировать данные отчетов с помощью excel. Но есть еще много недостатков. В нем нет отчета о выпуске выпуска. Чтобы произвести полезное сжигание спринта, вам необходимо записать фактические данные в свои задачи. Заготовка продукта трудно ухаживать. История пользователя является единственным элементом отставания, поэтому отслеживание технических ошибок или нестандартных требований неудобно.
В Sprint 1.0 используется тип рабочего типа "Спринт", который быстро и быстро сжимает скорость и выгорание.
Итак, что касается инструментов, это очень хорошо.
Мое резюме: TFS Architect/Admin с 2005 года по настоящее время. Многие крупные и малые организации развития от 20 до 7 000 человек. Общественный и частный сектор. HIPAA, FDA, SOX. ALM, SCM, RM.
В настоящее время ответы на эти вопросы направлены на то, чтобы ответить на вопрос с точки зрения проектного уровня, который является типичным, а не с точки зрения организации и обслуживания. А также сайдинг с одним лагерем или другим, чего следует избегать.
Ответ на ваш вопрос зависит от вашей ситуации. Какие типы запросов или отчетов нужны или хотели бы видеть в проекте? И чтобы повторить, какой главный ответ: инструмент не должен диктовать схватку и идти вместе с этим, должен ли проект быть несколько гибким?
Отвлечься от реальных сценариев, которые я испытал с несколькими клиентами, заключается в том, что они обычно начинаются с основного шаблона Microsoft Visual Studio Scrum 1.0, а затем добавляют к нему что-то. т.е. запросы, отчеты, рабочие элементы, информационные панели и т.д. Это неизбежно приводит их обратно к шаблону Agile или CMMI с добавлением сжигаемых отчетов/запросов/рабочих элементов. Видел это несколько раз, независимо от размера организации.
Не имеет значения, пришел ли бог схватки и создал шаблон схватки для TFS. Более важный вопрос: "Что поддерживает ваш процесс? насколько дисциплинированными являются персонал, который следит за процессом; и могут ли они согласиться на семантику? Если это действительно беспокоит, что имена не совпадают, типы/имена рабочих элементов могут быть изменены/добавлены/удалены, все равно процесс управления всем этим имеет значение.
Одним из важных аспектов шаблонов, начиная с чистого TFS-perpsective, является то, что рабочие элементы scrum 1.0 могут быть добавлены в гибкие рабочие элементы 5.0 легче, чем наоборот. Зачем? Поля и точки ввода данных уже существуют в гибкой ситуации, где они не находятся в схватке. Это, в свою очередь, уменьшает время, определяющее, какие поля, которые существуют в системе, используются повторно, не вызывая конфликтов.
Без здравого смысла, и я стараюсь не слишком, это похоже на то, что использование Microsoft Word - это запутать людей, потому что слишком много функций/функций. Большинство людей игнорируют эти функции/функции, пока не будет любопытство или их использование. В противном случае компании не должны иметь дополнительных расходов на оплату лицензий Microsoft Word и просто использовать WordPad. Любопытство и потребность - это то, что способствует пониманию и знаниям.
Шаблон SCRUM следует некоторым терминологиям и артефактам SCRUM. У вас есть спринты, а не итерации, у вас есть истории пользователей, а не требования, задачи, графики выгорания и т.д. Но, на мой взгляд, TFS трудно использовать, потому что он не очень продуктивен.
Мы используем аналогичный шаблон для MS Visual Studio TFS 2008. Во время моего первого проекта SCRUM мы использовали напрямую TFS и Excel для сбора пользовательских историй, подготовки заданий и т.д. Это было очень медленно. Просто создавая задачи для 4-5 разработчиков и 4-недельного спринта (я больше никогда не буду использовать такой длинный спринт), я взял меня всегда около двух дней. Такие отходы. Кроме того, не было поддержки для печати карточек для панели задач. Другими недостатками шаблона non MS (не уверен, что это то же самое для MS one) является то, что каждая сообщенная ошибка сразу же добавляется к отставанию продукта (это новая история пользователя), нет возможности собирать ограничения, истории пользователей не имеют предопределенное поле для критериев приемлемости, а задачи не имеют поля для реального времени, затраченного на завершение задания (полезно для ретроспективной оценки). Поля могут быть добавлены, если у вас есть TFS под вашим контролем, но это не мой случай.
Мне все еще нужно использовать TFS (политика компании), но я работаю с историями пользователей и задачами как можно больше за пределами TFS. Лучше всего работает ручка и бумага. Тем не менее TFS хорош для отслеживания прогресса спринта и автоматически генерируемых графиков выгорания, но вам нужно найти хороший баланс между количеством задач, сложностью задач и длиной спринта.
Эта страница MSDN может быть полезной: Выбрать шаблон процесса.
Он делает достойную работу, выделяя различия между следующими 3 шаблонами процессов по умолчанию.
Имейте в виду, что он нацелен на набор инструментов Visual Studio 2012.
Шаблон Visual Studio Scrum 1.0 был создан с нуля, чтобы поддерживать Scrum, используя терминологию Scrum как можно больше. Он разрабатывается в координации с Scrum.org и программой Scrum Professional Developer. Если вы используете Scrum, шаблон VSS 1.0 будет предлагать вам меньше трения, чем шаблон Agile.
Тем не менее, вы должны быть смутно и сомневаться в том, что принятие TFS и шаблона VSS 1.0 может обеспечить вам лучшую ценность, чем использование текущего инструмента, который вы используете сейчас. Здесь вы можете задать следующие вопросы: получите ли вы преимущества интеграции элементов отставания продукта, задач Sprint, проверок кода, сборок CI, ручных тестов, кодированных тестов, Unit Test результатов и т.д.
Возможно, некоторые стандартные отчеты позволяют лучше понять качество приращения продукта. Например. Вы сделали? Отчеты о модулях и отчеты о покрытии кода, отчеты об испытаниях, отчеты о создании. Помогают ли эти вопросы лучше ответить на этот вопрос?
Возможно, ничто из этого не применимо, и использование вашего текущего решения - лучший способ улучшить вашу команду. Это зависит от вас, чтобы экспериментировать и решать.
(Или вы можете нанять меня, и я с удовольствием помогу вам решить после работы в команде и выяснить, какие проблемы могут улучшить вашу команду;)