Когда гибкая итерация считается завершенной?
Я работаю в команде, которая изучает возможность применения методов гибкой разработки.
Один вопрос, с которым мы сталкиваемся, - это решить, когда итерация (спринт) должна быть завершена.
Допустим, мы определили наше отставание по функциям и подготовили для них приблизительные оценки, и мы решили, что первый 30-дневный спринт будет включать функции A, B, D и F. Что вы должны делать, если у вас есть Вы достигли конца спринта, и вы выполнили A, D и F - но B завершен только на 80%. Тебе следует:
Завершите спринт вовремя, но исключите функцию B (отложить оставшуюся работу до будущего спринта)
Продлите спринт на время, необходимое для завершения функции B, но не начинайте следующий спринт.
Продлите спринт на время, необходимое для завершения функции B, и начните работу над следующим спринтом.
Сбой весь спринт, и объединить все работы, чтобы стать частью будущего выпуска.
Проблема, которую я вижу с вариантом 1, состоит в том, что команда не выполняет то, к чему она привержена. В некоторых случаях вы не сможете исключить функцию B, не сделав весь выпуск бесполезным (или, по крайней мере, существенно менее ценным). Это может затруднить направление следующего спринта без функции B.
Проблема с вариантом 2 заключается в том, что некоторые члены команды могут простаивать в течение значительного периода времени, что сказывается на общей производительности. Возможно, вы сможете добавить больше юнит-тестов или усовершенствовать функции, но это не добавит пропорциональное значение. Также политически сложно объяснить руководству, почему большая часть вашей команды бездействует.
Вариант 3, кажется, противоречит духу гибкости - вы подвергаете риску следующий спринт, не позволяя результатам предыдущего спровоцировать следующую итерацию разработки.
Вариант 4 кажется серьезным и имеет большинство тех же проблем, что и Вариант 1 и 3. Во-первых, вы полностью упускаете обязательство. Во-вторых, включение большего количества функций в последующую версию усложняет тестирование и проверку у клиентов - и это опять-таки лишает возможности руководить будущей итерацией на основе отзывов предыдущих.
6 ответов
Вариант 1 конечно. Ваша скорость для следующей итерации будет меньше, так как она основана на вчерашней погоде, поэтому на следующей итерации у вас больше шансов быть завершенной.
В схватках ты время-бокс. И вы предоставляете только те функции, которые работают.
При планировании спринта вы сделали оценку того, что могли бы предоставить. Заказчик должен принять определенный уровень неопределенности в оценке или быть готовым иметь слишком много ресурсов в команде.
Если вы пропустите следующую итерацию снова, переключитесь на более короткую итерацию и убедитесь, что размер отдельных объектов меньше.
Могу ли я ответить "Это зависит"? Кроме того, я хотел бы добавить "Определить завершено".
У нас была такая ситуация пару раз, и мы решали ее по-разному, в зависимости от обстоятельств.
Насколько я помню, в двух случаях мы позволили спринту провалиться. На самом деле это был скорее отказ от демонстрации. Сами функции были сочтены командой полными, но было слишком много открытых вопросов, недоумений и мелких деталей, которые всплыли во время демонстрации. Потребовалось бы несколько дней, чтобы все обернуть, поэтому мы допустили сбой спринта и перенесли все открытые позиции в следующий спринт. Мы по-прежнему планировали ретроспективу и спринт для новых пользовательских историй, но не было интеграции строк кода, и спринт был официально помечен как неудачный.
В другом случае у нас была только пара ошибок, которые появились в последнюю минуту, плюс пара вещей из пользовательской истории. Мы оценили общую работу до трех дней и просто продлили спринт. Этого было достаточно для того, чтобы мы исправили ошибку, внесли пару изменений и сделали второе демо спринта примерно через три дня.
Таким образом, это был либо вариант 4, либо вариант 2 для нас, когда он был востребован.
Здесь есть несколько вещей, которые следует учитывать. Прежде всего (и я здесь говорю о терминологии Scrum, потому что я к этому привык, поэтому смело заменяйте ее на то, что подходит лучше всего), соберите ScrumMaster, владельца продукта и команду вместе и открыто обсудите варианты. Я не думаю, что есть один путь. Вы можете придерживаться чистой методологии, но в реальной жизни это не всегда лучший путь. Иногда изменение правил немного помогает и облегчает жизнь всем.
Если вы хорошо работаете вместе, вы должны найти вариант, который подходит для всех участников. (Если вы не можете, у вас могут возникнуть проблемы в любом случае.) Не просто бросайте что-то в команду, не хотя бы обсудив это или хотя бы объяснив причины.
Вариант 3 звучит как самый грязный для меня, так что я исключаю это.
Многие люди здесь утверждают, что вариант 2 идет вразрез с базовыми гибкими (или Scrum) правилами, но я бы не согласился. Скрам прямо говорит, что вы можете расширить спринт, если потребуется, так же, как вы можете уменьшить количество историй или добавить ресурсы. Тебе не следует делать это до тех пор, пока это не станет абсолютно необходимым, но, насколько я знаю, это не строго против книги. На базе, когда мы это делали, это было лучшее решение для всех, потому что мы все-таки сделали спринт всего три дня спустя, и все были очень довольны результатами. Если бы мы говорили неделю или больше, вариант 2 был бы неуместным.
Мне не очень нравится вариант 1. Извлекать наполовину готовые вещи из работающей реализации может быть очень грязно. Вы теряете связь с кодом, который был сделан, и интеграция, честно говоря, может быть болезненной. Это может отличаться в зависимости от того, как вы работаете, но, исходя из моего опыта, вы не хотите делать код из кодовой строки.
Что касается варианта 4, он довольно резкий, но, опять же, при правильном сообщении все должно быть в порядке. Команда обычно знает, когда все испортилось, и не сможет доставить, так что вы не сообщаете им никаких новостей.
Итак, есть несколько вещей для рассмотрения.
- Сколько времени понадобится, чтобы это сделать? Если это только один или два дня, продление спринта может быть лучшим вариантом.
- Сколько будет усилий, чтобы удалить код, который уже там? Если это грязно и занимает много времени, выберите вариант 2 или 4. Если это просто, возможно, вариант 1 - это путь.
- Что думает команда? Что думает владелец продукта? Что думают другие? Отсутствие весны может повлиять на командный дух, но это не так.
Вы обычно делаете вариант 1 - закончить спринт. Используйте выполненную работу, пусть незавершенная работа отразится на скорости проекта - поэтому в будущем планировании учитываются трудности, с которыми вы столкнулись.
Да, вариант 1 означает, что мы не выполнили то, к чему стремились, - но если это то, что произошло, то лучше признать это и научиться справляться лучше в следующий раз, чем скрывать это. Плохие вещи случаются со всеми - самое важное - это то, как мы улучшаем свое положение.
Вы могли бы сделать вариант 2 - продолжить завершать выдающуюся работу, расширяя спринт. Делайте это только в том случае, если работа имеет сверхвысокий приоритет для клиента, и он явно решит это сделать. Увеличение длины спринтов затрудняет их сравнение друг с другом - потому что они разной длины.
Абсолютно НИКОГДА не позволяйте одному спринту сливаться с другим - либо вы расширяете старый спринт, либо запускаете совершенно новый. Если вы позволите двум спринтам слиться друг с другом, то вы больше не будете делать спринты и планирование нарушится...
Для гибкого проекта важно иметь "Определение выполненного". Это небольшой контрольный список того, что нужно сделать, чтобы классифицировать что-либо как завершенное. Нет ничего необычного в том, чтобы делать разные уровни:
User Story - Это может включать в себя такие вещи, как все задачи, связанные с США, должны быть выполнены, весь код проверен и успешно собран с прохождением модульных тестов, приемочное тестирование завершено.
Спринт - это может включать такие вещи, как все истории для спринта "сделаны" (см. Выше, проведена ретроспектива, владелец продукта видел демонстрацию функциональности и т. Д. И т. Д. И т. Д.).
Выпуск спринта - разработка предыдущей серии спринтов была успешно интегрирована и регрессивно протестирована, функциональность была выпущена в живую среду.
С точки зрения 4 вариантов это менее четкий. Много сказано и написано о том, что следует и чего не следует делать в случае неудачи спринта, расширения спринта и исключения тех или иных функций. Я считаю, что с гибкими проектами требуется много прагматизма, особенно в первые несколько спринтов.
Главное не зацикливаться на этом. Просто учитесь на этом, адаптируйтесь и двигайтесь дальше.
Я бы взял вариант для варианта 1. Если функция B может быть разбита на то, что завершено, а что не завершено, это должно привести к пересмотренному набору задач для его завершения для следующего спринта. То, что закончено, доставлено, и хотя доставка не идеальна, идея должна состоять в том, чтобы попытаться сделать все возможное, а затем работать над тем, что будет дальше в соответствии с приоритетом.
Расширение спринта - это рецепт катастрофы для меня. Означает ли завершение функции устранение всех ошибок на ней? Вы когда-нибудь видели программное обеспечение с нулевыми ошибками?
Неудача в спринте привносит слишком много перфекционизма в вещи. Что-то, что на 99% сделано бесполезным? Я бы так не думал, но есть люди, у которых действительно высокие стандарты и которые могут быть довольно требовательными.
РЕДАКТИРОВАТЬ: Иногда функция изначально предоставляется с неопределенными требованиями, которые выясняются в ходе спринта. Например, запрос функции "Как пользователь, я хотел бы разместить заказ" может быть разбит как на часть планирования спринта, так и во время спринта. В любом случае, если некоторые истории, связанные с какой-либо функцией, уже созданы, они могут и должны быть представлены на демо-версии, если таковая имеется. Смысл в том, чтобы быть в состоянии сказать: "Это то, где мы находимся. Насколько приоритетным является завершение этого?" поскольку то, что могло быть срочным раньше, может быть не так в конце спринта.
Во-первых, правило: итерации - это временные рамки фиксированной длины, и они завершаются в конце временного окна. Таким образом, это исключает Вариант 2 и Вариант 3. Что касается Варианта 4, аварийное завершение итерации может произойти при очень определенных обстоятельствах (уверенность в том, что цель не может быть достигнута, внешнее событие делает недействительной цель...), но это должно оставаться исключительным событием. И прежде чем прервать, есть в общем другие варианты: 1. Сделать что-то еще / ввести новшества 2. Получить помощь / аутсорсинг 3. Уменьшить сферу. И это оставляет вам вариант 1, очевидный выбор.
Проблема, которую я вижу с вариантом 1, состоит в том, что команда не выполняет то, к чему она привержена. В некоторых случаях вы не сможете исключить функцию B, не сделав весь выпуск бесполезным (или, по крайней мере, существенно менее ценным). Это может затруднить направление следующего спринта без функции B.
Если это правда, то либо B был важнее, чем A, D и F, и вы сначала не работали над наиболее важными элементами, что неправильно, этого не должно происходить, либо... A, D и F на самом деле очень В этом случае ваше предположение неверно, и отсрочка B, таким образом, не является большой проблемой. Итак, просто сделайте это, как только вы поймете, что этого не произойдет, и посмотрите, сможете ли вы заменить его на более мелкий предмет.