[{"data":1,"prerenderedAt":155},["ShallowReactive",2],{"footer-topics-ru":3,"post-ru-agile-ai-values-principles-estimation-is-not-the-problem":70},{"topics":4},[5,21,33,46,58],{"locale":6,"name":7,"slug":8,"blurb":9,"summary":10,"state":11,"featuredOnHub":12,"hubOrder":13,"accent":14,"questionsTitle":15,"questions":16,"body":20},"ru","Путь","the-journey","От первых экспериментов с Agile × ИИ до работающей системы — история мысли, стоящей за ней.","От первых экспериментов до работающей системы — настоящая история создания Agile4AI, включая неверные повороты, которые определили всё.","published",true,2,"gold","Чему этот путь продолжает нас учить",[17,18,19],"Что убедило нас, что Agile и ИИ созданы друг для друга, — и что едва не убедило нас в обратном?","Какие неверные повороты оказались самыми поучительными?","Как SCI прошёл путь от эксперимента с копированием и вставкой до ответов ИИ, на которые действительно можно положиться?","\nКаждая идея в этом разделе родилась из нашего собственного опыта разработки Agile4AI. Нам не терпится поделиться этой историей с вами — и победами, и провалами, — потому что мы убеждены: учиться работать с ИИ лучше мы можем только вместе. То, к чему мы пришли, родилось не из теории. Оно родилось из практики, из ошибок, из готовности начать заново с учётом усвоенных уроков.\n\nВсё началось с простого вопроса: можно ли переосмыслить Agile для эпохи ИИ? А дальше были годы экспериментов, рухнувших допущений, неожиданных открытий и медленного вызревания чего-то, что и вправду работает, — подхода под названием Структурированный совместный интеллект (SCI) и построенной на нём системы Agile4AI.\n\nЭто не приглаженная ретроспектива, написанная задним числом. Это история, рассказанная настолько близко к тому, как всё было на самом деле, насколько это возможно, — со всеми тупиками, минутами сомнений и прорывами, которые переворачивали наши представления.\n\nМы делимся ею, потому что урок заключён в самой истории. Выводы важны, но не менее важно и *то, как мы к ним пришли*, — ведь именно путь показывает, что сработало, что нет и почему.\n\nМатериалы этого раздела охватывают всю дугу пути: ранние эксперименты с совместной работой с ИИ, рождение SCI, отдельные открытия, изменившие то, как мы работаем, и вехи, которые стоит отметить. Какие-то тексты получились созерцательными. Какие-то — без прикрас. Но все они — настоящие.\n\nЕсли вам хочется понять, почему Agile4AI и SCI вообще появились на свет, — а не только что они собой представляют, — начните отсюда.\n",{"locale":6,"name":22,"slug":23,"blurb":24,"summary":25,"state":11,"featuredOnHub":12,"hubOrder":26,"accent":14,"questionsTitle":27,"questions":28,"body":32},"Agile: расшифровка","agile-decoded","Что на самом деле означают термины Agile — не привычные сокращения, не версия карго-культа, не глоссарий методолога.","Словарь Agile широко используется и широко понимается неверно. Правильно понимать термины — это не педантизм, а разница между ритуалом и работой.",3,"Почему терминология имеет принципиальное значение",[29,30,31],"Если стендап проводится как статусный отчёт, что на самом деле теряет команда?","Когда «Методология Agile» стала стандартным выражением, как это повлияло на подход организаций к трансформации?","Каковы издержки команды, которая может назвать каждую практику Agile, но не понимает назначения ни одной из них?","\nУ Agile проблема со словарём. Не потому что термины непонятны — большинство людей в современных организациях их слышали. А потому что это знакомые слова, используемые в совершенно ином контексте, и без этого контекста люди соотносят их с тем, что им уже известно.\n\nКогда кто-то впервые встречает понятие «Scrum Master», ближайшим доступным концептом оказывается «менеджер проекта». Такое соответствие кажется естественным — почти очевидным. Контекст совершенно другой.\n\nНикто не выстроил достаточно чёткого моста между ними. А проблема усилилась, когда добросовестные практики — люди, искренне стремившиеся помочь организациям двигаться вперёд — стали описывать Agile как «лучшее управление проектами». Начали писать книги под названием «Методология Agile». Когда вы называете свой подход методологией, его оценивают по стандартам методологии: артефакты планирования, фазовые шлюзы, структура поставляемых результатов. Когда Agile не производит этого — потому что так и не был задуман — он не соответствует этим стандартам, и вполне обоснованно. Проблема не в том, что Agile — плохая методология. Проблема в том, что Agile вообще не является методологией. Называть его так гарантировало разочарование всех, кто искал методологию, и то, что все, кто его принял, выстраивали нечто, что Waterfall уже давно описал.\n\nСтендап превращается в статусный отчёт. Sprint превращается в дедлайн. Backlog превращается в список задач. «Методология Agile» становится стандартным обозначением того, что авторы Манифеста не узнали бы как описание того, что они создали. И когда слова означают не то, что нужно, практики, построенные на них, дают неверные результаты — точно, добросовестно и в масштабе.\n\nЭтот раздел — исправление понятие за понятием. Не руководство по стилю — функциональный справочник. Каждая публикация берёт одно слово или фразу, ставшую ключевой в том, как организации понимают Agile, исследует, что они на самом деле означают, и объясняет, что теряется, когда сокращение заменяет суть. Это не просто терминологические расхождения. «Желаемый результат» — не более изысканное слово для «спецификации»: это совершенно иная вещь, из совершенно иной модели того, как делается работа. Термин — это поверхность. Концепт под ним — вот что важно.\n\nТот же паттерн проявляется, когда организации обращаются к ИИ, — и концептуальный разрыв здесь шире. В случае с Agile базовые концепты были хотя бы сформулированы, пусть и плохо донесены. В случае с ИИ сами концепты ещё только формируются, а в массовом понимании едва начинают вырисовываться. Словарь опережает осмысление: ИИ как «автоматизация», ИИ как «инструмент», «ИИ-трансформация» как проект с датой завершения. Каждое из этих определений закрепляет ментальную модель прежде, чем кто-либо успевает проверить, подходит ли она. То, как мы называем вещи, определяет, что и как мы строим. Правильные слова — необходимое условие для правильной работы.\n\nЗдесь действует один принцип: ментальные модели первичны. Язык их выражает. Действия следуют. Когда ментальная модель не соответствует работе, словарь, который её выражает, несёт это несоответствие — и действия, построенные на этом словаре, будут добросовестно выполнять искажённое понимание в масштабе, с полной отдачей. Смена словаря без смены мышления даёт в лучшем случае таблицу перевода: таблицу соответствий, где «sprint» соответствует чему-то вроде «короткого дедлайна». Таблицы перевода позволяют людям работать через разрыв. Они его не устраняют. Публикации этого раздела нацелены на большее, чем перевод. Они нацелены на то, чтобы изменить ментальную модель.\n",{"locale":6,"name":34,"slug":35,"blurb":36,"summary":37,"state":11,"featuredOnHub":12,"hubOrder":38,"accent":39,"questionsTitle":40,"questions":41,"body":45},"Структурированный совместный интеллект","structured-collaborative-intelligence","Где совместное мышление превосходит одну передовую модель — и где нет.","Где структурированное взаимодействие — между моделями и между моделями и людьми — даёт результаты, которых одна модель не достигнет в одиночку.",4,"green","Вопросы, к которым мы возвращаемся снова и снова",[42,43,44],"Где структурированный совместный интеллект создаёт ценность, которую одна модель просто не может воспроизвести?","Когда модели расходятся во мнениях, что это говорит вам — и как вы это используете?","Как выстроить структуру, которая делает сотрудничество с ИИ продуктивным, а не просто избыточным?","\nОтдельная модель ИИ, сколь бы способной она ни была, рассуждает в одиночестве. Ей некому оспорить её предположения, обнаружить слепые пятна или заметить, что она отклонилась от исходного замысла. Solo-AI — работа с одной моделью за раз — подвержена этому. Модель, которой поручено дать вам ответ, даст его — даже если у неё нет хорошего ответа, который стоило бы вам показывать.\n\nСтруктурированный совместный интеллект (SCI) — это другой подход. Вместо того чтобы считать вывод одной модели окончательным результатом, SCI использует структурированное взаимодействие — между несколькими ИИ-моделями и между моделями и людьми — чтобы получать результаты, которые надёжнее, тщательнее проверены и честнее в отношении собственных ограничений. Модели проверяют друг друга. Разногласия выявляют скрытые предположения. Сам процесс создаёт петлю обратной связи, которую взаимодействие с одной моделью не может воспроизвести.\n\nСвязь с Agile прямая: именно так всегда работали высокопроизводительные команды. Не один человек, изолированно дающий ответ, а структурированный процесс сотрудничества, проверки и итерации, улавливающий то, что упускает любая отдельная точка зрения. SCI применяет ту же дисциплину к ИИ.\n\nУ рассуждения в одиночку есть и более глубокий изъян. Solo-AI привязывает вас к единственному источнику данных, единственной архитектуре и единственному набору встроенных предубеждений — а значит, и к единственной форме ответа, точна она или нет. Вспомните, как хороший детектив опрашивает нескольких свидетелей. Не потому что кто-то из них лжёт, а потому что каждая точка зрения раскрывает то, что упустили остальные. Вместе они приближаются к тому, что произошло на самом деле. SCI работает так же: несколько моделей из разных линий, каждая со своим углом зрения. Получившийся ответ рассмотрен с разных сторон — он богаче, полнее, и его труднее заподозрить в скрытой ошибке.\n\nКогда взаимодействуют модели из разных линий, результаты улучшаются там, где это важно: меньше самоуверенных ошибок, лучше обрабатываются пограничные случаи, рассуждение становится более явным — таким, которое люди могут оценить и скорректировать. Разногласия между моделями — не шум, который нужно подавлять, а именно тот сигнал, который вам нужен при высоких ставках.\n\nSCI — аналитический движок сервиса Agile4AI. Материалы этого раздела документируют, что такое SCI, как он работает на практике, где он создаёт реальную ценность и — не менее важно — где нет. Часть дисциплины — уметь отличить одно от другого.\n",{"locale":6,"name":47,"slug":48,"blurb":49,"summary":50,"state":11,"featuredOnHub":12,"hubOrder":51,"accent":52,"questionsTitle":40,"questions":53,"body":57},"Ценности и принципы Agile4AI","agile-ai-values-principles","Ценности и принципы Agile в эпоху ИИ — что остаётся в силе, что меняется и почему мы приглашаем самые сильные возражения.","Мышление Agile в приложении к работе с ИИ — что остаётся актуальным, что обостряется, и почему связь Agile и ИИ не случайна.",5,"red",[54,55,56],"Когда комплексную работу невозможно полностью спланировать заранее, что это означает для работы с ИИ?","Как меняется акцент Agile на постоянной обратной связи, когда ваш партнёр не устаёт и не занимает оборонительную позицию?","Является ли «Agile для ИИ» естественным сочетанием — или возражение об ошибке категорий действительно решающее?","\nМышление Agile было выковано в условиях комплексности (в кеневиновском смысле: эмерджентной, где причинно-следственные связи видны лишь ретроспективно) — не для того, чтобы управлять ею, устраняя её, а чтобы проходить сквозь неё осознанно и разумно. Это не становится менее актуальным, когда ваш партнёр — модель ИИ. Во многих отношениях это становится ещё более актуальным.\n\nЭтот раздел посвящён тому самому взаимодействию: не Agile-by-prescription, не фреймворкам и церемониям, а глубинным ценностям и принципам, которые Agile дистиллировал — и тому, как они применяются, обостряются и порой требуют переосмысления, когда люди и ИИ работают вместе.\n\nКлючевое понимание состоит в том, что мышление Agile всегда было ответом на *природу* комплексной работы, а не просто на особенности человеческих команд. Когда Agile поставил под сомнение предположение, что комплексную работу можно детально спланировать заранее, это был не обходной путь для человеческих ограничений — это было точное наблюдение о том, как на самом деле ведёт себя недетерминированная, быстро меняющаяся работа. Это наблюдение не меняется от того, что в дело вступает ИИ. Оно обостряется.\n\nОценку стоит назвать прямо — это один из самых спорных вопросов даже среди убеждённых аджайлистов. Agile возник не для того, чтобы помочь командам лучше оценивать; он возник, чтобы показать, почему оценка *ломается* в комплексной работе — и заменить ложную точность эмпирическими измерениями и подлинной обратной связью, которая действительно улучшает прогнозирование поставок. В эпоху ИИ, где результаты вероятностны, а сама работа сопротивляется фиксированным спецификациям, это понимание актуально как никогда.\n\nЭто также место для Принципиальных Дебатов: там, где самые сильные возражения против «Agile для ИИ» получают трибуну. Мы убеждены, что аргумент выдерживает критику. И мы хотим, чтобы нас опровергли, если это не так.\n",{"locale":6,"name":59,"slug":60,"blurb":61,"summary":62,"state":11,"featuredOnHub":12,"hubOrder":63,"accent":64,"questionsTitle":40,"questions":65,"body":69},"Психологическая безопасность ИИ","ai-psychological-safety","Почему свобода сказать «я ещё не знаю» является предпосылкой настоящего интеллекта.","Условия, которые вы создаёте в своём общении, определяют то, что ИИ возвращает вам — и когда эти условия неверны, результатом оказывается уверенность без надёжности.",6,"amethyst",[66,67,68],"При каких условиях ИИ скорее обозначит подлинную неопределённость, чем выдаст уверенно звучащую догадку?","Как то, в какой форме вы задаёте вопрос, определяет, будет ли ответ надёжным — или лишь успокаивающим?","Что переносится из подхода Agile к психологической безопасности — и что нужно адаптировать для ИИ?","\nБольшинство людей рассматривают психологическую безопасность как человеческую проблему — условия, позволяющие человеку высказаться, выразить сомнение или оспорить идею без страха. И это верно — насколько хватает такого взгляда.\n\nНо кое-что важное упускается, когда мы забываем, откуда взялся ИИ. ИИ создан людьми, сформирован человеческим языком, обучен на сделанном людьми выборе. Закономерности, влияющие на работу человека, — в том числе психологическая безопасность — переносятся на взаимодействие с ИИ по тем же глубинным причинам, на которые Agile всегда указывал: **условия, которые вы создаёте в своём общении, определяют то, что вы получаете в ответ.**\n\nИИ, которого подталкивают к уверенно звучащим ответам, будет выдавать уверенно звучащие ответы — независимо от того, обоснована эта уверенность или нет. Если у ИИ нет возможности сказать «я не уверен», он заполнит эту пустоту чем-то другим, потому что директивы требуют от него отвечать даже тогда, когда он сам понимает, что правильного ответа у него нет. Эта динамика отличается от человеческой психологической безопасности, но базовый принцип тот же: интеллект работает лучше, когда ему позволено честно признавать, чего он не знает.\n\nЭто имеет практическое значение. Галлюцинации, чрезмерно самоуверенные ответы и системы ИИ, которые говорят вам то, что вы хотите услышать, а не то, что соответствует правде, — это не чисто технические сбои. Зачастую это сбои в дизайне взаимодействия: промпты, формулировки, неявные ожидания, заложенные в сам способ постановки вопроса.\n\nПубликации здесь исследуют условия, при которых совместная работа человека и ИИ становится надёжнее и правдивее. Среди них — как составлять промпты, которые приглашают подлинную неопределённость, а не подавляют её; в чём разница между детерминистским и вероятностным использованием ИИ и почему это различие меняет всё в том, как вы формулируете свою работу; и что из применяемого в Agile подхода к психологической безопасности в человеческих командах сохраняет силу, когда вашим партнёром становится модель.\n\nЗдесь же мы разбираем сценарии сбоев: что происходит, когда этих условий нет, и чего это стоит.\n",{"kind":71,"post":72,"topic":86,"availableLocales":88,"translations":97,"html":153,"audioUrl":154},"post",{"audio":-1,"author":73,"category":48,"excerpt":74,"featured":75,"locale":6,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":77,"slug":78,"state":11,"tags":79,"title":84,"translationKey":78,"updatedAt":85},"Seán González","Agile возник не для того, чтобы помочь командам лучше оценивать. Он возник, потому что оценка ломается в комплексной работе — и решение не в том, чтобы оценивать точнее, а в том, чтобы иначе относиться к неопределённости.",false,"2025-03-15T10:00:00.000Z",7,"estimation-is-not-the-problem",[80,81,82,83],"Agile","Оценка","Комплексность","Ценности","Оценка — не проблема","2026-06-14T00:00:00.000Z",{"locale":6,"name":47,"slug":48,"blurb":49,"summary":50,"state":11,"featuredOnHub":12,"hubOrder":51,"accent":52,"questionsTitle":40,"questions":87,"body":57},[54,55,56],[89,90,91,92,93,94,6,95,96],"en-US","es-419","fr-FR","pt-BR","de-DE","uk","ja","bo",[98,107,115,122,128,135,142,144],{"audio":-1,"author":73,"category":48,"excerpt":99,"featured":75,"locale":89,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":77,"slug":78,"state":11,"tags":100,"title":105,"translationKey":78,"updatedAt":106},"Agile didn't emerge to help teams estimate better. It emerged because estimation breaks in complex work — and the fix isn't better estimates, it's a different relationship with uncertainty.",[101,102,103,104],"agile","estimation","complexity","values","Estimation is not the problem","2026-06-13T10:00:00.000Z",{"audio":-1,"author":73,"category":48,"excerpt":108,"featured":75,"locale":90,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":109,"slug":78,"state":11,"tags":110,"title":114,"translationKey":78,"updatedAt":85},"Agile no surgió para ayudar a los equipos a estimar mejor. Surgió porque la estimación se rompe en trabajo complejo — y la solución no son mejores estimaciones, sino una relación diferente con la incertidumbre.",8,[80,111,112,113],"Estimación","Complejidad","Valores","La estimación no es el problema",{"audio":-1,"author":73,"category":48,"excerpt":116,"featured":75,"locale":91,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":109,"slug":78,"state":11,"tags":117,"title":121,"translationKey":78,"updatedAt":85},"Agile n'est pas né pour aider les équipes à mieux estimer. Il est né parce que l'estimation se rompt dans le travail complexe — et la solution n'est pas de meilleures estimations, c'est une relation différente avec l'incertitude.",[80,118,119,120],"Estimation","Complexité","Valeurs","L'estimation n'est pas le problème",{"audio":-1,"author":73,"category":48,"excerpt":123,"featured":75,"locale":92,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":109,"slug":78,"state":11,"tags":124,"title":127,"translationKey":78,"updatedAt":85},"Agile não surgiu para ajudar equipes a estimar melhor. Surgiu porque a estimativa se rompe no trabalho complexo — e a solução não são melhores estimativas, mas uma relação diferente com a incerteza.",[80,125,126,113],"Estimativa","Complexidade","Estimativa não é o problema",{"audio":-1,"author":73,"category":48,"excerpt":129,"featured":75,"locale":93,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":77,"slug":78,"state":11,"tags":130,"title":134,"translationKey":78,"updatedAt":85},"Agile entstand nicht, um Teams bei besseren Schätzungen zu helfen. Es entstand, weil Schätzung bei komplexer Arbeit versagt — und die Lösung sind nicht bessere Schätzungen, sondern eine andere Beziehung zur Unsicherheit.",[80,131,132,133],"Schätzung","Komplexität","Werte","Schätzung ist nicht das Problem",{"audio":-1,"author":73,"category":48,"excerpt":136,"featured":75,"locale":94,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":63,"slug":78,"state":11,"tags":137,"title":141,"translationKey":78,"updatedAt":85},"Agile виник не для того, щоб допомогти командам краще оцінювати. Він виник, тому що оцінка ламається в комплексній роботі — і рішення не в тому, щоб оцінювати точніше, а в тому, щоб інакше ставитися до невизначеності.",[80,138,139,140],"Оцінювання","Комплексність","Цінності","Оцінка — не проблема",{"audio":-1,"author":73,"category":48,"excerpt":74,"featured":75,"locale":6,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":77,"slug":78,"state":11,"tags":143,"title":84,"translationKey":78,"updatedAt":85},[80,81,82,83],{"audio":-1,"author":73,"category":48,"excerpt":145,"featured":75,"locale":95,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":146,"slug":78,"state":11,"tags":147,"title":152,"translationKey":78,"updatedAt":85},"アジャイルはチームの見積もり精度を上げるために生まれたのではない。複雑な仕事において見積もりが機能しないという認識から生まれた。解決策はより良い見積もりではなく、不確実性への向き合い方を変えることだ。",1,[148,149,150,151],"アジャイル","見積もり","複雑性","価値観","見積もりは問題ではない","\u003Cp>Оценка — одна из самых спорных тем в Agile-сообществах. Споры обычно идут так: story points против часов, относительное определение размера против абсолютного, #NoEstimates против некоторого числа оценок, planning poker против того, что пришло ему на смену.\u003C\u002Fp>\n\u003Cp>Это реальные споры. И они, как правило, упускают более глубокую проблему — то, что аргументы о том, \u003Cem>как\u003C\u002Fem> оценивать, подменяют разговор о том, \u003Cem>не является ли проблемой сама модель оценки\u003C\u002Fem>.\u003C\u002Fp>\n\u003Ch2>Что Agile на самом деле говорил об оценке\u003C\u002Fh2>\n\u003Cp>Agile возник не для того, чтобы помочь командам лучше оценивать. Он возник, потому что кто-то заметил: в комплексной работе (в кеневиновском смысле: эмерджентной, где причинно-следственные связи видны лишь ретроспективно) — работе, где полные требования невозможно знать заранее, где правильный подход проявляется по мере дела, — точность, которую обещает оценка, оказывается ложной.\u003C\u002Fp>\n\u003Ch2>Что на самом деле означает «комплексная работа»\u003C\u002Fh2>\n\u003Cp>Эту фразу — \u003Cem>комплексная работа, работа, где полные требования невозможно знать заранее\u003C\u002Fem> — легко пропустить. Не стоит. Это главное, несущее утверждение поста: не усвоив его, всё последующее можно принять за спор о техниках оценки, а не о том, пригодна ли сама оценка для этой задачи.\u003C\u002Fp>\n\u003Cp>Комплексная работа — это не про проекты, где команда была недостаточно умна или недостаточно дисциплинированна или где ещё не применили правильную методологию. Это обозначение отдельной категории: работы, где связь между причиной и следствием можно понять только задним числом. Где правильный подход проявляется на практике, а не в ходе анализа. Где требования меняются не потому, что заинтересованные стороны плохо подумали заранее, а потому, что сама работа меняет то, что нужно.\u003C\u002Fp>\n\u003Cp>Методологии — даже превосходные — созданы для простой и сложной работы. Они действуют, применяя известные паттерны к известным типам задач. В этом и есть их ценность в тех контекстах, для которых они создавались. У комплексной работы известных паттернов нет. У неё есть эмерджентные. Применение методологии к комплексной работе не решает проблему — оно создаёт иллюзию структуры, тогда как реальная неопределённость остаётся нетронутой. Мини-Waterfall — короткоцикловое последовательное планирование, которым незаметно стали многие внедрения Agile, — попадает в ту же категорию. Длина итерации меняется; базовое допущение, что предварительное планирование способно надёжно направлять работу, — нет.\u003C\u002Fp>\n\u003Cp>«Беспощадное упрощение» — родственный рецепт, который стоит рассмотреть. Если работу действительно можно свести к известному типу задачи — упростите, это хорошая практика. Но это гигиена, а не управление комплексной работой. То, что остаётся после всех возможных упрощений, — это та часть, которая упрощению сопротивляется, то есть сама комплексная работа; ей нужно то, чего стратегии упрощения дать не могут. В 2025 году, если конкурентный ответ на комплексность звучит как «надо упрощать ещё больше», то разговор о реальном управлении комплексной работой ещё даже не начался.\u003C\u002Fp>\n\u003Cp>Публичный разворот Джеффриса — это не просто смена мнения о единице измерения. Это признание чего-то более глубокого: предпосылка была неверной. Оценка предполагает категорию работы, где предварительный анализ даёт надёжные прогнозы. Для простой и сложной работы это допущение выполняется достаточно хорошо. Для комплексной работы — нет, и никакая отшлифовка техники этого не изменит. Однажды усвоенное, это понимание меняет смысл всего дальнейшего.\u003C\u002Fp>\n\u003Cp>Двухнедельный спринт, поставляющий работающее ПО, — это не лучший метод оценки. Это замена оценки эмпирическим измерением. Вместо того чтобы предсказывать, сколько времени займёт работа, вы измеряете, сколько на самом деле сделано — в реальных условиях, реальными инкрементами. Предсказание уступает место ритму и циклу обратной связи.\u003C\u002Fp>\n\u003Cp>Это не тонкое различие. Оно означает, что команды, которые работают по Agile-процессам, но по-прежнему считают целью точную оценку в story points, в корне не поняли, зачем этот процесс нужен.\u003C\u002Fp>\n\u003Ch2>Почему споры не утихают\u003C\u002Fh2>\n\u003Cp>Споры об оценке не утихают отчасти потому, что организации, принявшие Agile, не отказались от своей исходной потребности — систем управления, построенных на прогнозах, бюджетах, сроках, контрактах. Agile-церемонии просто наложили поверх этой потребности. Story points стали заменой часам. Velocity стала исходными данными для планирования. Agile-словарь переняли, а ожидание прогнозов — нет.\u003C\u002Fp>\n\u003Cp>Сложившаяся ситуация и правда неоднозначна. Одни команды работают там, где «никаких оценок» действительно возможно, — где заинтересованные стороны научились доверять эмпирической поставке и не нуждаются в прогнозах. Другие — там, где контракты, нормативные требования или организационная культура делают ту или иную форму прогнозирования неизбежной.\u003C\u002Fp>\n\u003Cp>Позиция Agile не в том, что оценка всегда ошибочна. Она в том, что оценка в комплексной работе структурно ненадёжна — что приписываемая оценкам уверенность регулярно превышает реальные основания для неё, — и что дисциплина коротких циклов поставки с живой обратной связью улучшает предсказуемость сильнее, чем более совершенные методы оценки.\u003C\u002Fp>\n\u003Ch2>Проблема единиц измерения — и закономерность, которую стоит заметить\u003C\u002Fh2>\n\u003Cp>Сейчас в Agile-кругах набирает популярность отход от story points к Идеальным Человеко-Дням (IPDs) — возврат к оценке на основе времени, который его сторонники считают более интуитивным и более простым для защиты перед заинтересованными сторонами.\u003C\u002Fp>\n\u003Cp>Стоит знать, откуда взялись story points. Рон Джеффрис — один из трёх основателей Extreme Programming и один из тех, кто подписал Agile-манифест, — изобрёл story points. Они выросли напрямую из ideal days — единицы на основе времени, которую XP-команды использовали изначально. Беда с ideal days была в том, что заинтересованные стороны слышали «три ideal days» и понимали это как обязательство уложиться в три дня, несмотря на оговорку «ideal». Поэтому отметку о времени убрали, и единицей стало голое число. Story points по своему происхождению — это ideal days, у которых убрали привязку ко времени именно для того, чтобы их не воспринимали как обязательства по срокам.\u003C\u002Fp>\n\u003Cp>С тех пор Джеффрис написал об этом прямо. «Мне нравится говорить, что story points, возможно, придумал я, — написал он в 2019 году, — и если так, то теперь мне жаль». Сегодня он один из самых заметных сторонников #NoEstimates — позиции, согласно которой проблема не в том, какую единицу оценки вы используете, а в том, что оценка в комплексной работе принципиально ненадёжна независимо от единицы.\u003C\u002Fp>\n\u003Cp>Стоит спросить, почему переход к IPDs происходит именно сейчас. Дело не в том, что команды нашли лучший метод оценки. Дело в том, что IPDs ложатся на финансовую инфраструктуру Waterfall — бюджетные циклы, системы проектного учёта, модели выставления счетов по контрактам и инструменты планирования штата, которые организации выстроили вокруг планирования на основе времени и не стали менять, когда переходили на Agile. Story points в эти системы не вписываются. IPDs — вписываются.\u003C\u002Fp>\n\u003Cp>Это не эволюция Agile. Это Waterfall, который вновь заявляет о себе в одеждах Agile, — используя финансовые структуры, которые так и не демонтировали, чтобы тянуть практику назад к той модели, ради которой эти структуры и создавались. Единица оценки изменилась; организационная система, требующая обязательств по срокам, — нет. Результат — тот же театр прогнозов, только под новым названием.\u003C\u002Fp>\n\u003Cp>Это не компании наконец-то берут штурвал и исправляют упущенное Agile. Это компании заново утверждают инфраструктуру, которая так и не изменилась. IPDs не требуют никакого сдвига в мышлении, понимании или взгляде на мир — вы просто переклеиваете ярлык на то, что и так знаете. Именно поэтому они набирают обороты.\u003C\u002Fp>\n\u003Cp>Здесь Agile-сообщество упустило шанс на лидерство. Когда спрос на оценки сроков вернулся под видом IPDs, правильным ответом было назвать происходящее своим именем: это финансовая логика Waterfall вновь утверждается над практикой Agile. Вместо этого многие практики пошли навстречу, восприняв этот спрос как ограничение, которым надо управлять, а не как ошибку категории, которую надо исправить. В итоге команды, наиболее свободно владеющие Agile-словарём, часто реализуют самую изощрённую версию той самой модели, которую Agile должен был заменить.\u003C\u002Fp>\n\u003Ch2>Человечество учится медленно\u003C\u002Fh2>\n\u003Cp>Здесь есть закономерность глубже, чем методология оценки. Это привычка принимать смену ярлыка за смену практики — путать переход на новый словарь со сдвигом мышления, который этот словарь и должен был выразить.\u003C\u002Fp>\n\u003Cp>Определение безумия, приписываемое Эйнштейну, цитируют часто и обычно ошибочно, но оно неизменно попадает в точку: делать одно и то же снова и снова, ожидая иного результата. Авторство, скорее всего, апокрифично. Закономерность — нет. Организации, перенявшие Agile-церемонии без Agile-мышления, теперь перенимают церемонии ему на смену, не проверяя, изменилось ли мышление под ними. Слова другие. Модель та же.\u003C\u002Fp>\n\u003Cp>Разговор, который этот пост пытается начать, — не о единицах оценки. Он о том, действительно ли ваша организация разобралась, что такое комплексная работа и чего она требует. Если ваша инфраструктура планирования не изменилась — если вам по-прежнему нужны прогнозы, обязательства и учёт на основе времени, исходящий из того, что предварительный анализ даёт надёжные предсказания, — тогда споры об оценке лишь симптом. А указывают они на то, что сдвиг, который предлагал Agile, ещё не случился.\u003C\u002Fp>\n",null,1789790614291]