Управление процессами Scrum - Советы, Подводные камни, Идеи [закрыто]

Question

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

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

Во-вторых, у нас есть крайние сроки.Они строгие и оказывают большое влияние на расстановку приоритетов.Конечным результатом являются изменения отставания в середине спринта из-за изменения крайнего срока или плохие результаты в конце спринта.У нас также есть много нетехнической работы, такой как поддержка клиентов, которая должна быть выполнена в данный момент и не может быть спланирована, поскольку она сильно варьируется.Поэтому я думаю, что структура команды, культура и практика в некотором роде несовместимы со Scrum.Scrum для меня - это инструмент управления процессами для команд, работающих над разработкой единого программного продукта.

Что вы, ребята, думаете о применении этого в более конкретных и сложных сценариях?Есть ли у вас какой-нибудь опыт, которым вы могли бы поделиться?

Answer 1

Как правило, тестировщики и документалисты (и другие непроизводители) являются равноправными членами scrum-команды.Идея, стоящая за этим, заключается в минимизации риска.

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

Если тестирование не начнется до ОКОНЧАНИЯ разработки.когда это сделано, происходит то, что после того, как разработчики выполнили задачу, обнаруживается множество ошибок.Итак, теперь вам нужно исправить эти ошибки, а это очень медленно и дорого, как потому, что ошибки взаимодействуют, так и потому, что общее правило таково:"Затраты на исправление ошибки растут экспоненциально со временем". Ошибки, которые вы обнаруживаете на ранней стадии, дешевы и их легко исправить, поздние ошибки - это кошмар.

Вот почему вы хотите, чтобы тестирование (и документация) шло в ногу с разработкой.И прямо сейчас вы должны спросить, каким образом!Тестирование идет медленно, как, черт возьми, оно может идти в ногу с разработчиками?

Ответ заключается в автоматизации, то есть SCRUM всегда находится поверх XP или Agile, которые требуют отличного покрытия модульным тестированием и TDD.Вот еще один момент, на который следует обратить внимание.Разработчиками функций должны быть те, кто пишет как модульные, так и системные тесты.Вся автоматизация тестирования должна выполняться разработчиком функций.Команда.Некоторые места разделены функцией dev.от разработчика автоматизации.и это плохо.

Итак, теперь у вас есть отличное автоматическое тестирование, и вы запускаете его ПО КРАЙНЕЙ мере раз в день.И, очевидно, вы практикуете непрерывную интеграцию, не так ли?Это значительно снижает рабочую нагрузку тестировщиков.И именно так тестирование может идти в ногу с разработчиками.И еще: тестировщики теперь работают над действительно сложными и креативными материалами, которые невозможно или очень сложно автоматизировать, каждый раз, когда они находят ошибку таким образом, все, что потребовалось для выявления ошибки, автоматизируется и становится частью ежедневных регрессионных тестов.Фух, какой длинный ответ!

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

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

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

Answer 2

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

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

Ваша команда должна быть в состоянии сказать: "Задача B требует, чтобы задача A была выполнена первой.Задача А займет 8 часов, тогда задача В займет 4 часа".Если оценки вашей задачи точны, то зависимости вообще не являются проблемой.

Во-вторых, у нас есть крайние сроки.Они строгие и оказывают большое влияние на расстановку приоритетов.Конечным результатом являются изменения отставания в середине спринта из-за изменения крайнего срока или плохие результаты в конце спринта.У нас также есть много нетехнической работы, такой как поддержка клиентов, которая должна быть выполнена в данный момент и не может быть спланирована, поскольку она сильно варьируется.

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

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

Answer 3

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

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

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

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

Тестировщики, если они работают в непосредственной близости от разработчиков, могут помочь определить, действительно ли работа завершена!

Answer 4

прежде всего, вы вообще не используете Scrum, возможно, вы используете некоторые методы scrum, но не весь процесс в целом.

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

В зависимости от задачи нет никакой связи, которая встречается редко, и способности правильно планировать.При планировании спринта команда должна оценить истории, касающиеся определения "Сделано".Если это включает в себя, а это действительно должно включать в себя разработку и тестирование истории, оценка усилий, необходимых для выполнения критериев приемлемости истории, должна включать задания по разработке и тестированию.

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

Кажется, что длина вашего спринта шире, чем вам нужно.Почему бы тебе не попытаться сделать это короче?Хорошая длина спринта - это длина, которую вы можете зафиксировать, чтобы избежать внесения изменений в спринт.Я думаю, 1 недели хватило бы.

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