Scrum Process Management-советы, подводные камни, идеи [закрыто]
Я уже некоторое время занимаюсь scrum с командой, но по некоторым причинам все кажется запутанным. Я думал о том, как их можно изменить, и у меня есть пара вопросов, которые я хотел бы поднять здесь.
Во-первых, какова должна быть роль тестировщиков, дизайнеров и не разработчиков в целом в процессе Scrum? Если они равны с другими членами команды, возникает пара проблем. Проектировщики и тестировщики обычно работают над задачей после завершения разработки, поэтому они не могут адекватно планировать спринт из-за этой зависимости. Во-вторых, у нас есть крайние сроки. Они строги и оказывают большое влияние на определение приоритетов. Конечным результатом является изменение отставания в середине спринта из-за изменения крайнего срока или плохие результаты в конце спринта. У нас также есть много нетехнической работы, такой как поддержка клиентов, которая должна быть выполнена в то же время и не может быть запланирована, поскольку она сильно варьируется. Так что я думаю, что структура команды, культура и практика не совместимы. со Скрамом. Scrum для меня-это инструмент управления процессами для команд, работающих над разработкой единого программного продукта.Что вы, ребята, думаете о применении его в более конкретных и сложных сценариях? У вас есть какой-нибудь опыт, чтобы поделиться?
4 ответа:
В целом тестировщики и документалисты (и другие не-разработчики) являются равноправными членами scrum-команды. Идея заключается в том, чтобы минимизировать риск.
Требование определения done, которое включает потенциально отгружаемый продукт, полностью протестированный и документированный, заставляет проект объединяться в конце каждого спринта.
Если тестирование начнется только после dev. что происходит, так это то, что многие ошибки обнаруживаются после того, как разработчики закончили с задачей. Так теперь вы должны исправить эти ошибки, и это очень медленно и дорого как потому, что ошибки взаимодействуют, так и потому, что общее правило таково: "затраты на исправление ошибки растут экспоненциально со временем."Ошибки, которые вы ловите рано, дешевы и легко исправимы, поздние ошибки-это кошмар.
Вот почему вы хотите, чтобы тестирование (и документация) двигались в ногу с разработкой. И прямо сейчас вы должны спросить, как! Тестирование идет медленно, как, черт возьми, он может двигаться в ногу с Дэв?Ответ-автоматизация., то есть SCRUM всегда сидит на вершине XP или Agile, оба требуют превосходного покрытия юнит-тестов и TDD. Вот еще один человек, которого надо остерегаться. Разработчики функций должны быть теми, кто пишет как модульный, так и системный тест. Вся автоматизация тестирования должна выполняться разработчиком функций. команда. В некоторых местах сплит-функция dev. от автоматизации разработки. и это плохо.
Хорошо, теперь у вас есть отличное автоматическое тестирование, и вы запускаете его по крайней мере один раз в день. И, очевидно, вы практикуете непрерывную интеграцию, верно? Это значительно снижает рабочую нагрузку тестировщиков. И именно так тестирование может идти в ногу с Дэв. Еще одна вещь, тестировщики теперь работают над действительно трудными и творческими вещами, которые невозможно или очень трудно автоматизировать, каждый раз, когда они находят ошибку таким образом, что бы ни потребовалось, чтобы выявить ошибку, автоматизируется и становится частью ежедневных регрессионных тестов. Фу, какой длинный ответ!
Теперь перейдем ко второй части вашего вопроса. Scrum - это дисциплина. Спринты короткие и изменения отставания во время спринта не должны происходить. Нетехническая работа должна быть разветвлена на группу поддержки клиентов, и они могут сделать Scrum вокруг этого. Вы правы, когда говорите, что это звучит так, как будто ваша культура и практика несовместимы со scrum. По моему опыту, переход на Scrum / Agile-это очень болезненный, напряженный процесс, и большинство попыток перехода терпят неудачу. Одним из ключевых факторов успеха является чемпион по Scrum / Agile в команде руководителей. По вашему описанию это похоже, у тебя его нет.В Scrum есть затраты и выгоды, но вы делаете это плохо, вы можете нести затраты с небольшой или никакой пользой. Если вы делаете Scrum неправильно и плохо, вам, возможно, лучше вообще не делать Scrum.
Во-первых, какова должна быть роль тестировщиков, дизайнеров и не-разработчиков в целом в процессе scrum? Если они равны с другими членами команды, возникает пара проблем. Проектировщики и тестировщики обычно работают над задачей после завершения разработки, поэтому они не могут адекватно планировать спринт из-за этой зависимости.Если проектировщики и тестировщики не могут планировать спринт из-за зависимости разработки, это означает, что ваша разработка не планируется правильно. Это проблема, которую нужно решить.
Ваша команда должна уметь сказать: "задача в требует, чтобы задача а была выполнена первой. Задача а займет 8 часов, а задача Б-4 часа". Если ваши оценки задач точны, то зависимости не являются проблемой вообще.Во-вторых, у нас есть крайние сроки. Они строги и оказывают большое влияние на определение приоритетов. Конечным результатом является изменение отставания в середине спринта из-за изменения крайнего срока или плохие результаты в конце из спринта. У нас также есть много нетехнической работы, такой как поддержка клиентов, которая должна быть выполнена в то же время и не может быть запланирована, поскольку она сильно варьируется.Если это происходит, то проблема в том, что вы не делаете Scrum. Scrum работает только в том случае, если руководство полностью покупается на этот процесс. Это означает, что вы оставляете разработчиков в покое на 30 дней, пока они работают над своим запланированным спринтом, и добавляете новую работу с помощью методов, которые Scrum имеет для этого. Вы добавляете элементы списка пожеланий в список невыполненной работы по продукту, а затем во время планирования спринта разработчики и заинтересованные стороны договариваются о том, что будет работать в следующем спринте.
Если у вас постоянно возникают проблемы с поддержкой клиентов, прерывающие нормальное развитие, то вам следует серьезно подумать о разделении команды и иметь одну группу, посвященную работе над развитием в Scrum, и другую группу, которая занимается вопросами поддержки клиентов. В конце концов, вы могли бы вращать людей взад и вперед из каждого спринта.
Вам действительно не следует добавлять изменения в список невыполненной работы спринта на основе изменений, внесенных в середине спринта, они должны только войти в список невыполненной работы продукта и игнорироваться до тех пор, пока спринт не закончится.
Вы должны согласовать свои крайние сроки со спринтами. Я думаю, что вполне допустимо отказаться от задачи в середине спринта, но не вводить новую.
Если вы обнаружите, что добавляете много задач в середине спринта, ваши спринты, вероятно, слишком длинные. Помните, что вы нацелены на около 20 дней работы в каждый спринт, больше, и вы начинаете получать проблемы, которые вы описываете!
Тестировщики важны для любого гибкого процесса, но на самом деле не вписываются в Scrum, где теория-любой человек без активной задачи выбирает следующую задачу. Попытка выбрать ассоциации между задачами и людьми начинает входить в планирование, которого все это время пытались избежать!Тестировщики, если они работают в непосредственной близости от разработчиков, могут помочь в определении того, является ли предмет работы на самом деле полный!
Во-первых, вы не используете Scrum вообще, вы можете использовать некоторые методы scrum, но не весь процесс.
Проектировщики и тестировщики обычно работают над задачей после завершения разработки, поэтому они не могут адекватно планировать спринт из-за этой зависимости.
Нет никакой связи в зависимости от задачи, ведьма редко встречается, и способность правильно планировать. При планировании спринта команда должна оценить истории, касающиеся определения Done. Если это включает в себя, и это действительно должно включать, проектирование и тестирование истории, оценка усилий, необходимых для выполнения критериев принятия истории, должна включать в себя задачи проектирования и тестирования.
Конечным результатом является изменение отставания в середине спринта из-за изменения крайнего срока или плохие результаты в конце спринта.
Похоже, что ваша длина спринта шире, чем вам нужно. Почему бы тебе не попытаться сделать его короче? Хорошая длина спринта-это длина, которую вы можете зафиксировать, чтобы сохранить изменения из спринта. Я думаю, что 1 неделя будет работать.
И это поведение демонстрирует, что ваш Scrum-мастер не выполняет свою работу должным образом, поскольку он не устраняет препятствия.