Щоденні ставки - так чи ні? [зачинено]

Наскільки цінними (чи ні), на вашу думку, є щоденні зустрічі з stand-up ?

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

На зустрічі ви обходите кімнату і кожен говорите: - Що ви робили вчора - Що плануєте сьогодні зробити - Будь-які блокатори чи перешкоди вашому прогресу.

Як ви вважаєте, ця практика має цінність? Хтось працював у місці, яке це робило, і що ви думали?

У нас на щоденній роботі були щоденні результати. Що ж, з усіма кооперативами / інтернами / темпами, це було насправді на довгій стороні - як правило, приблизно 30 хвилин.

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

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

Я вважаю ці зустрічі дуже цінними. Вони пропонують такі переваги - взамін витратити всього 15 хвилин!

• Тримає всіх за темою . Легко зануритися у власні проблеми та забути про те, що роблять інші, або повторити роботу, яку виконує хтось інший. Щоденні зустрічі запобігають цьому.
• Не дозволяє людям ковзати . На цих зустрічах ви даєте обіцянки. Тоді ви просто повинні спробувати зберегти їх.
• Змушує людей взаємодіяти . Зазвичай програмісти не люблять спілкуватися з людьми. Однак на таких зустрічах вони отримують заохочення (і догани) від своїх колег, що позитивно впливає на мораль.
• Збирає всіх на одному місці . Ви отримуєте бонус, знаючи, що всі прийдуть туди. Це можна використовувати для організації інших зустрічей, оголошення оголошень та продовження цієї щоденної зустрічі в менших групах для обговорення конкретних проблем. Зазвичай організація таких зустрічей займає багато уваги і вимагає навичок, якими програмісти не люблять користуватися.

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

Але ей, якщо вставання дає змогу повторно брендувати щось як спритне, це повинно бути добре!

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

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

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

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

Але витрачаючи чверть години щодня просто для того, щоб ви могли відчувати себе спритними та чудовими та іншим? Марна трата часу.

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

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

2. Неспрямована спеціальна зустріч: хтось (зазвичай менеджер, прем'єр-міністр або хтось із бізнесу) приходить і зіштовхує його з путівки. Може, ми говоримо про пожежу сьогодні докладно, або про те, як хтось занепокоєний, якщо ми збираємось дотриматись терміну тощо. 15 хвилин перетворюються на півгодини чи довше. Усі стоять, хоча ми справді повинні сидіти, якщо це буде так довго.

Крім того, "стенд-ап" частина стенд-апів не допомагає затримати зустрічі, вона просто додає фізичного дискомфорту суміші.

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

Я думаю, що вони дуже цінні, якщо виконуються правильно. Формат, який добре працював для мене, це такий ..

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

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

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

Я не вважаю їх корисними, як це практикують на моєму робочому місці, де "Щоденний 15-хвилинний режим" тягнувся до 30, потім 45, а зараз часто 60 хвилин; де всі сідають, чекаючи, коли керівник проекту поспілкується з проектором, або мережевою часткою, або ще чим завгодно випадковим демоном дня; де він наполягає на тому, щоб кожен мав час надати оновлення статусу до зустрічі, але потім знову запитує всіх (про всяк випадок, якщо ми останні кілька моментів зробили щось інше); Єдина частина оригінальної концепції, яка залишається, - це "Щодня".

Не робіть цього.

Це може бути корисно, але часто це не на практиці.

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

На практиці це іноді спонукає людей не обговорювати питання одразу, і це може стати значним смоктанням часу. Наприклад:

Якщо я перебуваю лише на одному активному проекті розвитку (як правило, я на двох), як правило, принаймні один закінчує контроль якості та один розкручується одночасно. Це три тривалість 15 хвилин на день. Шахта майже ніколи не повертається назад. Ви втрачаєте деякий час, переконуючись, що перебуваєте на зупинці перед кожною з них, і аналогічно повертаєтесь назад за кожним. Навіть якщо ви припускаєте, що ці втрати становлять один 10 хв кожний, що означає більш ніж цілий робочий день, що втрачається на очікування кожного тижня.

Додайте до зустрічей та демонстрацій комітетів, і це легко з'їсть цілий додатковий день.

ІМХО, якщо у вашої команди виникають проблеми із спілкуванням, то щоденні зустрічі можуть допомогти, але робити їх інакше - просто занадто велика кількість ресурсів.

Задовго до того, як SCRUM і Agile коли-небудь замислювалися, я був керівником команди дослідження кадрового потенціалу, що займало 2 роки. Минуло б набагато довше без щоденних зустрічей. По-перше, люди, будучи людськими істотами, вони відхиляться, якщо знають, що ніхто не звертає уваги. Якщо їм доводиться щодня демонструвати прогрес, вони зменшуються менше. Якщо Джо, здається, досягає більшого прогресу, ніж вони, вони менше відхиляються. Крім того, він дає можливість керівникові (або кому завгодно) знати, коли виникають проблеми до того, як вони перейдуть у кризу. Отже, якщо Стів запізниться на тиждень, а Гаррі попереду, ми можемо перенести деякі завдання. Це не дає проекту відстати, бо одна людина застрягла. Крім того, зазвичай хтось інший зможе допомогти людині відклеїтись.

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

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

Так чи ні, і чи вони цінні - це два різних питання. Відповіді також можуть бути різними. У випадку останнього питання відповідь може залежати від точки зору.

Перше питання, так чи ні? Це так . З точки зору Scrum або XP, резервна робота є важливою діяльністю. Якщо у вас немає щоденних scrums, то це насправді не Scrum, це називається "scrum, але ми не робимо щоденних резервів" або scrumbut коротко. якщо ви хочете включити перспективу Kanban, більшість команд Kanban роблять складові, навіть якщо їх метод не прописує їх.

2-е питання, (наскільки вони цінні), є складнішим. Якщо ви практикуєте Scrum або XP, ви повинні вважати, що складові необхідні для сприяння співпраці, роботі в команді та зробіть свою команду більш ефективною. Тож відповідь, безумовно, цінна .

Точка перспективних прихильників дуже різна . Надзвичайно худорлявий погляд на те, що ваш клієнт не байдуже, якщо ви займаєтеся складом, тож вони просто відходи. Що ти з відходами? Ви скоротили його до мінімуму, в ідеалі до нуля.

Більш помірний погляд на те, що хоч і не зовсім відходи, щоденні зміни - це ціна координації, а не діяльність із доданою вартістю . Ви можете зіграти адвоката диявола зі своїми колегами по Scrum і запитати їх: якщо ви вважаєте, що ваші 15-хвилинні стадії - це діяльність з доданою вартістю, чому б вам не робити щодня 30 хвилин або 45 хвилин і легко збільшити додану вартість?

Канбан, який має худорляве коріння, але має на меті досягти принципів Agile Manifesto, вирішує цей парадокс, проводячи стендапи, але використовуючи зовсім іншу структуру зустрічей, ніж традиційний спритний формат standup. Результат - набагато коротша зустріч, яка вирівнюється з точки зору худорлявої точки зору. У цій книзі є приклад, коли команда Kanban, що вміщує 50 осіб, проводить щоденні стадії за 10 хвилин .

Підводячи підсумок, робити чи ні щодня робити відповіді, відповідь є певним так . Але чи вони цінні, наскільки цінні - це залежить .

Найбільш корисним типом standup є тип Kanban.

1. Вам знадобиться дошка завдань, яка відображає ваш реальний потік роботи / значення. Ця панель завдань є центром фокусного огляду.
2. Зосередьтеся на робочих предметах, а не на людях
   • Зосередьтеся більше на тому, які робочі предмети ви, як команда, можете закінчити (на основі дошки завдань), ніж те, що ви можете починати
   • Зосередьтеся на вирішенні завдань, на яких показує рада - вузькі місця, блоки тощо

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

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

Наскільки цінними (чи ні), на вашу думку, є щоденні зустрічі з stand-up?

Виключити всі засідання Рамкової програми є важливими, але я вважаю, що щоденна зустріч standup є "найважливішою" зустріччю в Scrum Framework. Це як серце в тілі. Якщо серце не перекачує кров регулярно, то організм повинен померти, в цьому випадку тіло - це Організація або Проект, що слідує за суперечкою, і серце - це зустріч scrum.

Як ви вважаєте, ця практика має цінність? Так.Daily Scrums покращують комунікацію, усувають інші зустрічі, виявляють та усувають перешкоди для розвитку, підкреслюють та сприяють швидкому прийняттю рішень та покращують рівень усіх знань про проекти. Daily Scrum - це не зустріч із статусом. Щоденний Scrum - це інспекція прогресу до досягнення цілі спринту (три питання). Наступні зустрічі, як правило, відбуваються для адаптації до майбутньої роботи у спринті. Наміром є оптимізація ймовірності того, що Команда досягне своєї мети. Це ключова перевірка та адаптація зустрічі в емпіричному процесі Scrum.

Хтось працював у місці, яке це робило, і що ви думали?

Так, у моєму останньому проекті ми дотримувались принципів Scrum Framework та Agile. Ми взагалі дуже серйозно ставилися до Рамок Scrum, і не робили цього наполовину. Спочатку я був у команді 5-ти, потім я перейшов у більшу команду, яка складала близько 9, а потім знову до 6-ї, розповсюдженої на 4-річний термін. Щоденна зустріч з обговореннями гарантувала, що всі синхронізуються, перешкоди були прозорими, і ми, як Команда, могли бачити, як Команда прогресує з вигоранням перед нами, і ми точно знали, хто над чим працює і де ми можемо зробити свій внесок себе. Це, безумовно, простіше зробити, коли у вас є команди 6 або менше. Мета мітингу - провести перевірку самоінспекції, і якщо якась річ виявиться не в напрямку до мети або якщо щось заблоковано, самоорганізована команда адаптується,

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

Швидше є щотижневики.

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

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

Щоденний звіт про стан в кінці кожного дня перед тим, як піти додому, має однаковий ефект.

Для мене це було ефективно в командах з 3 та 5 осіб, і я бачив, що він ефективно використовувався для команди планувальників подій, в якій було близько 20 осіб. Ви повинні тримати його коротко, ви повинні тримати його в русі. Це добре, якщо ви сидите, але не повинно бути зайвих речей (роздатковий матеріал, дошка, відео тощо)

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

Де ми є маркетинговою командою, нас почали копіювати, і тепер ми також маємо стенд-ап - так це не тільки для розробників!

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

Зустрічі повинні бути короткими, у нас зазвичай відбувалися зустрічі за 10 хвилин із 7 членами команди. Це допомагає планувати їх безпосередньо перед перервою на десять годин. Крім того, ми не використовуємо технологію на зустрічах, а лише дошку скрабів із завданнями та деякими графіками.

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

З негативного боку, ці зустрічі (щодня: що ти робив? Що ти збираєшся робити? Що у тебе на шляху?) Відштовхують те, що ми можемо назвати "google-time", або працювати / вчитися на побічному проекті, який не має негайний вплив на бізнес, але може мати суттєвий вплив вниз.

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