Чому і з яких причин розробникам може не подобатися "щоденна скрам"? [зачинено]

Існують переваги у щоденному проведенні скраму, наприклад:

1. Команда координується між собою
2. Всім відомо, яка кількість завдань виконана
3. Діаграма Берндоун стає все більш повною
4. Дошка завдань оновлюється
5. Це триває не так багато, 15 хвилин нікого не вб'ють

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

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

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

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

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

Я впевнений, що буде багато любителів СКРУМУ, які скажуть "Але це так чудово" - ну, збережіть, я все це чув.

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

• Інформація, якою ви ділитесь, ніколи не стосується мене і не впливає на неї.
• Відсутність власності команди та кожного, хто завжди працює над власними проектами.
• Відсутність командної комунікації поза стадіоном.
• Відсутність видимого або повідомленого прогресу.
• Відсутність інформації для обміну.

Це просто з моєї голови, але завжди можливі причини.

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

Деякі проблеми, з якими стикаються щоденні засідання SCRUM:

• ті, які тривають занадто довго. Ви не хочете, щоб будь-який хлопець-менеджер в цих щодня, тому що вони є першопричиною подібних проблем. Подивіться, як вони зазвичай будуть тими, хто використовує стілець (так, потрібно встати на них - це спокушати людей бути швидкими)
• доводиться чути про когось (або 2 або 3 диявола), що описує якусь окрему проблему, яку він має, натомість замість нього вирішує запланувати іншу реальну зустріч пізніше, щоб обговорити її із зацікавленими особами
• дурні години. Ці зустрічі не повинні бути вранці: ви не говорите про те, що зробили вчора, і вирішуєте, що будете робити сьогодні; ви говорите про те, що робили між останнім щоденним і цим, і вирішуєте, що будете робити до наступного.
• відсутність власності на додаток для розробників. SCRUM працює, якщо розробки не вважаються кодованими мавпами. Перша ознака того, що процес піде не так - це коли чорти не ті, що оцінюють, скільки часу знадобиться зробити.
• знову тупі години. Якщо частина команди почала працювати над деякими речами і перебуває «в зоні», коли щодня трапляється, це набридає. Хороший час проводити таких щодня - це коли ніхто не повинен працювати (наприклад, після обіду або перед тим, як розпочати якісь дискусії під час обіду).

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

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

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

Наприклад, команді призначено робити ряд коротких виправлень помилок на різних проектах. Вони насправді працюють не як команда, а як особи. Однак, оскільки політика компанії / департаменту покладає на це обов'язки, керівник / керівник команди в будь-якому разі проводить щоденні зустрічі з обговореннями. Все, що було досягнуто, - це забирати 15+ хвилин на марну зустріч і дотримуватися 15-30 хвилин розгубленості та недостатньої продуктивності до та після зустрічі.

Тепер я бачив, як у Scrum було зроблено добре проект, який мав жорсткі терміни і вимагав великої координації між людьми, які працюють над різними творами. У цьому контексті це була чудова система. Але в контексті "Ми маємо зустріч, тому що ми мандруємо / спритний магазин, і це, що ми, мабуть, зробити" може насправді відмовити.

Переконайтесь, що ніхто не монополізує зустріч.

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

Відставте мить і подумайте про свою команду:

• Чи працюють вони ефективно?
• Чи вчасно виконані завдання?
• Чи надійний і добре написаний код?
• Чи гарантує команда, що через щілини нічого не потрапить?
• Чи координує команда сама себе, щоб вони не повторювали роботу і не ступали один на одного?

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

Чи відбулося зниження продуктивності після припинення щоденних вилазок, або все тикає так само, як і раніше? Якщо нічого не змінилося, навіщо продовжувати зустрічі?

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

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

Я б запропонував, якщо ви проведете ретроспективну зустріч, щоб побачити "Що вдалося" та "Що не пішло добре" і побачити, чи розробники перераховують щоденну зустріч stand-up як марна трата часу. Тоді вам доведеться трохи переорганізувати це.

Мій особистий досвід:

• Мета - знати, що ми робимо сьогодні і де ми були вчора. Замість того, щоб дотримуватися порядку денного, він впадає в технічну дискусію щодо блокаторів між двома особами, а іншим 15 набридає. Визначте проблему, але обговоріть зовні
• Люди не входять в зал засідань вчасно, і це стає циклом, який деякі роблять навмисно. Тож Майстру Scrum потрібно проводити тиху дискусію з ними поза зустріччю, щоб переконатися, що вони розпочалися і закінчуються вчасно.
• Ми вже оновлюємо діаграми виходу за межі зустрічі Scrum, так що це не є основною метою щоденного резервного огляду.

Опір виникає, коли: 1) Вони використовуються для того, щоб змусити людей кидатися в 9 ранку. Це додатковий стрес, коли поїзд спізнюється. 2) Погане керівництво скандалом. Лідер повинен говорити людям знімати речі, а не стояти навколо, слухаючи щось, що на них не впливає. 3) Безцінний зміст. Це знову проблематичне керівництво. Він повинен бути форумом для вирішення вузьких місць, проблем з траєкторією та потенційної співпраці. Що насправді трапляється, кожен каже лише те, що очікує, що працюватиме в цей день, що нікому не корисно і не цікавить. 4) Стоячи. Я не витримаю стоячи. Логіка стояння полягала в тому, що вона спонукає людей бути короткими. Люди насправді просто брязкають незалежно.

Я багато разів керував і був частиною команд scrum. Основна причина, яка розробникам не подобається scrum:

• Оскільки ними керує дуже бідний майстер scrum, якщо він перетвориться на 45 хвилин, ваш майстер scrum повинен покращитись у контролі над scrum.
• Найбільша і на сьогодні найчесніша причина, чому їм це не подобається, полягає в тому, що дуже важко сховатися в поганій робочій етиці. Деяких дияволів, з якими я працював, шокують, вони займають дні, виконуючи завдання, які мають бути 30-хвилинними. Хороший прем'єр-міністр повинен усунути бар'єри для чортів, а це означає, що вони повинні мати можливість орати свої завдання в спринті. Девам це не подобається, бо їм доводиться вставати кожен день і демонструвати прогрес, який вони досягли. Це викликає занепокоєння, коли вони не можуть демонструвати прогрес з будь-якої причини. Якщо це пов’язано з дійсною проблемою, хороший майстер розробки повинен вирішити цю проблему якнайшвидше.

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

Відверто кажучи, у 99% щоденних зустрічей з обговореннями, на які я ходив, майже всі дискусії / питання / відповіді могли бути усунені за допомогою декількох електронних листів.

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

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

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

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

• Фокус - програмне забезпечення проти зустрічей
• Менеджмент - менеджери потребують вимірювання
• Особистість - Інтроверти проти Екстравертів
• Час - переривання, час Maker та Manager
• Цілі, пріоритети

Кожен з цих факторів пояснюється нижче,

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

Розробникам потрібно уникати відволікань, і багато хто вважає, що є переваги кодувати пізно ввечері (вони уникають шуму, телефонних дзвінків, зайнятого офісу та не перешкоджають роботі колег, які не розробники). А коли ви працювали до 10, 11 чи 12 вечора, нерозумно прийти на роботу пізніше (10, 11, полудень?). Чи розумно очікувати, що розробники працюватимуть з 9 ранку до півночі?

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

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

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

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

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

Пол Грехем має чудову статтю про Maker Time vs. Manager Time, яка пояснює цю проблему набагато краще, ніж я. Досить сказати, що переривання наради, заплановане чи заплановане може порушити потік, і примусити розробника з Maker time на час менеджера. Повірте, ви хочете розробників на час Maker.

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

Яка мета? Створювати програмне забезпечення, яке відповідає потребам, швидко та якісно, ​​а обмеження (якість, час, вартість, процес). Scrum та інші гнучкі методології визнають обмеження процесу та намагаються мінімізувати цей фактор, і були успішними, оскільки вони мінімізують це обмеження. Але додавання зустрічей коштує часу, а переривання коштує розробнику набагато більше, ніж тривалість зустрічі.

Змініть зустріч, щоб переконатися, що вона приносить переваги:

1. Сплануйте його на час, який пропонує певну зручність. Чому не може пройти 30 хвилин після початку роботи, щоб кожен міг переглянути електронну пошту та організувати свої думки на зустріч. Стислість займає планування. Непідготовлений може розігнатися назавжди.
2. Визначте проблеми, яких можна було б уникнути, якби питання було повідомлено під час зустрічі. Кожен повинен зрозуміти, у чому сенс.
3. Зробіть все, що потрібно, щоб мінімум вкладу всіх. Це не місце для дебатів. Запропонуйте людям приватно розкладати зустрічі поза щоденними зустрічами, присвячені темі, яка потребує обговорення. Правило: одночасно розмовляє лише одна людина.

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