Антихрупкость Agile
Добрый день, друзья!
Недавно закончил читать книгу Нассима Талеба «Антихрупкость». Книга понравилась, заставляет задуматься: а как можно применить понятие антихрупкости в своей работе? Является ли мое подразделение антихрупким? А Agile в целом?
Содержание
1. Понятие Антихрупкости.
Тем, кто читал предыдущие книги Талеба, известно что кардинально меняют нашу жизнь редкие явления, которые он называет «Черными лебедями». Такие события практически невозможно предсказать, т.к. вероятность их возникновения крайне мала. Но именно эти события очень сильно влияют на жизни, системы, страны и т.д. Прочитав книгу об этих событиях, возникает вопрос: что же делать? Как защититься от негативных непредсказуемых событий? Талеб пытается дать ответ в книге «Антихрупкость. Как извлечь выгоду из хаоса».
В чем суть понятия «Антихрупкость»: Талеб делит системы на хрупкие — неуязвимые — антихрупкие. Хрупкие — это системы, которые ломаются от случайных/непредсказуемых явлений. Неуязвимые — системы, которые до какой-то степени противостоят случайным воздействиям. Антихрупкие — системы, которые улучшаются от случайных воздействий. Причем, по мнению Талеба, риск измерить нельзя, антихрупкость — можно.
| Хрупкое | Неуязвимое | Антихрупкое |
| Дамоклов меч | Феникс | Гидра |
Меч постоянно висит над Дамоклом на конском волосе и любое воздействие на меч или волос будет губительно для Дамокла. Феникс, чтобы не случилось, снова и снова возрождается из пепла. С ним ничего нельзя сделать, но лучше он не становится. Гидра же, напротив, улучшается при каждом смертоносном воздействии: вместо одной отрубленной головы, возникает три новых. Здесь должна быть шутка про восьмибитного Горыныча.
Основная мысль в следующем: не надо пытаться предугадать маловероятные события, т.к. это невозможно, нужно строить антихрупкие системы, которые от случайных воздействий и потрясений будут лишь улучшаться.
2. Составляющие антихрупкости.
Как же нам сделать нашу систему неуязвимой, а лучше антихрупкой? Чтобы не потерять нить, пойдем по пути размышления Нассима.
2.1. Стрессоры
Во-первых, комфортное существование или по Талебу — отсутствие стрессоров, делает нашу систему хрупкой. И действительно, давно ли вы меняли свою работу? Может рынок труда уже изменился настолько, что, в случае вашего увольнения, вы уже никому не нужны? Ребенок, которого ограждают от всех напастей и стрессоров, вряд ли вырастет способным противостоять социуму или проблемам, которые ждут его во взрослой жизни. Любой стресс — это знания. Также пример гормезиса — ограниченного воздействия стрессоров на организм, от которого организм становится лучше. Узнали? Это же вакцинация. Или же, например… хотя, придумайте сами — тысячи примеров вокруг.
Итак, система регулярно должна подвергаться воздействию стрессоров.
Посмотрим на Agile.
Стрессоров в Agile много: отсутствие полноценного ТЗ, постоянные изменения в процессе работы, а также, возможно, переработка уже сделанного, а еще и выполнение амбициозных целей каждые две недели (в Scrum). Нужно обладать определенным мышлением и гибкостью, чтобы выживать в Agile.
Напомню ценности Agile:
- Люди и взаимодействие важнее процессов и инструментов.
- Работающий продукт важнее исчерпывающей документации.
- Сотрудничество с заказчиком важнее согласования условий контракта.
- Готовность к изменениям важнее следования первоначальному плану.
Посмотрите, все что находится справа как раз и необходимо нужно для снижения рисков и стресса. Но, справедливости ради, стоит сказать что Agile не отрицает этого, но больше фокусируется на левой части.
2.2. Слабые делают систему сильнее
Во-вторых, ошибки, усиливающие системы. Гибель Титаника принесла пользу для отрасли кораблестроения. Вместо безопасности инженеры занимались бы размерами и гибель судна, превышающего размера Титаника, повлекла бы гораздо большее число жертв. Это те ошибки, которые губят один корабль, чтобы другие стали лучше. Получается что антихрупкие системы состоят из хрупких элементов. Самые слабые части отмирают, делая всю систему сильнее.
Узнали? Это же эволюция. Такая вот природная антихрупкость.
В Скраме есть две вещи, которые, на мой взгляд, попадают под этот пункт:
- Изменения в процессе, которые губят спринт. Но они же делают процесс сильнее, после хорошей «работы над ошибками» она же ретроспектива или цикл Деминга-Шухарта.
- Команды самостоятельно или с помощью скрам-мастера могут устранять слабые звенья своей цепи, сотрудников, которые безответственно относятся к своей работе и срывают поставку ценности.
2.3. Переменчивость — залог здоровья
Идём дальше — переменчивость. Идея в том что переменчивые системы лучше приспособлены к воздействию случайных событий, нежели их противоположности. Талеб приводит пример таксистов, которые постоянно подстраиваются под «случайные» заработки и они более антихрупки, нежели офисные работники, привыкшие к регулярным окладам. Сглаживая переменчивость, мы усиливаем уязвимость систем. То же и со странами: Швейцария, с их самоуправлением на местном уровне и СССР с централизованной экономикой.
На графике изображена две системы: слева – переменчивая, колебания в которой гасят друг друга, справа «стабильная» и внезапное случайное событие в ней.
Самое главное, о чем стоит упомянуть в этом пункте — это команды: самоорганизующиеся, которые строят работу внутри себя без директивного управления сверху. Очень похоже на устройство Швейцарии. Самоорганизация, помимо повышения ответственности, еще и несет некоторую степень случайности.
Также в переменчивость я бы добавил регулярные изменения процесса работы на ретроспективах и готовность к изменениям целей, ради Additional Value или же из-за изменения конъюнктуры.
2.4. Стратегия штанги: только крайности, никаких средних
Стратегия штанги (двухуровневая стратегия): с одной стороны мы максимально избегаем потерь, делая систему антихрупкой, с другой ставим на риск и получаем неограниченный доход (пользу). В итоге мы и защищены и можем получить профит, если что-то произойдет. Можно привести инвест пример: 90% портфеля с низким риском и 10% с высоким, что, в целом, делает систему антихрупкой.
Дальнейшие пункты, в основном, связаны с работой Владельца Продукта в части гипотез. Как известно, часть работы продакта состоит в том чтобы проверять гипотезы, это и есть стратегия штанги, по Талебу: разработка понятной «основной» части продукта чтобы снизить риск и регулярная проверка новых гипотез, чтобы найти позитивного Черного лебедя. С одной стороны мы точно получим продукт, с другой стороны есть вероятность наткнуться на золотую жилу.
2.5. Опционы
Анхрупкость выпукла, это означает что наши потери ограничены, а доходы могут расти по экспоненте. Интересный пример с маслобойнями: древнегреческий философ Фалес Милетский законтрактовал все маслобойни в округе за небольшие деньги и случился урожайный год на оливки. Он освобождал маслобойни от своих контрактов за круглую сумму. Это первый в истории опцион. Взгляните на график зависимости стоимости аренды маслобоен и прибыли:
Его убытки ограничены, а прибыль неограниченно растет.
Этот пункт также касается продуктовых гипотез, но немного с другой стороны. Важно проверять гипотезы как можно быстрее и дешевле. Т.е. с одной стороны мы ограничиваем убытки с помощью прототипа продукта, MVP (minimum viable product), с другой стороны возможный неограниченный спрос, он же позитивный Черный лебедь. Это и есть выпуклость антихрупкости.
Также автор вводит понятие рационального фланера: это человек, который на каждом шагу пересматривает свой дальнейший маршрут. Маршрут изменяется по мере получения новой информации. Противоположность — турист с изначально запланированным маршрутом. Способность отклоняться от заданного курса – это выбор, который мы можем сделать. Опциональность – это то, что позволяет извлечь выгоду из позитивной стороны неопределенности, а заодно и уклониться от серьезного вреда с ее негативной стороны.
Рациональный фланер, это прямо про Agile.
После обзора спринта, Владелец продукта пересматривает бэклог и решает что будет иметь максимальную ценность для клиентов (заказчиков) на данный момент. Мы сделали прототип, проверили свои гипотезы и корректируем цели, а не следуем первоначальному плану. О чем, собственно, и говорит нам скрамгайд.
2.6. Бриколаж
В продолжение опционов, Талеб говорит о «бриколаже» или прилаживании или о методе «проб и ошибок». Смысл примерно тот же: совершая небольшие ошибки мы рисуем немногим, но если попадем в цель, то это будет «позитивный» Черный лебедь. Выпуклость работает на нас, ведь Черный лебедь может и не иметь ограничений по потолку. И для этого случая тоже есть картинка:
Простое эвристическое правило, которое автор называет правилом определения хрупкости (и антихрупкости). Пусть вы хотите выяснить, не слишком ли оптимизировано движение транспорта в городе. Вы производите замеры и узнаете, что когда трафик возрастает на 10 тысяч машин, время поездки увеличивается на 10 минут. Но если трафик возрастает еще на 10 тысяч машин, время увеличится еще на полчаса. Такое возрастание трафика показывает, что транспортная система хрупка, а значит, в городе слишком много машин. То же самое касается зависимости хрупкой компании от продаж. Если продажи вырастут на 10%, прибыль вырастет меньше, чем на 10%; если продажи упадут на 10%, компания понесет убыток больше 10%.
Метод проб и ошибок — стихия Agile. Ошибайся быстро!
Ошибается PO, ошибаются команды, ошибаются заказчики, ошибаются все. Хорошо что в Agile это происходит, как правило быстро, а значит дешево. Но самое главное, это можно изменить. Команды проводят ретроспективу и улучшаются, PO проверяет гипотезы и бракует несработавшие. Минимально рабочий продукт MVP, который дают заказчику, это тоже, своего рода, метод проб и ошибок. Заказчик «прилаживает» небольшой работающий продукт, который дает представление о том что будет в дальнейшем.
2.7. Меньше, значит больше
Принцип «Меньше, значит больше» несколько раз появляется в книге. Приведу пару цитат из которых станет ясен смысл этого принципа:
«Между тем поток информации легко может навредить: если, переходя улицу, присматриваться к тому, какого цвета у других глаза, рискуешь попасть под грузовик. Когда переходишь улицу, следует отбросить все несущественное, кроме непосредственной угрозы. Как писал Поль Валери: que de choses il fuat ignorer pour agir — сколь многим нужно пренебречь, чтобы действовать!»
В Scrum это называется фокусом. Мы ставим себе цель спринта, чтобы фокусироваться на самом важном что должно быть сделано. Если мы сделаем много мелочей и не выполним цель, то грош цена нашей работе. Воистину меньше — значит больше!
И вторая цитата, она не относится к антихрупкости agile, но очень нравится:
«Я обнаружил, что использовал правило «меньше – значит больше» как инструмент для принятия решений (в противоположность методу, по которому все «за» и «против» выводятся на экран компьютера) чисто интуитивно. К примеру, если у вас есть больше одной причины сделать что-то (например, выбрать врача или ветеринара, нанять садовника или иного работника, жениться или выйти замуж, отправиться в путешествие), просто не делайте этого. Это вовсе не значит, что одна причина лучше двух; просто если вы предлагаете себе больше одной причины, значит, вы пытаетесь в чем-то себя убедить. Очевидные решения (неуязвимые в отношении ошибок) требуют не больше одной причины. Точно так же во французской армии действует эвристическое правило отвергать извинения за самоволку, если солдат указывает более одной причины, скажем, у него умерла бабушка, а еще он подхватил простуду и вдобавок его укусил кабан. Если некто нападает на книгу или концепцию, используя более одного довода, вы знаете, что эти доводы можно игнорировать. Никто не говорит: «Он уголовник, убивший много людей, а еще он отвратительно ведет себя за столом, у него пахнет изо рта и он скверно водит машину».
2.8. Via negativa
И последнее о чем хотелось бы сказать в этой статей — via negativa. Римский папа спросил Микеланджело, в чем секрет его таланта – и как скульптору удалось создать статую Давида, которая считается шедевром среди шедевров. Микеланджело ответил: «Это просто. Я лишь отсек все то, что не есть Давид». Мы знаем куда больше о том, что неверно, чем о том, что верно, или, если перефразировать идею в терминах хрупкости/неуязвимости, негативное знание (о том, что неверно и не работает) более неуязвимо в отношении ошибок, чем позитивное знание (о том, что верно и работает).
С детства мы эмпирически подходим к изучению мира: пробуем и делаем выводы, ошибаемся, падаем, чтобы встать и начать заново, получая бесценный опыт. Так и работает Agile. Мы постоянно улучшаем процессы, зная что у нас работает а что нет. Талеб ставит знание о том что не работает выше чем знание о том что работает. Не исключено что он прав.
Заключение
Надеюсь что вас заинтересовала статья про Антихрупкость и Agile и вам удастся добраться до книги. Там около 800 страниц и их невозможно уместить в одной статье. Ради интереса попробуйте приложить понятие антихрупкости к традиционному проектному управлению. А еще интереснее к своей жизни:)