Взгляд на мощную основу, которая упрощает гибкую разработку

Нет, не такая схватка. Сегодня мы говорим об Agile разработке!

  1. Планирование
  2. Встаньте
  3. Рассмотрение
  4. Ретроспектива

Эти четыре встречи, или «церемонии схватки», составляют мощную основу гибкой разработки. Каждый из них играет важную роль в структуре Scrum, и отклоняться от него просто нельзя. В следующей статье я дам обзор каждого из них и объясню непосредственные преимущества, которые вы увидите, применив их к своей последовательности разработки программного обеспечения.

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

  • Продукт - это видение того, как будет выглядеть ваше программное решение, когда вся работа будет завершена.
  • Элементы невыполненной работы по продукту (PBI) - это отдельные части работы, которые вместе составляют невыполненную работу по продукту. Несколько типов PBI включают функции, дефекты, техническую работу и сбор знаний (также известные как всплески).
  • Критерии приемки - это список предопределенных требований, которые необходимо выполнить, прежде чем отдельный PBI будет считаться выполненным.
  • Определение выполненного - это список критериев, которым необходимо соответствовать, прежде чем PBI можно будет считать выполненным. В отличие от критериев приемки, определение «готово» применяется ко всем PBI, которые завершает команда разработчиков. В то время как критерии приемлемости гарантируют, что PBI является «правильным», определение выполненного гарантирует, что PBI был проведен «правильным способом».
  • Вертикальный сегмент функциональности - это часть продукта в целом, которая соответствует определению готового и потенциально может быть передана покупателю, который найдет в нем ценность.
  • Потенциально доступный прирост продукта - это комбинация всех PBI, также известных как «элементы бэклога спринта» (SBI) к моменту начала спринта, которые составляют результат каждого спринта. Каждый PBI / SBI, помеченный как завершенный, должен иметь такое высокое качество, чтобы Release Manager мог вырезать выпуск из стабильной ветви в любой момент времени.

А теперь перейдем к церемониям!

Планирование спринта

(Один раз за спринт перед официальным запуском спринта)

Первая церемония Scrum - это планирование спринта. Это собрание, на котором владелец продукта, мастер Scrum и команда разработчиков собираются вместе, чтобы взять на себя твердые обязательства в отношении PBI, готовых к спринту, которые будут приняты в спринте. Для этого команда возьмет каждый PBI, готовый к спринту, и разбивает его на задачи, необходимые для достижения цели «Готово».

Настоятельно рекомендуется, чтобы задачи были осмысленными, а не просто списком категорий задач. Хотя для PBI может потребоваться проектирование, тестирование и кодирование, простая запись этих слов не обеспечивает контекст для других членов команды разработчиков. Если бы вы взялись за задачу, не зная, что в нее входит, были бы вы уверены, что взяли на себя обязательство ее выполнить? А что насчет того, когда вы и ваша команда работаете над PBI и сталкиваетесь с задачей, в которой есть просто слово «кодирование» или «тестирование»? Как вы могли бы действовать с уверенностью? Ответить, наверное, не так-то просто. Поэтому вместо того, чтобы создавать такие ситуации, будьте как можно тщательнее при создании задач.

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

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

Ежедневный Скрам

(Один раз в день на каждый день спринта)

Вторая церемония Scrum - это Daily Scrum, также известная как Daily Standup. Это быстрое (примерно 15 минут) совещание, на котором члены группы разработчиков сообщают обновленную информацию о статусе своей работы и о том, сталкиваются ли они с какими-либо препятствиями на пути к своей работе. Часто эта информация передается в формате ответов на следующие вопросы:

  • Что ты делал вчера?
  • Что ты будешь делать сегодня?
  • У вас есть блокираторы?

Эти ежедневные встречи играют важную коммуникативную роль, и вы никогда не должны опаздывать на них. Вы также должны придерживаться правил, которые вы и ваша команда создали для них. Это демонстрирует уровень уважения к времени других и к самому процессу схватки. Как Scrum Master вы никогда не должны бояться выдвигать тему на обсуждение после схватки, если вы обнаружите, что обсуждение затягивается. Каждый член команды должен стремиться к быстрому и конкретному обновлению информации, вызывая всех блокирующих, чтобы группа могла обсудить и разрешить их как можно скорее.

Обзор спринта

(Один раз за спринт ближе к концу спринта)

Третья церемония Scrum - это обзор спринта. Это собрание, которое длится примерно от 1 до 1,5 часов, где члены команды разработчиков будут иметь возможность представить живые демонстрации и / или рассказать о том, чего они достигли в текущем спринте.

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

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

Следует сказать, что может произойти и, скорее всего, произойдет обратное - когда заинтересованное лицо увидит вашу работу и решит, что она им настолько нравится, что у них возникнет еще одна идея, которую они захотят добавить. Когда это происходит, новый PBI должен быть добавлен в бэклог продукта для каждого вертикального среза потенциального изменения. Однако, если в Sprint Review решено, что существующий фрагмент функциональности больше не требуется, PBI следует удалить из журнала невыполненных работ.

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

Ретроспектива спринта

(Один раз за спринт ближе к концу спринта)

Четвертая церемония Scrum - это ретроспектива спринта. Это собрание, которое длится около 1 часа в конце спринта, где члены команды разработчиков будут иметь возможность обсудить, как, по их мнению, прошел спринт.

Цель Agile и Scrum не только в том, чтобы строить, но и в том, чтобы постоянно учиться и улучшать сам процесс. В этом вся суть Ретроспективы Спринта. Это время, когда вы как команда делитесь тем, что, по вашему мнению, прошло хорошо во время спринта, и что можно было бы сделать лучше.

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

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

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

Заключительные мысли и вопрос к вам

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

Однако, если они неясны, я прошу вас оставить ответ на эту статью с другими вопросами, которые могут у вас возникнуть. Кроме того, дайте мне знать, как вы добились успеха во внедрении Scrum Framework в вашей организации.

Давайте начнем разговор и поможем распространить радость от Scrum!