Должны ли мы документировать постоянные встречи?

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

Итак, должны ли мы задокументировать встречи?

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

Тем не менее: вы должны делать заметки? Нет; По моему опыту, в ту минуту, когда команда решает вернуться к некоторым из основных принципов, таких как:

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

затем эта команда начнет отходить от Agile к более трудоемкому и низкоскоростному подходу к работе.

В книге Мартина Фаулера «Это не просто вставать» нет упоминания о том, чтобы делать заметки или документировать «протоколы» стоячей встречи. Все, что вы должны забрать с этой встречи - ПОДАРКИ:

• Чтобы помочь начать день хорошо
• Поддерживать улучшение
• Чтобы усилить внимание на правильные вещи
• Чтобы укрепить чувство команды
• Чтобы сообщить, что происходит

Как мнемоническое устройство, подумайте о ПОДАРКАХ: хорошее начало, улучшение, фокус, команда, статус

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

Для справки, я владелец продукта и сейчас наставник ScrumMaster в моей компании, и из всех проводимых нами Agile встреч (scrum, планирование спринта, обзор спринта, ретроспектива спринта), единственное, которое мы принимаем официально Минуты - это ретроспектива, потому что это дает команде что-то конкретное, к чему можно стремиться и на что нужно ссылаться в следующем спринте (а эти «минуты» - это пара наборов коротких маркеров).

Ваша схватка должна быть:

• Над чем я работал
• Над чем я работаю дальше
• Любые блокаторы

Вот и все. Быстро и точно. 5-10 минут макс. Абсолютно не нужно документировать, но если кому-то нужно записать что-то в действие, это не должно быть проблемой.

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

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

Я думаю, что документооборотные встречи - это разумно, если вы абсолютно уверены в важности контента и только если вы можете сказать, что это поможет вашей команде в ближайшем или отдаленном будущем.

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

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

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

Нет (почти не может быть) абсолютного ответа на это - очень много, это зависит ...

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

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

Формальные минуты хотя? Я бы подумал, что это противоречит духу вещи.

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

Так что мой совет будет:

• Для одиночной команды документирование стендов может не стоить потраченного времени. Scrum Master может просто передавать оповещения или важную информацию в устной форме, кому он посчитает нужным впоследствии.

• Для нескольких команд, чья работа тесно связана, документирование стоянок - это способ передавать потенциально изменяющую игру информацию сразу после встречи, не дожидаясь Scrum of Scrums.

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

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

Это добавляет ценность? Люди позже смотрят на документацию встреч? Если нет, то это просто пустая трата времени. И я серьезно сомневаюсь, что они есть. Написание документа, который никто не читает, - пустая трата времени.

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

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

Да .

Принимаете ли вы решения о том, (а) кто отвечает за рабочий элемент и / или (б) важность рабочего элемента по сравнению с другими элементами?

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

Если нет, не проводите собрания.