Должны ли Agile-команды ежедневно предоставлять новые функции?

Моя компания находится в процессе перехода от разработки в стиле водопада к Agile / Scrum. Помимо прочего, нам говорят, что мы ожидаем, что в конце каждого дня у нас появятся новые рабочие, проверяемые (по QA) функции.

Большинство наших разработчиков теряют около 2 часов в день на встречи и другие накладные расходы. Это означает, что за любой заданный 6-часовой (в лучшем случае) период мы должны спроектировать, написать, выполнить модульное тестирование, построить и развернуть (с примечаниями к выпуску) достаточное количество кода, чтобы создать полную функциональность для QA, с которой можно играть. Я понимаю, что примечания по сборке / развертыванию / выпуску могут быть автоматизированы при правильной настройке CI, но мы еще не готовы.

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

Мы пытаемся разбить истории на узкие, глубокие вертикальные фрагменты, чтобы завершить сквозные функции как можно быстрее, но большинство дней чувствуют себя довольно отчаянно, и я часто ловлю людей, использующих глупые, хрупкие ярлыки, чтобы убедиться, что QA имеет свою структуру. Эта проблема усугубляется после того, как спринт продолжается в течение нескольких дней, когда неизбежные дефекты начинают появляться и должны вписываться в то же самое 6-часовое окно.

Это нормальный темп для Agile команд? Даже если нам удастся реализовать настройку CI, я не могу понять, как мы сможем поддерживать этот темп и все же создавать качественное программное обеспечение.

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

Преступления, которые совершаются во имя Agile в наши дни, меня огорчают. Многим людям трудно сделать этот переход.

Agile Manifesto: «Мы ценим людей и взаимодействие, а не процессы и инструменты». Когда людям явно больно, процесс идет неправильно. Я не хочу говорить вам, как это сделать, но поделюсь, как я это делаю.

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

Смысл не в том, что вы должны что-то совершать каждый день. Подразумевается, что вы должны совершать только хорошие вещи, чтобы каждый день вы могли собрать все хорошие вещи, которые кто-либо совершил. Таким образом, команда продолжает стрелять по всем цилиндрам.

В моих командах QA постоянно. Я создаю коммерческие продукты, поэтому проект никогда не заканчивается, пока продукт не устареет. QA Engineers тестируют функции, доступные для тестирования. Инженеры QA всегда имеют отставание. Времени QA никогда не хватает, чтобы протестировать или автоматизировать все, что мы хотели бы идеалистически.

Если разработчикам требуется несколько дней, прежде чем объединить изменения для какой-либо функции или исправления, будет хорошо, если это поможет им получить правильный код, прежде чем рисковать временем. Разработчики могут фиксировать код в своем частном репо или филиале, не влияя на команду или QA. Разработчики могут запускать модульные тесты или автоматизацию регрессии для кода, созданного из репозитория разработчика или частного филиала. В особо рискованных случаях QA Engineer будет работать с разработчиком для тестирования перед слиянием, чтобы защитить команду от задержки.

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

Agile Manifesto, для меня, суммирует лучшее из нового мышления о процессе развития, которое появилось в 1990-х годах. Я в значительной степени верю в эти принципы, но детали процесса могут отличаться. На мой взгляд, цель Agile - адаптировать ваш процесс к потребностям вашего продукта и клиентов, а не быть рабом процесса.

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

Когда, наконец, некоторые функции будут завершены и проверены в главном филиале, у вас должен быть автоматизированный процесс, который собирает программное обеспечение и запускает тесты. Если есть проблема со сборкой или запуском тестов, команда получает уведомление, и они сосредотачивают свои усилия, чтобы он снова заработал. Именно так работает CI и помогает вам постоянно выпускать работающее программное обеспечение.

Краткий ответ: нет . Это просто не может быть достигнуто ежедневно.

Тем не менее, гибкая команда должна предоставлять рабочие части программного обеспечения или истории пользователей в каждом спринте . Как правило, статусные встречи проводятся ежедневно, чтобы увидеть прогресс и препятствия.

Что касается качественного программного обеспечения , то процессы непрерывной интеграции (CI) позволят убедиться, что контроль качества применяется к небольшим частям усилий (проверкам) и выполняется так часто, как настроено. Он также нацелен на улучшение quality of softwareи сокращение времени, необходимого для его доставки, заменив традиционную практику применения контроля качества после завершения всех разработок.

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

Если вы выполняете разборку, вы должны выполнять как минимум 2-недельные спринты, причем для выполнения функций требуется примерно от 0 до 8 дней. Владелец продукта обещает предоставить новый, проверенный и проверенный правильный рабочий код, который может быть запущен в производство в конце спринта. (ПРИМЕЧАНИЕ: вам не нужно на самом деле запускать его в производство, но цель в том, что это может быть, если вы захотите)

Хорошая методология предполагала, что вы настроили сервер непрерывной интеграции (CI), на котором вы автоматизировали создание хотя бы одной ежедневной сборки работающего программного обеспечения. Идея состоит в том, что вы проверяете свой код, как только заканчиваете функцию, чтобы она могла быть в следующем цикле сборки, а затем в руках QA для тестирования.

Помните, что цель состоит в том, чтобы сделать функции и протестированы к концу спринта! Вам не нужно заставлять QA ждать до последнего дня спринта, чтобы вы сделали сборку, а затем попросили их протестировать все функции. У них не будет времени, чтобы проверить все это, и у вас не будет времени, чтобы исправить ошибки ...

Если вы не можете настроить CI-сервер, то практикой должно быть то, что вам нужно вручную создавать новую сборку для QA каждый раз, когда разработчик проверяет свой законченный код и заявляет, что он завершил работу с функцией и готов к передаче в QA.

Это на самом деле зависит от размера проекта; если проект большой, то не существует реального способа достичь этого.

Ежедневные (или даже более частые) сборки, основанные на инструментах непрерывной интеграции, не означают работающего программного обеспечения; это едва ли означает скомпилированный код.

Есть много проектов, которые предоставляют ежедневные сборки, которые благодаря непрерывной интеграции работают как программное обеспечение. По крайней мере, в теории.

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

Теоретически, если вы не можете ежедневно выполнять больше работы по обеспечению качества, вы должны либо увеличить количество разработчиков, либо уменьшить количество тестеров. Ужасная идея!

Ваша работа состоит в том, чтобы добиться цели.

Скажите QA, что они получат что-то для тестирования, когда это будет сделано. Вы должны объяснить им, почему.

Я думаю, что вы смущены идеей "CI". Возможно, вы захотите посетить эту замечательную статью Мартина Фаулера о том, как CI работает на практике. Она должна правильно ответить на ваш вопрос.