Управление процессами Скрама - Советы, Подводные камни, Идеи
Некоторое время я занималась с командой, но по некоторым причинам все кажется беспорядочным. Я думал о том, как их можно изменить, и у меня есть пара вопросов, которые я хотел бы поднять здесь.
Во-первых, какова роль тестировщиков, дизайнеров и не разработчиков в целом в процессе Scrum? Если они равны с другими членами команды, возникает пара вопросов. Дизайнеры и тестировщики обычно работают над задачей после завершения разработки, поэтому из-за этой зависимости они не могут адекватно планировать спринт.
Во-вторых, у нас есть сроки. Они являются строгими и имеют большое влияние на расстановку приоритетов. Конечным результатом является изменение отставания в середине спринта из-за изменений крайнего срока или плохих результатов в конце спринта. У нас также есть много нетехнических работ, таких как поддержка клиентов, которая должна быть сделана в то же время и не может быть запланирована, поскольку она сильно варьируется. Поэтому я думаю, что структура команды, культура и практика не совместимы со Scrum. Scrum for me - это инструмент управления процессами для команд, работающих над разработкой единого программного продукта.
Что вы, ребята, думаете о применении его в более конкретных и сложных сценариях? Есть ли у вас опыт поделиться?
4 ответа
В целом, тестировщики и документаторы (и другие не разработчики) являются равноправными членами команды разработчиков. Идея заключается в том, чтобы минимизировать риск.
Требование определения выполненного, которое включает потенциально отправляемый продукт, который полностью протестирован и задокументирован, вынуждает проект собираться вместе в конце каждого спринта.
Если тестирование не начинается до ПОСЛЕ dev. После того, как разработчики выполнили задание, обнаружилось много ошибок. Так что теперь вы должны исправить эти ошибки, и это очень медленно и дорого как потому, что ошибки взаимодействуют, так и потому, что общее правило таково: "Затраты на исправление ошибки растут экспоненциально со временем". Ошибки, которые вы обнаруживаете раньше, дешевы и их легко исправить, а поздние ошибки - это кошмар.
Вот почему вы хотите, чтобы тестирование (и документация) шли в ногу с развитием. И сейчас вы должны спросить, как! Тестирование медленное, как, черт возьми, оно может двигаться вместе с dev?
Ответ - автоматизация, то есть SCRUM всегда стоит на вершине XP или Agile, и оба требуют превосходного охвата модульных тестов и TDD. Вот еще одна ошибка, на которую стоит обратить внимание. Разработчики функций должны писать как модульное, так и системное тестирование. Вся автоматизация тестирования должна выполняться функцией dev. команда. В некоторых местах разделена функция Dev. от разработчика автоматизации и это плохо.
Итак, теперь у вас есть отличное автоматическое тестирование, и вы запускаете его как минимум раз в день. И, очевидно, вы практикуете непрерывную интеграцию, верно? Это значительно снижает нагрузку на тестеров. И вот как тестирование может идти в ногу с dev. Еще одна вещь: тестеры теперь работают над действительно сложными и творческими вещами, которые невозможно или очень сложно автоматизировать, каждый раз, когда они находят ошибку таким образом, то, что когда-либо требовалось для выявления ошибки, автоматизируется и становится частью ежедневных регрессионных тестов., Фу, это длинный ответ!
Теперь ко второй части вашего вопроса. Скрам - это дисциплина. Спринты короткие, а изменения во время спринта НЕ должны происходить. Нетехническая работа должна быть направлена на команду поддержки клиентов, и они могут делать Scrum вокруг этого. Вы правы, когда говорите, что это звучит так, будто ваша культура и практика несовместимы с схваткой.
По моему опыту, переход на Scrum/Agile - очень болезненный, стрессовый процесс, и большинство попыток перехода проваливаются. Один из ключей к успеху - чемпион Scrum/Agile в исполнительной команде. Из вашего описания это звучит так, как будто у вас его нет.
У Scrum есть свои издержки и выгоды, но вы делаете это плохо, возможно, вы несете расходы практически без выгоды. Если вы делаете Scrum неправильно и плохо, вам лучше не делать Scrum вообще.
Во-первых, какова роль тестировщиков, дизайнеров и не разработчиков в целом в процессе схватки? Если они равны с другими членами команды, возникает пара вопросов. Дизайнеры и тестировщики обычно работают над задачей после завершения разработки, поэтому из-за этой зависимости они не могут адекватно планировать спринт.
Если дизайнеры и тестировщики не могут планировать спринт из-за зависимости от разработки, это означает, что ваша разработка не спланирована правильно. Это проблема, которая должна быть исправлена.
Ваша команда должна быть в состоянии сказать: "Задача B требует, чтобы задача A выполнялась первой. Задача A займет 8 часов, затем задача B займет 4 часа". Если ваши оценки задач точны, то зависимости вообще не являются проблемой.
Во-вторых, у нас есть сроки. Они являются строгими и имеют большое влияние на расстановку приоритетов. Конечным результатом является изменение отставания в середине спринта из-за изменений крайнего срока или плохих результатов в конце спринта. У нас также есть много нетехнических работ, таких как поддержка клиентов, которая должна быть сделана в то же время и не может быть запланирована, поскольку она сильно варьируется.
Если это происходит, то проблема в том, что вы не делаете Scrum. Единственный способ, которым Scrum работает, - это когда руководство полностью участвует в процессе. Это означает, что ваши разработчики должны оставаться одни на 30 дней, пока они работают над запланированным спринтом, и добавлять новые работы с помощью методов, которые Scrum использует для этого. Вы добавляете элементы списка пожеланий в журнал ожидания продукта, а затем во время планирования спринта разработчики и заинтересованные стороны договариваются о том, над чем будет работать следующий спринт.
Если у вас постоянно возникают проблемы со службой поддержки, которые мешают нормальному развитию, вам следует серьезно подумать о разделении команды и создать одну группу, посвященную разработке в Scrum, и создать другую группу, которая занимается вопросами поддержки клиентов. Затем вы можете вращать людей взад и вперед в конце каждого спринта.
Вы действительно не должны добавлять изменения в журнал невыполненных работ Sprint на основе изменений, внесенных в середине Sprint, они должны идти только в журнал незавершенного производства и игнорироваться до тех пор, пока Sprint не закончится.
Вы должны согласовывать свои сроки со Спринтами. Я думаю, что это приемлемо, чтобы удалить задачу середины спринта, но не вводить новую.
Если вы обнаружите, что вы добавляете много задач в середине спринта, ваши спринты, вероятно, слишком длинные. Помните, что вы стремитесь к 20 дням работы в каждом спринте, и вы начинаете получать проблемы, которые вы описываете!
Тестеры важны для любого гибкого процесса, но на самом деле они не вписываются в Scrum, где теория заключается в том, что любой человек без активной задачи выбирает следующую задачу. Попытка выбрать ассоциации между задачами и людьми начинает влиять на планирование, чего все это старалось избежать!
Тестеры, если работают в непосредственной близости от разработчиков, могут помочь определить, действительно ли какой-либо элемент работы завершен!
Во-первых, вы вообще не используете Scrum, вы можете использовать некоторые практики Scrum, но не весь процесс.
Дизайнеры и тестировщики обычно работают над задачей после завершения разработки, поэтому из-за этой зависимости они не могут адекватно планировать спринт.
Нет никакой зависимости в зависимости от задачи, ведьма редко возникает и способность правильно планировать. При планировании спринта команда должна оценить истории, касающиеся определения "Готово". Если он включает и действительно должен разрабатывать и тестировать историю, оценка усилий, необходимых для выполнения критериев приемлемости истории, должна включать задачи проектирования и тестирования.
Конечным результатом является изменение отставания в середине спринта из-за изменений крайнего срока или плохих результатов в конце спринта.
Кажется, что ваша длина спринта шире, чем вам нужно. Почему бы тебе не попробовать сделать его короче? Хорошая длина спринта - это длина, которую вы можете зафиксировать, чтобы сохранить изменения в спринте. Я думаю, что 1 неделя будет работать.
И это поведение демонстрирует, что ваш Scrum Master не выполняет свою работу должным образом, так как он не устраняет препятствия.