Чи повинні ми документувати зустрічі зі стендами?

Інша команда моєї компанії починає документувати свої засідання, але я вважаю це марною витратою часу. Наскільки я знаю, зустрічі, що проводяться, є для спілкування, а не для звітування про стан (будь ласка, виправте мене, якщо я помиляюся)

Отже, чи слід документувати засідання?

Однією з переваг Agile є те, що кожна команда може визначити, що для них найкраще працює, і піти з цим.

Однак: чи слід робити замітки? Ні; з мого досвіду, коли команда вирішить почати відслідковувати деякі основні принципи, такі як:

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

тоді ця команда почне віддалятися від Agile та спрямовуватись на більш важкий для документації підхід та низьку швидкість роботи.

У творі Мартіна Фаулера "Це не просто стоячи" є нарядні згадки про прийняття записів або документування "хвилин" засідання. Все, що вам слід взяти з цієї зустрічі, - це ПОДАРУНКИ:

• Щоб добре почати день
• Для підтримки вдосконалення
• Щоб посилити фокус на правильних речах
• Щоб посилити почуття команди
• Повідомляти про те, що відбувається

Як мнемічний пристрій, подумайте про ПОДАРУНКИ: Хороший старт, удосконалення, фокус, команда, статус

Однак , якщо у когось є блокатор, який вам потрібно допомогти йому чи її працювати, і ви зробите помітку про те, що вони говорять, це зовсім інше. - вибити себе з цього.

В якості орієнтиру я є власником продукту і зараз наставляю ScrumMaster в моїй компанії, і з усіх Agile зустрічей у нас (скрут, планування спринту, огляд спринту, ретроспектива спринту), єдиний з якого ми приймаємо офіційний Хвилини - це ретроспектива, тому що це дає команді щось конкретне для того, щоб працювати і посилатися на наступний спринт (а ці "хвилини" - це пара наборів коротких куль).

Ваш скам повинен бути:

• Над чим я працював
• Над чим я працюю далі
• Будь-які блокатори

Це воно. Швидко і до речі. 5-10 хв макс. Абсолютно не потрібно документувати, але якщо комусь потрібно щось записати на дію, це не повинно бути проблемою.

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

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

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

Ставтесь до стенд-апасу як до випадкової зустрічі - не сподіваючись, що заяви є формальними, завершальними тощо, що змусить людей рідше ставити теми, які їм ще не зручні, - але просто розумійте, що все важливе повинно мати дискусію продовжуйте десь ще, навіть якщо це просто простий електронний лист до команди. Окрім того, щоб допомогти не перетворити standup на повноцінну зустріч проекту, це також дозволяє уникнути виключення тих, хто не зміг би перейти до певного складу.

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

Якщо щось із особливих уваги заслуговує уваги на засіданні, то ви повинні документувати саме це і транслювати це окремо, але я не впадав би в звичку документувати кожну зустріч щодня.

На це немає (майже не може бути) абсолютної відповіді - це дуже багато чого - це залежить ...

Прагматично, якщо ви робите "що я робив, що я збираюся робити, ось мої питання", то для деяких (тих, хто за фахом відповідальний) цілком може бути заслуга, записавши це, щоб ви могли перевірити вона на наступній зустрічі (хоча "робота над" також повинна бути очевидною іншими способами) - але не особливо за її межами, тобто інформацією, яка повинна перестати мати значення після завершення наступної зустрічі.

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

Хоча формальні хвилини? Я б подумав, що це суперечить духу речі.

У моїй теперішній компанії ми маємо 2 команди Scrum з окремими складовими і документуємо їх, надсилаючи короткий електронний лист в кінці кожної програми. Це працює досить добре, і важливу інформацію негайно знають усі члени іншої команди. Ми особливо не зберігаємо історію електронних листів для архівних цілей.

Тож моя порада буде:

• Для однієї команди документування стендів може не коштувати витраченого часу. Майстер Scrum може просто передати усні сповіщення або важливу інформацію, кому згодом вважає за потрібне.

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

Я не бачу жодної проблеми відходити від такої зустрічі та відправляти групу електронним листом як нагадування / уточнювач про важливі рішення, які були прийняті або дії, що виникли. Зрештою, ви не хочете ризикувати забути чи дати часу згасати пам'яті про те, що обговорювалося.

Що ж стосується формального документування зустрічі, як це можна зробити для більш традиційної зустрічі ... ну, це здається контрінтуїтивним. Такі зустрічі повинні бути худорлявими та спритними, тому замикання їх занадто великим «процесом» видається контрпродуктивним.

Чи додає це значення? Люди згодом переглядають документацію зустрічей? Якщо ні, то це просто марна трата часу. І я серйозно сумніваюся, що вони є. Написання документа, який ніхто не читає, - це марна трата часу.

У якийсь момент ми фактично документували та архівували зміни статусу в нашій щоденній розбитці, тобто хто працював над тим, яке завдання, хто виконував експертну перевірку тощо. Це було зроблено лише тому, що хтось вважав це необхідним для того, щоб відповідати вимогам вимога простеження від системної вимоги до коду, оскільки ми розробляли програмне забезпечення для медичних пристроїв.

Пізніше нам вдалося переконати керівництво, що це насправді не так, і практика була покинута з великою радістю для відповідальних за цю документацію.

Так .

Чи приймаєте ви рішення щодо (а) відповідальності за предмет роботи та / або (б) важливості предмета роботи стосовно інших предметів?

Якщо ви є, запишіть ці рішення. Інакше ви будете повторно їх переробляти, і рішення так само, як і вони, нескінченно.

Якщо ви цього не робите, не проводите зустрічей.