Главная Новости

Совет по прямой трансляции, если вам нужна информация Канбана?


Опубликовано: 05.10.2023

Статья взята с сайта http://scrum.sk/index.php/produktivne_anovanie/

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

Меня в них заинтересовало следующее:

  1. Эффективность планирования не зависит от продолжительности использования гибкого приложения.
  2. Команды без обратной связи впадают в стереотипы и только применяют процессы.
  3. Команды сосредотачиваются на упрощении работы (поймите, они ленивы) и совершенно забывают причины, по которым она запланирована.
  4. В результате не получается план, понятный всем.
  5. План — это не командный план, а индивидуальный план.
  6. Непонимание, когда и как применять сюжетные очки и когда часы.
  7. Непонимание, зачем оценивать время.
  8. Несмотря на планирование, спринты по-прежнему не завершаются вовремя, и команда по-прежнему не чувствует ответственности.

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

И результат? Разочарование руководства неясными сроками поставки, приводящее к постоянным изменениям приоритетов. Это, естественно, расстраивает как клиента, так и команду. Более того, это способствует невозможности планирования именно из-за частых изменений. И в мире существует порочный круг. Планирование — это болезненное разочарование, и именно поэтому мы хотим избавиться от него.Боже мой, за эти 4 часа можно запрограммировать столько всего.

Правда дедов

Один из моих первых менеджеров научил меня практическому правилу. Проще говоря, нельзя просто рубить деревья. Даже дровосеку приходится остановиться, выбрать правильное направление, рвать деревья и затачивать топор. Только потом срубайте деревья, чтобы оно царило и на следующий день. Как там в ИТ? (Лучше?) Разработчик хочет развиваться. Все остальное - балласт. Топор точат лишь изредка.

Ну, есть чем топор точить...

Правда старых аджилистов

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

Цель планирования – планировать, а не строить планы.

Так:

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

Повестка дня

Часто замечаемая ошибка – полное отсутствие повестки дня заседания. Неподготовленность с точки зрения организации времени, процедуры, помещения и необходимого материала. Команда просто пришла к плану и дала себе волю. В таких случаях чаще всего можно будет услышать вопрос «А когда мы вообще обедаем?» Да, это чаще всего первый вопрос.

Итак, что же нужно для планирования? Вот некоторые наблюдения.

Время

Ожидайте продолжительность около 2-4 часов в зависимости от готовности бэклога. Это долго? Лучше посидеть два часа и договориться, чем несколько дней в растерянности искать решение...

Готовность

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

Хороший владелец продукта придет к планированию с готовыми требованиями и приоритетами. С расчетной стоимостью бизнеса, риском и MoSCoW. С критериями приемки. В той форме, которую команда считает готовой (определение готовности).

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

В этом случае 10 человек точно закончат планирование спринта за 2 часа. Вы заметили дисциплину в подготовке?

Карты

Вам понадобятся карточки, карточки, карточки. И еще раз карты. Забудьте о ноутбуках. Планирование должно быть командным усилием (манифестом).

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

Как насчет одного ноутбука и проектора?Продуктивность. Все сидят вокруг стола, сложив руки и, в лучшем случае, глядя в стену. Обычно они играют с телефоном под столом. Поэтому продуктивно.

Хм, ноутбук

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

Определение готово

Также принесите свое определение. Готово. В помощь вам в качестве шаблона для написания заданий. Вам может понадобиться несколько определений. Для пользовательских историй или ошибок.

Скорость и история

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

Емкость

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

Чтобы вы могли проверить, не запланировали ли вы случайно слишком много работы на спринт, которую у вас нет возможности выполнить.

А результат планирования?

Хорошее планирование приводит к:

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

Чувства зачастую вернее любых математических расчетов…

Удачи в планировании следующих спринтов, которые вам удастся завершить.

rss