Так-то правда, спору нет. Я бы таких начальников от подчинённых изолировал. Но в западных компаниях сейчас очень много обратного. Демократия, псевдоаджайл, мы самоорганизующаяся команда, не решай ничего за нас. И почти никаких средств нажать на них. Другая крайность, но, как говорил ИВ, "Оба хужэ!"
Сами проблемы реальны. В этом смысле со статьёй трудно не согласиться. А вот методы -- тут много вопросов.
Во-первых, создать систему тотальной слежки, анонимных жалоб и всеобщих KPI — это, на мой взгляд, значит породить такую же токсичную атмосферу, только в другом стиле. В европейских компаниях это очень популярно, но помогает довольно плохо. Хотя вроде тут и цели по SMART, и каналы для жалоб, и прочее, но толку, увы, немного. В лучшем случае вместо атмосферы вечных гладиаторских боёв формируется атмосфера секты. Может, это и лучше, но не так радикально, как хотелось бы.
Во-вторых, "обучить эмоциональному интеллекту" — это как? Научить можно максимум имитации некоторых его проявлений, что же до эмоционального интеллекта, то вы человеку принудительно 10 лет психотерапии назначите? А что в эти 10 лет делать? А если не пойдёт он в терапию? Да и терапия ведь не для всех работает. Тяжёлое НРЛ или явную социопатию (а история с орешками и изюмом похожа на проявление этих проблем, хотя, может, просто у человека нервный срыв) чёрта с два выйдет надёжно вылечить, обычно пациент не захочет так глубоко копать.
Трекание потраченного времени -- ересь полная. Я трекаю остаток оценок по задачам, и то только для burndown'а, чтобы понять заранее, что спринт пошёл не так. А кто там сколько потратил -- нафиг мне это вообще знать? Когда кто-то халявит, это и так видно, а гестаповскими методами проверять каждого -- только ухудшать ситуацию. Команда, с которой ты враг и для которой ты источник постоянных проверок, не будет работать эффективно. И зачем тогда этот разрушающий контроль? Дела испортить?
Не, ну, конечно, бывает разное. Низкооплачиваемый низкоквалифицированный труд, высокая текучка, человек -- винтик, всех легко заменить. Но это совершенно особый случай, и обычно работать в таком месте не слишком интересно, скорее всего, я, как аджайл-коуч, туда просто не пойду. Кому из нормальных людей интересно быть надсмотрщиком в концлагере?
Ааааа! Вот о чём речь. Что у некоего пользователя, под которым запущен скрипт, появились права. Но где гарантия, что появятся? Или что после чтения данных права не восстановят?
Оценка всегда вопрос непростой. Некоторые люди оценивать работу очень не любят, и часто приходится изрядно поработать, объясняя, что, дав ту или иную оценку, человек не несёт за неё жёсткой ответственности. И некоторым командам в моей практике это было очень непросто объяснить. Если применяется оценка остатка работ для построения burndown, совсем сложно.
Тем не менее, обычно я настаиваю на оценке и на оценке остатка на дейли. Естественно, не микроменеджмента ради (чего некоторые боятся), а для контроля того, успеваем ли, не надо ли что-то неважное выкинуть и т. п. О проблеме всегда комфортнее узнать заранее. То же, как каждый работает, команде обычно видно и так, для этого не надо портить жизнь всем микроменеджментом.
А вот к тому, как объяснять стори-поинты, я в итоге сформировал такой подход, что говорю, что это идеальные человеко-часы. Для расчёта длины спринта при этом вводится некий волшебный коэффициент, равный стоимости стори-поинта в человеко-часах. В качестве стартового значения я рекомендую 1.5, а обычно он в итоге колеблется от 1.3 до 1.8, точному вычислению не подлежит (точные вычисления тут вообще, имхо, утопия), подбирается экспериментально. Ошибок при оценке всегда много, но если оценка не является совсем бредовой, сумма оценок задач в спринте имеет распределение, сильно отличающееся от распределений оценок отдельных задач. Известно, что сумма многих равномерно распределенных случайных величин имеет распределение с острым пиком в середине, и чем этих величин больше, тем больше шансов на получение предсказуемой суммы. Если же исходные величины распределены не совсем равномерно и всё-таки имеют какой-то максимум в районе верной оценки, то с суммой всё обычно совсем хорошо.
Декомпозиция -- неплохой способ, и её в любом случае стоит делать, но всё-таки трудоемкость отдельных задач часто сильно варьируется. После декомпозиции я рекомендую обычно оценивать части.Вот с чем бывает очень много проблем -- это с тем, что даже в кросс-функциональной команде обычно нет такого, что люди кросс-функциональны. Те же тестировщики -- отдельный ресурс. В итоге я часто советую давать не одну оценку задаче, а две (бывает и больше, м но чаще всего две). Тут, правда, надо потратить ещё немало усилий, чтобы загрузить тестировщиков (обычно работающих после разработчиков) равномерно -- это отдельная повесть о куче хитрых трюков, вплоть до впихивания в спринт задач, которые никто не планирует довести до протестированности и деплоя: они должны быть реализованы в этом спринте и загрузить тестировщиков на начало следующего.
В общем, это мир таких плясок с бубном, что даже программирование как таковое бледнеет.
Слушайте, объясните мне, пожалуйста, каким образом успешное открытие файла на чтение скриптом служит маркёром того, что кто-то в него полез? В упор не пойму, что этот скрипт, собственно, проверяет. Если бы проверялось то, не создал ли кто-то эти файлы, я бы понял, это подобным образом проверить можно. Но почему успешное открытие на чтение говорит о том, что кто-то файл прочитал?
Справедливости ради, если команда имеет неформального лидера, это тоже случай самоорганизации. Но соглашусь, что часто под самоорганизацией ошибочно понимают полное всеобщее равенство и отсутствие иерархий, которое есть утопия.
Кросс-функциональные же и правда редки. Я давно перестал во многих случаях даже пытаться её добиться. Скажем, одна из команд: два тестера, три бекендера, фронтендер и саппортер, большинство -- по аутстаффингу и не очень надолго. И что, мне предлагается убедить их, что надо за счёт заказчика выровнять компетенции? Или чтобы этих выгнали и заменили? Такой бред я им не предложу.
Я бы сказал, что Скрам -- действительно не самоцель. В реальности приходится строить свой процесс, и он лишь напоминает Скрам, поскольку заимствовал оттуда многие черты.
Что же касается многих идей -- кросс-функциональности, частых релизов, то, увы, это действительно не всегда применимо. Самый радикальный пример -- это когда у вас продукт с 30-летней историей, большая часть которого создана не то что без всех этих Continuous Delivery, а из расчёта, что тестировщики глазами посмотрят. (Конечно, есть вещи, которые надо смотреть именно глазами, но когда 95% функциональности тестируется так, релиз даже каждые две недели -- утопия). Самое смешное, что и новые продукты часто создаются именно так, и ключевой вопрос архитектуры современных продуктов -- "как это непрерывно тестировать?" -- игнорируется с самого начала. И в итоге мы получаем ту же историю и ломаем рекомендуемый процесс под реальность.
Ломать процесс при этом именно приходится, выхода нет. Но жаль, что в эту, пардон, задницу, попадают новые продукты, а не 30-летние монстры с десятками миллионов строк кода, которых действительно могила исправит.
А уж когда на странные процессы внизу накручивается, пардон, какой-нибудь SAFe, смотреть на это часто и вовсе больно.
Нет, тогда не компьютеры сбоили часто, а система зависала часто по причине полного отсутствия защищённого режима в 8086 и 8088. Изоляция программ была совершенно невозможна, все использовали одно адресное пространство, могли выполнять любые инструкции процессора и делать что угодно, поэтому любой сбой в прикладном приложении обычно клал систему.
Правда, комбинация Ctrl-Alt-Del работала тоже не всегда. Если программа сама обрабатывала клавиатурный ввод без помощи BIOS или зависала, предварительно запретив прерывания (скажем, в обработчике прерывания), то через Ctrl-Alt-Del ничего было не добиться. Например, большинство игр, естественно, сами обрабатывали прерывания от клавиатуры.
Оценка сугубо по результатам тестов, конечно, лишена индивидуальности, спору нет. И система образования (даже сами вузы) во многих сферах сильно устарела, это тоже правда. Если хирургов и других медиков, скажем, надо всё-таки учить привычным образом, то большинство профессий вполне допускают и самостоятельное освоение. Это с одной стороны.
А с другой -- некий формальный барьер всё равно надо преодолеть. ЕГЭ, при всей своей нелепости, есть фильтр на мотивацию к учёбе, пусть и сильно несовершенный. И сдать его на приемлемом уровне 99% мотивированных учеников вполне в состоянии. Исключения есть: скажем, сдать русский с дисграфией сложно, а талантливый, например, математик или психолог может иметь такой дефект. Было бы хорошо, чтобы такие исключения обрабатывались как-то корректно. Однако вообще любая система отбора -- не без дыр. То, что было до ЕГЭ, тоже не было совершенно, но как-то же мы сдавали и поступали?
Да, давно пора снизить формализацию требований к образованию в тех областях, где это возможно (вот у медиков, повторюсь, точно нельзя, хирург не может учиться по онлайн-курсу). Думаю, это придёт. Но, увы, сейчас переходный период.
Во времена моего программистского детства почти 40 лет назад мы обычно не знали названий конкретных алгоритмов поиска пути, но знали две группы алгоритмов -- "поиск вглубь" (хороший пример -- рекурсивные алгоритмы), при котором ты просматривает путь сначала вглубь, потом вариации, и "поиск вширь", при котором идёшь от одной вершины и подсчитываешь цену пути от начала до набора просматриваемых в данный момент точек. Именно ко второй группе относится Ваш алгоритм.
Дальше на основе общей идеи этих групп можно конструировать алгоритмы под конкретную задачу, часто с серьёзными вариациями (например, для конкретной задачи часто нужен необычный порядок выборки вершины из набора просматриваемых). Остаётся прикинуть в каждом случае две основных характеристики алгоритма -- вычислительную сложность и (сейчас это реже надо смотреть) используемую память. Иногда -- для среднего и худшего случая отдельно. Вообще это всё очень забавный конструктор алгоритмов, в который раньше постоянно играли в олимпиадных задачах.
Да, многие так и думают. :-) Хотя реально это важнейшая вещь, часто куда важнее спринт ревью. И как-то у меня обычно люди реально говорят, что им нравится и не нравится в процессе, что пошло не так, что и как стоит попробовать иначе, и очень редко это отсутствие очистителя. :-) Именно по итогам ретроспектив можно процесс настраивать. Scrum -- это, имхо, в последнюю очередь ритуалы. Если некий ритуал мешает, мы его просто заменяем тем, что нам надо, и пусть хоть сто книжек возмущаются, именно в этом суть нормального вменяемого Agile, идеи которого в ориентации на реальность, а не на процессные правила.
В большинстве компаний Scrum вообще используют совершенно безумно, а потом удивляются, что люди выгорают и увольняются. Особенно меня умиляет желание сразу реализовать какой-нибудь SAFe в армейском стиле хождения строем. Но зовут варваров-консультантов, платят им миллионы и не думают, не фигню ли мы делаем. Это же во всём мире принято. :-)
А ещё в головах сеют полный бред типа "суть Agile в том, что всё решает команда". В плане принятия решений суть в том, что всё должны решать те, кто имеет компетенции для принятия именно этого решения, а не демократическое голосование. Часто это команда. Или команда + продакт овнер. Или ещё и представитель бизнеса, знающий нужный аспект. Или часть команды. Или даже конкретный человек. Но не некий "начальник" и не голосование людей, ничего не знающих о вопросе.
Соглашусь с тем, что если Scrum и Agile вообще воспринимать как набор правил, если реализовывать их "по книжке", не понимая сути, но видя букву, обычно так и получается -- уродливая потогонка и хронический стресс.
Но в действительности надо всего лишь не обкарнывать реальность под буквальное понимание Scrum, а дорабатывать методологию под свой случай. Просто я очень часто слышу совершенно химерические представления о том, как какие-то вещи надо делать в Scrum (просто потому, что в некоей книжке автор советовал так). Но большинство легенд совершенно бредовы.
Ообычно это:
"Нельзя ничего менять в спринте по ходу выполнения". А кто это сказал? Нет, ну если вы полностью поменяли видение задач на спринт, лучше, наверное, прервать и перепланировать (и не считать это бедой или виной команды). Но если вам просто регулярно падают баги, просто, например, оставляйте на них ресурсы при планировании. Посчитайте (грубо: точные расчёты тут -- ересь) реальную скорость выполнения задач с учётом обычного количества отвлечений -- и спокойно берите разумное количество срочных багов, не думая, что ваш мир рушится.
"Полная кроссфункциональность команды любой ценой". Оценили трудоёмкость задач в Стори пометах, разделили на размер команды, учли скорость -- и всё. Ребята, а тестировщики ручные у вас есть? Они тоже взаимозаменяемы с разработчиками? А фронтендер с бэкэндером? Вот прямо на 100%? И вы правда хотите тут полной кроссфункциональность? А зачем? Потому что в книжке так написано? Но извините, если тестировщиков у вас не хватает, вам всё равно придётся разделять оценку затрат на тестирование и на разработку. А иначе ваши абстрактные стори поинты в вакууме не покажут вам, что вы реально успеете, и не помогут спланировать спринт. И оценка становится многомерной. Мне приходилось работать с командой, где потребовалось разделить бэкенд, фронтенд и тестирование, что дало трёхмерную оценку и три burn down graph'а на одном листе. Но это работало. И мне было абсолютно плевать, что обычно так делать не рекомендуют.
"Жёсткая и одинаковая длина спринтов". Если вы не вписаны в релизный график большей сущности, то зачем? Пусть длина колеблется от полутора до трёх недель, а завершение подгадывается к важным внешним событиям. Кому это мешает?
"Спринты подряд". А нафиг? Во-первых, небольшой разрыв между спринтами даёт расслабиться и подумать о долговременных задачах. Во-вторых, пошёл у вас период чистого багфикса с полной непредсказуемостью и отсутствием интерактивности -- так вообще перейдите к Канбану и не вымучивайте цели спринтов там, где их фактически нет.
"Спринт нельзя продлить". Ну, положим, не очень желательно. Но затянули на день (если никого не подводите, конечно) -- невелика беда. Обсудили на ретроспективе, сделали выводы -- и перестали переживать.
В общем, надо методологию подгибать под реальность, а не наоборот. Иначе выйдет death march, а это жесть.
Так-то правда, спору нет. Я бы таких начальников от подчинённых изолировал. Но в западных компаниях сейчас очень много обратного. Демократия, псевдоаджайл, мы самоорганизующаяся команда, не решай ничего за нас. И почти никаких средств нажать на них. Другая крайность, но, как говорил ИВ, "Оба хужэ!"
Сами проблемы реальны. В этом смысле со статьёй трудно не согласиться. А вот методы -- тут много вопросов.
Во-первых, создать систему тотальной слежки, анонимных жалоб и всеобщих KPI — это, на мой взгляд, значит породить такую же токсичную атмосферу, только в другом стиле. В европейских компаниях это очень популярно, но помогает довольно плохо. Хотя вроде тут и цели по SMART, и каналы для жалоб, и прочее, но толку, увы, немного. В лучшем случае вместо атмосферы вечных гладиаторских боёв формируется атмосфера секты. Может, это и лучше, но не так радикально, как хотелось бы.
Во-вторых, "обучить эмоциональному интеллекту" — это как? Научить можно максимум имитации некоторых его проявлений, что же до эмоционального интеллекта, то вы человеку принудительно 10 лет психотерапии назначите? А что в эти 10 лет делать? А если не пойдёт он в терапию? Да и терапия ведь не для всех работает. Тяжёлое НРЛ или явную социопатию (а история с орешками и изюмом похожа на проявление этих проблем, хотя, может, просто у человека нервный срыв) чёрта с два выйдет надёжно вылечить, обычно пациент не захочет так глубоко копать.
Трекание потраченного времени -- ересь полная. Я трекаю остаток оценок по задачам, и то только для burndown'а, чтобы понять заранее, что спринт пошёл не так. А кто там сколько потратил -- нафиг мне это вообще знать? Когда кто-то халявит, это и так видно, а гестаповскими методами проверять каждого -- только ухудшать ситуацию. Команда, с которой ты враг и для которой ты источник постоянных проверок, не будет работать эффективно. И зачем тогда этот разрушающий контроль? Дела испортить?
Не, ну, конечно, бывает разное. Низкооплачиваемый низкоквалифицированный труд, высокая текучка, человек -- винтик, всех легко заменить. Но это совершенно особый случай, и обычно работать в таком месте не слишком интересно, скорее всего, я, как аджайл-коуч, туда просто не пойду. Кому из нормальных людей интересно быть надсмотрщиком в концлагере?
Ааааа! Вот о чём речь. Что у некоего пользователя, под которым запущен скрипт, появились права. Но где гарантия, что появятся? Или что после чтения данных права не восстановят?
Оценка всегда вопрос непростой. Некоторые люди оценивать работу очень не любят, и часто приходится изрядно поработать, объясняя, что, дав ту или иную оценку, человек не несёт за неё жёсткой ответственности. И некоторым командам в моей практике это было очень непросто объяснить. Если применяется оценка остатка работ для построения burndown, совсем сложно.
Тем не менее, обычно я настаиваю на оценке и на оценке остатка на дейли. Естественно, не микроменеджмента ради (чего некоторые боятся), а для контроля того, успеваем ли, не надо ли что-то неважное выкинуть и т. п. О проблеме всегда комфортнее узнать заранее. То же, как каждый работает, команде обычно видно и так, для этого не надо портить жизнь всем микроменеджментом.
А вот к тому, как объяснять стори-поинты, я в итоге сформировал такой подход, что говорю, что это идеальные человеко-часы. Для расчёта длины спринта при этом вводится некий волшебный коэффициент, равный стоимости стори-поинта в человеко-часах. В качестве стартового значения я рекомендую 1.5, а обычно он в итоге колеблется от 1.3 до 1.8, точному вычислению не подлежит (точные вычисления тут вообще, имхо, утопия), подбирается экспериментально. Ошибок при оценке всегда много, но если оценка не является совсем бредовой, сумма оценок задач в спринте имеет распределение, сильно отличающееся от распределений оценок отдельных задач. Известно, что сумма многих равномерно распределенных случайных величин имеет распределение с острым пиком в середине, и чем этих величин больше, тем больше шансов на получение предсказуемой суммы. Если же исходные величины распределены не совсем равномерно и всё-таки имеют какой-то максимум в районе верной оценки, то с суммой всё обычно совсем хорошо.
Декомпозиция -- неплохой способ, и её в любом случае стоит делать, но всё-таки трудоемкость отдельных задач часто сильно варьируется. После декомпозиции я рекомендую обычно оценивать части.Вот с чем бывает очень много проблем -- это с тем, что даже в кросс-функциональной команде обычно нет такого, что люди кросс-функциональны. Те же тестировщики -- отдельный ресурс. В итоге я часто советую давать не одну оценку задаче, а две (бывает и больше, м но чаще всего две). Тут, правда, надо потратить ещё немало усилий, чтобы загрузить тестировщиков (обычно работающих после разработчиков) равномерно -- это отдельная повесть о куче хитрых трюков, вплоть до впихивания в спринт задач, которые никто не планирует довести до протестированности и деплоя: они должны быть реализованы в этом спринте и загрузить тестировщиков на начало следующего.
В общем, это мир таких плясок с бубном, что даже программирование как таковое бледнеет.
Слушайте, объясните мне, пожалуйста, каким образом успешное открытие файла на чтение скриптом служит маркёром того, что кто-то в него полез? В упор не пойму, что этот скрипт, собственно, проверяет. Если бы проверялось то, не создал ли кто-то эти файлы, я бы понял, это подобным образом проверить можно. Но почему успешное открытие на чтение говорит о том, что кто-то файл прочитал?
Справедливости ради, если команда имеет неформального лидера, это тоже случай самоорганизации. Но соглашусь, что часто под самоорганизацией ошибочно понимают полное всеобщее равенство и отсутствие иерархий, которое есть утопия.
Кросс-функциональные же и правда редки. Я давно перестал во многих случаях даже пытаться её добиться. Скажем, одна из команд: два тестера, три бекендера, фронтендер и саппортер, большинство -- по аутстаффингу и не очень надолго. И что, мне предлагается убедить их, что надо за счёт заказчика выровнять компетенции? Или чтобы этих выгнали и заменили? Такой бред я им не предложу.
Я бы сказал, что Скрам -- действительно не самоцель. В реальности приходится строить свой процесс, и он лишь напоминает Скрам, поскольку заимствовал оттуда многие черты.
Что же касается многих идей -- кросс-функциональности, частых релизов, то, увы, это действительно не всегда применимо. Самый радикальный пример -- это когда у вас продукт с 30-летней историей, большая часть которого создана не то что без всех этих Continuous Delivery, а из расчёта, что тестировщики глазами посмотрят. (Конечно, есть вещи, которые надо смотреть именно глазами, но когда 95% функциональности тестируется так, релиз даже каждые две недели -- утопия). Самое смешное, что и новые продукты часто создаются именно так, и ключевой вопрос архитектуры современных продуктов -- "как это непрерывно тестировать?" -- игнорируется с самого начала. И в итоге мы получаем ту же историю и ломаем рекомендуемый процесс под реальность.
Ломать процесс при этом именно приходится, выхода нет. Но жаль, что в эту, пардон, задницу, попадают новые продукты, а не 30-летние монстры с десятками миллионов строк кода, которых действительно могила исправит.
А уж когда на странные процессы внизу накручивается, пардон, какой-нибудь SAFe, смотреть на это часто и вовсе больно.
Нет, тогда не компьютеры сбоили часто, а система зависала часто по причине полного отсутствия защищённого режима в 8086 и 8088. Изоляция программ была совершенно невозможна, все использовали одно адресное пространство, могли выполнять любые инструкции процессора и делать что угодно, поэтому любой сбой в прикладном приложении обычно клал систему.
Правда, комбинация Ctrl-Alt-Del работала тоже не всегда. Если программа сама обрабатывала клавиатурный ввод без помощи BIOS или зависала, предварительно запретив прерывания (скажем, в обработчике прерывания), то через Ctrl-Alt-Del ничего было не добиться. Например, большинство игр, естественно, сами обрабатывали прерывания от клавиатуры.
Оценка сугубо по результатам тестов, конечно, лишена индивидуальности, спору нет. И система образования (даже сами вузы) во многих сферах сильно устарела, это тоже правда. Если хирургов и других медиков, скажем, надо всё-таки учить привычным образом, то большинство профессий вполне допускают и самостоятельное освоение. Это с одной стороны.
А с другой -- некий формальный барьер всё равно надо преодолеть. ЕГЭ, при всей своей нелепости, есть фильтр на мотивацию к учёбе, пусть и сильно несовершенный. И сдать его на приемлемом уровне 99% мотивированных учеников вполне в состоянии. Исключения есть: скажем, сдать русский с дисграфией сложно, а талантливый, например, математик или психолог может иметь такой дефект. Было бы хорошо, чтобы такие исключения обрабатывались как-то корректно. Однако вообще любая система отбора -- не без дыр. То, что было до ЕГЭ, тоже не было совершенно, но как-то же мы сдавали и поступали?
Да, давно пора снизить формализацию требований к образованию в тех областях, где это возможно (вот у медиков, повторюсь, точно нельзя, хирург не может учиться по онлайн-курсу). Думаю, это придёт. Но, увы, сейчас переходный период.
Во времена моего программистского детства почти 40 лет назад мы обычно не знали названий конкретных алгоритмов поиска пути, но знали две группы алгоритмов -- "поиск вглубь" (хороший пример -- рекурсивные алгоритмы), при котором ты просматривает путь сначала вглубь, потом вариации, и "поиск вширь", при котором идёшь от одной вершины и подсчитываешь цену пути от начала до набора просматриваемых в данный момент точек. Именно ко второй группе относится Ваш алгоритм.
Дальше на основе общей идеи этих групп можно конструировать алгоритмы под конкретную задачу, часто с серьёзными вариациями (например, для конкретной задачи часто нужен необычный порядок выборки вершины из набора просматриваемых). Остаётся прикинуть в каждом случае две основных характеристики алгоритма -- вычислительную сложность и (сейчас это реже надо смотреть) используемую память. Иногда -- для среднего и худшего случая отдельно. Вообще это всё очень забавный конструктор алгоритмов, в который раньше постоянно играли в олимпиадных задачах.
Да, многие так и думают. :-) Хотя реально это важнейшая вещь, часто куда важнее спринт ревью. И как-то у меня обычно люди реально говорят, что им нравится и не нравится в процессе, что пошло не так, что и как стоит попробовать иначе, и очень редко это отсутствие очистителя. :-) Именно по итогам ретроспектив можно процесс настраивать. Scrum -- это, имхо, в последнюю очередь ритуалы. Если некий ритуал мешает, мы его просто заменяем тем, что нам надо, и пусть хоть сто книжек возмущаются, именно в этом суть нормального вменяемого Agile, идеи которого в ориентации на реальность, а не на процессные правила.
В большинстве компаний Scrum вообще используют совершенно безумно, а потом удивляются, что люди выгорают и увольняются. Особенно меня умиляет желание сразу реализовать какой-нибудь SAFe в армейском стиле хождения строем. Но зовут варваров-консультантов, платят им миллионы и не думают, не фигню ли мы делаем. Это же во всём мире принято. :-)
А ещё в головах сеют полный бред типа "суть Agile в том, что всё решает команда". В плане принятия решений суть в том, что всё должны решать те, кто имеет компетенции для принятия именно этого решения, а не демократическое голосование. Часто это команда. Или команда + продакт овнер. Или ещё и представитель бизнеса, знающий нужный аспект. Или часть команды. Или даже конкретный человек. Но не некий "начальник" и не голосование людей, ничего не знающих о вопросе.
Соглашусь с тем, что если Scrum и Agile вообще воспринимать как набор правил, если реализовывать их "по книжке", не понимая сути, но видя букву, обычно так и получается -- уродливая потогонка и хронический стресс.
Но в действительности надо всего лишь не обкарнывать реальность под буквальное понимание Scrum, а дорабатывать методологию под свой случай. Просто я очень часто слышу совершенно химерические представления о том, как какие-то вещи надо делать в Scrum (просто потому, что в некоей книжке автор советовал так). Но большинство легенд совершенно бредовы.
Ообычно это:
"Нельзя ничего менять в спринте по ходу выполнения". А кто это сказал? Нет, ну если вы полностью поменяли видение задач на спринт, лучше, наверное, прервать и перепланировать (и не считать это бедой или виной команды). Но если вам просто регулярно падают баги, просто, например, оставляйте на них ресурсы при планировании. Посчитайте (грубо: точные расчёты тут -- ересь) реальную скорость выполнения задач с учётом обычного количества отвлечений -- и спокойно берите разумное количество срочных багов, не думая, что ваш мир рушится.
"Полная кроссфункциональность команды любой ценой". Оценили трудоёмкость задач в Стори пометах, разделили на размер команды, учли скорость -- и всё. Ребята, а тестировщики ручные у вас есть? Они тоже взаимозаменяемы с разработчиками? А фронтендер с бэкэндером? Вот прямо на 100%? И вы правда хотите тут полной кроссфункциональность? А зачем? Потому что в книжке так написано? Но извините, если тестировщиков у вас не хватает, вам всё равно придётся разделять оценку затрат на тестирование и на разработку. А иначе ваши абстрактные стори поинты в вакууме не покажут вам, что вы реально успеете, и не помогут спланировать спринт. И оценка становится многомерной. Мне приходилось работать с командой, где потребовалось разделить бэкенд, фронтенд и тестирование, что дало трёхмерную оценку и три burn down graph'а на одном листе. Но это работало. И мне было абсолютно плевать, что обычно так делать не рекомендуют.
"Жёсткая и одинаковая длина спринтов". Если вы не вписаны в релизный график большей сущности, то зачем? Пусть длина колеблется от полутора до трёх недель, а завершение подгадывается к важным внешним событиям. Кому это мешает?
"Спринты подряд". А нафиг? Во-первых, небольшой разрыв между спринтами даёт расслабиться и подумать о долговременных задачах. Во-вторых, пошёл у вас период чистого багфикса с полной непредсказуемостью и отсутствием интерактивности -- так вообще перейдите к Канбану и не вымучивайте цели спринтов там, где их фактически нет.
"Спринт нельзя продлить". Ну, положим, не очень желательно. Но затянули на день (если никого не подводите, конечно) -- невелика беда. Обсудили на ретроспективе, сделали выводы -- и перестали переживать.
В общем, надо методологию подгибать под реальность, а не наоборот. Иначе выйдет death march, а это жесть.