[{"data":1,"prerenderedAt":126},["ShallowReactive",2],{"footer-topics-ru":3,"post-ru-agile-decoded-a-sprint-is-not-a-deadline":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":82,"availableLocales":84,"translations":92,"html":124,"audioUrl":125},"post",{"audio":-1,"author":73,"category":23,"excerpt":74,"featured":75,"locale":6,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":77,"state":11,"tags":78,"title":81,"translationKey":77,"updatedAt":76},"Seán González","Спринт — это окно фиксированной длины для исследования и поставки. Дедлайн — это финиш гонки. Если относиться к спринту как к дедлайну, получаются ровно те модели поведения, которые спринты призваны предотвращать.",false,"2024-10-01T10:00:00.000Z","a-sprint-is-not-a-deadline",[79,80],"sprint","teams","Спринт — это не дедлайн",{"locale":6,"name":22,"slug":23,"blurb":24,"summary":25,"state":11,"featuredOnHub":12,"hubOrder":26,"accent":14,"questionsTitle":27,"questions":83,"body":32},[29,30,31],[85,86,87,88,89,90,6,91],"en-US","es-419","fr-FR","pt-BR","de-DE","uk","ja",[93,97,101,105,109,113,117,119],{"audio":-1,"author":73,"category":23,"excerpt":94,"featured":75,"locale":85,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":77,"state":11,"tags":95,"title":96,"translationKey":77,"updatedAt":76},"A sprint is a fixed-length window for exploration and delivery. A deadline is the end of a race. Treating a sprint like a deadline produces exactly the behaviors that sprints were designed to prevent.",[79,80],"A sprint is not a deadline",{"audio":-1,"author":73,"category":23,"excerpt":98,"featured":75,"locale":86,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":77,"state":11,"tags":99,"title":100,"translationKey":77,"updatedAt":76},"Un sprint es una ventana de duración fija para la exploración y la entrega. Una fecha límite es el final de una carrera. Tratar un sprint como una fecha límite produce exactamente los comportamientos que los sprints fueron diseñados para evitar.",[79,80],"Un sprint no es una fecha límite",{"audio":-1,"author":73,"category":23,"excerpt":102,"featured":75,"locale":87,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":51,"slug":77,"state":11,"tags":103,"title":104,"translationKey":77,"updatedAt":76},"Un sprint est une fenêtre de durée fixe pour l'exploration et la livraison. Une échéance est la fin d'une course. Traiter un sprint comme une échéance produit exactement les comportements que les sprints étaient censés empêcher.",[79,80],"Un sprint n'est pas une échéance",{"audio":-1,"author":73,"category":23,"excerpt":106,"featured":75,"locale":88,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":77,"state":11,"tags":107,"title":108,"translationKey":77,"updatedAt":76},"Um sprint é uma janela de duração fixa para exploração e entrega. Um prazo é o fim de uma corrida. Tratar um sprint como um prazo produz exatamente os comportamentos que os sprints foram projetados para evitar.",[79,80],"Um sprint não é um prazo",{"audio":-1,"author":73,"category":23,"excerpt":110,"featured":75,"locale":89,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":77,"state":11,"tags":111,"title":112,"translationKey":77,"updatedAt":76},"Ein Sprint ist ein Zeitfenster fester Länge für Exploration und Lieferung. Eine Deadline ist das Ende eines Rennens. Wer einen Sprint wie eine Deadline behandelt, erzeugt genau die Verhaltensweisen, die Sprints verhindern sollten.",[79,80],"Ein Sprint ist keine Deadline",{"audio":-1,"author":73,"category":23,"excerpt":114,"featured":75,"locale":90,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":77,"state":11,"tags":115,"title":116,"translationKey":77,"updatedAt":76},"Спринт — це вікно фіксованої тривалості для дослідження та постачання. Дедлайн — це фініш гонки. Якщо ставитися до спринту як до дедлайну, виходять саме ті моделі поведінки, яким спринти покликані запобігати.",[79,80],"Спринт — це не дедлайн",{"audio":-1,"author":73,"category":23,"excerpt":74,"featured":75,"locale":6,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":38,"slug":77,"state":11,"tags":118,"title":81,"translationKey":77,"updatedAt":76},[79,80],{"audio":-1,"author":73,"category":23,"excerpt":120,"featured":75,"locale":91,"pinnedInTopic":75,"pinnedOverall":75,"publishedAt":76,"readingMinutes":121,"slug":77,"state":11,"tags":122,"title":123,"translationKey":77,"updatedAt":76},"スプリントは、探索と提供のための長さの決まった枠である。締め切りはレースのゴールだ。スプリントを締め切りのように扱うと、スプリントが防ぐために設計されたまさにその振る舞いが生まれる。",1,[79,80],"スプリントは締め切りではない","\u003Cp>Дедлайн создаёт давление в сторону завершения: сделай это к такой-то дате, чего бы это ни стоило. Неявная логика здесь такова, что самое важное — закончить то, что обещано, в срок. Если это действительно ваш высший приоритет, то Agile не для вас — как и комплексная работа (в кеневиновском смысле: эмерджентная, где причинно-следственные связи видны лишь ретроспективно). Но учтите: управление комплексной работой средствами традиционного управления проектами ведёт к ненадёжному прогнозированию (вы заставляете свою команду реализации угадывать или, хуже того, лгать, потому что неизвестное невозможно поставить в график диаграммы Ганта).\u003C\u002Fp>\n\u003Cp>Спринт — это тайм-бокс: отрезок фиксированной длины, обычно от одной до четырёх недель, внутри которого команда работает над определённым объёмом, поставляет то, что \u003Cem>возможно\u003C\u002Fem>, а затем инспектирует и адаптирует. Граница — это не финишная черта. Это петля обратной связи.\u003C\u002Fp>\n\u003Cp>Само слово «спринт» добавляет путаницы. Спринтовать — значит бежать как можно быстрее. Использовать это слово для того, что в действительности является устойчивым, размеренным, ограниченным по времени циклом поставки, — значит с самого начала посылать неверный сигнал.\u003C\u002Fp>\n\u003Ch2>Что ломается, когда спринты становятся дедлайнами\u003C\u002Fh2>\n\u003Cp>Когда команды переживают спринты как дедлайны, появляются защитные механизмы культуры дедлайнов: сокращение объёма без прозрачности, срезание углов в качестве под предлогом нехватки времени, героические усилия, которые дают поставку в краткосрочной перспективе за счёт долгосрочной устойчивости, и так далее.\u003C\u002Fp>\n\u003Cp>Спринт был задуман именно для того, чтобы противодействовать этой динамике. Создавая предсказуемые повторяющиеся циклы со встроенной инспекцией, спринты заменяют вопрос «успеем ли мы к дедлайну?» на вопрос «что мы реально можем поставить за этот цикл и чему мы на этом учимся?».\u003C\u002Fp>\n\u003Cp>Почему петля обучающей обратной связи так важна? Потому что работа, которой занимается Agile, комплексная — это тот род работы, который нельзя аккуратно, шаг за шагом, уложить в диаграмму Ганта, потому что вы не знаете того, чего вы не знаете, пока не упрётесь в стену. Вот почему петля обратной связи так важна: она даёт ровное, предсказуемое подтверждение \u003Cem>курса\u003C\u002Fem> и того \u003Cem>темпа\u003C\u002Fem>, который \u003Cem>возможен\u003C\u002Fem> при имеющихся неизвестных, а не поставку к конкретной дате.\u003C\u002Fp>\n\u003Cp>Поэтому конец спринта — это перезапуск цикла получения знаний, а не вынесение приговора. Незавершённая работа, если она есть, переходит в следующий цикл с ясными указаниями на то, почему команда не смогла её завершить, — это ключевой предиктор похожих ухабов в будущем. Команда получает точную картину своей реальной пропускной способности — а это гораздо ценнее однократной героической поставки с последующим провалом.\u003C\u002Fp>\n\u003Cp>Когда спринт переживается как дедлайн, этого перезапуска не происходит. Команда заканчивает его измотанной и так и не узнав, что именно мешало. Мера пропускной способности искажена авралом. Следующий спринт начинается с истощённой позиции. Показатели Velocity становятся ненадёжными. Петля обратной связи, которая и делает спринты ценными, перестаёт давать полезный сигнал.\u003C\u002Fp>\n\u003Cp>Значит ли это, что нормально переносить работу из спринта в спринт и открывать каждую сессию планирования обзором долгов? Нет — не как норма. Как исключение — да: команда прямо называет разрыв, разбирается, что его вызвало, и использует это понимание, чтобы он не повторился. Прозрачность и есть суть. Разрыв, который вынесен на свет и разобран, принадлежит петле обучения. Разрыв, который тихо перекатывается в следующий цикл, не учит команду ничему, а тихим его держит именно давление выглядеть быстрым.\u003C\u002Fp>\n\u003Cp>Заинтересованным сторонам нужна уверенность в том, что каждый спринт возвращает что-то ценное — будь то ожидаемая работа или понимание того, что помешало и как избежать похожих ситуаций в будущем или лучше ими управлять. Вот в чём обязательство. Долгая история его выполнения создаёт тот кредит доверия, который позволяет \u003Cem>изредка\u003C\u002Fem> промахнуться без тревоги. Команда, которая регулярно поставляет меньше ожидаемого, этот кредит проедает: доверие размывается, требования растут, чтобы компенсировать ожидаемые промахи, и команде оказывается не лучше, чем при традиционном управлении проектами. Держаться должны обе половины — надёжная поставка \u003Cem>и\u003C\u002Fem> пространство для обучения.\u003C\u002Fp>\n\u003Ch2>Вопрос темпа\u003C\u002Fh2>\n\u003Cp>Один из принципов Agile, заложенных Манифестом, — устойчивый темп: команда должна быть способна работать в том темпе, в котором работает, неограниченно долго. Это не приятное дополнение. Это принцип надёжности. На команду, которая способна поставлять только спринтуя — в смысле быстрого бега, — нельзя опереться, когда нужен прогноз того, что она поставит в предстоящие месяцы. Команда, работающая в устойчивом темпе, нарабатывает закономерности пропускной способности, которые позволяют делать настоящий прогноз даже при работе с неизвестными, — и в этом \u003Cstrong>ценность Agile: дать вашей компании возможность работать в ровном темпе посреди неизвестного.\u003C\u002Fstrong>\u003C\u002Fp>\n\u003Cp>Спринт, понятый правильно, — это цикл поставки в устойчивом темпе со встроенной точкой инспекции. Это нечто совсем иное, чем дедлайн. Разница не семантическая: именно она снижает риск на каждой итерации.\u003C\u002Fp>\n",null,1792032616908]