Где в scrum-процессе обсуждается архитектура программирования? [закрытый]

Допустим, у меня есть свое видение, и теперь у меня есть отставание по продуктам. Эта часть написана и готова к использованию. Я собираюсь создать свой спринт(ы). Мне любопытно. Когда команда программистов садится и говорит: "давайте использовать эту платформу, этот фреймворк и язык", и такие вещи, как" нам нужен класс здесь", или" я вижу, как мы можем использовать интерфейс с этим " и так далее. Когда еще такие разговоры ведутся?

Есть ли встречи, которые происходят перед спринтом, где кто-то решает за все команды - "мы собираемся использовать Linux, MySQL, PHP и CodeIgniter" , и затем одна из команд имеет спринт для реализации этой инфраструктуры, в то время как другие команды ждут завершения, чтобы начать другие спринты (команда A2 строит пользовательский интерфейс или модель безопасности и ее функции из отставания продукта)?

Это также место, где такие инструменты, как trac, будут использоваться на уровне команды, когда спринты только начинаются?

Извините, если я повсюду с этим. Я просто никогда не видел, как это делается, и просто ... когда я думаю, что понимаю его, я думаю о новом вопросе.

Также это не имеет значения, но как вы называете свои команды? Команда Боба, команда Смита, что-то более яркое?

Спасибо.

5 4
project-management agile scrum

5 ответов:

Короткий ответ: "это зависит", поскольку для первой части могут быть другие команды, которые в какой-то степени диктуют такие условия. Например, в моем текущем проекте некоторые вещи почти даны,например IDE=Visual Studio, отслеживание ошибок=HP Quality Center,управление версиями=Subversion, O/S для разработчиков XP Professional и т. д.

Может быть Sprint 0, где некоторые инфраструктурные элементы обрабатываются как сервер CI, wiki для команды, удостоверяясь, что у всех есть учетные записи в SVN, и другие административные вопросы, которые нужно решить.

Названия команд, такие как кодовые имена, могут появляться в любое время,хотя они могут иметь разные значения, поскольку то, что кто-то может использовать для названия команды в одном месте, может быть не так хорошо где-то еще, например Team Voltron может не подходить для тех, кто совершенно не знаком с этим термином.

1

Некоторые команды начинают свои проекты сSprint Zero, где они уточняют видение, определяют глобальную архитектуру (выбор платформы, языка, а не класса или интерфейсов), определение "сделано "...

Этот спринт особенный, он посвящен подготовке и, в отличие от других спринтов, может не привести команду к поставке какого-либо рабочего программного обеспечения..

1

Если вы являетесь частью команды agile-scrum, скорее всего, там ваша компания уже определил закономерности и зодчие.

На мой взгляд scrum-команды не отвечают за дизайн, есть отдельные дизайн-команды, которые отвечают за общий дизайн и интеграционный план любых текущих проектов.

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

Scrum-master вместе с team-leads отвечают затактику реализации проектов в соответствии с дизайном.

Программисты, тестировщики и инженеры по контролю качества несут оперативную ответственность за написание и тестирование кода.
1

Я бы разделил его на несколько частей.

Такие вещи, как выбор инструментов / платформ (Linux, MySQL, PHP и т. д.), Я бы согласился еще до запуска sprint 0. Я рассматриваю sprint 0 скорее как установку видения и архитектуры высокого уровня, которая в какой-то степени зависит от инструментов/платформ по вашему выбору. Люди, которых вы хотели бы иметь в команде, также будут отличаться для ASP.NET проект, чем для проекта PHP.

Другое дело-переход к дискуссиям типа "Мне нужен класс здесь и интерфейс там."Этот уровень деталей не может быть действительно решен заранее во время спринта 0. Мы просто следуем этим решениям на протяжении всего пути. Это означает, что мы меняем нашу архитектуру довольно часто, но это редкая ситуация, когда изменения глубоки. И почти всегда, когда мы что-то меняем, это обоснованное решение.

Подытоживая: ключевые технологические решения перед запуском, высокоуровневая архитектура во время спринта 0, низкоуровневые проектные решения, когда это необходимо (во время спринта).
1

"Sprint 0" - это стандартный подход к запуску. Для текущих крупных архитектурных решений (switch toolkit, язык, платформа) хорошо сработала серия историй спайков исследований, если они настолько малы и сфокусированы, насколько это возможно. История-это обращение к конкретному вопросу или доказательство концепции. Инфраструктурные вопросы могут-и я бы сказал, должны-быть разбиты на небольшие истории, или вы можете заблудиться на карте.

Небольшие инфраструктурные изменения иногда хорошо работали в качестве "налог" на другие истории, иногда нет. (Например, исследование и добавление инструмента инъекции зависимостей, переход к универсальному инструменту гибернации) налогообложение историй требует отличной связи между продуктом и разработкой. Он предполагает, что какой-то нетерпеливый Дев уже сделал некоторые ночные домашние задания по инфраструктуре.

Безуспешно мы пытались надеяться, что основные архитектурные решения произойдут в ходе обычной работы. Это не удается, потому что scrum держит вас слишком сосредоточенным.

0