Наша версия Agile не работает. Подсказки?

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

Фон:

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

Мы начинаем каждый спринт, рассказывая истории, которые наш менеджер создает для нас. Иногда он тоже бросает задания, и мы их оцениваем. Мы не используем сюжетные очки. Мы используем программное обеспечение Urban Turtle для «управления нашими спринтами», которое по сути является просто историями и задачами, а также связанным с ними сгоранием. Мы не планируем выпуск в конце спринта.

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

Единственное предложение, которое нам предоставляется, - это быть более активным в корректировке наших оценок и обновлении информации в утренние часы ожидания, чтобы мы могли приспособиться к необходимому дополнительному времени.

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

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

потому что мы отстаем от графика

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

После этого не имеет значения, если вы постоянно недооцениваете задачи - ваша скорость уже учитывает это.

Очевидно, это невозможно, если вы используете часы вместо очков.

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

Маленькие задачи гораздо легче точно оценить, чем большие, поэтому попробуйте разбить свои задачи на гораздо более мелкие куски.

Не позволяйте никому делать оценку для любой задачи, если они точно не знают, как они собираются это сделать. Для любой задачи, которую разработчик не знает, что выполнить, уделите некоторое время расписанию ЭТОГО спринта, чтобы разработчик провел некоторое исследование и проектирование, и придумайте точную оценку. Никогда не меньше, чем полдня. Но перенесите задачу на СЛЕДУЮЩИЙ спринт. Затем, когда вы придете к планированию следующего спринта, у вас будет хорошая оценка. Обратите внимание, что это дополнительное время не тратится впустую, потому что в любом случае разработчик в конечном итоге потратит деньги.

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

Вы пытаетесь выделить 100% своего времени? Если так, прекратите это делать. Начните с суммирования всех часов, которые ваша команда должна внести во время спринта. Сделайте это, предполагая, что каждый работник в лучшем случае будет уделять 6 часов в день проекту. Это считается "идеальным днем". Эти два часа? Поглощенный встречами, перерывами, административными задачами, тем утром, когда вы читаете электронную почту и планируете свой день и т. Д. Это не «хеджирование ваших ставок» или «мешки с песком», это реалистично.

Во-вторых, умножьте это 6 часов в день на 80% . Зачем? Потому что, как люди, мы не умеем предсказывать, сколько времени займет задание. Это объясняет ошибки в нашем суждении. Опять же, не мешки с песком, это реалистично.

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

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

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

Критерии принятия плохо определены в начале спринта?

Первоначальные оценки часто бывают слишком низкими, потому что карты историй имеют плохие критерии приемлемости (если таковые имеются), когда они оцениваются. Как насчет перехода на Acceptance-Test-Driven Development (ATDD), также известный как тестирование историй, чтобы помочь команде понять, что такое карта?

Истории слишком велики?

Другая причина, по которой вы узнаете в середине спринта, что ваши истории занимают больше времени, чем ожидалось, может быть в том, что они слишком велики. Вы видели Agile в колоде флэш- карт? У них есть карта под названием «Shrink XL story to Fit». Он дает стратегии для разделения историй, таких как отсрочка крайних случаев, побочные эффекты, нефункциональные аспекты или обработка ошибок для последующих историй.

Не можете оценить, потому что у вас нет достаточной информации?

@sleske делает хорошее предложение о шипах . Попробуйте определить технические неизвестные во время оценки. Если таковые имеются, посмотрите, можете ли вы отложить историю до более позднего спринта и вместо этого провести временное исследование (всплеск) этого спринта, чтобы попытаться узнать, что потребуется для оценки. Не увлекайтесь и не разгадывайте оригинальную историю - всплеск заканчивается, когда вы знаете достаточно, чтобы оценить историю.

Провалиться быстрее

И я согласен с @Patrick Hughes - подумайте о переходе на 1-недельный спринт, чтобы вы могли быстрее увидеть проблемы.

В дополнение к хорошим предложениям @Kevin и @Patrick ...

Agile подходы не "один размер подходит всем", но этот комментарий привлек мое внимание:

Мы внедряем версию Agile, которая, кажется, постоянно предоставляет нам одни и те же трудности

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

Аренда опытного тренера Scrum (на несколько итераций) может стать настоящим отличием. Есть тонкость в том, чтобы стать ловким и правильным.

Сначала я рекомендую следующую книгу scrum-xp-from-the-trenches . Посмотрите на странице 26 пункт о расчетах скорости. Идея состоит в том, чтобы определить фактор фокуса и сказать, что для следующего спринта:

доступные человеко-дни * коэффициент фокусировки = расчетная скорость

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

И после одного спринта вы рассчитываете коэффициент фокусировки последнего спринта как:

коэффициент фокусировки = фактическая скорость / доступные человеко-дни

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

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

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

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

Пусть всем будет удобно отправлять красный флаг, как только они попадают в препятствие, вместо того, чтобы застрять в проблеме на несколько часов. Попробуйте отделить эго и обвинить в этом процессе, для некоторых это легче, чем для других =)

Как и в случае с @Kevin, на самом деле вы никогда не планируете 100% -ное непосредственное планирование задач, потому что всегда есть накладные расходы, такие как встречи и т. Д., Которые вы можете не распознать как пожирателей времени.

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