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


31

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

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

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

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

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

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

Ответы:


52

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

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

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

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

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

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

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

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


2
+1: потрясающий ответ. Какой-то действительно хороший взгляд на то, что на самом деле должно означать «проворный»
Джим Г.

24

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

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


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

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

8

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

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

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


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

1
поясним: «Вы не должны ничего выгружать в QA до тех пор, пока пользовательская история не будет сделана и проверена».
Е.Л. Юсубов

Еще немного уточнения: история не закончена, пока код для истории не будет протестирован.
Брайан Оукли

@ElYusubov Насколько я понимаю, мы должны были предоставлять новые функции / истории в конце каждого спринта, что вполне разумно.
Джошуа Смит

4

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

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

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

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

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


1
Это то, что мы делаем сейчас, но новые функции редко занимают всего один день, особенно с участием оффшоров.
Джошуа Смит

2
Что хорошо, agile / scrum просто говорит, что в конце спринта будет доставлен потенциально загружаемый код, даже не новые функции! Во многих местах есть целые спринты, где это просто улучшает производительность или очищает код. Любое место, которое ожидает, что вы будете делать новую функцию каждый день, злоупотребляет разборками, чтобы воспользоваться вами.
Алан Барбер

2

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

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


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

1

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

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

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

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

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


1
Тысячу раз это. Я сказал руководителю проекта, что обеспечение контроля качества работой не входит в обязанности моей команды, и он получил решительный отпор.
Джошуа Смит

Попытайтесь вернуться с более убедительными фактами: developersurvivalguide.com/how-to-convince-your-boss

@JoshuaSmith: я отредактировал свой ответ, чтобы он соответствовал вашему недавнему редактированию, но я боюсь, что это не тот ответ, который вы ищете ...

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.