О кстати, читал давеча такой хот тейк от западных Agile

светил: беклог - это антипаттепн управления продуктом. Типа если стратегия продукта ясна, то все истории связанные со следующим майлстоуном стоит оставить, а остальные выкинуть. Что думаете?

Беклог не про управление продуктом же, это просто очередь с заданным порядком, своего рода буфер. Управление продуктом – широкий термин, но по сути самы элементы рождаются где-то за пределами беклога, приореты выставляются за пределами беклога… тут и impact mapping и множество discovery практик и risk management и custdev. Ну например, есть немало команд, которые используют дерево impact mapping вместо беклога

Это то , про что я обычно рассказываю на тренингах про Agile подходы. Так как это система ориентирована на команды разработки, то инструменты постановки целей и долгосрочного планирования в ней отсутствуют. Есть только ближний горизонт. Конечно "Метафора системы" и "Шип" проработки архитектуры частично решают задачу проектирования, но не задачу планирования проекта и постановки общих целей. А про "буфер" - интересная концепция, я не думал про это в разрезе управления мощностью команды. Но это стыкуется с ББК (ТОС) по отношению к команде разработки.

Кмк беклог и входной буфер немного разные вещи. Буфер в понимании Канбана - штука хорошая, у неё может быть WIP, а ее опустошение может быть сигналом для апстрима. При этом никакого «грумминга» не подразумевается, скорее это часть процесса (шаг). В таком разрезе беклог здравая штука. А в скраме это приоритезипованныц лист требований. Который а) Потенциально длинный, представляет весь продукт б) За ним нужно «ухаживать», добавлять детали и приоритезировать. Вообще идея с этими груммингами сомнительная. Если что бы сделать какую-то строю, нужна ещё какая-то работа до, зачем это куда-то прятать под ковёр создавая иллюзию маленького LT?

Кент Бек в XP вполне четко пишет: «We will plan by quickly making an overall plan, then refining it further and further on shorter and shorter time horizons—years, months, weeks, days. We will make the plan quickly and cheaply, so there will be little inertia when we must change it.» И сразу после этого он поясняет: «Do only the planning you need for the next horizon—At any given level of detail, only plan to the next horizon—that is, the next release, the end of the next iteration. This doesn't mean that you can't do long-range planning. You can, just not in great detail. You can cover this release in great detail and cover the next five (proposed) releases with a set of bullet items. Such a sketch will not lose much over trying to plan all six releases in detail.» Само планирование - это не одна встреча на все случаи жизни и зависит от того, с какой целью оно проводится. «Planning for priorities vs. planning for development—Be aware of the purposes of planning. Planning so the customer can establish priorities needs much less detail to be valuable than planning for implementation, where you need specific test cases.» Чаще всего планирование используется как способ предсказать будущее. Это абсурд в условиях изменяющихся условий, так что отбросим. 1. Совершенно иные методы проявляются если под планом понимать поиск альтернативных путей достижения целей. 2. Если мы планируем для поиска скрытых рисков, для самопроверки, то это еще один подход к планированию. 3. Возможно планирование для установления договоренностей об очередности выполнения для управления зависимостями между командами. И это третий метод. Ну и так далее. Первые два, к слову, из коробки дает покер планирования на уровне команды, а третий - это совместное планирование зависимостей между командами только тех задач, по которым есть зависимости (тут многоуровневая система - уровень команд, уровень систем, уровень отделов, - управление зависимостями отличается для разных видов зависимостей, конечно). Да, про зависимости он пишет явно: «Ignore dependencies between parts—Plan as if the parts of development can be switched around at will. As long as you are careful to implement the highest business priorities first, this simple rule will keep you from trouble. "How much for the coffee?" "The coffee is 25 cents, but refills are free." "Just give me a refill, then." This doesn't tend to happen.». И об этом я могу писат бесконечно, но если взять одну фразу, которая бы подошла по контексту к этому сообщению, то это было бы – если вы не можете избавиться от зависимостей, сделайте все, чтобы они были не блокирующими по отношению друг к другу

1. Всегда ли условия меняются так сильно что нужно "не планировать"? 2. В чем природа изменений? Это два ключевых вопроса которые при внимательном рассмотрении меняют всю парадигму управления. И проекты в которых участвовал Бек - внутренние, крупная модернизация ИТ-систем совсем не тоже самое что и эксперименты для рынка.

Я не смог декодировать к какой части моего сообщения относятся эти вопросы 🙂 Разве что про Бека – же вроде в apple и facebook работал, а сейчас в стартапе каком-то и постоянно работал как консультант с кучей стартапов. Вполне рыночная история 🙂

Каких-то конкретных методов?

Всех Agile методов. (у которых "есть священный Беклог и мы мы из не го берем задачи" )

Вот я и уточнняю 👀 Cтрого говоря Scrum – это не «agile-метод», ну и не методология (https://www.scrum.org/resources/what-is-scrum - «Scrum is a framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. Scrum is not a methodology. Scrum implements the scientific method of empiricism.»). Он появился за 6 лет до появления манифеста, а первое упоминание – за 15 лет до появления манифеста. И Сазерленд отдельно говорит как построить Agile Software Development с помощью Scrum (у него буквально книнга так называется), он нигде не говорил, что Scrum - это agile-подход. Он может помочь, это правда, но в целом он живет своей жизнью. Ну а в XP строго говоря нет беклога 🙂 Я с другой позиции смотрю на это. Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems. Нет complex problems – можно обойтись без scrum. XP is a lightweight methodology for small-to-medium-sized teams developing software in the face of vague or rapidly changing requirements. Нет vague or rapidly changing requirements – XP будет явным оверхедом. И Бек в книге xp explained явно указал (все бы авторы так 🙂 ): «XP is designed to work with projects that can be built by teams of two to ten programmers, that aren't sharply constrained by the existing computing environment, and where a reasonable job of executing tests can be done in a fraction of a day.»

Так что ж Скрам пихают тогда везде куда не попадя?

Не могу согласиться. Дело в том что аджайлом называют все что угодно. Один из аспектов скрама - корректировка плана исходя из регулярной и быстрой обратной связи. Официальный гид на этом делает особый акцент. А именно это и есть основная идея аджайла - смелость признать что мы знаем не все и должны подтверждать гипотезы обратной связью (эмпирический метод) Другое дело - канбан, который ошибочно много где назван аджайловым методом

С кем ге можете согласиться? Я официальные цитаты привел от авторов :)

Отсутствие конкретного слова не говорит о не вхождении в классификацию

Так с кем или с чем не согласны?

Скрам 0 уровня зрелости очень удобен для начала преобразования команды. Это называется "Попробовать внедрить Скрам". Как первая иерация работает у многих относительно хорошо - при помощ и ретро и циклов планирования-груминга-обзорспринта команды начинают лучше работать

Что за уровни зрелости?

Детство, отрочество, юность))

Перед этим например был облегченный хаос в виде имитации управления проектами в условиях запутанного домена

Попробую ответить, тут столько двусмысленных терминов (облегченный хаос, имитация управления проектами, запутанный домен), если что-то не так понял – поправьте 🙂 Хаос - это свойство, выраженное в невозможности предсказания последствий на сколь угодно коротком интервале времени и сильная чувствительность начальным условиям. Скрам в таком контексте слишком медленный и тяжелый. Скрам не меняет контекст, он не уберет хаоc (да и не всегда это нужно, здесь же максимальные возможности спрятаны 🙂 Кажется, здесь терминология из Киневин. Тогда к ней и обратимся, только сведем к общепринятым терминам: Complicated - упорядоченная сложная система Complex - неупорядоченная сложная система В scrum циклы inspect&adapt неявно разделены для процесса разработки и самого продукта. Процесс из complex в complicated переводится самим фреймворком, задавая структуру, порядок (повторющиеся итерации с фиксированным набором ролей и мероприятий с понятными входами и выходами) Продуктовый домен, если он complex, перевести с помощью самого продукта в complicated не получится, поэтому подбираются техники работы, подходящие под продуктовый домен и изучается сам домен (эмпирически; если б домен был complicated, упорядоченный, то тратить на эмпирику время было бы избыточным и хорошо показали бы себя аналитические методы). Если в условном банке аналитик ищет куда внести изменения, в какую базу и в какие поля – это упорядоченная система с привнесенной сложностью. Здесь эмпирика избыточна, хотя такое поведение говорит о срочной потребности в управлении техдолгом 🙂 Но если мы запускаем новый продукт на новую ЦА – в таком кейсе еще нет порядка, каждый следующий шаг может непредсказкуемым образом и зменить и наши представления о продукте и представление ЦА о том, как его использовать. Привет, HADI-циклы 🙂 Однако способ разработки (как способ обучения) все равно по своей природе итеративный, но здесь нам не только нужно исследовать, но и фиксировать точки, в которых продукт в рабочем состоянии (чем чаще - тем лучше), потому что только это является подтверждением того, что то, что мы написали можно использовать как новое знание, а до такого подтверждения у нас как бы продукт Шредингера – и в рабочем в нерабочем состоянии одновременно 🙂

И получается все равно как с разработкой Джеймса Уэбба - https://habr.com/ru/post/670044/ В такие моменты понимаешь, что неопределённость - она и в инженерии неопределённость, даже если её назвать планетарным масштабом, который уууу Ватерфол не работает как задумано чуть более чем нигде )))

Ой как вы ошибаетесь, весь мир это не ИТ, да и в таком мире есть, проекты которые отлично вводятся в эксплуатацию по каскадной модели.

>работает как задумано Можно примеры? Я таких не видел )

Вам именно ИТ или весь мир?) Вот мне дом сдает застройщик на 6 месяцев раньше срока, в стройке используется каскадная модель, не видел что бы дом сдавали по 1 этажу 😅

Предлагаю вернуться к изначальному моему тезису >не работает как задумано Всегда идёт что-нибудь не так Это железобетон! Точно также в Agile всегда есть планирование, хоть на минуту вперёд В мужчинах всегда есть женские гормоны (эстроген), а в женщинах мужской (тестостерон) Схожее и здесь >не работает где Я же писал, чуть более чем нигде Вы вообще не читаете что я пишу?))

Бегло, спасибо за уточнение) В этом мире как будто мало что вообще работает как запланировано, но это только придает ему какой-то изюминки )

Вся суть в балансе prediction и adaptation. "Most of us would prefer to wait until we have more information so that we can make a more informed decision. When dealing with important or irreversible decisions, if we decide too early and are wrong, we will be on the exponential part of the cost-of-deciding curve in Figure 3.6. As we acquire a better understanding regarding the decision, the cost of deciding declines (the likelihood of making a bad decision declines because of increasing market or technical certainty). That's why we should wait until we have better information before committing to a decision." —"Essential Scrum: A Practical Guide to the Most Popular Agile Process" by Kenneth Rubin, "Chapter 3 Agile Principles :: Prediction and Adaptation" Более того, баланс Prediction/Adaptation зависит от конкретных условий проекта и исторического контекста. В конце 90-х снижалась стоимость адаптации, а системы были проще. Сегодня средняя система на рынке стала на порядки сложней, стоимость адаптации диспропорционально возросла, но зато удешевляется Prediction, за счет появления Event Storming и других легковесных методик. Стоимость Prediction не константна по отношению к жизненному циклу системы, и имеет тенденцию к понижению по мере реализации проекта. То есть нет неработающих методов вне контекста их применения. При строительстве моста prediction на порядки дешевле adaptation, мост не перестраивается всю жизнь (обычно), как софт.

Теперь на основе тезисов о prediction и adaptation посмотрим, что происходит, когда мы пытаемся искусственно использовать prediction. Чтобы дать оценку нужны данные, которые получаешь позже, чем даешь оценку, если кратко :) Таким образом, любая оценка носит вероятностный характер. Чем дальше от текущего момента, тем ниже вероятность. Теперь возьмем типичный PI-планинг. Между задачами трайба есть зависимость в виде последовательности выполнения. Плюс у многих задач есть зависимости от других трайбов и команд. Эти зависимости на разном удалении от точки во времени, когда мы даем оценку. Общая вероятность, как известно, равна произведению вероятностей. И вот мы оценили огромный объем, на основе этой оценки выстроили последовательность и зависимости, но вероятность выполнения в обозначенные сроки из-за вышесказанного стремится к нулю, а обязательства никто не снимал и вот помимо затрат на оценку и планирование добавляются затраты на разруливание искусственно (гарантированно) созданной жопы :) Теперь об интервалах. Квартал – это очень странный, большой горизонт, да еще и дискретный. В agile/devops не просто так все подряд используется в словосочетании со словом continuous :) , а тут каждый квартал по сути планируется заново. Теперь вспомним ниточки (зависимости) на program board. Смысл в том, что PI-планирование как-бы «разрешает» зависимости, дает иллюзию контроля и закрепляет зависимости, ухудшая ситуацию. То есть каждый следующий PI ситуация будет ухудшаться, так как закрепляются существующие зависимости, которые обрастают дополнительными. Цель PI-планирования должны быть в том, чтобы стать ненужным, – подсветить все зависимости и систематически их устранять. (Выше писал про разные цели планирования: https://t.me/agile_ru/229631 ) Я здесь PI привел как самый известный и наверное понятный в этом чате пример дисфункции при балансе prediction/adaptation. Уже формируется поколение, которое никогда не видело в дикой природе waterfall, так что можно смело использовать понятный синоним - PI-планирование в SAFe 🌏

По поводу оценки и опыта, но не всегда задачи настолько сложные что это r&d и мы понятия не имеем как это реализовать, чаще уже есть прошлый опыт на котором в том числе с определенной долей погрешности может строиться планирование или нет?

В компаниях где применяется CCPM всё работает. Но часто верхнее руководство об инструментах даже не догадывается.

Конечно, так и живем 🙂 Важно то, что там где можно не фиксировать даты – лучше не фиксировать. Это ж вот прям христомайтино: есть фиксированная дата, а скоуп становится гибким. И дальше идут всякие технически и менеджерские решения – нанять людей, упростить решения или еще что-то. Причем таких кейсов же не так много, обычно это какие-то мероприятия, вроде нового года, олимпиады, конференции и так далее. Тут главное не создавать себе проблем фиксируя даты там, где это совершенно не нужно, тем самым создавая на ровном месте себе проблемы 🙂

Мне кажется, что мы с вами под словом «все работает» понимаем разные вещи )

Леха Пименов @pimenaus об этом может отлично рассказать, в канбан-методе классы обслуживания прекрасный пример инструмента такого баланса, но опять же остается человеческая сущность и ничто не мешает нам всем задачам проставить fixed date просто из-за когнитивного искажения «иллюзия контроля (https://ru.wikipedia.org/wiki/Иллюзия_контроля)» у начальства, у которого от реализации зависит бонус и названные сроки помогают избавиться от тревоги из-за неопределенности и/или переложить ответственность. В конце концов – все мы люди и ничто человеческое нам не чуждо 🙂