Перевод статьи Лукаса Ф. Косты "Why your daily stand-ups don't work and how to fix them" с моими небольшими комментариями и дополнениями.
Ежедневные стендапы (daily scrum) – классический пример выученной беспомощности. Мы все знаем, что они бесполезны, но мы говорим себе «так уж обстоят дела» и ничего с этим не делаем.
В наши дни мы проводим стендапы, потому что нам так говорят, а не потому, что они решают какие-то конкретные проблемы.
Индустрия разработки софта проводит ежедневные стендапы так долго, что уже и не помнит, для чего они нужны. В какой-то момент стендапы превратились из решения в бессмысленный догматический ритуал.
Например фреймворк Scrum прямо запрещает отказываться от дейли встреч.
В руководстве по Скраму прямо написано – можно что-то добавить своё, но убирать ничего нельзя. В принципе это правильно, создатели этого фреймворка последовательно, от версии к версии работают над сокращением основы Скрам подхода, оставляя только самые необходимые, проверенные практикой части – essential parts, без которых подход совершенно точно «не поедет». И чем более компактным становится официальное руководство, тем большее значение приобретает каждая фраза в нем, каждый артефакт и событие. И соответственно тем важнее понимание смысла этих артефактов и целей имеющихся в Скраме церемоний.
Вот симптомы, указывающие на то, что вы проводите стендапы неправильно, и искажаете их смысл:
Стендапы занимают более 15 минут
Люди говорят о своей работе, а не о целях
Люди перестают регулярно приходить на стендапы
Члены команды разговаривают со своим менеджером (или скрам-мастером), а не с коллегами.
Если менеджер или скрам-мастер не может прийти, стендап не проводится.
И еще кое-что:
Я бы добавил еще один подпункт:4.1. 50% и более времени встречи говорит менеджер или скрам-мастер – довольно распространённая ситуация в "иерархических" скрам командах управляемых в ручном режиме
Если в вашей команде присутствуют три или более из этих симптомов, диагноз ясен: ваши стендапы бесполезны.
В этом посте я объясню реальную цель стендапа и почему это продуктивная встреча, если проводить ее правильно. Кроме того, я объясню, что означает «правильно» и нюансы, связанные с адаптацией стендапа в соответствии с вашими потребностями. Как обычно в индустрии разработки ПО, не существует такого понятия, как «один размер подходит всем».
Как мы тут оказались?
Как и в случае с каждым отдельным принципом Agile-манифеста, мы превратили набор принципов в набор предписывающих правил. Мы забыли, что «нашим наивысшим приоритетом является удовлетворение клиента за счет максимальной быстрой и непрерывной поставки программного обеспечения, несущего в себе какую-то ценность», и начали думать, что быть гибким (agile) означает принятие жестких рамок, таких как Scrum и экстремальное программирование. Мы превратили наши средства в цели.
Почему мы это сделали? Мы сделали это, потому что легче слепо следовать набору правил, чем понять принципы, лежащие в основе, и настроить их для достижения своей цели.
Ежедневный стендап – пожалуй, лучший пример решения, когда твердые принципы превратились в бессмысленную догму. На самом деле, с ежедневными стендапами у нас дела обстоят еще хуже – мы неправильно поняли догму!
Вот что Scrum.org говорит о цели ежедневного стендапа:
Как описано в Руководстве по Скраму, цель Daily Scrum — инспекция прогресса в достижении Цели Спринта, адаптация Бэклога Спринта по мере необходимости, корректировка запланированной предстоящей работы.
Разработчики могут выбирать любую структуру и техники, которые сочтут нужными, при условии, что их ежедневный Скрам фокусируется на прогрессе в достижении Цели Спринта и создает план действий на следующий рабочий день. Это обеспечивает сфокусированность и улучшает самоуправление.
Теперь подумайте о своих ежедневных стендапах:
Вы когда-нибудь корректируете бэклог или цель спринта из-за них или просто говорите людям «работать усерднее», чтобы вам не пришлось менять план?
Вы фокусируетесь на прогрессе в достижении цели спринта или на занятости людей?
Создаете ли вы действенный план реагирования на новую информацию?
Стимулируют ли эти стендапы команды к сотрудничеству и самоуправлению или же они прививают бюрократическую культуру страха?
Что произошло со стендапами, так это то, что мы сместили акцент с «довести дело до конца» на «убедиться в том, что люди работают».
Правда в том, что многие менеджеры превратили свой стендап в оружие, чтобы занять работой сотрудников. Менеджеры такого типа верят в занятость, а не в результативность. Это обычно приводит к тому, что они загружают свою команду на максимум, считая что это ускорит поставку продукта, но на самом деле это только замедляет их работу.
Классический пример стендапа как оружия против команды – это стендап в первую же минуту рабочего дня.
«У нас гибкий график работы», – говорят они. Конечно, но ровно в 8:30 состоится встреча, чтобы убедиться, что все уже на местах.
Чтобы исправить наши стендапы, мы должны изменить их назначение. Мы должны проводить эти встречи так, чтобы фокусироваться на наших целях, и корректировать эти цели по мере поступления новой информации.
Стендапы могут быть полезными: это отличный способ без лишних затрат создать каденцию (ритм). Когда каждый день в календаре у каждого члена команды есть фиксированное время, люди организуются вокруг него, сокращая накладные расходы на планирование встреч с занятыми коллегами.
Кроме того, когда система ежедневно выдает синхронную превентивную обратную связь, для выявления проблемы потребуется максимум один день.
Наконец, стендапы помогают различным функциям бизнеса согласовывать свои графики с целью, улучшают точность ваших метрик и стимулируют самоуправление.
Как заставить стендапы работать
Вот что я рекомендую сделать командам, чтобы улучшить свои стендапы:
Прекратите болтать. Пройдитесь по Канбан-доске.
В первую очередь решайте затянувшиеся проблемы.
Уделите основное внимание блокирующим факторам.
Пригласите всю команду, включая продакт-менеджеров и дизайнеров.
Сделайте подробные обсуждения асинхронными.
Стимулируйте самоуправление и создавайте атмосферу психологической безопасности.
За исключением последнего пункта, остальные я не считаю обязательными. Это рекомендации.
Теперь я объясню, почему каждая рекомендация обычно работает, и поделюсь некоторыми предостережениями.
1. Прекратите болтать. Пройдитесь по Канбан-доске
Что ты делал вчера? Что ты собираешься сегодня делать? Возможно, это худшие вопросы, которые можно задать во время стендапа.
"Как идут дела?" – тоже не очень хороший вопрос. Этот вопрос является воплощением стиля управления MBWA (Management By Walking Around), и столь же бесполезен.
Эти вопросы ничего не говорят о вашем прогрессе в достижении цели спринта. Вместо этого они создают культуру страха и побуждают сотрудников к бесполезной трате времени и занятием всякой ерундой, только чтобы доказать, что они очень заняты.
Работа с доской Канбан решает все эти проблемы. Это мотивирует людей быть краткими, потому что фокус на цели спринта, а не на чьей-то продуктивности. Вместо того, чтобы объяснять, что они делали, и все мельчайшие технические детали, инженеры сосредотачиваются на том, нужна ли им помощь и что они должны сделать, чтобы переместить конкретный элемент в правую часть доски: в колонку «Готово».
Кроме того, это стимулирует команду визуализировать и отслеживать работу, которая в противном случае осталась бы невидимой. Если появится критическая ошибка, люди добавят ее на доску, чтобы они могли попросить других о помощи и предупредить всех о том, что что-то происходит.
Еще одно преимущество использования Канбан-доски заключается в том, что она делает метрики более точными. В разработке программного обеспечения наши показатели обычно измеряются в «днях». Поэтому при ежедневном просмотре доски вы будете обновлять задачи не реже одного раза в день, предотвращая ситуацию «забыл переместить в выполненное».
Только будьте осторожны, чтобы не начать управлять исключительно метриками! Метрики помогают обнаруживать аномалии, но ничего не говорят о том, как исправить эти аномалии или почему они произошли, хотя могут дать полезную информацию.
2. Отдайте предпочтение решению давних затянувшихся проблем.
Найдите минутку, чтобы взглянуть на актуарную таблицу смертности в Соединенных Штатах. Как видите, по мере увеличения возраста численность населения этого возраста, очевидно, уменьшается. Чем дольше кто-то живет, тем больше он выделяется, потому что он пережил большее количество фатальных событий, которые могли произойти.
Точно так же, чем дольше живет проблема, тем больше она становится из ряда вон выходящей. Поэтому большего внимания она заслуживает.
Проблема, которая только что проявилась, не заслуживает такого внимания, потому что она все еще находится в пределах времени нашего цикла. Зачем нам тратить время на обсуждение того, что еще не стало проблемой? С другой стороны, проблемы, которые проявились давно, должны привлекать наше внимание. То, что они прожили так долго, должно означать, что в них есть что-то сложное по своей сути или есть один или несколько факторов, препятствующих разрешению проблемы.
Фокусируясь на затянувшихся проблемах, вы естественным образом перестанете тратить время на простые задачи и начнете вкладываться в решение сложных. Это не значит, что вы не должны говорить о проблемах, которые только что проявились. Это просто означает, что затянувшиеся проблемы должны вызывать тревогу.
После того, как проблема озвучена, команда должна обсудить нужно ли им уточнить требования, сократить объем работ или попросить кого-то предоставить часть информации, которой не хватает для выполнения задачи.
Также крайне важно, чтобы этот процесс был для всех прозрачным и нацеленным на решение проблем, а не поиск виноватых. Если определенные типы задач продолжают отнимать слишком много времени, команда должна обсудить, какие процессы или политики следует изменить, чтобы предотвратить повторение проблемы. Нагнетание страха во имя «ответственности» просто заставит людей скрывать то, что выставляет их в плохом свете.
СОВЕТ: JIRA и большинство других программ для управления проектами позволяют выделять проблемы старше определенного возраста. Воспользуйтесь этой функцией, чтобы сделать канбан-доску вашей стендапа более интуитивно понятной.
3. Сосредоточьтесь на блокирующих работу факторах
Фокус на блокерах имеет тот же эффект, что и фокус на затянувшихся проблемах. Он направляет инвестиции времени на важные вопросы.
Если проблема только проявилась, возможно разработчику не стоит сообщать о ней всем, если только это не блокер или есть вероятность скорого появления блокера.
После сообщения о блокерах команда должна обсудить, что они должны сделать, чтобы разблокировать задачу. Чем дольше задача остается заблокированной, тем больше становится среднее время цикла и менее предсказуемыми становятся команды. Помните: завершение начатого делает команду более продуктивной и предсказуемой.
По моему опыту, как только команды начинают сосредотачиваться на блокерах и затянувшихся проблемах, их апдейты статуса переходят от технической болтовни, например:
Я обнаружил сдвиг частоты нановолн в плазменном глюонном кристалле. Сегодня я переверну транспортер ионов и заменю торсионный новообразованный кожух. Интересно, есть ли временная аномалия в спинном кронштейне биполярного двигателя? Что все думают? [вставьте сюда длинное бессмысленное обсуждение]
к следующему виду:
Все идет хорошо. Никаких блокеров.
Насколько это лучше?
Когда вы сосредотачиваетесь на целях и препятствиях на пути к этим целям, каждый тратит меньше времени на доказательство своей продуктивности и больше времени на то, чтобы быть продуктивным.
4. Пригласите всю команду, включая продакт-менеджеров и дизайнеров
Людей, которых вы называете сейлами, продакт-менеджерами, дизайнерами и инженерами-программистами, я называю командой. Продукт представляет собой комбинацию всех этих функций. Поэтому, если вы хотите создать успешный продукт, вы должны вовлекать в работу все функции (роли).
Задачи блокируются не только сложными техническими проблемами. Их часто блокируют запутанные спецификации, пробелы в дизайне, неприемлемые бизнес-возможности.
Включение людей с разными ролями в ваши стендапы упрощает решение блокеров, зависящих от иных функций кроме собственно разработки ПО – а это происходит очень часто.
Если эти люди регулярно посещают ваши стендап-встречи, они могут внести свой вклад в устранение блокеров и даже могут сказать вам, когда конкретное требование из спеки не стоит реализовывать.
Предположим, вы обнаружили, что реализация определенной функции займет как минимум несколько дополнительных недель, например, из-за ее сложности. В этом случае эти люди могут обсудить, на какие компромиссы можно пойти чтобы обеспечить быструю поставку за небольшую часть стоимости без существенного влияния на вашу прибыль.
Кроме того, это помогает отделам продаж, маркетинга и дизайна скорректировать свои приоритеты в соответствии со скоростью работы команды разработчиков. «Мультифункциональные» стендапы помогают всем.
Обратите внимание: я не говорю, что все эти люди всегда должны присутствовать на каждом стендапе. Я просто говорю, что небольшие мультифункциональные команды, как правило, более гибкие, потому что эти стендапы сокращают цикл обратной связи между разными командами.
Не всем тоже нужно что-то говорить на встрече. Иногда просто слушать – огромное преимущество, особенно если вы следуете моему предыдущему совету, который сделает встречу короткой и, таким образом, снизит ее стоимость.
5. Переместите детальные обсуждения в асинхронный режим
Всякий раз, когда инженеры попадают в ловушку обсуждения глубоких технических вопросов, выносите эти обсуждения в асинхронный режим и включайте в последующее обсуждение только тех, кто заинтересован.
Если люди вынуждены слушать обсуждения неинтересных тем, которые не способствуют продвижению к цели команды, люди – обоснованно – перестанут приходить на стендапы (или начнут жаловаться на них, как мы сейчас).
Воспринимайте стендап встречу как время для выявления проблем, а не как время для их решения.
Ответственные команды являются самоорганизующимися, что означает - как только возникает проблема, они приступают к действиям, необходимым для ее решения, при условии что им понятен желаемый результат.
Если что-то можно решить прямо на месте, в идеале менее чем за три-четыре минуты – сделайте это. Стоимость планирования еще одной встречи и координации с разными людьми выше, чем использование времени команды на стендапе для решения проблемы. Если для решения нужно больше времени, то более затратно заставлять всех слушать обсуждение, не имеющее к ним отношения.
Обратите внимание, я не говорю, что вы должны исключать людей из этих обсуждений. На самом деле все совсем наоборот. Я просто говорю, что вы не должны предполагать, что все заинтересованы. Вместо этого вы должны предположить, что они не заинтересованы, но дать всем возможность принять участие в последующей встрече.
"Живое обсуждение" или асинхронный режим?
Последнее время в связи с глобальной популярностью удаленной работы и распределенных команд, вообще очень часто встречается совет перевести все коммуникации, которые возможно, в асинхронный режим. Что означает стараться уменьшать количество живых созвонов, по возможности обсуждения вести в почте/мессенджерах, активнее использовать разделяемые облачные сервисы. При необходимости живого обсуждения онлайн приглашать только заинтересованных лиц, остальные - опционально, заранее высылать нужную для обсужденния вводную информацию, повестку и т.п.
Логика в этом есть - чем меньше переключений контекста у разработчика, тем проще удерживать концентрацию на решении сложной проблемы, состояние "потока".
В интернета полно статье и комментариев от разработчиков, которые жалуются что на удаленке до 50% времени занимают бесполезные созвоны и митинги.
Но при всём этом, отказываться от ежедневных "живых" стендапов всё таки не стоит по причинам, описанным выше.
6. Стимулируйте самоуправление и создавайте атмосферу психологической безопасности
Этот последний совет является единственным, которому я считаю обязательным следовать.
Когда людей наказывают за выявление проблем, они перестают это делать. Следовательно, проблемы проявятся только тогда, когда они станут слишком критичными или почти неразрешимыми. Вместо этого вы должны стимулировать команду озвучивать проблемы, как только они появляются.
При раннем выявлении проблемы обычно легко решаются. Например, изменение проблемной спецификации обычно обходится намного дешевле, чем попытка исправить критическую ошибку в производственной среде.
В атмосфере психологической безопасности члены команды знают, что любые вопросы уместны. Вместо того, чтобы предполагать что они знают ответ и только усугубить проблему в будущем, они просто лишний раз спросят, понимая что за это не будет наказания.
Кроме того, я считаю, что психологическая безопасность является правом работника. Никто не заслуживает жить в страхе и беспокойстве из-за вещей, которых он не понимает, особенно учитывая, что в большинстве случаев это не его вина. Даже если это не так, это не имеет значения. Разработка продукта — это не про поиск виноватых. Обвинение других не поможет вам достичь ваших целей. Поиск ответов на вопросы и решение проблем – поможет.
Команды, которые чувствуют себя в психологической безопасности, являются более инновационными и продуктивными и, следовательно, способны к самоорганизации.
Психологическая безопасность помогает людям сосредоточиться на поставленной цели, что означает - они знают, что нужно делать, и будут искать решения, даже если их менеджер или скрам-мастер отсутствуют.
Лучшие архитектуры, требования и проекты создаются самоорганизующимися командами. — Agile-манифест
Собираем всё вместе
Ежедневные стендапы — классический пример выученной беспомощности. Мы все знаем, что они отстой. Тем не менее, мы ничего с этим не делаем. В наши дни мы проводим стендапы потому что нам так говорят, а не потому что они решают какие-то конкретные проблемы.
Стендапы сами по себе не являются пустой тратой времени. Они стали пустой тратой времени из-за того, как их проводит большинство команд.
Фокус на работе людей и использование занятости в качестве меры продуктивности сводит на нет преимущества стендап встреч. Наоборот, эти встречи должны быть короткими, лаконичными и фокусироваться на коллективной цели команды.
Если все сделано правильно, стендапы сокращают время, необходимое для получения обратной связи, уменьшают накладные расходы на коммуникацию и позволяют различным функциям согласовать свои приоритеты.
Для улучшения стендап встреч и достижения своих целей я рекомендую следующее:
Прекратите болтать и вместо этого пройдитесь по Канбан-доске.
Отдайте предпочтение решению затянувшихся проблем.
Уделите основное внимание блокирующим факторам.
Пригласите всю команду, включая продакт-менеджеров и дизайнеров.
Сделайте подробные обсуждения асинхронными.
Стимулируйте самоуправление и создавайте атмосферу психологической безопасности.
Комментарии (32)
terraplane
17.09.2022 08:17+16Скрам-мастера, стендаперы и прочие it-комики... Индустрия обросла
паразитамиэффективными управленцами.Идите работать. От перекладывания ручки по столу производительность не меняется.
nikolas78
17.09.2022 17:55+1Ну я бы не сказал, что организовывать работу разработчиков не надо совсем. Просто выглядит вот это вот всё конечно как оправдание собственной занятости.
v1000
17.09.2022 09:21+7По моему опыту, как только команды начинают сосредотачиваться на блокерах и затянувшихся проблемах, их апдейты статуса переходят от технической болтовни, например:
Я обнаружил сдвиг частоты нановолн в плазменном глюонном кристалле. Сегодня я переверну транспортер ионов и заменю торсионный новообразованный кожух. Интересно, есть ли временная аномалия в спинном кронштейне биполярного двигателя? Что все думают? [вставьте сюда длинное бессмысленное обсуждение]
к следующему виду:
Все идет хорошо. Никаких блокеров.
А потом вдруг выяснится, что сегодня будут проводиться регламентные работы на транспортере ионов, и когда его перевернут, из него все ионы высыпятся на пол.(сарказм)
Так что без длинного бессмысленного обсуждения, но статус работ иногда определять полезно.
SigSauer Автор
17.09.2022 16:27Никто не говорит что статус вообще не нужно детально обсуждать или описывать.
Здесь речь конкретно про дейлики - если нет блокировщиков, и нет какой-то важной информации по этой задаче для остальной команды, не смысла подробно описывать что вы там сделали и что собираетесь делать, команда от этого теряет бдительность и засыпает )
anton19286
17.09.2022 15:26-1почему вероятность смерти после 11 лет растёт так резко?
SigSauer Автор
17.09.2022 16:29Где вы это увидели? В таблице по ссылке нет резкого скачка вероятности после 11 лет
steelratty
17.09.2022 16:30+1Есть n работы. Введение скрама и прочих методик этого не уменьшает. Однако смещает ответственность менеджера к работникам, заставляя их работать более плотно, интенсивно, в режиме постоянного дедлайна (ну мне же надо это сделать до завтра, я же команду пожведуууу), что приводит к выгораниям, психозам и, в конечном итоге к текучке кадров.
SigSauer Автор
17.09.2022 16:40+3Скрам не задумывался как подход, предназначенный для уменьшения работы в общем случае.
Он предназначен для уменьшения лишней "неправильной" работы, когда конечный результат не ясен, промежуточные шаги не ясны и т.п. Вместо того чтобы пытаться изначально все планировать, Скрам предлагает идти мелкими шагами, после каждого шага пробуя что получилось и выясняя, туда ли мы движемся.
И да, в Скраме нет менеджера.
Если вы работаете в окружении что менеджер есть и он всю ответственность переложил на команду, Скрам тут не при чем.
Скрам-мастер запросто может быть один из разработчиков, PO (product owner - владелец продукта) формально тоже, хотя в реальности так бывает редко - человек с такими навыками, которые нужны хорошему РО, сам код не пишет, это нерационально.
Проблемы не в подходе Скрам/Канбан/водопад/whatever как таковом, а в неумелом управлении, неуместном или неправильном применении подхода, неправильном подборе команды и так далееsteelratty
17.09.2022 18:14+2Вся проблема не в том как задумывалось, а в том, как реализуется. Компания, внедряя любую методику ждёт результата - а ей нужно увеличение производительности. Компания не будет ничего делать, если что-то потенциально выгоды не сулит. Ну, а так как объем работ не уменьшается, а требуется в итоге от менеджеров/линейшиков показать снижение трудозатрат - имеем то, что имеем
Так же, есть и такое, что давайте сократим менеджера/линейщика (а точнее дадим ему ещё три группы/команды) а его работу спустили посредством скрама(или другой подобной модной штуке) на рядовых работников, что собственно одно и то же с первым случаем - увеличивается нагрузка на каждого сотрудника, ну и ещё и допом повышают нагрузку, вы ж по скраму быстрее должны по клавишам стучать...
И, был ещё случай, наняли дорогого-дорогого специалиста по скрамам - и начал он внедрять, соответственно, затраты на него в виде увеличения нагрузки скинули на рядовых работников ну и никто не отказывается от требования снижения фактических тз за тот же объем работы - дорогому спецу тоже надо показать результат....
Короче, я встречал только унылую реализацию. А Дейли - это клёво, особенно когда относительно общую фигню пилим. Дейли не надо трогать.
SigSauer Автор
17.09.2022 18:50"давайте сократим менеджера/линейщика (а точнее дадим ему ещё три группы/команды) а его работу спустили посредством скрама(или другой подобной модной штуке) на рядовых работников" - а вот тут выше товарищ пишет что менеджеры и всякие скрам-мастера это паразиты, нет у них никакой работы ))
Но вы правильно написали - унылая реализация. При должном старании любой самый проверенный и надежный метод работы можно провалить. Скрам, как мне кажется, только миновал пик хайпа. Лет через 5 никто не будет ругать его как пустышку или считать волшебной таблеткой, просто еще один инструмент.
YONV
17.09.2022 16:30О. Наша тема. Со временем просто начинаешь отключаться от таких обсуждений, пока речь не доходит до тебя.
GospodinKolhoznik
17.09.2022 20:37-1Почему скрам не работает?
Мы забыли, что «нашим наивысшим приоритетом является удовлетворение клиента за счет максимальной быстрой и непрерывной поставки программного обеспечения, несущего в себе какую-то ценность»
Понимаете, наивысшим приоритетом. Т.е. этого надо достичь любой ценой! И если в результате таких действий ваша компания разорится, а руководство попрыгает в окно, это не имеет никакого значения, ведь цель оправдывает любые средства. Вот только руководству компании такой расклад может не очень понравится. Значит они в любом случае неизбежно будут отклоняться от этого наивысшего приоритета скрама. Ну а раз так, то это уже будет не скам.
Так почему же скрам не работает? Да потому что когда что то не работает, всегда можно сказать, что это от того, что скрам у вас ненастоящий. А настоящий скрам никто в здавом уме внедрять не будет, потому что он неадекватен по своему определению.
TimsTims
18.09.2022 14:58У вас произошла подмена понятий. Максимально быстро != Любой ценой. Это значит, настолько быстро, насколько это возможно, исходя из текущих ограничений. Ограничения - обычно это доступные ресурсы, такие как люди и деньги.
GospodinKolhoznik
18.09.2022 16:58-2Написано "наивысший приоритет". Не написано "наивысший приоритет, при соблюдении ряда ограничений".
У меня, как у программиста профдеформация: как написано, так я и понимаю, буквально, ничего не домысливая и не фантазируя - ведь по другому читать нельзя, потому что компилятор тоже прочитает буквально, ничего не домысливая и не трактуя метафорично.
Может быть поэтому я всегда недолюбливал всяких трактователей, как правильно надо читать и понимать тот или иной текст.
TimsTims
18.09.2022 21:22Всё правильно. Наивысший приоритет — счастливый клиент. Будет ли клиент счастливым, если компания разорится?
GospodinKolhoznik
19.09.2022 00:23+1А вы все не оставляете попыток трактовать как надо правильно понимать.
Конечно, ведь компания сделала все, чтобы клиент был счастлив, и теперь он счастлив.
Например клиент заказал у строительной компании строительство огромного бизнес центра. Строительная компания так сильно старалась угодить клиенту, что строила в убыток себе. В итоге построила прекрасный бизнес центр, но сама разорилась. Клиент счастлив, он выгодно заполучил дорогостоящий объект, который теперь сможет продать или сдавать в аредну за большие деньги. Почему ему не быть счастливым?
Если пример кажется недостаточно айтишным (а скрам это же не только про айти, а про любой вид проектов), то пусть заказчик это компания издатель заказывает у компании разработчика AAA игру (убийцу Ведьмака), разработчик так старается угодить заказчику, что вываливается за бюджет, но делает прекрасную игру качественно и в срок. В итоге издатель обогащается, а потому счастлив. Разработчик банкротится - ну что-ж, бывает...
SigSauer Автор
19.09.2022 01:01А виноват во всех этих бедах скрам, как я понял?)
Зачем строительная компания скрам использует, они что наугад строят БЦ?
Зачем геймдевы скрам используют при фиксированном бюджете и чётком ТЗ?
GospodinKolhoznik
19.09.2022 01:10Это было обязательным пунктом контракта, ведь заказчик хотел быть счастливым.
TimsTims
19.09.2022 14:41Разработчик банкротится — ну что-ж, бывает
Да, очень часто компании закрываются, не все осиливают сложные проекты, не рассчитывают силы (бюджет, сроки, человеческий фактор, итд).
Разработка ПО — очень дорогой процесс. Это не просто открыть магазин, и играешь в купи-продай. Сначала надо найти много денег, чтобы потихоньку собрать сильную команду. Пока набираешь команду, нужно уже иметь какие-никакие заказы, которые могли бы кормить разработчиков и не дать твоей фирме закрыться. Со временем, если ты все делаешь правильно, то у тебя команда становится слишком большой, и нужно делиться на несколько команд. Потихоньку, людей становится столько, что ты уже не знаешь имён личностей, которые у тебя работают. Ты не знаешь, как они работают, так же эффективно ли, как и ты.
Для этого в команды внедряют различные методики, одна из которых — скрам. Могут быть и другие. У гугла своя методика, в других компания — другая.
Если ничего не внедрять, и пустить на самотёк, то очень велик шанс, что разработчикистанут королямипотеряют цель, перестанут работать, и будут просто получать зарплату. Клиенты будут недовольны, и начнут уходить. В какой-то момент это приведёт к краху компании.
Скрам в данном случае — один из вариантов попытки направить команды и компанию в бизнес-русло, т.к. считается, что счастливый клиент сам принесёт больше денег (это правило не всегда и не везде работает).А вы все не оставляете попыток трактовать как надо правильно понимать.
Ну я ваши же слова вам привёл)
p0st
17.09.2022 23:23+1Про MBWA в статье, если пройти по ссылке и почитать внимательно отсылку к 5s (методология весёлых японцев), то можно узнать, что в их концепте - это краеугольный камень. И что наблюдая за каждодневным процессом можно понять, где есть издержки и хреновый процесс, чтобы поправить это.
Из собственной практики - это правда может помочь с неявными проблемами, особенно между командами и командой и чем-то ещё. Потому что кроме команды, в проекте или работе над продуктом может участвовать хелпдеск, СБ, бухгалтера, сторонние поставщики и прочие.
По теме скрама в целом, хочется порекомендовать - чёрный скрам. Хорошо развеивает ощущение, что скрам в чистом виде и строгое следование церемониям решит все проблемы.
SigSauer Автор
18.09.2022 13:52Здесь как мне кажется в MBWA тонкая грань между полезным приемом "гемба-менеджмент" или гемба-спринты, которые действительно могут быть полезны и помочь руководству получше узнать детали работы, и MBWA превращающийся в чайка-менеджемент.
Под "чёрным скрамом" вы видимо имели в виду "Черную книгу Скрама" И. Селиховкина?p0st
18.09.2022 15:16Да, именно её, Иван достаточно критично написал, но кмк, полезно, чтобы не забывать, что это лишь инструмент. Один из многих, который может работать, может не работать, может работать, но не так как ожидаешь.
lxsmkv
18.09.2022 00:17+3Есть доска есть задачи. Задачи должны решаться проблемы должны обсуждаться. Если задача не решается нужно просить помощи. Если релиз затягивается нужно поставить в известность заказчика. Все.
Я не могу себе представить что есть команды которые этого не понимают или делали бы другим образом если бы им не рассказали "как надо". От принудительных не приносящих продукту никакой оптенциальной пользы ритуалов (как например, давайте придумаем название нашей команде) страдает в конечном результате продукт, потому что разговаривать люди хотят все меньше и меньше. Ты приучаешься ждать какого-то собрания чтобы о чем-то сказать. Вместо того, чтобы общаться естественно и непринужденно.
Так это не работает. Общение происходит по необходимости а не по расписанию. Не видят в этом удобную возможность а видят только нудный очередной митинг, который нужно отсидеть. Ретроспективы превращаются в виртуальную жилетку вместо инструмента улучшения. Потому что все записи потом пропадают в архиве и никогда оттуда не достаются. И парадоксальным образом такие жесткое следование гайду работает против интересов заказчика. Время на "скрам" тратится, продукту пользы никакой.
И хуже всего когда скрам-мастер-(ица) все время пытается выполнятъ ведущую роль.Как мамаша. Так команда точно не научится быть самостоятельной. Никогда. Это то что тут в статье обозначили как выученную беспомощность. От своего желания быть полезным возникает поток акционизма,от которого страдает команда и продукт.
SigSauer Автор
18.09.2022 22:54У вас логическая ошибка.
Все что выше фразы "такое жесткое следование гайду" - никакого отношения к скраму не имеет
lxsmkv
19.09.2022 01:55+1Никаких логических следствий я не выводил. Поэтому никакой логической ошибки тут быть не может. Это чисто личные наблюдения от того, как то, что фирмы называют скрам может ощущаться в повседневной практике.
Судя по вашему замечанию вы знаете что такое скрам, и даже вероятно у вас есть положительный опыт его внедрения. С удовольствием почитаю, если найдете время обстоятельно изложить свой кейс.
----
А пока что, я продолжаю считать что бывший военный (Сазерленд) создал систему жесткой дисциплины и подавления. На что купилась вся военная индустрия, и пошло поехало. Вот статья написаная самим Сазерлендом: скрам трансформация методом шоковой терапии. Там просто предлагается делать все по указке. Как в казарме ломают новобранцев, чисто те же самые методы. Жесткая дисциплина, беспрекословное следование выдуманым ритуалам. Кондиционирование. Полный отказ от индивиуальности у членов команды. И пр. и пр.
В то время как аджайл скорее является гуманистическим подходом, скрам это чисто милитаристский подход. И он не просто ужасен, он опасен. В 50-60 годы может быть военные методы на гражданке еще и работали, но современное поколение не приемлет такого ущемления своей индивидуальности. "Бирюзовые организации" и все такое. Поэтому скрам будет жить в иерархически построеных огранизациях еще довольно долго. Но в общем и целом он со временем должен уйти из гражданских проектов.
Потому что единственное что важно в создании программного обеспечения это артефакты. Они или есть или их нет. На сегодняшний день Continuous Delivery показал себя как наиболее эффективный подход.
Представьте себе, в опенсорсе люди общаются асинхронно в цифровом виде уже десятки лет и ПО тоже создается. Баги резолвятся. Релизы выкатываются. Вся эта болтология и детский сад с ритуалами нафиг никому не нужны, нужны артефакты. Тикеты, пакеты, комментарии, документы, код, тесты, отчеты.
SigSauer Автор
19.09.2022 13:05+1Хорошо, я чуть подробнее объясню свою мысль:
Вы описываете некие проблемы, не связанные со скрамом как подходом к организации работы, а потом делаете вывод "такие жесткое следование гайду работает против интересов заказчика".
Какое следование гайду?
"От принудительных не приносящих продукту никакой оптенциальной пользы ритуалов (как например, давайте придумаем название нашей команде) " - нет там никаких названий команд. Вам эти ритуалы не приносят пользы, и вы делаете вывод что они бесполезные - а для других польза есть, представьте. Может дело не в ритуалах, а в том как вы их проводите?
"Ты приучаешься ждать какого-то собрания чтобы о чем-то сказать. Вместо того, чтобы общаться естественно и непринужденно" - нет этого в скраме и близко, там все наоборот. Если ваш менеджер не дает вам обсуждать проблемы с аргументом "сейчас не время, на ретро скажешь" - это не скрам.
Ну и так далее по остальным пунктам. Скрам последовательно сокращают, оставляя только самое важное, остальное - пробуйте и подбирайте для себя сами.
P.S. Вот "бирюзовые организации" это действительно глупость, притянутая за уши в отрасль.
CloseToAlgotrading
19.09.2022 13:50+1Например фреймворк Scrum прямо запрещает отказываться от дейли встреч.
Чисто из своего опыта, вот такой подход и есть главная ошибка автора этой статьи. Если команда самоорганизована и в ней нет "слабых" свеньев, то дейли можно и не проводить каждый день. Но часто бывает, что команда разнообразна, а еще и часть работает удаленно, и некоторым людям ежедневные митинги необходими, тогда уж от них отказываться не стоит, даже если часть команды считает это лишней тратой времени.
SigSauer Автор
19.09.2022 13:53Мысль интересная. Хотя в гайде и написано что дейли на то и дейли, чтобы каждый день в одно и то же время проходить, но если нет никаких проблем, всем понятен план на день (а предназначение дейли как раз "создает план действий на следующий рабочий день"), то наверное можно и не проводить каждый день.
Только мне кажется тут рисков будет больше чем выгоды с экономии этих 15 минутCloseToAlgotrading
19.09.2022 15:11Да 15 минут в день по большому счету роли не играют, главное что бы они не попадали в то время, когда команда наиболее сконцентрированна на работе :).
Тут как говорится "вам шашечки или ехать?". Скарм вроде как фреймворк дающий некоторую методолгию, но не гарантирующий результат. А что бы результат был, его нужно адаптировать под команду, иначе это все работать не будет. Так же тут зависимость есть от области применения. Но как это обычно бывает, вводят скрам по принципу, ну все делаем скрам как в методичке и это решит наши проблемы, но при этом в самой организации ничего не меняется. Все это превращается в трату времени именно изза этих 15 (растягивающихся на пол часа) дейли стендапах.
Green21
На стендапе ты можешь более подробно услышать какие задачи решают твои коллеги и почерпнуть что то полезное. А также чтобы не решать одну и ту же задачу по новой. Особенно это важно в отделе тех. поддержки и эксплуатации. И они не отнимают много времени.
Автор наверно хотел сказать про всякие совещания, куда дергают программистов, которые могли бы в это время продуктивно поработать.
SigSauer Автор
Ну строго говоря, чтобы не решать одну и ту же задачу по новой, есть другие инструменты, стендап здесь не обязателен, но в том числе да.
Техподдержка чаще Канбан использует, там другие встречи (называются "каденции"), ежедневный митинг обычно для обсуждения заблокированных задач.