Комментарии 36
Горшочек, может уже хватит варить?
Я ненавижу оценки, потому что они порождают политику и на самом деле не ускоряют выполнение работы или не делают её лучше (наоборот, это чаще всего так).
Встречный тезис: всё способно порождать и подпитывать политику, так что "порождает политику" - не работает как критерий выбора между вариантами.
Количественные оценки, по крайней мере, сцеплены с реальностью: если я оценил задачу в шесть дней, то либо я в действительности сделал её за шесть дней, либо нет (и четыре дня, и девять - одинаковое "нет"). Если моя сказанная вслух оценка была неверна, мне намного тяжелее придумать самооправдание "почему на самом деле я не ошибся".
Затем, оценка у вас всегда есть. Ответ "я не знаю" никогда не является честным отражением знания в голове (он может являться политически наиболее приемлемым, но если ваша коммуникация на работе определяется соображениями политики, то вы уже в глубокой заднице, независимо от того что прописано в графе "методология разработки"). Правильнее бы сказать что в голове есть распределение, но с не-точечными оценками тяжело осмысленно работать.
Требования Scrum в своей основе банальны донельзя: каждую итерацию озвучьте декомпозицию задачи на куски ограниченного размера (если не можете - воспользуйтесь помощью зала), вместе оцените эти куски, определите где кончается каждый конкретный кусок, отслеживайте насколько хорошо откалиброваны ваши оценки. Стратегически, упорядочите по приоритетам разные вещи которые "надо бы" сделать, добавляйте в бэклог вещи которые сделать надо, но раньше об этом никто не подумал.
Методология не мешает включить в список этих вещей финальное документирование модуля, построение proof-of-concept для некоторой фичи, рефакторинг неудачного класса и т.д. Насколько я вижу, главная проблема здесь - что методология делает эти затраты времени явными, не позволяя скрывать их под общим одеялом "вон сидит разработчик, что-то пилит". Но это не проблема методологии разработки, это проблема коммуникации, давайте их разделять.
Если ваше взаимодействие с менеджментом оказывается взаимно более конструктивным в формате "мы знаем что делаем, релиз будет в сентябре, отстаньте от команды" - хорошо, вы можете подправить правила взаимодействия с Product Owner на более "чёрноящиковые". Остальные правила при этом можно оставить на месте, они ничем не мешают (и позволяют вам лучше оценить, что релиз таки-будет в сентябре, а не к новому году). Если же одновременно вы хотите тратить время на технический долг, менеджмент хочет знать чем команда занимается, и при этом вы не хотите защищать перед менеджером необходимость выделения времени на технический долг, то давайте для начала называть вещи своими именами: вы хотите менеджера обмануть. И если вы выбираете методологию из соображений "что меньше мешает обманывать", то да, чем больше коммуникации и проверяемых количественных оценок заложено в методологию, тем менее она полезна для этой задачи.
Встречный тезис: всё способно порождать и подпитывать политику, так что "порождает политику" - не работает как критерий выбора между вариантами.
Тезис там в "они [оценки] ... на самом деле не ускоряют выполнение работы или не делают её лучше". Ну и плюс перевод дурацкий.
Правильнее бы сказать что в голове есть распределение, но с не-точечными оценками тяжело осмысленно работать.
Другими словами, мы вынуждены работать не с тем, что действительно важно, а с тем, что можем "осмысленно" оценить. Т.е. - по факту - то, о чём пишет автор - верно. С чем спорим-то?!
Насколько я вижу, главная проблема здесь ...
Он не про это же пишет. Он пишет про то, что на основе этих ("удобных", "осмысленных" и т.п.) оценок, в конечном счёте, производится планирование работы. О том, что - в реальности - если строго следовать этой методологии у вас - буквально - выбор из двух зол. Вы либо не работаете над тем, чем действительно нужно/важно, либо ваши планы - с огромной долей вероятности - накрываются медным тазом. И винить в том, что исполнитель выбирает первое, а не второе нужно не исполнителя, а методологию.
... и позволяют вам лучше оценить, что релиз таки-будет в сентябре, а не к новому году
Ну т.е. цель - "релиз в сентябре"? :-) То, что это хорошо для бизнеса, сомнений не вызывает. А вот для исполнителя - уже далеко не факт. И чем этот исполнитель более опытен - тем более "не факт". Собственно, об этом автор и пишет.
Другими словами, мы вынуждены работать не с тем, что действительно важно, а с тем, что можем "осмысленно" оценить.
Мысли преобразуются в слова с потерей информации. В данном случае потеря заметна только когда точечные оценки времени сами по себе уже очень хорошие и хочется высшие моменты распределения, большинство людей и команд не в этой точке.
Вы либо не работаете над тем, чем действительно нужно/важно, либо ваши планы - с огромной долей вероятности - накрываются медным тазом.
Не согласен. Вы можете ставить в план задачи, которые кажутся более важными. Затем вы их оцениваете так хорошо как можете.
Если у вас система поощрений привязана к точности оценки и тем самым создаёт стимул выбирать предсказуемые задачи вперёд важных - это проблема системы поощрений. Scrum, насколько я вижу, какой-то конкретной системы поощрений не предписывает, это другая проблема. Я согласен что она есть, но мне кажется что а) это проявление многоликой проблемы credit assignment (Шишков, прости...), у которой хорошего, универсального, известного решения просто нет, поэтому она вылезет при любом устройстве работы; б) конкретно в случае программной разработки тимлид/ПМ должны уметь противостоять этому стимулу и в видимых мне случаях вполне это делают.
Ну т.е. цель - "релиз в сентябре"? :-)
Цель - то, про что достигнут консенсус что это цель. Если одной стороне хочется результат X, а другой - Y и Z, то консенсуса нет, и это опять же проблема при любой методологии. В коммерческой разработке желательно (для получения денег всеми участниками), чтобы продажники имели внятное представление, что можно обещать клиентам к тем или иным срокам, к примеру. Исследовательская задача тоже может быть целью, но тоже обычно важны сроки: что к некоторой черте либо получается результат, либо делается вывод что результата не получилось.
В данном случае потеря заметна только когда точечные оценки времени сами по себе уже очень хорошие и хочется высшие моменты распределения, большинство людей и команд не в этой точке.
Вот честно. Вообще не понял к чему это всё было сказано :-(
Вы можете ставить в план задачи, которые кажутся более важными. Затем вы их оцениваете так хорошо как можете.
Мы точно о Scrum? В контексте статьи - план это бэклог спринта. Каким образом у вас в него пролезет "нечто" без estimate?!
Если у вас система поощрений привязана к точности оценки ...
К "точности оценки" привязано другое. Самой методологией, причем. Собственно, поэтому - так или иначе - и "система поощрений" будет привязана (в том числе) и к этой "точности".
Цель - то, про что достигнут консенсус что это цель ...
Бла-бла-бла. Просто вспомните про первоначальный тезис:
I hate estimates, because they don’t actually make the work get done faster or better
А с тем что "оценки" имеют ценность для PO и SM - никто не спорит.
автор пишет о коне в вакууме. Типа я бы хотел делать что-то такое, уххх, крутое, уххх полезное, а вынужден пилить фичи для бизнеса, пользы которых он не видит (а на самом деле не понимает, считая всех вокруг двоечками, а себя белопальтовым десятком). Ничего конкретного, мыслею по древу, что все вокруг дурачки, ничего не понимают, а он Д'Артаньян, знает, что если просто инженерам дать делать что-то важное, то получится важное. Или получится что-то неважное, мы ж творческие люди, лишь бы никто не смотрел и не канал за это каждые 2 недели. Просто деньги заносить не забывайте. У меня коты так же думают, откровенно. Чел мог бы быть хорошим котом.
Ну и занимается натягиванием совы на глобус, дергая узкие факты, извращая и подменяя их смысл, а потом придумывая им ложные цели. Это касается его отсылок "почему так делается, и кто это придумал так жить". Большей манипулятивной оленистики давненько не читал.
Чувак, иди прогай свой фейсбук3Д, тебе уже за 30, ты десятка-альфа-миллиардер-и-филантроп, у тебя куча возможностей и по твоим словам скиллов, так хрен ли ты этого не сделал? Что за тезисы про реально полезные и нужные вещи (какие вещи? Конкретно хоть 1 назвал?).
Но мы не узнаем, потому что перевод копипасты нам не сможет ответить)
На деле в разных схемах поработал, и могу сказать, что нет, нормальный тех.руководитель над командой вполне отлично слушает и помогает выбирать различные задачи, в том числе развитийные без ловушки "делаем маленькое за 2 недели". В продуктах устоявшихся уж точно. В стартапах нет, там всегда четко понятно, как догнать и перегнать через 5 лет, и пилить в них и пилить до лидеров рынка те самые 5 лет.
Я соглашусь, что статья эмоциональная и автор опирается только на собственный опыт. Перевел я ее скорее потому, что некоторые недостатки Agile / Scrum подсвечены ярко, в частности, вымывание ценных кадров. Кадры решают все. У вас был нормальный тех. руководитель и я рад за вас. Нам нужна методология, которую как минимум плохие менеджеры не смогут эксплуатировать в своих интересах, как аджайл, а как максимум – поможет сделать наглядной некомпетентность менеджеров и исполнителей, если таковая имеет место быть.
Плохие менеджеры могут испортить любую методологию. В поддержке и инфраструктуре многие специалисты ругают ITIL по тем же причинам, хотя методология тут вторична.
SCRUM сам по себе отличается от конкретной реализации в статье автора с его примерами. Ну и используя любую методологию нужно включать здравый смысл и иметь хороших командных менеджеров
Про оценки: Я не имею ничего против оценок в человеко-днях. Я думаю, главной проблемой здесь является то, что выполнение "плана" спринта в стори-поинтах становится метрикой, отслеживаемой менеджментом, и в силу закона Гудхарта такая метрика перестает давать какую-либо ценность. Второй проблемой являются сами стори-поинты, объем которых по факту никто не может конкретно объяснить, и в конечном итоге каждая команда имеет свой подход к переводу из сторипоинтов в условные человеко-дни.
Scrum со своими стори-поинтами пытается оценить сложность задачи, когда как на delivery в первую очередь влияет не предполагаемая сложность, а риски – риск пропуска сроков другой команды, баги в third party API и в целом количество неизвестных (unknowns) в конкретном функционале. Именно эти неизвестные факторы могут значительно повлиять на сроки delivery.
И если вы выбираете методологию из соображений "что меньше мешает обманывать", то да, чем больше коммуникации и проверяемых количественных оценок заложено в методологию, тем менее она полезна для этой задачи.
Вы знаете, большое количество коммуникации совершенно не мешает программистам при желании вешать лапшу на уши менеджерам ежедневно, при этом задачи можно декомпозировать таким образом, что из каждой мухи будет сделан слон. Я думаю, что автор статьи верно уловил тенденцию уравнивания высококвалифицированных и малоквалифицированных программистов на одном "поле" скрама, которая приводит к тому, что лучшие не выдерживают гонки по скоростному производству кода без оглядки на технический долг и уходят. И это уже вопрос кадровой политики. Распространено мнение, что лучшим, самым талантливым командам не особенно и нужен четко регламентированный процесс.
Что интересно, я дважды сталкивался (в российских условиях) с методикой, которую явно называли Scrum, и за описанием отсылали к Scrum Guide. И в обоих случаях мерой оценки задач были "часы работы данного исполнителя". Поэтому у меня есть впечатление, что Story Points - это отнюдь не непременный атрибут практики, не то что теории (в которой их изначально нет, и я готов спорить с аргументами о пользе их введения). И соображения "мне надо повозиться пару дней, чтобы понять, можно ли это сделать обсуждаемым способом вообще" вполне себе работали.
С другой стороны, сейчас я работаю в команде с принципиальным агностицизмом в отношении оценок времени. При хорошем опыте, приличном уровне и честности участников, застрять над задачей "думаю сделать это к пятнице" на месяц - печальная, повторяемая реальность. Поэтому, из моего опыта, проговаривание вслух декомпозиции на блоки меньше недели и их оценка - штука, негативные последствия нехватки которой я видел, а негативных последствий избытка - нет (и мои теоретические попытки их представить сводятся к избыточному микроменеджменту, который опять же, кажется, будет проблемой независимо от методологии).
Интересны причины, по которым участники застревали на задачах на месяц. Мне кажется, именно смещение акцента на раннее выявление рисков такого развития событий могут улучшить производительность команды, чем трата времени на аджайл покер с 3 - 5 - 8 стори-поинтами и соответственное переписывание user stories. Больше того, я бы скорее дал разработчикам несколько дней поработать непосредственно над фичей и ее низкоуровневой архитектурой, а уже потом разговаривал с ними о возможных дедлайнах.
Я думаю, главной проблемой здесь является то, что выполнение "плана" спринта в стори-поинтах становится метрикой ...
В смысле, "становится"?! Velocity в явном виде декларируется в Scrum как метрика, и отдельно расписано почему она важна, зачем её отслеживать и т.п.
... и в силу закона Гудхарта такая метрика перестает давать какую-либо ценность.
Если в смысле, что высокая Velocity становится целью для команды, и потом (достаточно быстро, на самом деле) приходит понимание того, как проще её набивать/удерживать - то полностью соглашусь с. Но, имхо, менеджмент в этом вопросе немножко вторичен. В том смысле, что если даже он - грубо говоря - играет по правилам, то лучше от этого не становится.
Я поинт автора (в этом плане) воспринял как, не то, что менеджмент "не такой какой-то", а в том, что он вообще есть. Собственно, и мой личный опыт в Scrum показывает что, это действительно работает только когда так и есть.
Scrum со своими стори-поинтами пытается оценить сложность задачи ...
"Сложность" - это слишком упрощенно же. По идее, в estimate входит (должно входить) всё, что влияет на delivery и, при этом, находится в зоне ответственности команды.
За короткое время уже вторая переводная статья того же автора, полная лютой ахинеи в адрес эджайла. Что бы это значило? Других тем нет? У автора неудачный опыт с эжайлом, психологическая травма, требующая компенсации таким вот способом?
Качество перевода, должен сказать, очень хорошее. Качество исходных материалов – ниже плинтуса. Этот – вообще набор абсолютно голословных выкриков, без малейших попыток чем-то подтвердить написанное.
Почему же? Просто эта тема автору интересна, он считает, что надо про нее рассказать на хабре. В статье много хороших мыслей, на мой взгляд.
По поводу голословных выкриков: посчастливилось работать в команде Acronis Storage, которая с нуля разработала отказоустойчивое хранилище, аналог CEPH, сделали S3 поверх него (я правда присоединился поздно и ничего полезного там не смог сделать, нечем похвастать). Так вот, в этой команде было человек 5 в среднем, никаким скрамом и эджайлом там не пахло, даже код ревью в привычном виде не было. Просто были люди, которые осознавали всю ответственность и работали на совесть. И это в такой области где риски потерять данные пользователей огромны.
Я тоже немного ощутил, то, что описывает автор. В числе первых людей начал работу над проектом, 2 года работал максимально эффективно, за первые 2 года сделал 2000 коммитов, при этом год работал тимлидом команды из 4 человек, приходилось и менеджерскими задачами заниматься. И в какой-то момент начальство решило настроить процессы, началось вот это "нельзя делать задачи не из спринта", желание работать пропало мгновенно, ушел оттуда через полгода.
Просто эта тема автору интересна
Я заметил. Только интерес какой-то нездоровый и весьма односторонний – выкапывает статьи, в которых оголтело критикуются недостатки эджайла, существующие только в воображении авторов. При этом абсолютно ничего не предлагается взамен.
В статье много хороших мыслей, на мой взгляд.
Наверное, я что-то пропустил. Приведите хотя бы одну. С позиции "как правильно" в ней есть единственное предложение: компании, управляемые инженерами. И апофеоз этой идеи в заключении:
Бизнес-ориентированная инженерия, в общем, — это тупик.
Только вот дело в том, что это глупость несусветная. Компании организуются не для получения автором удовольствия от работы, и даже не для создания красивых инженерных решений. Новаторские идеи и решения часто могут лежать в основе бизнеса компаний, но в конечном итоге, единственная цель их существования – зарабатывание денег. А инженеры (особенно увлечённые и талантливые) чаще всего довольно плохо в этом разбираются – если вообще задумываются. Инженер и бизнесмен – две абсолютно разные компетенции, а уж чтобы и то, и другое высокого класса – редкость необычайная. Когда они совпадают, получается что-то вроде Маска. Или Брина. Но, что характерно – чаще всего такое совпадение приводит к созданию гигантских, ориентированных на прибыль корпораций, в которых автор, скорее всего, тоже работать не захочет. В частности потому, что и эджайл в них в полный рост.
Всё ещё считаете статью полезной?
Как провалившееся коммунистическое государство, которое уравнивает людей, делая всех бедными
После этого выпада статейку можно прекращать изучать. Аффтор невменяем и пытается оперировать сущностями, ему неизвестными.
Приведёте пример богатого коммунистического государства? КНР - не предлагать, там есть право собственности на средства производства. То есть там - не коммунизм.
СССР, очевидно же. Богатое государство
Настолько богатое, что его граждане легко обменяли его на нормальную колбасу. Это если кратко...
"Богатое государство" не означает "богатые граждане"
Коммунистических государств в истории пока не было. И КНР и СССР - социалистические государства со смешанной, в той или иной степени, экономикой. В СССР, например, на всём протяжении его истории существовали кооперативные и различные коллективные формы собственности (артели, товарищества). Да и с колбасой не всё так однозначно, как некоторым сейчас кажется - я застал времена советских магазинов, под завязку забитых продовольственными и промышленными товарами - той же колбасой. И пропало это всё не из-за идеологии, как таковой...
Спасибо, отличная статья-предупреждение для безоговорочных любителей всего нового/иностранного, эффективных менеджеров и руководителей, считающей штурмовщину нормой. Интересно, чем отличался менеджмент того же Королева С.П. (космос) и Берия Л.П. (атом), который в сложнейших условиях решил неподьемные задачи в сроки, который до сих пор кажутся невероятными. Не является ли отсутствие свежих примеров признаком кратно возросшей бюрократии новых методик, с их-то автоматизацией?
Как всегда, не хватило доказательности, табличек итп, в которых бы было видно как и что испортилось от Agile/Scrum. Понятно что 70% отечественного бизнеса и госуправления до сих пор управляются по системе "я начальник ты дурак". Другие 30% играют в сабжи и BPMN. Однако не "притянутые за уши", правдивые метрики внедрений и оценок до/после мы от этих 30% не найдем нигде.
Как всегда, не хватило доказательности, табличек итп, в которых бы было видно как и что испортилось от Agile/Scrum.
Есть забавные статьи вроде такой (https://www.theregister.com/2024/06/05/agile_failure_rates/) про 268% более высокую вероятность неудачи для Agile проектов. Но фактически такую статистику подвести невозможно, поскольку все продуктовые команды в той или иной мере используют agile техники. Даже обычная канбан-доска, по мнению аджилистов, это Agile методика, хотя отец канбана в разработке, David J. Anderson, утверждал, что это не так, добавляя, что канбан – это истинный путь к гибкости (agility) – https://djaa.com/kanban-the-alternative-path-to-agility/
поверь, не эджайл появился, и все поменялось, а добрая половина примерно так и работала всегда, просто не было слова эджайл. Как в известной песне про попу, которая есть, а слова нет. И Королев с Хрущевым в том числе имели как элементы эджайла (планерки ежедневные на заводе, премии под конец месяца/итерации), квартальные и годовые планирования, переосмысления продуктов на ходу - чем блин не эджайл?
Методы мотивации в менеджменте Лаврентия Палыча берем во внимание при сравнении, или действительно думаете что бюрократия виновата?
Не буду таким категоричным, как другие комментаторы. С чем то я согласен, с чем-то нет, но есть ли рассмотрение какой-то альтернативы?
CCPM - только как альтернатива Waterfall
Prince2 - супер регламентированная штука, "творческие" люди тоже будут не в восторге, не говоря о том, что это не подходит для небольших/средних компаний.
По мне так Scrum + практики из XP довольно интересная тема, но также интересно, что предложил бы автор оригинала
Современные альтернативы, по крайней мере в западном бигтехе – это лайтовый канбан на минималках (https://blog.pragmaticengineer.com/project-management-at-big-tech/). Еще есть Shape Up от 37signals, но это достаточно специфическая методология, весьма opinionated, скажем так.
Очень субъективная статья, в которую запихали коммунизм, слежку, евреев и опенспейс. Водопад (священный Грааль PM - управления проектами) заклеймили. То плохо, это плохо. Начать надо с того что принять "дурного клиента" скорее побочный плюс, изначально Agile даёт быструю коммерциализацию - как говорится ничего личного, просто вместо полгода Водопада, вы за пару недель уже можете выбросить функционирующий прототип, а дальше ДевОпс вам в помощь. Невероятно эффективно.
Водопад ака Управление проектами (PM BOK)не менее эффективная модель в правильном месте с правильными руками. Особенно когда требуется "Квадратишь, Практишь, Гут".
Странно обвинять Agile в краткосрочности, если как раз в этом его главный плюс. Но многие пункты правильные: нет конвейера (рваный ритм), "Коммунизм" сениоров и инжеров, кстати, действительно факт, проблема социальной дисфункции (каждет тянет одеяло на себя).
Последняя история с компания которой управлял инженер это Intel, в каком она состоянии и что стало с Пэтом Гелсингером я знаю, так что не нужно рассказывать ...
Также непонятно откуда автор взял что перед Скрам Мастером надо отчитываться как перед Владельцами Продуктов (Owner). Тем более что Скрам Мастеру даётся власть (цитата "Эта команда не имела чёткого менеджера, поэтому выбирался лидер (например, «Scrum-мастер»), которому давалась власть") . Явно ошибка. Они другую роль играют, это вам не канонический руководитель проекта Водопадов который держит в ежовых руководицах.
"Agile был создан консультантами из маргинальных фирм для них самих" это уже не лезет ни в какие ворота ;). Учитывая что основа Agile была создана гораздо раньше - Contingency Theory. Художник так видит - Нуштош. Но то что там бесконечный производственный ад, это правда.
Сова очень сильно натянута глобус.
Agile был создан консультантами из маргинальных фирм для них самих" это уже не лезет ни в какие ворота ;). Учитывая что основа Agile была создана гораздо раньше - Contingency Theory.
Если взглянуть на биографии подписантов Agile Manifesto, то там не так много консультантов из больших консалтеров. Разве что Мартин Фаулер работает в крупном по английским меркам агентстве ThoughtWorks. Contingency Theory это замечательно, но эта теория не является аджайлом и не дает аджайлу никакого дополнительного веса. Итеративное программирование аджайл тоже присвоил себе, но не аджилисты его придумали, и не все итеративные подходы – аджайл.
Ну как бы Contingency является для Аджайла основой. Это все фреймворк оперативного планирования. В свою очередь, для самой Ситуативной теории (Contingency) "папой" является теория Хаоса, напр. Системо-Динамика. Аджайл всего лишь один из многих инструментов адаптации в условиях динамической внешней среды/процессов. В 80х их там много образовалось из-за перехода от Индустриальной эпохи к Постиндустриальной. Вы можете почитать оригинал J.W. Forester, Industrial dynamics, 1961, MIT.
Явно ошибка.
Это просто "корявости" перевода. В оригинале речь не про "отчитываться" и не про "например" :-)
это ваша авторская методология?
Если вам поможет, пользуйтесь на здоровье.
Пришел к этой схеме, когда предлагал систематизировать принятие решения в органах власти по единому образцу, чтобы тиражировать опыт на все территории нашей страны, но, как известно, никому не интересно, чтобы народ хорошо жил, кроме самого народа.
Подходит для всего. В том числе и для разработки программного продукта.
Уважаемый Автор, не поясните ли, что такое "бодишоп" из нижеприведённой цитаты?
В общем, люди склонны создавать два типа работы, как внутри компании, так и при передаче работы бодишопам.
И откуда Вы это странное слово взяли, если не секрет?
Open space-то тут причём? Agile и open space - это не синонимы.
Когда я читаю про все эти шаблоны управления, я не могу понять одного - столько умных людей пишут тонны умных статей про то, как надо управлять процессами на различных предприятиях. При этом в экономике (судя по другим статьям) дела, мягко говоря, не ахти. Сороконожка даже не столько пытается идти, сколько увлечена процессом пересчитывания ног и пальцев на них... Всё-таки, нужно сначала научиться заниматься делом, как таковым, а все эти паттерны управления использовать только там, где они реально могут что-то улучшить. Слишком много болтовни на тему "Как нам реорганизовать рабкрин"...
99 процентов людей эту статью не поймут вообще - все эти волшебные слова (agile, scrum, канбан) в конкретных условиях выглядят, как заклинания в мире, лишённом магии. Они были придуманы для другого мира, других пространств, заполненных чужими законами, традициями и обычаями, поэтому и не работают, а превращаются в своего рода религию...
Почему «Agile» и особенно Scrum ужасны