Я присоединился к новой команде, которая использует Agile / Scrum, и их процесс разработки выглядит следующим образом:
1) разработчики просматривают каждую историю перед каждым спринтом, чтобы убедиться, что она не пропустила ничего критического. Для этого есть формальное состояние в рабочем процессе.
2) во время начала спринта вся команда оценивает (планирование покера) сколько очков истории будет стоить каждая история.
3) наконец, сразу после начала каждого спринта каждый разработчик должен с готовностью разбивать все назначенные истории на подзадачи с оценками времени (в отличие от подзадач перед началом каждой истории).
Основным аргументом последнего шага является то, что он помогает выяснить, займет ли реализация истории больше времени, чем предполагалось, и предупредить мастера схваток о потенциальных рисках пропущенных сроков спринта.
Тем не менее, я нахожу это контрпродуктивным, в основном из-за следующих причин:
если цель состоит в том, чтобы предоставить приблизительную оценку, сюжетные пункты (шаг № 2) - то, что делает работу. Иначе зачем вообще рассказывать истории? - просто делайте подзадачи на ранней стадии.
если цель состоит в том, чтобы предоставить точные оценки, то это является ярким примером того, что описано в « Переключение задач человека, считающихся вредными» . Это, я думаю, особенно актуально для новых разработчиков, которые присоединяются к существующим командам в больших проектах, где понимание того, что необходимо сделать, может занять до 50% времени. Вам необходимо детально изучить историю № 1, затем историю № 2, № 3 и т. Д. И т. Д., Что дает большой объем информации.
Мне также говорят, что такая практика "по книге", и я даже не собираюсь это обсуждать. Может ли кто-нибудь дать ссылку на такую практику - четко ли это определено в Библии Scrum, и / или, возможно, предоставить какую-либо дополнительную информацию?
Это не отличается от того, как мы запускаем некоторые наши схватки. Мы
Оцените истории в верхней части задела в «историях»
Выберите / объясните истории, основываясь на историях, которые, по нашему мнению, «составят» спринт
Разбейте истории на более подробные технические задачи
Оцените технические задачи и сравните с первоначальной оценкой баллов (мы знаем приблизительно, сколько времени разработки обычно составляет балл)
Но вы хотите знать, почему мы оцениваем дважды!
Мы делаем грубую оценку (основываясь на истории), потому что нам нравится делать прогнозы относительно того, что может произойти в следующем спринте, и, возможно, даже в следующем. В конечном счете, руководство должно быть в состоянии общаться с клиентом о вероятных временных масштабах, поэтому, если у нас нет такой приблизительной оценки, тогда долгосрочное планирование практически невозможно.
Очевидно, это означает, что мы делаем грубые оценки не только для текущего спринта. Поскольку нет никакой гарантии, что порядок очередей не изменится для следующего спринта, мы не хотим тратить время на разбивки задач и мелкомасштабные оценки, пока они не потребуются.
Мы разбили задачу, чтобы убедиться, что все задачи были перечислены, и что истории могут быть обработаны параллельно более легко.
Мы делаем мелкомасштабные оценки (основанные на задаче), потому что это дает нам более плавный график выгорания (особенно там, где нет простого способа разбить большую историю на жизнеспособные «особенности»).
Поскольку мы делаем и то, и другое, они служат проверкой работоспособности друг друга - дикое несоответствие указывает на то, что где-то нам нужна ошибка, которую мы должны идентифицировать. Это полезный побочный продукт, но не причина сама по себе, почему мы оцениваем «дважды».
Перечитывая ваш вопрос и комментарий, я вижу некоторые различия между нашим рабочим процессом и вашим.
Мы разбиваемся как команда , и находим, что, тем не менее , накладные расходы больше, техническое обсуждение, которое мы получаем, часто очень ценно и может выявить недостатки в нашей истории. Когда у нас есть различие в опыте, знаниях или способностях, эта дискуссия также помогает тем, у кого больше, и тем, у кого меньше (очень полезно при новом найме).
Мы делаем оценки на уровне задач как команда , одна из причин, почему «планирование покера» работает из-за феномена «мудрости толпы» - как я упоминаю в комментариях, к этому моменту оценка задачи должна занимать менее 30 секунд Таким образом, накладные расходы незначительны.
Похоже, причина, по которой ваша команда выполняет разбивку заданий и оценки заданий, заключается в плавном сгорании - и это нормально, это все часть контроля за ходом спринта и предоставление возможности вашему мастеру scrum-мастера своевременно обнаруживать и устранять проблемы. Если вам нужна эта информация, вы должны сделать разбивки и оценки, и вы должны сделать их в первую очередь.
По моему мнению, переключение задач вряд ли будет проблемой для вас здесь, я не думаю, что разбивка разных задач - это действительно переключение задач в том же смысле, в котором переход от разработки одной функции к другой на части - переключение задач , Я думаю, что понимание общей «архитектуры» спринта, вероятно, весьма полезно.
Тем не менее, я думаю, что могут возникнуть и другие проблемы Как и в случае с Agile, вы должны определить проблему, которая у вас есть, и предложить решение , а затем решить, сработало ли ваше решение в ретроспективе . В этом суть построения гибкого решения, которое работает для вашей компании и вашей команды. Итак, некоторые проблемы у вас могут быть:
Вы делаете сбои индивидуально - так как ваши младшие / неопытные члены команды учатся у старших членов команды? Конечно, они, вероятно, могут научиться всему сами - но они будут учиться быстрее, если будут наставниками. Младшим членам команды требуется много времени, чтобы сломать вещи? Они делают ошибки или пропускают вещи, которые в долгосрочной перспективе стоили команде времени? Разбиться как команда может помочь здесь.
Вы делаете оценки индивидуально - то же самое относится к первому пункту, но кроме того, эти оценки менее точны, чем они могли бы быть?
Похоже, что задачи назначаются в начале спринта, но если это так, то как дорого вы находите его, когда вам нужно изменить назначение? Если кто-то отстает или болеет, насколько легко кому-то еще взять свои задачи? Должны ли они пройти через разбивку задач и попытаться понять их, не прерывая первоначального правопреемника? Если ты разбиваешься и оцениваешь как команду, то каждый должен работать над всем!
Ваши истории слишком велики? Если разрушение занимает 50% времени, истории звучат так, будто они очень вовлечены - возможно, их можно сделать меньше? Мы храним наши истории в течение 1 человековой недели работы.
Ваши задачи слишком малы? Если вы тратите много времени на составление списков задач, может быть, вы вдаваетесь в детали? У нас, как правило, есть задачи от 1 до 8 человеко-часов работы, так что в течение дня каждый добивается определенного прогресса в отчете при следующей ежедневной работе.
Спасибо за ваш ответ. Причины, которые я продолжаю слышать, очень похожи на те, которые вы перечислили. Тем не менее, из любопытства, ваш рабочий продукт основан (как в случае с продуктом и настраиваете) или проект (консультант / аутсорсинг)? И, самое главное, считаете ли вы нынешнюю модель продуктивной?
Миндас
Мы основаны на продуктах, но возможности продукта в значительной степени ориентированы на клиента (следовательно, необходимо заранее планировать функции). Я думаю, что разбивка задач очень важна для видов истории, которые мы используем, и добавление в оценки, как правило, довольно легко (к моменту, когда вы оцениваете задачу, для оценки и перемещения требуется менее 30 секунд). на). Так что в этом смысле это не будет стоить нам производительности - между нашим и вашим методами есть некоторые отличия, которые я отредактирую в своем ответе.
Адам Боуэн
3
Если именно так ваша компания хочет начать свое развитие и закрыла обсуждение, ваш выбор ограничен, или вы по крайней мере рискуете расстроить людей.
Учитывая, что конечной целью гибкой разработки является работающее ценное программное обеспечение, вы можете попытаться предложить свою помощь, измерив способность вашей команды доставить (количество доставленных / оцененных баллов, количество ошибок в спринте, количество тестов, покрытие кода, время безотказной работы, сгенерированные продажи - без разницы). Будьте готовы ко всем результатам - может быть, этот способ работы работает для них, даже если он не имеет смысла для вас. Если вы правы, отходы станут самоочевидными.
С осторожностью следите за процессом ради процесса - это тратит время и все еще доставляет плохие продукты. Хорошая гибкая команда экспериментирует, измеряет и учится. Лучший способ изменить поведение, не опускаясь до мнения, - это принимать решения на основе фактических данных
Это тоже мое мнение. Я предлагаю вам попробовать и измерить результат - посмотрите, что я там делал :)
Я предполагаю, что ваш спринт-спринт означает встречу по планированию спринта. Я думаю, что ваш Scrum Master неверно истолковал, как должна проходить эта встреча. Вы не только решаете, какие истории разрабатывать, вы также проверяете их для своей команды, чтобы они были готовы убедиться, что они ничего не пропустили (обычно с помощью INVEST ), и вы также делите эти истории на задачи. По словам Майка Кона (одного из основателей Scrum Alliance);
Задержка спринта является другим результатом планирования спринта. Журнал ожидания спринта - это список элементов журнала невыполненных работ, которые группа обязуется выполнить, а также список задач, необходимых для доставки этих элементов журнала незавершенного производства. Каждое задание в спринте также обычно оценивается.
Таким образом, разбивка историй и их оценка - все это часть сессии планирования спринта; не после окончания сеанса планирования и не индивидуально.
Чтобы обеспечить более глубокое понимание, наш рабочий процесс на собрании по планированию спринта выглядит следующим образом:
мы берем историю из верхней части списка продуктов и разбиваем ее на задачи. Как правило, одна задача обычно должна быть меньше дня.
Мы оцениваем историю с учетом задач, которые мы вычли. Если история оказывается большой, мы пытаемся разделить историю на более мелкие истории.
Промыть и повторять до тех пор, пока мы не достигнем суммы оценочных баллов
Вопреки тому, что говорит Кон, я обнаружил, что нет реальной необходимости оценивать каждую из задач в отдельности, так как задачи определены как не более одного дня. Учитывая, что задачи меньше одного дня работы, вы можете легко заметить во время ежедневного ожидания, когда задача занимает больше времени, чем ожидалось, так как человек, работающий над конкретной задачей, скажет, что он все еще работает над ней.
Во время спринта команда прорабатывает истории, и в конце команда должна подумать о том, сколько на самом деле сделано. Для этого и предназначена ретроспективная встреча Scrum. Если на столе все еще есть истории, вы можете сделать вывод, что ваша оценка была слишком оптимистичной, и действовать в соответствии с ней для следующего спринта. В качестве альтернативы могут иметь место определенные инциденты, которые влияют на то, как много вы сделали, и т. Д. Вы обнаружите, что оценки со временем улучшаются, когда вы о них думаете.
Да, я думаю, что неправильно использовал слово «крайний срок». Что я действительно имел в виду, так это ситуацию, когда некоторые истории / задания не могли быть закончены к концу спринта, и их пришлось перенести.
Миндас
3
«По книге» - это ваша проблема. Вы тонете в большем количестве процессов, чем если бы вы работали с водопадами.
Для Agile нет «книги», есть только проворный манифест, который гласит: «делай вещи без всяких накладных расходов». Итак, если вы оцениваете размеры, а затем разбиваете истории на задачи для их переоценки, то это бессмысленные накладные расходы на процесс, которые необходимо сделать более эффективными - в этом и заключается гибкость. Scrum и все остальные являются действительно отправной точкой для того, как вы начнете заниматься гибкими играми. Делая это, вы должны определять эти моменты, которые не имеют смысла или не помогают вашей команде работать более эффективно, и вы должны изменить их.
Тем не менее, некоторые люди думают, что запрещенные способы работы должны быть написаны в камне и никогда не отклоняться, независимо от того, насколько они глупы. Я бы постарался разбить истории на задачи перед началом схватки - вы говорите, что разработчики должны просматривать каждую историю, ну, у вас есть шанс сделать разделение одновременно в рамках обзора. Затем вы можете объявить задачи, составляющие историю, на собрании Scrum (не выделяйте для них время!) И позволить людям затем решить, насколько большой рабочий пакет истории, основываясь на этой дополнительной информации (что никогда не бывает плохо, принятие обоснованных решений намного лучше, чем догадки, и это может быть сделано только тогда, когда у вас есть информация для принятия решения).
После встречи вы все еще можете назначить время для задач (хотя я не вижу смысла в этом, спринты не основаны на времени, они основаны на «сколько вещей вы ожидаете сделать», что измеряется в сюжетных пунктах , а не время. Это общая проблема с схватками, очки не означают время, но вы должны набрать, скажем, 20 баллов за две недели, поэтому 2 балла = 1 день работы. Предполагается, что это будет быстрое предположение о том, сколько заданий поставить в спринте, так что вы не перегружены и не недоработаны, а не то, сколько фактически будет выполнено. Лучшие спринты - это те, у которых осталось несколько заданий, что показывает, что вы оценили идеально. Выполнение каждой задачи показывает, что люди либо срочно отправили последние, либо отложено их завершение в конце - ни один из них не является продуктивным).
Итак, вкратце - распечатайте копию Agile Manifesto и анти-проворную версию . Бьюсь об заклад, вы делаете больше анти, чем проворный. Скрам имеет тенденцию быть таким. Единственный способ исправить это - вступить в контакт с вашей командой и получить вступительный взнос за изменения. Не позволяйте руководству рассказывать вам, как работает ваша команда, это тоже не ловко, и это будет написано в Книге.
В какой-то момент во время каждого спринта у вас должно быть совещание по уточнению журнала ожидания продукта . На этом собрании вы гарантируете, что верхняя часть журнала невыполненных работ будет в достаточной степени разбита на элементы, которые будут добавлены в следующий список невыполненных работ по спринту.
Если корректировка отставания в продуктах ведется хорошо, совещание по планированию спринта может быть более эффективным. В идеале это избавит разработчиков от необходимости «охотно ломать» истории после запуска Sprint.
Если элементы журнала невыполненных работ по продукту добавляются в список невыполненных работ спринта до того, как они будут в достаточной степени разбиты для реалистичной оценки, это затруднит принятие правильных решений о том, что добавить в состав спринта.
Если именно так ваша компания хочет начать свое развитие и закрыла обсуждение, ваш выбор ограничен, или вы по крайней мере рискуете расстроить людей.
Учитывая, что конечной целью гибкой разработки является работающее ценное программное обеспечение, вы можете попытаться предложить свою помощь, измерив способность вашей команды доставить (количество доставленных / оцененных баллов, количество ошибок в спринте, количество тестов, покрытие кода, время безотказной работы, сгенерированные продажи - без разницы). Будьте готовы ко всем результатам - может быть, этот способ работы работает для них, даже если он не имеет смысла для вас. Если вы правы, отходы станут самоочевидными.
С осторожностью следите за процессом ради процесса - это тратит время и все еще доставляет плохие продукты. Хорошая гибкая команда экспериментирует, измеряет и учится. Лучший способ изменить поведение, не опускаясь до мнения, - это принимать решения на основе фактических данных
Это тоже мое мнение. Я предлагаю вам попробовать и измерить результат - посмотрите, что я там делал :)
источник
Я предполагаю, что ваш спринт-спринт означает встречу по планированию спринта. Я думаю, что ваш Scrum Master неверно истолковал, как должна проходить эта встреча. Вы не только решаете, какие истории разрабатывать, вы также проверяете их для своей команды, чтобы они были готовы убедиться, что они ничего не пропустили (обычно с помощью INVEST ), и вы также делите эти истории на задачи. По словам Майка Кона (одного из основателей Scrum Alliance);
Таким образом, разбивка историй и их оценка - все это часть сессии планирования спринта; не после окончания сеанса планирования и не индивидуально.
Чтобы обеспечить более глубокое понимание, наш рабочий процесс на собрании по планированию спринта выглядит следующим образом:
мы берем историю из верхней части списка продуктов и разбиваем ее на задачи. Как правило, одна задача обычно должна быть меньше дня.
Мы оцениваем историю с учетом задач, которые мы вычли. Если история оказывается большой, мы пытаемся разделить историю на более мелкие истории.
Промыть и повторять до тех пор, пока мы не достигнем суммы оценочных баллов
Вопреки тому, что говорит Кон, я обнаружил, что нет реальной необходимости оценивать каждую из задач в отдельности, так как задачи определены как не более одного дня. Учитывая, что задачи меньше одного дня работы, вы можете легко заметить во время ежедневного ожидания, когда задача занимает больше времени, чем ожидалось, так как человек, работающий над конкретной задачей, скажет, что он все еще работает над ней.
Во время спринта команда прорабатывает истории, и в конце команда должна подумать о том, сколько на самом деле сделано. Для этого и предназначена ретроспективная встреча Scrum. Если на столе все еще есть истории, вы можете сделать вывод, что ваша оценка была слишком оптимистичной, и действовать в соответствии с ней для следующего спринта. В качестве альтернативы могут иметь место определенные инциденты, которые влияют на то, как много вы сделали, и т. Д. Вы обнаружите, что оценки со временем улучшаются, когда вы о них думаете.
источник
«По книге» - это ваша проблема. Вы тонете в большем количестве процессов, чем если бы вы работали с водопадами.
Для Agile нет «книги», есть только проворный манифест, который гласит: «делай вещи без всяких накладных расходов». Итак, если вы оцениваете размеры, а затем разбиваете истории на задачи для их переоценки, то это бессмысленные накладные расходы на процесс, которые необходимо сделать более эффективными - в этом и заключается гибкость. Scrum и все остальные являются действительно отправной точкой для того, как вы начнете заниматься гибкими играми. Делая это, вы должны определять эти моменты, которые не имеют смысла или не помогают вашей команде работать более эффективно, и вы должны изменить их.
Тем не менее, некоторые люди думают, что запрещенные способы работы должны быть написаны в камне и никогда не отклоняться, независимо от того, насколько они глупы. Я бы постарался разбить истории на задачи перед началом схватки - вы говорите, что разработчики должны просматривать каждую историю, ну, у вас есть шанс сделать разделение одновременно в рамках обзора. Затем вы можете объявить задачи, составляющие историю, на собрании Scrum (не выделяйте для них время!) И позволить людям затем решить, насколько большой рабочий пакет истории, основываясь на этой дополнительной информации (что никогда не бывает плохо, принятие обоснованных решений намного лучше, чем догадки, и это может быть сделано только тогда, когда у вас есть информация для принятия решения).
После встречи вы все еще можете назначить время для задач (хотя я не вижу смысла в этом, спринты не основаны на времени, они основаны на «сколько вещей вы ожидаете сделать», что измеряется в сюжетных пунктах , а не время. Это общая проблема с схватками, очки не означают время, но вы должны набрать, скажем, 20 баллов за две недели, поэтому 2 балла = 1 день работы. Предполагается, что это будет быстрое предположение о том, сколько заданий поставить в спринте, так что вы не перегружены и не недоработаны, а не то, сколько фактически будет выполнено. Лучшие спринты - это те, у которых осталось несколько заданий, что показывает, что вы оценили идеально. Выполнение каждой задачи показывает, что люди либо срочно отправили последние, либо отложено их завершение в конце - ни один из них не является продуктивным).
Итак, вкратце - распечатайте копию Agile Manifesto и анти-проворную версию . Бьюсь об заклад, вы делаете больше анти, чем проворный. Скрам имеет тенденцию быть таким. Единственный способ исправить это - вступить в контакт с вашей командой и получить вступительный взнос за изменения. Не позволяйте руководству рассказывать вам, как работает ваша команда, это тоже не ловко, и это будет написано в Книге.
источник
В какой-то момент во время каждого спринта у вас должно быть совещание по уточнению журнала ожидания продукта . На этом собрании вы гарантируете, что верхняя часть журнала невыполненных работ будет в достаточной степени разбита на элементы, которые будут добавлены в следующий список невыполненных работ по спринту.
Если корректировка отставания в продуктах ведется хорошо, совещание по планированию спринта может быть более эффективным. В идеале это избавит разработчиков от необходимости «охотно ломать» истории после запуска Sprint.
Если элементы журнала невыполненных работ по продукту добавляются в список невыполненных работ спринта до того, как они будут в достаточной степени разбиты для реалистичной оценки, это затруднит принятие правильных решений о том, что добавить в состав спринта.
источник