Когда agile-итерация считается завершенной? [закрытый]
Я работаю над командой, которая изучает возможность принятия гибких методов разработки.
один вопрос, с которым мы сталкиваемся, решает, когда должна завершиться итерация (спринт).
предположим, мы определили наше отставание по функциям и подготовили оценки сюжетных точек для них, и мы решили, что первый 30-дневный спринт будет включать функции A, B, D и F. Что вы должны делать, если вы достигаете конца спринт, и вы завершили A, D и F, но B завершен только на 80%. Должны ли вы:
завершите спринт вовремя, но исключите функцию B (отложив оставшуюся работу до будущего спринта)
продлить спринт на время, необходимое для выполнения функции B, но не начать следующий спринт.
продлить спринт на время, необходимое для выполнения функции B и начать работаем над следующим спринтом.
провалить весь спринт и связать все работы, чтобы быть частью будущего выпуска.
проблема, которую я вижу с вариантом 1, заключается в том, что команда не выполняет то, что она обязалась. В некоторых случаях вы не сможете исключить функцию B, не сделав весь выпуск бесполезным (или, по крайней мере, существенно менее ценным). Это может затруднить руководство направлением следующего спринта без функции Б.
проблема с вариантом 2 заключается в том, что некоторые члены команды могут простаивать в течение значительного периода времени, что влияет на общую производительность. Вы можете добавить больше модульных тестов или полировать функции, но это не добавляет пропорционального значения. Также политически трудно объяснить руководству, почему большая часть вашей команды бездействует.
Вариант 3, кажется, против духа agile - вы ставите следующий спринт под угрозу, не позволяя результаты из предыдущего, чтобы направлять следующую итерацию развития.
Вариант 4 кажется серьезным и имеет большинство тех же проблем варианта 1 и 3. Во-первых, ты полностью упускаешь обязательства. Во - вторых, объединение большего количества функций в последующем выпуске затрудняет тестирование и проверку с клиентами-и это снова исключает возможность направлять будущую итерацию на основе отзывов от предыдущих.
3 ответов
Вариант 1, конечно. Ваш скорость для следующей итерации будет меньше, так как он основан на вчера погода, поэтому на следующей итерации у вас больше шансов на завершение.
в scrum вы время-бокса. И вы предоставляете только те функции, которые работают.
на планирование спринта вы сделали оценку того, что вы могли бы доставить. Клиент должен принять определенный уровень неопределенности в оцените, или будьте готовы иметь слишком много ресурсов в команде.
Если вы снова пропустите следующую итерацию, переключитесь на более короткую длину итерации и убедитесь, что размер отдельных объектов меньше.
вы обычно делаете Вариант 1 - закончить спринт. Используйте завершенную работу, пусть незавершенная работа отразится на скорости проекта - так будущее планирование учитывает трудности, которые вы испытали.
да, Вариант 1 означает, что мы не закончили то, что мы обязались - но если это то, что произошло, то лучше признать это и научиться справляться лучше в следующий раз, чем скрывать это. плохие вещи происходят со всеми - критическая вещь, как мы совершенствуемся там, где мы есть.
вы можете сделать Вариант 2-продолжить завершение выдающейся работы, продлив спринт. Сделайте это только в том случае, если работа является сверхвысоким приоритетом для клиента, и они явно решили это сделать. расширение длины спринтов затрудняет их сравнение друг с другом-потому что они имеют разную длину.
абсолютно никогда не позволяйте одному спринту сливаться в следующий - либо вы расширяете старый спринт, или вы начинаете совершенно новый. Если вы позволяете двум спринтам сливаться друг с другом, вы больше не делаете спринтов и планирование ломается...
могу ли я ответить "это зависит"? Кроме того, я хотел бы добавить "Define complete".
У нас была такая ситуация пару раз и разобралась с ним по-разному в зависимости от обстоятельств.
насколько я помню, в двух случаях мы допустили провал спринта. На самом деле это был скорее демонстрационный отказ. Сами функции считались полными командой, но было слишком много открытых вопросов, свободных концов и небольших деталей, которые выскочили во время демонстрация. Это заняло бы пару дней, чтобы закончить все, поэтому мы позволили спринту потерпеть неудачу и взяли все открытые предметы в следующий спринт. У нас все еще была ретроспектива и планирование спринта для новых пользовательских историй, но не было интеграции строк кода, и спринт был официально отмечен как неудачный.
в другом случае у нас была только пара ошибок, которые появились в последнюю минуту, плюс пара вещей из истории пользователя. Мы оценили общую работу в три дня максимум и просто продлил спринт. Этого было достаточно, чтобы исправить ошибку, внести пару изменений и сделать вторую демонстрацию спринта примерно через три дня.
Итак, это был либо вариант 4, либо вариант 2 для нас, когда он был вызван.
есть несколько вещей, чтобы рассмотреть здесь. Прежде всего, (и я говорю о терминологии Scrum здесь, потому что я привык к ней, поэтому не стесняйтесь заменять ее тем, что подходит лучше всего) получите ScrumMaster, Product Owner и команду вместе и обсудите варианты открыто. Я не думаю, что есть один путь. Вы можете придерживаться чисто методологии, но в реальной жизни это не всегда лучший способ пойти. Иногда нарушение правил немного помогает и делает жизнь проще для всех.
Если вы хорошо работаете вместе, вы должны найти решение, которое работает для всех участников. (Если вы не можете, у вас могут быть основные проблемы в любом случае.) Не просто бросайте что-то в команде, не обсуждая это или, по крайней мере, не объясняя причины почему?.
Вариант 3 звучит как самый грязный для меня, поэтому я бы исключил это.
многие люди здесь утверждали, что вариант 2 идет против основных правил agile (или Scrum), но я бы не согласился. Scrum явно говорит, что вы можете продлить спринт, если потребуется, так же, как вы можете уменьшить истории или добавить ресурсы. Вы не должны делать этого без крайней необходимости, но, насколько я знаю, это не совсем против книги. В базе, когда мы это сделали, это было лучшее решение для все, потому что мы все еще сделали спринт, только через три дня, и все были очень довольны результатами. Если бы мы говорили неделю или больше, Вариант 2 не был бы уместен.
Мне не очень нравится вариант 1. Взятие наполовину сделанного материала из рабочей реализации может быть очень грязным. Вы теряете связь с кодом, который был сделан, и интеграция, честно говоря, может быть болью. Он может быть разным в зависимости от того, как вы работаете, но из моего опыта, принимая код из репозиторий-это не то, что вы хотите сделать.
Что касается варианта 4, это довольно жестко, но опять же, при правильном общении это должно быть хорошо. Команда обычно знает, когда она напортачила и не сможет доставить, так что не похоже, что вы сообщаете им какие-либо новости.
Итак, есть несколько вещей, чтобы рассмотреть.
- сколько времени потребуется, чтобы это сделать? Если это только один или два дня, продление вашего спринта может быть лучшим выбор.
- сколько усилий потребуется, чтобы удалить код, который уже есть? Если это грязно и занимает много времени, решите вариант 2 или 4. Если это легко, возможно, Вариант 1-это путь.
- что думает команда? Что думает владелец продукта? Что думают другие? Неудача весны может повлиять на моральный дух команды, но это может и не повлиять.