Комментарии 35
На стендапе ты можешь более подробно услышать какие задачи решают твои коллеги и почерпнуть что то полезное. А также чтобы не решать одну и ту же задачу по новой. Особенно это важно в отделе тех. поддержки и эксплуатации. И они не отнимают много времени.
Автор наверно хотел сказать про всякие совещания, куда дергают программистов, которые могли бы в это время продуктивно поработать.
По моему опыту, как только команды начинают сосредотачиваться на блокерах и затянувшихся проблемах, их апдейты статуса переходят от технической болтовни, например:
Я обнаружил сдвиг частоты нановолн в плазменном глюонном кристалле. Сегодня я переверну транспортер ионов и заменю торсионный новообразованный кожух. Интересно, есть ли временная аномалия в спинном кронштейне биполярного двигателя? Что все думают? [вставьте сюда длинное бессмысленное обсуждение]
к следующему виду:
Все идет хорошо. Никаких блокеров.
А потом вдруг выяснится, что сегодня будут проводиться регламентные работы на транспортере ионов, и когда его перевернут, из него все ионы высыпятся на пол.(сарказм)
Так что без длинного бессмысленного обсуждения, но статус работ иногда определять полезно.
Никто не говорит что статус вообще не нужно детально обсуждать или описывать.
Здесь речь конкретно про дейлики - если нет блокировщиков, и нет какой-то важной информации по этой задаче для остальной команды, не смысла подробно описывать что вы там сделали и что собираетесь делать, команда от этого теряет бдительность и засыпает )
почему вероятность смерти после 11 лет растёт так резко?
Есть n работы. Введение скрама и прочих методик этого не уменьшает. Однако смещает ответственность менеджера к работникам, заставляя их работать более плотно, интенсивно, в режиме постоянного дедлайна (ну мне же надо это сделать до завтра, я же команду пожведуууу), что приводит к выгораниям, психозам и, в конечном итоге к текучке кадров.
Скрам не задумывался как подход, предназначенный для уменьшения работы в общем случае.
Он предназначен для уменьшения лишней "неправильной" работы, когда конечный результат не ясен, промежуточные шаги не ясны и т.п. Вместо того чтобы пытаться изначально все планировать, Скрам предлагает идти мелкими шагами, после каждого шага пробуя что получилось и выясняя, туда ли мы движемся.
И да, в Скраме нет менеджера.
Если вы работаете в окружении что менеджер есть и он всю ответственность переложил на команду, Скрам тут не при чем.
Скрам-мастер запросто может быть один из разработчиков, PO (product owner - владелец продукта) формально тоже, хотя в реальности так бывает редко - человек с такими навыками, которые нужны хорошему РО, сам код не пишет, это нерационально.
Проблемы не в подходе Скрам/Канбан/водопад/whatever как таковом, а в неумелом управлении, неуместном или неправильном применении подхода, неправильном подборе команды и так далее
Вся проблема не в том как задумывалось, а в том, как реализуется. Компания, внедряя любую методику ждёт результата - а ей нужно увеличение производительности. Компания не будет ничего делать, если что-то потенциально выгоды не сулит. Ну, а так как объем работ не уменьшается, а требуется в итоге от менеджеров/линейшиков показать снижение трудозатрат - имеем то, что имеем
Так же, есть и такое, что давайте сократим менеджера/линейщика (а точнее дадим ему ещё три группы/команды) а его работу спустили посредством скрама(или другой подобной модной штуке) на рядовых работников, что собственно одно и то же с первым случаем - увеличивается нагрузка на каждого сотрудника, ну и ещё и допом повышают нагрузку, вы ж по скраму быстрее должны по клавишам стучать...
И, был ещё случай, наняли дорогого-дорогого специалиста по скрамам - и начал он внедрять, соответственно, затраты на него в виде увеличения нагрузки скинули на рядовых работников ну и никто не отказывается от требования снижения фактических тз за тот же объем работы - дорогому спецу тоже надо показать результат....
Короче, я встречал только унылую реализацию. А Дейли - это клёво, особенно когда относительно общую фигню пилим. Дейли не надо трогать.
"давайте сократим менеджера/линейщика (а точнее дадим ему ещё три группы/команды) а его работу спустили посредством скрама(или другой подобной модной штуке) на рядовых работников" - а вот тут выше товарищ пишет что менеджеры и всякие скрам-мастера это паразиты, нет у них никакой работы ))
Но вы правильно написали - унылая реализация. При должном старании любой самый проверенный и надежный метод работы можно провалить. Скрам, как мне кажется, только миновал пик хайпа. Лет через 5 никто не будет ругать его как пустышку или считать волшебной таблеткой, просто еще один инструмент.
О. Наша тема. Со временем просто начинаешь отключаться от таких обсуждений, пока речь не доходит до тебя.
Почему скрам не работает?
Мы забыли, что «нашим наивысшим приоритетом является удовлетворение клиента за счет максимальной быстрой и непрерывной поставки программного обеспечения, несущего в себе какую-то ценность»
Понимаете, наивысшим приоритетом. Т.е. этого надо достичь любой ценой! И если в результате таких действий ваша компания разорится, а руководство попрыгает в окно, это не имеет никакого значения, ведь цель оправдывает любые средства. Вот только руководству компании такой расклад может не очень понравится. Значит они в любом случае неизбежно будут отклоняться от этого наивысшего приоритета скрама. Ну а раз так, то это уже будет не скам.
Так почему же скрам не работает? Да потому что когда что то не работает, всегда можно сказать, что это от того, что скрам у вас ненастоящий. А настоящий скрам никто в здавом уме внедрять не будет, потому что он неадекватен по своему определению.
У вас произошла подмена понятий. Максимально быстро != Любой ценой. Это значит, настолько быстро, насколько это возможно, исходя из текущих ограничений. Ограничения - обычно это доступные ресурсы, такие как люди и деньги.
Написано "наивысший приоритет". Не написано "наивысший приоритет, при соблюдении ряда ограничений".
У меня, как у программиста профдеформация: как написано, так я и понимаю, буквально, ничего не домысливая и не фантазируя - ведь по другому читать нельзя, потому что компилятор тоже прочитает буквально, ничего не домысливая и не трактуя метафорично.
Может быть поэтому я всегда недолюбливал всяких трактователей, как правильно надо читать и понимать тот или иной текст.
А вы все не оставляете попыток трактовать как надо правильно понимать.
Конечно, ведь компания сделала все, чтобы клиент был счастлив, и теперь он счастлив.
Например клиент заказал у строительной компании строительство огромного бизнес центра. Строительная компания так сильно старалась угодить клиенту, что строила в убыток себе. В итоге построила прекрасный бизнес центр, но сама разорилась. Клиент счастлив, он выгодно заполучил дорогостоящий объект, который теперь сможет продать или сдавать в аредну за большие деньги. Почему ему не быть счастливым?
Если пример кажется недостаточно айтишным (а скрам это же не только про айти, а про любой вид проектов), то пусть заказчик это компания издатель заказывает у компании разработчика AAA игру (убийцу Ведьмака), разработчик так старается угодить заказчику, что вываливается за бюджет, но делает прекрасную игру качественно и в срок. В итоге издатель обогащается, а потому счастлив. Разработчик банкротится - ну что-ж, бывает...
А виноват во всех этих бедах скрам, как я понял?)
Зачем строительная компания скрам использует, они что наугад строят БЦ?
Зачем геймдевы скрам используют при фиксированном бюджете и чётком ТЗ?
Разработчик банкротится — ну что-ж, бываетДа, очень часто компании закрываются, не все осиливают сложные проекты, не рассчитывают силы (бюджет, сроки, человеческий фактор, итд).
Разработка ПО — очень дорогой процесс. Это не просто открыть магазин, и играешь в купи-продай. Сначала надо найти много денег, чтобы потихоньку собрать сильную команду. Пока набираешь команду, нужно уже иметь какие-никакие заказы, которые могли бы кормить разработчиков и не дать твоей фирме закрыться. Со временем, если ты все делаешь правильно, то у тебя команда становится слишком большой, и нужно делиться на несколько команд. Потихоньку, людей становится столько, что ты уже не знаешь имён личностей, которые у тебя работают. Ты не знаешь, как они работают, так же эффективно ли, как и ты.
Для этого в команды внедряют различные методики, одна из которых — скрам. Могут быть и другие. У гугла своя методика, в других компания — другая.
Если ничего не внедрять, и пустить на самотёк, то очень велик шанс, что разработчики
Скрам в данном случае — один из вариантов попытки направить команды и компанию в бизнес-русло, т.к. считается, что счастливый клиент сам принесёт больше денег (это правило не всегда и не везде работает).
А вы все не оставляете попыток трактовать как надо правильно понимать.Ну я ваши же слова вам привёл)
Про MBWA в статье, если пройти по ссылке и почитать внимательно отсылку к 5s (методология весёлых японцев), то можно узнать, что в их концепте - это краеугольный камень. И что наблюдая за каждодневным процессом можно понять, где есть издержки и хреновый процесс, чтобы поправить это.
Из собственной практики - это правда может помочь с неявными проблемами, особенно между командами и командой и чем-то ещё. Потому что кроме команды, в проекте или работе над продуктом может участвовать хелпдеск, СБ, бухгалтера, сторонние поставщики и прочие.
По теме скрама в целом, хочется порекомендовать - чёрный скрам. Хорошо развеивает ощущение, что скрам в чистом виде и строгое следование церемониям решит все проблемы.
Здесь как мне кажется в MBWA тонкая грань между полезным приемом "гемба-менеджмент" или гемба-спринты, которые действительно могут быть полезны и помочь руководству получше узнать детали работы, и MBWA превращающийся в чайка-менеджемент.
Под "чёрным скрамом" вы видимо имели в виду "Черную книгу Скрама" И. Селиховкина?
Есть доска есть задачи. Задачи должны решаться проблемы должны обсуждаться. Если задача не решается нужно просить помощи. Если релиз затягивается нужно поставить в известность заказчика. Все.
Я не могу себе представить что есть команды которые этого не понимают или делали бы другим образом если бы им не рассказали "как надо". От принудительных не приносящих продукту никакой оптенциальной пользы ритуалов (как например, давайте придумаем название нашей команде) страдает в конечном результате продукт, потому что разговаривать люди хотят все меньше и меньше. Ты приучаешься ждать какого-то собрания чтобы о чем-то сказать. Вместо того, чтобы общаться естественно и непринужденно.
Не видят в этом удобную возможность а видят только нудный очередной митинг, который нужно отсидеть. Ретроспективы превращаются в виртуальную жилетку вместо инструмента улучшения. Потому что все записи потом пропадают в архиве и никогда оттуда не достаются. И парадоксальным образом такие жесткое следование гайду работает против интересов заказчика. Время на "скрам" тратится, продукту пользы никакой.
И хуже всего когда скрам-мастер-(ица) все время пытается выполнятъ ведущую роль.Как мамаша. Так команда точно не научится быть самостоятельной. Никогда. Это то что тут в статье обозначили как выученную беспомощность. От своего желания быть полезным возникает поток акционизма,от которого страдает команда и продукт.
У вас логическая ошибка.
Все что выше фразы "такое жесткое следование гайду" - никакого отношения к скраму не имеет
Никаких логических следствий я не выводил. Поэтому никакой логической ошибки тут быть не может. Это чисто личные наблюдения от того, как то, что фирмы называют скрам может ощущаться в повседневной практике.
Судя по вашему замечанию вы знаете что такое скрам, и даже вероятно у вас есть положительный опыт его внедрения. С удовольствием почитаю, если найдете время обстоятельно изложить свой кейс.
----
А пока что, я продолжаю считать что бывший военный (Сазерленд) создал систему жесткой дисциплины и подавления. На что купилась вся военная индустрия, и пошло поехало. Вот статья написаная самим Сазерлендом: скрам трансформация методом шоковой терапии. Там просто предлагается делать все по указке. Как в казарме ломают новобранцев, чисто те же самые методы. Жесткая дисциплина, беспрекословное следование выдуманым ритуалам. Кондиционирование. Полный отказ от индивиуальности у членов команды. И пр. и пр.
В то время как аджайл скорее является гуманистическим подходом, скрам это чисто милитаристский подход. И он не просто ужасен, он опасен. В 50-60 годы может быть военные методы на гражданке еще и работали, но современное поколение не приемлет такого ущемления своей индивидуальности. "Бирюзовые организации" и все такое. Поэтому скрам будет жить в иерархически построеных огранизациях еще довольно долго. Но в общем и целом он со временем должен уйти из гражданских проектов.
Потому что единственное что важно в создании программного обеспечения это артефакты. Они или есть или их нет. На сегодняшний день Continuous Delivery показал себя как наиболее эффективный подход.
Представьте себе, в опенсорсе люди общаются асинхронно в цифровом виде уже десятки лет и ПО тоже создается. Баги резолвятся. Релизы выкатываются. Вся эта болтология и детский сад с ритуалами нафиг никому не нужны, нужны артефакты. Тикеты, пакеты, комментарии, документы, код, тесты, отчеты.
Хорошо, я чуть подробнее объясню свою мысль:
Вы описываете некие проблемы, не связанные со скрамом как подходом к организации работы, а потом делаете вывод "такие жесткое следование гайду работает против интересов заказчика".
Какое следование гайду?
"От принудительных не приносящих продукту никакой оптенциальной пользы ритуалов (как например, давайте придумаем название нашей команде) " - нет там никаких названий команд. Вам эти ритуалы не приносят пользы, и вы делаете вывод что они бесполезные - а для других польза есть, представьте. Может дело не в ритуалах, а в том как вы их проводите?
"Ты приучаешься ждать какого-то собрания чтобы о чем-то сказать. Вместо того, чтобы общаться естественно и непринужденно" - нет этого в скраме и близко, там все наоборот. Если ваш менеджер не дает вам обсуждать проблемы с аргументом "сейчас не время, на ретро скажешь" - это не скрам.
Ну и так далее по остальным пунктам. Скрам последовательно сокращают, оставляя только самое важное, остальное - пробуйте и подбирайте для себя сами.
P.S. Вот "бирюзовые организации" это действительно глупость, притянутая за уши в отрасль.
Так именно про это выше и говорилось - по итогу всегда можно сказать "это не скрам" и "вы все делаете не так". Хотя казалось бы в "гибких методологиях" (с) все должно быть "не так" как по учебнику, а "так" как это удобнее команде. Но тогда это стновится "не настоящим скрамом" и можно уже начинать искать виноватого
Мне кажется вы путаете гибкую методологию управления и отсутствие методологии.
Ответы на ваши вопросы на самом деле уже есть в гайде по скраму. Но кто-то заставляет вас использовать именно этот фреймворк? Если вам не нравятся дейли или ретроспективы - не проводите их. Не хотите брать писать цель продукта и цель спринта, брать на себя ответственность, хотите полную свободу - ну на здоровье. Если у вас в таком виде все работает - отлично, если нет - не стоит считать что скрам какой-то не такой.
Судя по вашей риторике, "хотим работать так как удобно нам", "искать виноватого" - мне кажется скрам вам не нужен, при всем уважении.
Дельная статья, спасибо за перевод. Обязательно перешлю в команду :-)
Например фреймворк Scrum прямо запрещает отказываться от дейли встреч.
Чисто из своего опыта, вот такой подход и есть главная ошибка автора этой статьи. Если команда самоорганизована и в ней нет "слабых" свеньев, то дейли можно и не проводить каждый день. Но часто бывает, что команда разнообразна, а еще и часть работает удаленно, и некоторым людям ежедневные митинги необходими, тогда уж от них отказываться не стоит, даже если часть команды считает это лишней тратой времени.
Мысль интересная. Хотя в гайде и написано что дейли на то и дейли, чтобы каждый день в одно и то же время проходить, но если нет никаких проблем, всем понятен план на день (а предназначение дейли как раз "создает план действий на следующий рабочий день"), то наверное можно и не проводить каждый день.
Только мне кажется тут рисков будет больше чем выгоды с экономии этих 15 минут
Да 15 минут в день по большому счету роли не играют, главное что бы они не попадали в то время, когда команда наиболее сконцентрированна на работе :).
Тут как говорится "вам шашечки или ехать?". Скарм вроде как фреймворк дающий некоторую методолгию, но не гарантирующий результат. А что бы результат был, его нужно адаптировать под команду, иначе это все работать не будет. Так же тут зависимость есть от области применения. Но как это обычно бывает, вводят скрам по принципу, ну все делаем скрам как в методичке и это решит наши проблемы, но при этом в самой организации ничего не меняется. Все это превращается в трату времени именно изза этих 15 (растягивающихся на пол часа) дейли стендапах.
Почему ваши ежедневные стендапы не работают и как это исправить