Я только что немного обсудил это с несколькими коллегами, но мы еще не пришли к выводу. У нас есть куча проектов, которые активно поддерживаются и разрабатываются с помощью scrum, с фиксированными двухнедельными спринтами, интеграцией бэклога TFS и т. д.
У нас также есть отдельный проект под названием Mobiltec.Framework, который предназначен для расширения стандартного фреймворка .Net (большинство наших проектов — это проекты C#). Этот служебный проект предназначен для поддержки любого другого проекта в компании с общей функциональностью, не привязанной к какому-либо конкретному продукту, и находится в собственном TeamProject в TFS, независимо от любых других проектов.
Мы находимся в процессе перехода к новой версии TFS 2013, и я сразу же подумал:
Какой шаблон процесса TFS я буду использовать с этим?
Это, очевидно, специфично для TFS, но я думаю, что вопрос достаточно общий: какой метод лучше всего использовать для разработки такого проекта утилиты по запросу? Scrum не имеет для меня абсолютно никакого смысла. В него редко добавляются функции, и он достаточно стабилен. Понятия спринта нет, и у нас вообще нет специальной команды, которая бы занималась проектом (теоретически любой разработчик из всей компании мог бы добавлять в него вещи, если они не специфичны для продукта).
Я чувствую, что все еще должен быть своего рода бэклог с задачами / пользовательскими историями, сопоставленными с ним, чтобы, по крайней мере, отслеживать, что делается, но я не вижу, как я должен интегрировать это во весь гибкий конвейер. Должен ли я просто полностью игнорировать идею «итераций» (как концептуально, так и в TFS) и просто разрабатывать и выпускать непосредственно из основного источника, создавая пользовательские истории и ошибки?
Есть ли пример такого проекта, в котором все функциональные возможности предоставляются по запросу и нет внутренней концепции спринтов или итераций, на которой я мог бы основывать наш проект?
В Team Foundation Server 2013 по умолчанию доступны 3 шаблона для командного проекта.
Все они достаточно гибкие , чтобы удовлетворить ваши потребности, но я думаю, что первые два более удобны. Шаблон Scrum предназначен для поддержки методологии Scrum, определенной организацией Scrum. Однако, если ваш проект не должен приносить пользу итеративным и инкрементным образом, настроенным спринтами и итерациями, вы можете вообще не настраивать их.
В TFS 2013 для каждого командного проекта есть команда «Настроить расписание и итерации...». Вы можете оставить эту часть без настройки и использовать шаблон scrum только для написания и отслеживания рабочих элементов.
Единственное, что вам нужно, это то, что при создании нового рабочего элемента итерация должна быть самим проектом. Например, если вы создаете задачу для Mobiltec.Framework, итерация задачи будет Mobiltec.Framework, а не Mobiltec.Framework->Выпуск 1->Спринт 1. Делая это, вы можете создавать запросы с условием «Итерация-> >Mobiltec.Framework» и иметь все пользовательские истории, ошибки, задачи в одном месте.
Вы также можете настроить каждый шаблон проекта в соответствии с вашими потребностями, используя этот файл .
Кроме того, в TFS 2013 у вас могут быть разные команды, работающие над одним и тем же проектом, и вы можете видеть вклад каждой команды в проект.
Надеюсь это поможет
Этот вопрос вызывает у меня большой вопрос — это вообще проект сам по себе или что-то, что будет переделываться в рамках других проектов? Если последнее, ему может не понадобиться ничего, кроме контроля версий.
Удалив из этого вопроса элемент TFS, Канбан представляет собой гибкую методологию без ограничений по времени, которую можно было бы применить. В таких ситуациях вам нужно обратиться к принципам Agile, а не к процессам, и найти решение, соответствующее вашим потребностям. Вы можете подойти к этому, начав с чего-то похожего на Scrum и убрав время, если это то, в чем заключается ваш опыт, но вам нужно будет подумать, как вы обеспечите прогресс в проекте (если это важно).
Я бы посоветовал взглянуть на шаблон MS kanban 1.0 . Что больше похоже на непрерывный процесс доставки, а не на итерационный подход.
Вы можете использовать доски Канбан, прикрепленные к каждому невыполненному заказу, для непрерывного процесса.
https://msdn.microsoft.com/en-us/library/jj838789.aspx
Одна небольшая проблема:
В VSO (я не тестировал последние локальные TFS) эти доски работают с элементами Story/Feature/Epic (процесс Agile) и элементами Feature/Backlog (процесс Scrum). Это означает, что доски задач, показывающие отдельные задачи для каждой дорожки истории, по-прежнему находятся внутри итераций/спринтов.
Как уже говорили другие, канбан кажется подходящим, исходя из ваших критериев. Я также настоятельно рекомендую вам игнорировать инструменты и программное обеспечение для управления, когда вы сначала думаете о том, как работать наиболее эффективно. :)
Редактировать: я думаю, что начало работы с конкретным инструментом или технологией накладывает слишком много ограничений на первоначальный взгляд на работу и ограничивает потенциальные подходы. Это также часто (к сожалению) остается ограничением, и команда будет подчиняться ему, а не наоборот. Классическим примером является руководство или заинтересованные лица, желающие иметь конкретное представление о выполняемой работе, например панель мониторинга, и требующие, чтобы все команды внутри организации использовали «стандартизированный» инструмент управления проектами, который показывает им это представление. Затем рабочий процесс этого инструмента и представление/данные локальной команды будут навязаны команде и будут ограничивать их, что может даже повлиять на их культуру и представление о себе как об организации (не говоря уже о проблемах командования и контроля/отсутствия доверия, которые он демонстрирует). ). Начав без ограничений инструмента, команда может придумать отличный способ управления и просмотра своей работы локально, а затем перевести ее в другой инструмент, синхронизируя раз в неделю и т. д., чтобы удовлетворить потребности обеих сторон. Надеюсь, это поможет прояснить. :)
На мой взгляд нужно сделать кастомный шаблон, немного его обрезать. Возьмите гибкий шаблон. Оставьте только два типа элементов, как в канбане: «Карточка» и, например, «Ошибка/Проблема» только для разделения типов. Тогда у вас есть только одна итерация, как упоминалось ранее, которая является корнем проекта. Затем вы делаете состояние парковки «Ожидание/Незавершенная работа» и другие состояния для «Выполняется» (этапы процесса для доставки элемента). Подумайте, что это охватывает базовый простой служебный подход, поскольку вам наверняка нужен Канбан.
саакян
Джулеалгон
Азиз Шейх