Comments 94
Задачи, которые можно быстро закрыть, выдаются как приз тем, кто хорошо работал на долгих задачах
скрам=скам
угадать сроки
Ключевая фраза
Выглядит как "давайте уберём ремень безопасности: он только мешает, и ни разу пока не помог"
ремень безопасности не есть рулевое колесо. Просто на дороге не нужно уж так теребонькать рулем туда-сюда, изображая крутецкий дрифт
Т.е., скрам помогает так же редко, как ремень безопасности? А если помогает, то прям точно помогает?
Скрам скорее навигатор, который каждые 100 метров перестраивает маршрут и требует подтвердить, что ты все еще едешь прямо, иногда проще выключить его и ехать по знакам
Не, это как "мы знаем что то что мы ищем где-то на севере, мы не знаем где именно, мы не знаем как долго мы будем ехать на север чтобы это найти, мы предполагаем что с очень высокой вероятностью мы доедем до этого за 3 месяца и мы не будем останавливаться каждый час и измерять пройденное расстояние, мы будем просто ехать вперёд ибо чтобы достичь цели к ней нужно двигаться".
Метрики нужны не когда все хорошо и все работает, а когда что то работает со сбоями или плохо, и что бы попытаться предугадать проблемы хотя бы до того как они начнут заметно влиять.
Как вы собираете искать 'импостера' в команде, если команда для вас - черный ящик.
Как собирать и какие именно метрики нужно собирать что бы стало хорошо, вопрос на миллион.
Как вы собираете искать 'импостера' в команде, если команда для вас - черный ящик.
Это очень легко делается: просто научитесь программировать и смотрите что они там коммиттят.
А если вам это лень, и удобнее занятым людям голову клевать, то значит вы занимаете чужую должность
Конечно, это прекрасно работает в команде до 10.. ну 20 человек, а дальше 'научитесь программировать' уже не работает, вы человек и ваши возможности ограничены.
Я сейчас не защищаю современные методы построения этих метрик, там такой кошмар что волосы дыбом встают, но собирать метрики так или иначе нужно, и задача руководителя построить систему контроля такой, что бы она не мешала (или мешала по минимуму) работе.
ИМХО, не сто́ит иметь столь большие команды, лучше их дробить на более мелкие из 5..6 человек, включая лида. Опять-таки, ИМХО, глубокая древовидная структура предпочтительнее и эффективнее новомодной "плоской" модели.
Вы удивитесь, но из команд по 5 человек формируются отделы по 20 и направления по 100. И их руководителям тоже нужно как-то отслеживать эффективность работы своих подчинённых и прогресс своих задач. Процессы не заканчиваются отношениями между разработчиком и его тимлидом.
Тут ключевое "тоже нужно как-то отслеживать", причём каждое слово важно.
"Тоже нужно" - ну какой же он руководитель без отслеживания? Нельзя же подвергнуть сомнению его необходимость в роли руководителя?
"Как-то" - значит всё равно как, не важно точно или не точно ты отслеживаешь, оказывает этот контроль положительное влияние на процессы или не оказывает. Главное, чтобы были хоть какие-то цифры, которые можно показать и вниз и вверх для создания иллюзии контроля.
Процессы не заканчиваются отношениями между разработчиком и его тимлидом.
Почему? У 6 разработчиков есть тимлид, у 6 тимлидов есть тимтимлид. У тим тим тим лида в подчинении 258 человек, а подчиненных - шестеро. И еще 36 человек могут "через голову" нажаловаться на своего руководителя.
Никогда этого не понимал. Зачем? К чему этот микроменелжмент? Вы рук отдела, у вас есть лиды, всё. Если кто-то проёбывается, это вопрос к лиду, он уже должен делать свою работу.
То есть это всё нужно когда в менеджменте сидит левый контингент, не разбирающийся в этой этой отрасли, присосавшийся к айтишке на волнах хайпа?
Ой давайте уберем дедлайн, он же стресовый....
Дейли как ремень безопасности в авто, лишь бы не пригодился, но если что то важное и неожиданное происходит позволяет узнать об этом раньше.
Вообще без стеснения укладываемся в 5 минут дейли. Прощелкали доску, проговорили нет ли рисков если есть запланировали обсуждение и пошли работать дальше.
В зрелой команде нет осуждений что кто то 3 спринта одну задачу может копать или промахнуться в оценке.
Ни нужно ни одно действие в жизни воспринимать абсолютно, все имеет некий разбег, Много метрик не есть хорошо, и работать без метрик не есть хорошо. Дедлайн как священная корова - утопия, но и без дедлайна работать плохая идея.
Если происходит что-то важное и неожиданное, нужно ли ждать дейли, чтобы об этом рассказать? Может лучше рассказать сразу, но по другому каналу передачи информации?
И не похож дейли на ремень безопасности. Скорее похож на жужжание навигатора, который кроме предстоящих действий сообщает о выполненных: "Когда я повернул на улицу Ленина, увидел что она перекрыта. Поэтому маршрут перестроил и совершил разворот. На ближайшем перекрёстке поверну направо и поищу параллельную улицу." Польза есть, если кто-то это внимательно слушал и знает, что там параллельных улиц нет до самого выезда из города. Подскажет, что надо повернуть налево: сэкономит немного времени на манёврах. Вот и всё, пожалуй. А ремень безопасности - это алерты и автооткат релизов по метрикам приложения. Но это уже не про мерам.
Если происходит что-то важное и неожиданное, нужно ли ждать дейли, чтобы об этом рассказать?
А человек может и не знать, что у него проблема. Что он решает промежуточную проблему, которую уже позавчера решили в соседней команде. Или что эту проблему год назад решал другой человек и признал её заградительно дорогой. Или что ваши работы случайно пересеклись и вы на мёрже друг другу помешаете. Или что сосед знает более эффективное решение. Разработчик, например, может не отдавать себе отчёта в том, что фичу лучше урезать, если она растягивается, но решить в срок. И так далее, много может что быть.
И дейли тут выступает в роли милиционера на лошади - одна голова хорошо, а две лучше.
В простых потоковых задачах это, может быть, и не нужно, а в сложных проектах с большим количеством контрибьюторов без постоянной коммуникации постоянно кто-нибудь будет забредать не туда, не по злобе, а просто ну потому что разработчик заведомо знает меньше, чем пять разработчиков.
А всё потому что, оказывается, созвониться на 15 минут в день придумал злой лид от безделья.
Даже если сам дейлик занимает 5 минут, чего я никогда и нигде не встречал, то это не значит, что его стоимость 5 минут. Overhead на неё всё равно не меньше 30-60 минут на разработчика: как и любая встреча он разбивает поток на до и после. Время тратится как на вхождение в митинг с потерей контекста разработки, там и на выход
До этого надо ещё дойти, через боль и слезы видимо. Причём система как описана у автора более требовательная нежели история с списанием часовых затрат на каждую задачу.
Я так думаю, что команде мотивированных профи и правда ничего не нужно, никаких фреймворков. А как управлять командой, где есть джуны, стажёры, токсичные авторитеты и другие интересные кадры каждый со своим взглядом на всё вокруг?
Добавить в этот коктейль скрам-токсичности, как же ещё?
//У меня была супер-мотивированная команда, которую мне позволили набрать самому. Это были люди, которые изначально хотели заниматься дизайн-системой
Вот. И как с остальными командами, которые занимаются: легаси г..ом, сервисами перекладывания "json", и в т.ч. где "джуны, стажёры, токсичные авторитеты и другие интересные кадры "
Токсичные авторитеты любой скрам превратят в балаган, тут не процессы нужны, а жесткие кадровые решения. Никакой диаграммой Ганта токсичность не лечится
А как управлять командой, где есть джуны, стажёры,
Над ними берут шефство опытные разработчики
токсичные авторитеты и другие интересные кадры
Этих надо держать в узде. Всё-таки, руководство — это не про даш-борды, а про людей.
Да, и добавим сюда более реалистичные условия, чем "делаем никому не нужную хрень с нуля и без внешних сроков". Ну там постоянный поток багов, легаси, обязательства по срокам перед заказчиками/инвесторами и прочие милые особенности реального мира.
джунам помогает тимлид и лично следит без всякого скрама как они развиваются. "токсичные авторитеты" вообще наоборот получают буст к токсичноси при наличии всяких ритуалов скрама
Из всех скрам-церемоний я на самом деле положительно отношусь к дейликам и, как ни странно, к ретро. Сейчас и так все на удалёнке, никто никого не видит, общение, хотя бы по звонку, полезно. С Ретро то же самое.
Груминги постановок с командой, общекомандные демо - тоже полезные практики, но прибито ли это гвоздями к пресловутому "скрам-процессу"?
Спринты, с моей точки зрения, имеют смысл только тогда, когда они привязаны к релизам. На этапах R&D, MVP это просто бесполезная церемония.
Оценки не имеют смысла никогда. Будучи тим-лидом я мог оценить скорость доставки фичи плюс-минус палец без всяких циферок, просто понимая степень проработанности постановки, сложность открытых вопросов и валовой объём работы. Гадание на сторипойнтах точности не прибавит. И я совершенно согласен с посылом автора, что вся эта скрам-история - это создание иллюзии контроля для менеджеров среднего звена и красивых отчётиков для бизнеса.
ИМХО, если задача не зашита под разработчика, который уже давно в теме что и как он будет делать, то гадание на сторипоинтах позволяет убедиться, что все понимают задачу одинаково, что никто из команды не видит подводных камней. На покере как раз сталкиваются взгляды "построим кастомизируемый механизм, заложим фундамент на его развитие на годы вперед" против "ну эту мелкую хотелку можно подпереть костылем за пол дня работы"
без всякого покера когда создается задача в ней тим-лид пишет описание как минимум вида "заложим фундамент на его развитие на годы вперед" либо "ну эту мелкую хотелку можно подпереть костылем за пол дня работы"
У нас аналитики пишут. Что-то типа "надо чтобы пользователю был виден статус документа" А дальше можно завести реквизит статус, и пусть проставляют что хотят, а можно сделать интеграцию с ЭДО и подтягивать статус оттуда. Причем сделать красиво, не для одного документа естественно, а с возможностью подключения любого.
Оценка помогает приоритезации. Когда ты приходишь к бизнесу и говоришь - у нас тут 100500 задач, в каком порядке брать? И понимая размер задачи бизнесс может захотеть что-то в первую очередь пропихнуть, что-то во вторую.
Вообще не понимаю сторонников отмены оценки. Особенно со стороны тимлидов. Рассуждения уровня хобби.
Как бизнесу (заказчику) понимать, как быстро он получит что-то, что ему настолько важно, что он готов платить немалые деньги?
Да, оценка это пальцем в небо. Но лучше уж так, и продать её (вернее труд команды), а потом обосновать почему больше. Чем сказать: мы беремся, но сроков нету, собирать метрики работают ли вообще в команде не будем, но хотим 2млн в наносек. Каждому.
Хорошо, на 4 месяца энтузиазма и мотивации точно хватит, когда команда пилит новый продукт. Все заряженные и неуставшие. Но что дальше? Когда продукт в виде uikit будут использовать множество команд, ставить свои сроки фич и требовать быстрого фикса багов? Тут придётся прикручивать процессы
SCRUM это скам над Agile. Если скам убрать, то получатся то самое, что задумывали отцы-основатели (читаем манифест).
Из личных наблюдений - перешел с работы с отчетами по часам и оценками задач на обычный канбан без оценок и заметил, что стал работать эффективнее.
Просто потому, что если ты дал оценку в 10 часов с рисками, её все согласовали, а ты сделал работу за 5 часов - нет никакой мотивации сдавать задачу сильно раньше.
Отчасти это, конечно, из-за отсутствия нормальной системы мотивации и оценки перформанса, но все же.
Бесполезной управленческой единице надо показать и доказать свою нужность перед вышестоящим начальством. Оменно отсюда вылезают почти все метрики. Бездельник наводит суету, но, поскольку высокое начальство за матчасть своих подчиненных не шарит - у них свои задачи, оно принимает пустопрожнюю мышиную возню за реальные производственные процессы. Если взять и проверить, чего за пузомерки мы считаем - две трети менеджеров вылетят со свистом. Та же история в чиновничьем аппарате, например.
Как только мы начинаем что-то измерять, и это измерение начинает влиять на зарплаты - будте уверены, большинство работников сразу переключится с основной цели на накрутку/закрытие показателей. И если, например, на заводском конвеере можно точно синхронизировать цели и метрики - процент брака, количество деталей в час, и так далее - то в разработке считать нечего, почти все метрики там искуственные, не отражающие реальность в полной мере. Тут для оценки нужен менеджер, который сам разбирается в матчасти, чтобы понять, какая команда проседает, где есть проблемы, и всё в этом духе...
Scrum нужен и удобен там, где много задач, которые после декомпозиции по объему меньше или равны длине спринта. То есть никаких монолитных RnD на полгода, никакого рефакторинга одной фичи на пять спринтов, и прочего - только то, что мы можем адекватно разбить на подзадачи. И опять же, никаких сторипоинтов - задачи распределяет живой человек, и спрашивает статус на дейликах по ним тоже живой человек.
Дейлики и прочие встречи не чаще раза в день (лучше через день-два, зависит от задач) - хорошо, так как на удаленке очень важно понимать, что делает коллега. Встречи чаще раза в день, и больше часа - уже рак и трата времени. Если команда настолько большая, что каждый не успевает за час высказаться - эта команда должна быть поделена на части.
Разработка радиоэлектроники. Работал по системе с ежедневными отчетами... месяца три, наверное. Как итог:
При постановке задачи требуемый срок в голове умножал на два и орал, как контуженная чайка, что даже в этот срок укладываюсь только с мотивацией и загрузкой 146%.
Рабочий день закончен - adios, amigos, через 9 часов и 30 секунд после утреннего логина на свой ПК никакой силой меня не удержать на рабочем месте, ибо отчет за день готов и отправлен.
Нужно надуть себе атомарных задач, чтобы отчет выглядел солиднее? Нет никаких проблем, я-то на каждый клик мышкой в САПР могу написать предложение, которое этот клик превращает в самостоятельную задачу. Учитывая, что административный персонал термины "импеданс", "диаграмма Смита" и "децибел относительно милливатта" понимал ещё хуже, чем я SCRUM и AGILE, проблем никогда не возникало.
Так и не смог придумать, к каким задачам отнести те 15 минут в день, что я ходил, простите, пописать и покакать. Размазывал (ой какой плохой каламбур вышел...) по остальной "воде".
На написание отчета уходило от 15 до 30 минут, с учетом п.2... Эффективность зашкаливала.
Ладно спринты, я юнитесты убрал для малых проектов и тоже ничего не сломалось. А разработчики стали тщательнее тестировать. Правда ничего и не улучшилось, только стало меньше переключений контекста.
У меня была супер-мотивированная команда, которую мне позволили набрать самому
C таким чит-кодом любой менеджер будет эффективным, а попробуй выдать результат с теми, кто есть: с уставшим мидлом, джуном, который боится комитить, и сеньором, которому все надоело. А с "командой мечты" можно и в баре планирование проводить, результат будет отличный
"А с майонезом огуречный" а со скрамом всё это сразу взлетит!
Уставшего мидла заменяем на свежего и бодрого
Джуна уже заменила нейронка
Синьеру тоже предлагаем найти место, где ему будет веселее, может тогда и интересно сразу станет
А если серьезно, то такую команду в целом ничего не спасет
В большинстве контор есть куча реальных, годами не разгребаемых проблем, которые являются реальными причинами и усталости мидла, и безразличия сеньора. Проблемы остаются всё теми же, а графики agile с годами становятся всё краше.
Уставшего мидла заменяем на свежего и бодрого
и шерстяного 🐺
Кажется, это автоматически вытекает из желания горящих глаз вместо повидавших некоторого дерьма, если речь о грейде от мидла и выше.
Я в новой команде сменил формат дейли на пн/ср/пт и ничего не изменилось кроме экономии 1 часа времени в неделю.
Сказал команде, что как поставим всё на рельсы и если все будут хорошо работать, то сделаю формат пн/пт и все только обрадовались ,
Спойлер, спустя полгода так ничего и не сломалось...
На споры о важности процессов можно ответить так же, как и на споры о важности знания алгоритмов: если вы можете успешно работать без них, значит вы решаете слишком простые задачи.
Впринципе согласен. Вкратце изложил бы причины появления скрамов так:
1. карго культ - другие так делают, значит и мы должны
2. менеджмент хочет иллюзию контроля. Они никогда на самом деле не будут контролировать, но иллюзию в виде циферок они хотят
3. менеджмент хочет наверх носить какую-то статистику. Но они не умеют пользоваться гитом. Поэтому они заставляют вести дублирующую и бесполезную статистику вместо того чтобы брать статистику из коммитов, смотреть на мры и обсуждения (даже не код, а просто даты, что делается и далее).
В моей компании делалось бы примерно так:
Есть просто список задач, оцениваются они не в стори поинтах, а легко/сложно. Только для больших задач ещё оценивается компетенции скольких людей вообще потребуются для реализации, кому что придётся изучить новое
из созвонов - дейли 2-3 раза в неделю в целях просто обсуждения кто чем занимается, обсудить предложения, возникшие проблемы
никаких оценок в днях наперёд, только назад. Т.е. записываем сколько ушло времени на задачу (без всяких трекеров, просто от взятия до коммита)
маленькие команды (4-5 человек) профессионалов, тщательный отбор
@Kelbon, я помню потратил порядка 20 часов, искал баг в подключаемой по jni библиотеке, его не было когда ее подключаешь напрямую, но через прослойку - вылезали страшные глюки, отлаживать java было не просто, поэтому ковырялся с логами и экспериментами с кодом (правил его то тут то там)... проблему я нашел, ее исправление была одна строчка, добавил auto в определение переменной.
Если вы мою работу оценивали бы по git-у, вы бы меня уволили.
Если просто назвать рандомное количество дней, и то будет лучше. Так хотя бы команде не придется постоянно заниматься этим адом с покер-планингом и прочими ритуалами.
Так и делаю. Если людям наверху нужны реперные точки, то зачем мне мучить команду. Правда, иногда спрашивают за сроки, но мы же не миссию на Марс отправляем: опоздание на пару недель ни к какой катастрофе не приведёт
Я был и PM, и PO. И ключевая ошибка в подобных текстах — путать «у нас получилось» с «так можно управлять».
Процессы нужны не для контроля людей и не ради отчётов наверх.
Процессы — это про управляемость и снижение неопределённости, чтобы с высокой вероятностью получить ровно тот результат, который задумывали, в нужный срок и с понятными рисками.
По тексту создаётся ощущение, что автор никогда не нёс ответственности за бюджет, занятые деньги или стоимость срыва сроков — либо воспринимал их как абстрактные фантики, хотя по тому как вы себя позиционируете это явно не так. В реальности за потраченные ресурсы нужно отвечать: перед бизнесом, инвесторами, иногда — буквально своей позицией.
Да, в маленькой, изолированной, супер-мотивированной команде без внешних зависимостей можно работать без Scrum, оценок и спринтов. Я сам так работал — и это действительно эффективно. Но это частный кейс, а не воспроизводимая модель для продукта, платформы или бизнеса.
Как только появляются:
— несколько команд
— зависимости
— бюджет и стоимость простоя
— ожидания бизнеса до, а не после результата
любая антипроцессная романтика быстро заканчивается.
Проблема не в Scrum, сторипойнтах или дейли.
Проблема в том, что процессы часто внедряют без понимания зачем, превращая их в имитацию контроля.
Но отсутствие процессов — это не свобода.
Это ставка на удачу и мотивацию, а не на управляемую систему.
Зачем сюда писать генерированные AI комментарии? Пора бы уже настроить на хабре автоопределение и не допускать к публикации такие тексты
любая антипроцессная романтика быстро заканчивается.
Про-процессная романтика может заканчиваться не менее быстро, поскольку требует очередной попытки определиться с трудоемкостью выполнения инженерных задач и склонна превращаться в формальность и тягомотину.
Проблема не в Scrum, сторипойнтах или дейли.
Это также может вызывать отторжение...
«Не совсем понимаю, почему многие называют судьбу индейкою, а не какою-либо другою, более на судьбу похожею птицею"
Не спорю с вами, даже в некотором роде согласен.
Просто процессы позволяют планировать тройственное ограничение: деньги, время, ресурсы. Когда это всё ваше собственное, поверьте ни от какого планирования вы отказываться не будете. Это как в поход собираться в горы. Поверьте, когда в горы собираешься, точно решишь посчитать количество еды, вес, и собственные силы, это не прихоть, это вопрос вашего выживания.
Не спорю с Вами и даже полностью согласен, когда Вы описали вопрос русским языком.
Частично согласен когда "всё ваше собственное" вы начинали с нуля.
Нельзя согласиться, когда приходит дядя со стороны и говорит, все ваши опыты, СП, СНИПЫ, ГОСТЫ...ерунда, а он принес!!!...непонятно что.
:-) А впоследствии оказывается и похожее на то, что было раньше (Скажем, сетевое планирование)
— А давайте будем оценивать задачи в сторипойнтах! — предлагает радостно
— Зачем?
— Чтобы давать предсказуемые сроки по фичам
— Каким образом это поможет угадать сроки?
— …
выдуманные диалоги легче поворачивать куда вам нужно.
в реальном таком диалоге, даже если вдруг он состоится и вас позовут, решение уже принято менеджером и согласовано выше, вас позвали ознакомить с решением и заручиться непротивлением.
если вы будете сопротивляться громко, то вся ложь, которая не случилась, не случилась из за вас, тк вы саботируете и вообще всегда были проблемным кадром. если не будете громко сопротивляться - тоже, потому что вы согласились и саботируете/недостаточно хорошо работаете, вечно у вас что-то там, нужно взять на контроль (от которого ничего не станет лучше, но будет создаваться правильная иллюзия у ЛПР).
реальность не важна, цифры не важны, никому до этого нет дела. важны ощущения нескольких ЛПР, то как они интерпретируют то, что слышат. не результаты, а то, что они чувствуют, когда им эти результаты преподносят.
контроль не важен, важна иллюзия контроля (привет Илон Маск, Роскомнадзор). результаты не важны, важно ощущение, возникающее у слушателя, когда результаты презентуют (привет OpenAI, Apple).
так появляется правильно подобранная статистика, карго-культистские процессы и пр.
РФ специфика менеджмента, с его ордынской архитектурой, лишь добавляет оттенков поверх, не меняет картину радикально.
добро пожаловать в IT, и корпоративный мир в целом.
Разгадка тут:
У меня была супер-мотивированная команда
Чаще всего это это не так.
Подитоживая реплики ряда комментаторов: В вашем описанном кейсе:
Компактный срок в 4 месяца и чётко поставленная цель.
Команда, подобранная без существенных ограничений.
Неудивительно, что Скрам тут бесполезен. Он придуман для больших задач с не конкретной целью (слишком амбициозной или заказчик сам не до конца знает). Для этого проект бъется на спринты, каждый из которых согласуется с заказчиком. Такой компромисс между Time&material и проектами с фиксированной оплатой за результат.
А кроме таких задач, которым подходит Скрам, есть и другие. Например, когда целей много (различные сервисные команды). Для них есть другие системы.
Тут наверняка комментируют много людей, кто строил процессы. Поделитесь что у вас реально заработало?
И что можно было бы сделать в случае микро команд (2-3-4 чел, это без учета менеджмента, типа продукт овнера и скрам мастера) на довольно сложных проектах, а еще когда нет отдельных людей на аналитику и некоторые программисты или QA работают на два спринта одновременно или даже отвлекаются на саппорт.
я могу сказать про то, что не заработало: ничего. Если у вас нет гарантированной длины спринта ("отвлекаются на саппорт"), нет команды ( в том числе это варианты типа "в прошлый раз на проекте работал Вася, в этот раз будет Петя", "Вася пилит проект слева, Петя справа, точек пересечения нет"), нет того, что любят называть "ненужными ритуалами" - то ничего и не заработает.
Мда, какое гигантское количество агиле адептов улетают в космос на задней тяге. Я думал мода на это прошла уже достаточно давно, чтобы даже в России начали выздоравливать от скрума и прочих эффективноменеджерские болезней.
Интересно, как же в других отраслях живут без спринтов, сторипойнтов и прочей чепухи?! Чем же айтишка такая особенная, что им нужен целый набор профессий, чтобы строить эти самые эффективные процессы, оценивать задачи и клеить стикеры на доску?!
В общем, успехов автору, что встал на правильный путь эффективного менеджера без всяких посторонних примесей.
Цена контроля и управляемости в замедлении. Существенном. Большие команды - контролировать невозможно, можно только делать бумажки, на которые можно скинуть ответственность когда что-то пойдет не так, а оно пойдет. Менеджмент хочет быть сверху, хотя на деле он снизу, для многих программистов он прокладка для негатива. А ведь ещё можно проводить эксперименты с нейронами, дать одинаковые задания, но для одних вводить все это, для других нет.
И да заметить импортёра можно только имея хотя бы 60% его скиллов. Тогда можно оценить что человек делает, и нужно ли его держать в команде. А метрики - становятся предметом манипуляций, неизбежно если они открытые.
Акционерные общества обязаны отчитываться перед гос регуляторами. От сюда и все эти запары были внедрены в Agile, имхо.
А еще перед собеседованием не забудьте спросить у работодателя, если у них внедрена система ISO:2009, которая обязывает вести документацию таким образом, что любая требуемая информация должна быть получена в течении пяти минут. Естественно в таких условиях вам всем приходится не слабо напрягаться. Нет не только вам — программистам, а как раз тем менеджерам «прокладкам» между вами и топ-менджмеетом, между компанией и регулятором…
Так что да — это бюрократия. Удачи!
Уберите в маленьком городке разметку на дорогах, дорожные знаки и мало что изменится. Уберите в большом городе и получите хаос. Если ничего не сломалось, значит ничего и не работало.
Я тут попробовал ездить в чистом поле без всяких ПДД, поворотников и ремней безопасности и знаете - ничего не случилось. Вывод - пдд не нужны.
Уберите в большом городе
Возможно, просто убрано постоянное регулирование светофоров без причины и частые отчеты по грузопотокам в городских кварталах.
Вероятность того, что бывают "моддинги офисов" тоже исключить нельзя. Помните, когда на заре...приемные оборудовались панелями с мигающими лампочками, что очень влияло на клиентов.
Всё это просто болтология. Как выполненные цели в срок 4 месяца доказывают, что скрам неэффективен? А где гарантия, что вы с командой не выполнили бы эти же цели быстрее, пользуясь скрамом? Ваш успешный опыт ничего не доказывает и ничего не опровергает. Хотите что-то доказать, поставьте научный эксперимент: 2 команды с примерно равными навыками и опытом и две примерно одинаковые или одинаковые задачи; в одной команде пользуйтесь скрамом, а другая пусть просто пишет код; кто быстрее и качественнее справиться с задачей, тот и победил.
Очень вредная статья
Аффтор не понял что такое скрам и решил его изобрести заново. Тот же скрам, только на свой манер. И потом сказал, что он отменил его))
Когда одна команда а задач мало, никто не звонит и не дёргает с проблемами, все классно. Такой идеальный проект в песочнице. А когда куча зависимостей, проекты затрагивают 2-3-10 команд, компания динамичная, меняются архитектуры, продукты, без сроков просто каша, проекты застревают на месяцы некоторые выгорают а некоторые сидят без работы месяцами, куча узких мест и никто не может ничего исправить ....
Но это больше не про скрам а про масштабируемые фреймворк, конечно.
А целом, все сработало потому что условия скорее всего были тепличные
Соглашусь - грустная статья. В Скраме есть выражение - to do Scrum vs pretend to do Scrum. Как раз про ситуацию, когда Скрам отождествляется с церемониями. Выполняются церемонии, а Скрама нет, и соответственно нет эффекта. Не закрепилось в чем заключается Скрам, для чего нужен, в чем заключается эффект. Но нужно признать это недостаток оригинальной литературы по Скраму. Книги в основном рекламируют платное обучение и консалтинг.
Но дело даже не в Скраме, а в том, что является артефактами работы команды и для чего они вообще нужны.
у меня вопрос уже к первому абзацу. "если убрать все серам атрибуты то менеджерам будет нечего делать"
Я прошу прощения, но в скраме разве есть такая роль "менеджер"? Я не то что бы большой фанат скрам (имхо это такой костыль, для тех кто никогда не работал по agile). Но по моему каждый раз когда в критике скрам появляется слово "менеджер" это такой Ред флаг, говорящий что сейчас будет не критика скрам, а критика чего то, на что пытаются натянуть снятую со скрам "кожу" в виде терминологии, ритуалов и тп. Но что ни к скрам ни к аджайл отношения не имеет
Я убрал оценки задач, спринты, планирование и ретроспективы — и ничего не сломалось