Комментарии 58
10% это что с чем сравнивалось?
Нельзя так прям ванильный ажаль сравнивать с ванильным нежаль
Почему нельзя напрямую сравнивать? Вроде единица измерения одна и та же - скорость разработки.
Минус время на переделку и доделку.
А оно разное при разных скоростях
Ну положа руку на сердце, это неправильная величина. В творческих проектах есть две совершенно независимые величины: риск и кол-во условно безрисковой работы. Время, затрачиваемое на проект "складывается" из обеих составляющих. И про "скорость" можно говорить только после очень сильного усреднения составляющей "риск".
Так считать в лоб - слишком грубое упрощение.
Все разговоры про scrum, kanban,... и ускорение от них, они скорее про 2 простых момента:
Не переставать делать того, что нам нужно и полезно (краткосрочно и долгосрочно)
Не делать того, что нам вредно (краткосрочно и долгосрочно)
Если не следить за этими 2 вещами, поразительно быстро может оказаться, что 90-100% времени команда делает не то, ради чего она существует (несмотря на то, что продуктивность каждого формального хорошая), все от этого демотивируются, падает продуктивность и пр.
Тот же Scrum это просто вариация короткого цикла обратной связи и качественного фокуса на задаче, который помогает не распыляться и быстро выводить на рынок новые продукты или функции продуктов.
Поэтому полезность этих 15% стоит оценивать именно в этом ключе. Я видел ситуации, когда команда продуктивно работала над демкой полгода, позвала заказчика на демо, и оказалось, что 80% сделано неверно, т. е. 80% времени фактически было потрачено впустую, и несколько % на демки заказчику каждые 2 недели спасли бы ситуацию, и в итоге был значительно лучший результат.
В идеальном процессе разработки в вакууме, классическая разработка по лекалам PMBoK в до-Agile редакции дает оптимальную скорость и результат. Однако по факту, если вот так ритуалами не сгонять вместе бизнес и команду, обычно оказывается та самая 10-20% эффективность, поверх которой Scrum может писать про 800% улучшения.
Если условный Scrum дал 10% прирост (потребляя дополнительное время на себя) - это зачастую означает, банально, что люди в команде уже достаточно хорошо общались и адекватно работали с целеполаганием, и уже до этого показывали хорошую продуктивность.
Так считать в лоб - слишком грубое упрощение
Не соглашусь, потому что единица измерения одна - скорость разработки.
Если условный Scrum дал 10% прирост
Дело не в приросте как таковом, а в соотношении прирост/расходы. Если время на ритуалы стоит 15% от команды + внешние команды трансформации + SCRUM-мастера + аудиторы, мы можем говорить, что за те же деньги увеличим команды процентов на 30-40, что немало. И вот тут возникает вопрос - а что было бы эффективнее?
Т. к. внешние ресурсы по трансформации, это скорее одноразовые (или хотя бы не постоянные) расходы, их бы оставил за скобками.
Про "15% от команды", попробую немного утрированный пример для иллюстрации
Вариант 1. Представим, что у нас нет команды вообще, а просто 10 человек в кабинетах получают задачу в Jira, делают и отдают дальше, и так 8 часов в день.
Вариант 2. "10 человек час в день общаются, а 7 часов в день делают задачу, зная, как это влияет на другого коллегу и как выглядит результат в целом, и получают ответы на вопросы сразу".
1/8 это 12.5% времени, но я не верю, что по первому сценарию результат будет лучше второго. И даже если добавить в Вариант 1 11го человека - тоже.
По сути, любой адекватный коллектив будет общаться и тратить на это некоторое не нулевое время, но если пустить на самотек - тот, кто стесняется говорить или задавать вопросы - рискует закопаться и пойти не туда (опять же, будучи прекрасным специалистом). И все эти "ритуальные" точки синхронизации - дают площадку, помогающую всем вовремя получить ответы на вопросы и скорректировать курс. Т. е. не являются потерями, эти коммуникации так и иначе бы случились, только без расписания были бы рыхлыми, менее структурными и несвоевременными.
Так что, прирастить команду на 40% без хорошей культуры взаимодействия внутри и вовне - как по мне, может вообще дать отрицательный прирост поставки ценных результатов, зато будет распыление фокуса и велосипедостроение.
А в команде с хорошей коммуникацией - и Scrum мастер будет ролью, а не должностью, и дейлики по 15 минут, и демо будут укладываться в 45-60, и ретро будут продуктивными как коллективная деятельность, а не пустая коммуникация.
При этом, я, субъективно не очень хорошо отношусь конкретно к Scrum из-за ригидности подхода (излишняя ритуализация, вырождение "целей спринта" во многих случаях), и по факту в жизни для меня лучше работали гибриды Kanban-а и классического проектного управления.
Вы почему-то оставили команду без руководителя, который в традиционной модели и делает их командой, в не сотрудниками в комнате. В модели Agile команды вроде как должны самоорганизовываться, именно на это и направлены ритуалы, и так распределены роли. Но на моей практике я ни разу не видел самоорганизующуюся команду, только через личность руководителя/лидера. И часть смысла моего текста как раз была про это - мы тратим много времени команды на ритуалы, которые не достигают целей.
Я работал на проекте с само-организующейся командой. Заказчик из старой европы, по-моему, переизобрел колхоз. Как и в случае с колхозами в СССР - вы должны быть почти бесконечно богаты чтобы это работало. Сравнивая с проектами в РФ - в самоорганизующейся команде 15 человек делают то, что в иерархической команде делало бы пять (за то же, если не меньшее время).
Почему они это делают ? У самоорганизуемой бесконечными совещаниями команды есть одно преимущество: bus-фактор равен размеру команды. В РФ - потерять толкового тимлида или руководителя отдела - немедленно просаживает команду по производительности, а то и грозит тем что люди разбегутся (тут уместно сказать про культуру кадрового резерва, но это такая редкость что смысла нет...). Самоорганизуемый колхоз без явного лидера ползет вперед медленно - но сверхнадежно: можно хоть каждые три-четыре недели менять одного человека (за год почти 100% обновление команды) - и никто не заметит.
В конечном счете, еще раз подтверждается эмпирическое правило - эффективность всегда повышается за счет надежности. Финансистам из европы было наплевать на стоимость и скорость разработки - главное чтобы надежно...
единица измерения одна - скорость разработки
Нет, единица измерения не одна. Что вы скажете заказчику, если разработали всё действительно быстро, но не то? Скрам нам отвечает, что за счет быстрой обратной связи мы таким образом лучше понимаем проект, изучаем потребности заказчика. А если вы ушли в быструю и эффективную разработку на полгода и потом выяснилось, что сделали не то?
Единица измерения в скраме совсем другая - польза бизнесу, а никакая не скорость разработки в вакууме. Можно гордо строчить задачи одна за другой и хвастаться скоростью, но потом окажется, что все эти задачи сделаны в пустую.
Польза от скрама постулируется по сути одна - увеличение пользы для бизнеса за счет коротких циклов разработки и постоянного фидбека. Чтобы как выше пишут не оказалось, что мы год писали что-то очень быстро в отрыве от всех и били рекорды, а потом оказалось, что большая часть сделана впустую. Поэтому да, вот так в лоб нельзя сравнивать.
При любом подходе придется потратить время на планирование, оценку трудозатрат, декомпозицию задач и прочее. В приведенном примере - эти затраты всего 15%, и кажется, что есть потенциал, улучшить этот показатель. Не так плохо. Если применяемый подход, по сравнению с остальными дает от 10% к приросту эффективности, тоже вроде здорово. Ответ на последний вопрос представляется очевидным: «да, стоило». А если «нет», то какая альтернатива?
Выражаясь языком экономики, стоимость ритуалов SCRUM составляет 15% от стоимости команды. Эти средства уходят не на разработку, а на разговоры о том, кто что сегодня сделает, жалобы на процессы, игру в карты, показ сделанной работы руководству собственной фирмы и показ того же самого представителям заказчика.
В том-то и дело. Вы не можете выкинуть планирование (спринта, или любого другого периода). Планирование все равно будет - другое дело, что оно будет например происходить в другое время и в другом месте. Например, в голове или на бумажке у тимлида. Но само по себе оно никуда не денется, или у вас будет бардак почище эджайла.
Тоже самое - демо. Вы конечно можете никому не показывать результаты своего релиза - но это в конечном счете отольется вам же лишней работой по сопровождению. Ваш заказчик должен видеть, что вы сделали. Это даже не столько реклама себя, любимого, сколько обучение потребителя, чтобы он понимал, какие новые фишки появились, какие проблемы решены.
Планирования и прочего действительно не избежать.
Но 15% времени команды - это примерно 1/7, то есть один в команде из 7 человек занимается организацией. Или каждый занимается организацией 1/7 часть времени. Одно и то же?
Нет, потому что забыли время на переключение. То есть в скраме не выполняется скрамовская ценность "концентрация на одной важной задаче", one piece flow, парадокс.
Может вы и правы. Мой опыт - 10% это что-то на границе погрешности измерений.
В случае ТС же - 30 минут Дейли даже не много. Видел и по часу-два, даже до трёх! 🔫 Такие длинные совещания одна из форм прокрастинации сотрудников. Прекрасно описана в Законах Паркинсона.
Аджайл в таких командах скорее формальность. По сути под капотом - чаще ватерфол. Есть дух и буква. Следование только букве - формализм (опять Законы Паркинсона). А ещё - шанс команда уже на границе выгорания. Что делать - честно не знаю. Мне это предстоит - попробовать узнать.
Эффективный аджайл тоже видел: Дейли даже быстрее 15 минут. Вотерфол тоже застал. И потому могу сравнивать с аджайлом. Аджайл рулит, если не упирается в человеческий фактор.
Потери времени ещё больше. Например, разработчик вынужден выйти из рабочего режима, назовём это так, для какого-нибудь бессмысленного стендапа, а потом снова в рабочий режим переключаться. И так каждый день.
посчитайте что будет если ритуалам не следовать - сразу, через полгода, через год
Сколько часов стоит работа по классическому водопаду? Сколько будет стоить возражение заказчика "я не это имел ввиду"?
Я думаю что команда БКС сравнивала ажаил и ажаил и получился прирост 10%.
Смысл текста был в том, что буковки, вынесенные в эпиграф, есть прямая ложь, и внедрение аджайл не приводит к ускорению команд. Наверное я недостаточно ясно донес мысль.
Про БКС не знаю, может быть сравнивали плохой аджайл с хорошим.
Представьте: вам дают ТЗ и вы 2 месяца пишите совершенный код приложения. Через 2 месяца завершается 1 этап водопада, демо с заказчиком и посмотрев ваше демо он буквально говорит "мы думали, что вы сделаете по другому, это принимать мы не будем"... Разбирательства составление нового тз, 2 этап водопада и снова доработки. Так как все работают по аджайл скрамбану стоит отметить что в принципах водопада нет предварительных демо, промежуточных согласований и прочего. Это все от аджайл. В водопаде ТЗ, дедлайн на завершение всего ТЗ и по результатам демо, а потом согласование, что принимается что нет. Если представить весь ад водопада и потом перейти на аджайл - скорость разработки как раз таки и увеличится в 3, 4, а может быть и в 8 раз. Потому что фраза заказчика "я думал вы сделаете по другому" затягивает разработку кратно. И стоимость тоже.
Заказчик так делать не имеет права. ТЗ - это не какая то бумажка, это юридически обязывающий документ. Если заказчик поставил свою подпись и исполнитель выполнил работы, и результат работ удовлетворяет требованием ТЗ - принимай работу.
P.S. Отсюда и понятно, почему СКРАМ-мастера не любят и даже боятся ТЗ. Это ведь документ обязательный и для исполнителя. Подписал - выполняй! Не выполнил? С тебя дорогой СКРАМ-мастер и спросят в первую очередь.
Тут зависит то, что вам важнее: все полностью по ТЗ до каждой запятой и дальше их проблемы, или довольный заказчик, который с новым заказом придет к вам, а не к вашим более сговорчивым конкурентам. С точки зрения исполнителя как раз выгодно следовать ТЗ целиком и полностью, а потом тыкать клиенту "если вы хотели другого, то это ваши проблемы, вот ваша подпись, идите на хер или платите нам ещё за переделки". Тем же, кому важнее не сорвать денег и свалить в закат, а наладить плодотворное многолетнее сотрудничество, идут заказчикам навстречу и ориентируются не на строжайшее соблюдение ТЗ, а на то, чтобы заказчик получил то, что ему действительно нужно и остался доволен. И чтобы при на работе с такой целью рационально использовать ресурсы и не переделывать всё с нуля по три раза, и придумали все эти гибкие методологии, ключевое слово в них именно "гибкие".
ТЗ - это не какой то священный текст, не допускающий изменений. Нет - это просто документ, который вполне себе можно корректировать. Более того, зачатую исполнитель сам пишет ТЗ, и всегда можно по ходу работ его скорректировать при желании заказчика. Просто ТЗ дисциплинирует всех. Возникает понимание объемов работ и появляются четкие критерии их выполнения. Заказчик понимает за что он платит деньги и может жестко контролировать качество работы.
Ну и само-собой, что для сайта-визитки будет документ на пару страничек, а для системы управления ядерным реактором на пару сотен страничек. Разный подход и разная ответственность. В первом случае можно выдумывать всякие скрамы, аджайлы и прочие новомодности. В случае же ядерного реактора, работа по четкому ТЗ будет единственно возможным вариантом.
Это просто документ, который вполне себе можно корректировать. Более того, зачатую исполнитель сам пишет ТЗ, и всегда можно по ходу работ его скорректировать при желании заказчика.
Ну так аджайл грубо говоря это и есть способ корректировки ТЗ. Чтобы корректировать ТЗ, нужно знать, в какую сторону и каким образом его корректировать, и желательно делать это на начальных этапах разработки того или иного функционала, пока ещё не потратили кучу времени и не ушли далеко не в том направлении. И люди пришли к выводу, что самый лучший способ для этого - склепать прототип, показать его заказчику, получить обратную связь, внести правки и продолжить дальше. В этом, собственно, и суть аджайла - короткие итерации и быстрая обратная связь.
для сайта-визитки будет документ на пару страничек, а для системы управления ядерным реактором на пару сотен страничек. Разный подход и разная ответственность. В первом случае можно выдумывать всякие скрамы, аджайлы и прочие новомодности.
С этим никто не спорит. Но адерные реакторы и прочие подобные сферы (например ещё авиация и автомобилестроение) - это капля в море современного айти. В банкинге и финтехк, где цена ошибки тоже высока (риск потерять реальные деньги), аджайл очень распространен и отлично работает. В промышленной автоматизации, как ни удивительно, тоже, тут когда-то давно на Хабре в комментариях был рассказ одного человека, как они в древние времена занимались автоматизацией нефтегазопроводов и нефтепромыслов, и он там писал, что к чему-то очень близкому к аджайлу они пришли сами по себе, хотя даже слова такого не знали, и в итоге лучше стало и им, и их заказчикам из нефтянки.
Только вот заказчик не обязан ничего принимать. На испытаниях запросто может оказаться, что интерпретации исполнителя и заказчика расходятся и последний не считает ТЗ выполненным. И дальше только в суд и не факт, что исполнитель еще прав, тк возможно пытается натягивать сову на глобус, чтобы не переделывать ничего. И аджайл тут как раз очень кстати, тк позволит скорректировать реализацию на раннем этапе и прийти на испытания по сути как на формальность, тк заказчика уже все устраивает и он все видел. Интерес тут с обоих сторон есть и на моей практике теже гос заказчики очень желают так работать
Я такую вещь скажу, может быть для вас неожиданную. ТЗ - это не только про техническую часть, это еще и про деньги. Когда у вас проект на значимые для вас суммы (будь вы заказчик или исполнитель), то именно ТЗ страхует вас от недобросовестности другой стороны. В случае спорных и принципиальных для вас вопросов вы пойдете в суд. И суд будет рассматривать договор, ТЗ, протоколы и акты. А вот на всякие скарм и аджайл манифесты судья даже смотреть не будет. В общем ТЗ - это одна из таких вещей, которая прикрывает наши с вами задницы и в какой то мере защищает от недобросовестности второй стороны.
Более того скажу я вам. Когда я работаю по ГПХ, то я всегда для заказчика пишу краткое ТЗ, чтобы он понимал что и как будет сделано, и как затем он это смог проконтролировать. Когда я сдаю работу, то я всегда составляю протоколы. Мы их затем подписываем. И менеджеры и управленцы на той стороне очень любят такие протоколы. Как мне однажды один сказал - этот протокол прикроет меня в случае какой то проверки. Протокол покажет, что работа была реально выполнена, а не просто были попилены бабки)
P.S. Хотя бывало что просто руки пожмем с заказчиком и дело делаем. Почти никаких бумажек и прочей формалистики. Но в том случае мы друг друга давно знали, коньяки вместе пили) В общем, жизнь такая многогранная штука. Много в ней на доверии держится. Вот договоры, ТЗ, протоколы, акты призваны этот доверие немного улучшить.
Я видел реальный спор двух компаний по договору с ТЗ. Два года судебных заседаний, две экспертизы, и решение "ни вашим - ни нашим".
ТЗ само по себе не защищает ни от чего. Если мы с заказчиком подозреваем друг-друга в подготовке к кидку - тогда нужен полный комплект инженерно-конструкторской документации, включая методику приемо-сдаточных испытаний... Только вот пойди-напиши эту методику корректно когда продукта еще нету!
Я как разработчик, писал в своё время методику приемо-сдаточных испытаний на свой блок, а потом на испытаниях я по этой методике его сдавал представителю заказчика. Оформлялось всё это протоколами. В конце всех испытаний составлялся и подписывался акт. Да это работа, да рутинная работа. Но зато этот блок в составе всего комплекса аппаратуры уже более 10-и лет работает на объекте.
Я же совершенно согласен. Когда есть требования, и когда блок будет работать 10 лет - это так и должно быть! Но software потому и software что народ желает улучшений и изменений функционала быстрее чем раз в десятилетие. Желательно, как водится, вчера... И тут мы попадаем на зыбкую почву, где ни заказчик, ни исполнитель не могут составить ТЗ и методику приемо-сдаточных, причем не могут объективно - а не от лени, глупости или отсутствия образования - потому что _ни один из них_ на самом деле не знает будущего. И тут два выхода: когда еще до 2014 года один из наших предпринимателей решил заказать станок в Германии (то-ли гибочный, то-ли вальцовочный) - его тут же попросили ТЗ (ну или ответить на список из 60 предельно конкретных вопросов). А у него еще цех строится, и ему надо параметры станка в том числе для того, чтобы решить неопределенности с цехом. Когда он признался что не знает исчерпывающего списка параметров, немцы ему указали на дверь - вежливо, но твердо: мол, как определитесь - так и приходите, через 4-6 месяцев будет стоять и работать у вас в Сибири. Ну или идите к другим специалистам, которые вам запроектируют цех и сделают ТЗ на оборудование. В итоге, они пошли к итальянцам, делали станок (и параллельно строили цех) два года - и разошлись очень довольные друг-другом. Не будь на рынке раздолбаев-итальянцев готовых работать без четкого ТЗ - проект пришлось бы отменить. Выграет ли экономика в целом, если проекты без четко определенного будущего не будут иметь права на существование ? Скорее нет - должны цвести все цветы...
Вы задаёте вопрос Scrum'у: "Оно того стоило" на основании результатов своей команды и результатов БКС?
У БКС самих я думаю стоит спросить.
А теперь про Ваш Scrum.
Знаете почему его называют революционным? Потому что команда/компания в большинстве своём должна пережить революцию процессов, чтобы скарм не заработал. А если где-то не доработать, революции не случится.Не соблюдаете одну из ролей - всё в пустую. Нет одного эвента - всё в пустую. И т.д.
Из перечисленного я вижу упоминание только событий из Scrum.При этом Daily нарушен, Review тоже. Если подходить к доле рабочего времени приходяшегося на "церемонии", то его смело можно сократить как минимум на 2.5 часа за счёт более эффективного проведения Daily + ещё на 2 часа, если review проводит для всех сразу вместе. А если первое внутреннее ревью не проведёте или неуспешно его проведёте, внешнее проводить не будете? А я вам скажу, что вы эффективнее не только за счёт высвобожденного времени заработаете, а за даже счёт повышения эффективности этих событий. Здесь слишком мало места чтобы рассказать всю систему зависимостей, но это так.
Я ничего не вижу в статье про роли и распределение работы между ними.
Ничего нет про ценности. Вы можете сказать что-это абстрактная чушь, модная хрень... Но нет, ценности вполне реальные эффекты приносит по качеству и производительности. Кроме того, их даже можно измерить, на сколько они выражены, как они изменились.
Нет ничего про артефакты.
Нет никаких других практик.
По поводу сквозящей мысли о том, что эти мероприятия не нужны, можете ответить, вы о работе как узнаёте? Вы же как-то узнаёте что Вам надо что-то делать? Если Вы что-то делаете, значит узнаёте. Значит Вы в любом случае занимаетесь планирование в любом объёме, независимо от того есть у вас Scrum или нет. То что Вы покер используете и Вам это претит, дак не используйте. Scrum вообще ничего не говорит о том как планировать. Хоть в папугях измеряйте, хоть в часах.
То что у Вас нет взамозаменяемости и есть личный набор задач говорит о том, что нет взамозаменямости. Фактор автобуса у Вас в такой конфигурации сейчас какой? Это хорошо, не беспокоит? По канбану это одинм
В связи с этим, у меня предположение, что у Вас лишь некоторые атрибуты, Scrumfall'a. А так как революции не случилось, значит SCRUM не внедрился. Зачем тогда он него результатов ожидать в такой кондиции?
Вылечить вам Scrumfall можно, запустить можно, пользу от него реальную начать получать можно.
Нужен ли Вам Scrum - вот это отдельный вопрос. Он тоже комплексный. Зависит от среды определённости в которой Вы работаете, от компании, от продукта/сервиса.
Я сертифицированный Scrum мастер Kanban professional manafer, и я ещё не встречал на своём опыте ни одной компании с такой работой, для которой бы Scrum по самой его идее стоит на текущем этапе я бы сам рекомендовал, потому что он будет полезным на текущем этапе. Нет, он далеко не всем и не везде нужен. Приходится совершать революцию чтобы он заработал. Он хорош в комплексной среде (по Cynefin framework) для продуктовой работы в компаниях с уровнем зрелости 2 или хотя бы 1.5, по Kanban Maturity model. Вот тут сам боженька велел его начать использовать.
А вот если говорить про Kanban, то его не надо внедрять. Его артефакты и так есть у всех и везде. Вот этот метод примелем для любого производства. И то что используете из этого метода зависит лишь от ваших профессиональных менеджерских качеств. У вас есть список работ?
Я сертифицированный Scrum мастер Kanban professional manafer
Вот скажите, как профессионал, эпиграф - правдивый?
Приходится совершать революцию чтобы он заработал. Он хорош в комплексной среде (по Cynefin framework) для продуктовой работы в компаниях с уровнем зрелости 2 или хотя бы 1.5, по Kanban Maturity model. Вот тут сам боженька велел его начать использовать.
Я так понимаю 1.5 это от свидетелей оценки в стори поинтов с точностью до третьего знака до запятой?
Вообще то скрам это прыжок сразу на ML3.
Всегда был убежден, что планированием должен занимать лид, архитектор и РП
Зачем всю команду привлекать к планированию - загадка.
Остальные ритуалы с одной стороны создают некий каркас деятельности, обеспечивая определенную дисциплину, с другой стороны сотрудники находятся постоянно в состоянии подготовки и сдачи экзаменов, те режим постоянного давления.
Чтоб учесть все мнения всех профессионалов, составляющих команду.
Кто вам мешает учитывать?
Но делать шоу или ритуал из планирования, при этом в итоге решение все равно принимает лид и архитектор, на мой взгляд не рационально.
Особенно при наличии внутренних противоречий в команде.
Обычно в обсуждении участвует актив, остальные просто ждут решения.
в итоге решение все равно принимает лид и архитектор
Для госструктур очень характерно (да, у них тоже есть IT). Команда хочет одно, приходит Большой Начальник и говорит - будет иначе, я так решил. Такой вот ГосСкрам
Если вы лепите свой проект - ты вы и есть заказчик, делайте что хотите
Если вы делаете проект для внешнего заказчика - то именно он для вас и определяет и цели, и приоритеты, и выделяемые ресурсы.
И способ достижения целей, да:)))
Вы похоже из госухи?
Зачастую в ТЗ прописываются и особенности реализации - протоколы, системные платформы, фреймворки и т.д.
С госзаказами я не сталкивался, но с крупными заказчиками не один раз.
Так что по всякому бывает. Но конечно, определенная свобода внутри процесса исполнения проекта есть, но первичными являются внешние требования и ограничения.
Здесь надо усилием воли переключить мозги. Мы всегда работали в рамках иерархических команд, и всегда много ставим на личность и профессионализм руководителя. Скрам описывает работу в другой системе - где руководитель является администратором (канал эскалации проблем по менеджерской иерархии, бюджетирование, найм/увольнение и так далее). Он может ВООБЩЕ не принимать никакого участия в текущей жизни команды, и менеджерить таким способом 4-5-6 штук их. Да, иногда он появляется в совещаниях, иногда говорит какие-то новости - но в код даже не заглядывает.
Соответственно, процессы планирования, архитектуры, ревью и прочего - становятся предметом живого диалога с участием всех причастных. Это дорого, это менее эффективно чем хорошая команда при иерархическом руководителе (но много более эффективно чем та же команда при плохом руководителе) - но это работает и работает сверх-надежно (в смысле устойчивости к внешним факторам).
Ни разу не видела чтобы архитектор был частью scrum-команды, обычно архитектор один на несколько команд и решает исключительно архитектурные вопросы, что там делают команды ему мало интересно.
РП - обычно менеджер и не может оценивать задачки.
Лид теоретически оценить может, но при этом он может не знать каких то нюансов по некоторым задачам и ему их сложно оценить.
Поэтому и нужна вся команда, чтобы дать более точную и объективную оценку.
Плюс во время оценки можно задать вопросы и по технической части, чтобы у всех было понимание как, что и зачем мы будем делать, а не только у лида.
Если вы привлекаете команду, вы её прокачиваете и сплачаете, синхронизируетесь с исполнителем понимает ли он план, будет ли он ему следовать и т.п. да те же неочевидные идеи из опыта коллег получаете. Это дает в стратегическом плане много преимуществ. Но если вы разделяете ценности SCRUM, а если для вас это все непонятно и неинтересно то лучше даже не пробуйте станет хуже. Это просто один из вариантов организации работы в команде не более, с понятными и плюсами и минусами.
Вам понравится если без вашего участия подпишут сделать задачу за 2 дня, которая по вашему опыту должна выполняться за 4? А если бы Ваше мнение услышали, то оценили бы верно
Мне кажется, вы зря декомпозицию делаете на планировании, декомпозиция должна быть раньше. Не помню и не интересуюсь как там по гайдам, вроде декомпозировать надо на грумминге фичи.
Интересно, сколько времени у вас занимает реализация типичной фичи - спринт, два, полгода?
А с основным тезисом я согласен - чаще всего не стоило.
Если у вас дейли скрам занимает по полчаса, то вы вероятно не видели нормально работающую по скраму команду и попросту представляете, что такое скрам, скорее формально. Однако если бы команда и была работающая по скраму, я бы не называл прирост эффективности работы главной целью скрама - в реальности он нужен для предсказуемости результатов работы команд для менеджмента, т.е. для большей управляемости процесса разработки. Если в этой части вы не добились результатов - увольте или подайте в суд на тех, кто внедрял вам скрам.
Недостатком дейли в российской (а может быть и не только...) специфике является фокус на прошлом. Послушайте типичный дейлик в типичной компании - это школьный опрос по домашнему заданию: "... а я - учил!...". То есть дейлик - это, прости господи за менеджерский язык - не точка планирования, а точка контроля.
Теперь что с этим делать. Первое - если команда большая, то не надо делать дейли каждый день на всю команду. Разбивайте на рабочие группы не более 5 человек, и пусть синкаются сами внутри. Общий дейли - один раз в неделю, и хватит. Второе - на дейли надлежит ПЛАНИРОВАТЬ и СИНХРОНИЗИРОВАТЬ деятельность команды. То есть, если у вас есть релевантная для других членов команды информация из вчера (например, увидели необычное в логах или были вынуждены отступить от вчерашних договоренностей, и т.д.) - вы это озвучиваете. Дальше вы должны рассказать о том, что вы собираетесь делать. А другие могут задать вопрос или что-то посоветовать (или вы можете выяснить что вдвоем собираетесь править примерно одно и то же, поэтому есть смысл переговорить и делегировать это кому-то одному - реальный случай, кстати). Тут же решаются вопросы распредления ресурсов, если за них есть конкуренция (например, трудно тестировать две разные фичи на стейджинге если они еще не вмержены, и т.п.).
Это, конечно, трудно - потому что у большинства людей после школы или института нет опыта работы в горизонтальных связях: всегда есть учитель (преподаватель, начальник) который тебе скажет что делать, и потом с тебя спросит. Поэтому рефлексировать над своей работой и думать (и говорить языком!!!) как она влияет/может повлиять на других членов команды - надо учиться. Но оно на самом деле того стоит.
И если у вас дейли занимает много времени, и вы этим недовольны - то извините, обсуждали ли вы это на ретро ? Как бы ретро - это в первую руку встреча для обсуждения и улучшения процессов в команде, а не когда скрам-мастер всех развлекает...
Топикстартеру спасибо за прекрасную дискуссию в комментариях! Оно того стоило.
Выражаясь языком экономики, стоимость ритуалов SCRUM составляет 15% от стоимости команды. Эти средства уходят не на разработку, а на разговоры о том, кто что сегодня сделает, жалобы на процессы, игру в карты, показ сделанной работы руководству собственной фирмы и показ того же самого представителям заказчика.
Это координационные издержки, они всегда есть, что со скрамом, что без скрама.
Поэтому вопрос сколько их было до скрама и сколько со скрамом и после этого можно да сравнить и тогда можно говорить о это ужас ужас или нет.
Скорей всего без скрама вы их даже посчитать не можете :) так что...
Фундаментальная и неразрешимая проблема скрама, в том что реальная разработка не итеративна. На этом фоне описанные вами % не так уж и важны.
Очень странный пост. Вы пишете: ускорение на 10%. Стоило ли оно того? Очевидно, да. Раньше мы делали 10 задач, а теперь 11. И это несмотря на 15% времени на ритуалы.
У scrum, по личному опыту, есть 2 проблемы.
1. Команда, которая не желает работать по нему.
2. "Начальник", который не хочет терять свою важность в команде.
Что есть реальность, или эффективен ли SCRUM