Ретроспектива в agile что это
Ретроспектива в agile что это
Agile-коуч Марк Лоффлер уверен: ретроспектива — отличный инструмент для начала положительных изменений в команде или во всей компании. Эта практика учит смотреть в прошлое, чтобы извлекать уроки, не цепляться за старые решения и вовремя корректировать курс. Но как провести ее впервые? Вот детальный план из книги «Ретроспектива в Agile».
Подготовка
Определите агенду ретроспективы. Она может выглядеть так:
Обратите внимание: здесь нет одного из этапов — проверки гипотез. Дело в том, что наша агенда рассчитана на команды, которые используют практику впервые или не определили гипотезы в прошлый раз.
Так выглядит полная модель ретроспективы
Когда агенда будет готова, отправьте приглашение всем участникам. Запаситесь флипчартом, маркерами, ручками, стикерами. Не забудьте забронировать комнату, и прийти за 15-30 минут до начала, чтобы успеть подготовить пространство.
Открытие: сравнение с автомобилем
В начале ретроспективы поприветствуйте участников и кратко объясните агенду. Если у команды есть устав, напомните всем о правилах. При отсутствии устава пропустите этот шаг, но в будущем организуйте воркшоп по его созданию.
Попросите участников сравнить период, который обсуждаете, с автомобилем. Каждый должен в нескольких словах описать машину, о которой он подумал. Приведите пару примеров: «ржавый старый фольксваген пассат» или «первоклассный ламборджини мурселаго». Участникам не обязательно следовать фиксированному порядку, но высказаться должны все. Не комментируйте ответы. Поприветствуйте каждый вклад.
Сбор данных
Объясните участникам суть работы. Пусть каждый использует стикеры, чтобы записать все, что делало его раздраженным, грустным или довольным в течение рассматриваемого времени. Оставьте специальное поле, чтобы присутствующие могли сказать спасибо одному или нескольким членам команды.
Нарисуйте большой крест на доске или флипчарте и пометьте четыре области
Совет: пока участники пишут на стикерах, ваша задача — задавать вопросы о четырех категориях, чтобы предложить несколько идей. Это мотивирует других продолжать записи, когда вы почувствуете, что команда остановилась. Например:
Используйте последние 5 минут, чтобы прочитать заметки и получить разъяснения от авторов. Прекратить писать можно именно в это время. По мере чтения стикеров группируйте их по темам. В большинстве случаев это дает представление о насущных проблемах. Выбрать пару тем, которые будут в фокусе на оставшуюся часть ретроспективы, можно двумя способами:
Голосование стикерами или точками
Генерация идей: «5 почему»
Методу «5 почему» исполнилось более 100 лет. Его идея заключается в том, что большинство очевидных на первый взгляд причин проблем — лишь симптомы, а корень зла лежит гораздо глубже. Простой пример: предположим, вы разрабатываете автомобили, но их никто не покупает. Вот ряд вопросов, которые в связи с этим вы можете задать, и возможные ответы на них.
Найти единственный ответ на вопрос «Почему?» не всегда возможно. Иногда существует несколько причин, которые, в свою очередь, могут иметь свои основания. Это нормально.
Определение следующих экспериментов: мозговой штурм
На этом этапе у каждого участника есть 5 минут, чтобы придумать максимум три идеи, которые, по его мнению, имеют самый высокий потенциал для положительных изменений. Участники пишут свои идеи, придерживаясь правила «Один эксперимент на один стикер». Затем стикеры размещаются на открытом участке стены.
Когда время истекает, каждый кратко объясняет свою идею. Требуется рассказать, каким, по его мнению, будет эффект эксперимента. Участники должны попытаться сгруппировать идеи по мере их публикации. Используйте круглые стикеры, чтобы выбрать идею, которая имеет наибольший потенциал для успеха. Соглашайтесь лишь на одну идею. Это может показаться странным, учитывая, что теперь команда готова попробовать множество вариантов. Но если хотите убедиться, что работа действительно выполнена, важно выбрать что-то одно.
Дайте участникам понять, что идея, которую они выбрали, — это эксперимент. Вы способны лишь предположить, каким будет эффект, но никто не может быть в этом уверен. Сейчас важно добавить к выбранному эксперименту гипотезу. Убедитесь, что она поддается проверке. Так вы закладываете основу для следующей ретроспективы, где будете сравнивать исходную гипотезу с тем, что на самом деле произошло в эксперименте.
Совет: выбранные эксперименты должны быть конкретными, исполнимыми, измеримыми и достижимыми (выполняться в течение нескольких дней или недель). Убедитесь, что группа имеет право проводить их. Наконец, эксперимент должен быть ограничен по времени.
Теперь осталось определить, кто отвечает за проведение эксперимента и когда это произойдет. Объясните другим, что ответственный не обязательно должен делать все самостоятельно.
Закрытие: возврат на вложенное время (ROTI)
График, который поможет дать оценку ретроспективе
А теперь проведите ретроспективу о ретроспективе. Для этого часто используется график ROTI. Чтобы создать его, нарисуйте оси x и y, а затем диагональную линию, пронумерованную от одного до пяти. Единица означает: «эта встреча — пустая трата времени», тройка — «встреча стоила того времени, которое я на нее потратил», пятерка — «встреча замечательная, потраченное время полностью окупилось». Чтобы график принял завершенный вид, каждый участник ставит на нем крестик, отражающий его мнение. На рисунке выше видно, что команда довольна своей ретроспективой.
Поздравляем, вы провели свою первую ретроспективу! Пусть такие мероприятия станут регулярными, помогают учиться как на успехах, так и на неудачах, а хорошее делают еще лучше.
Ретроспектива по шагам. Рецепт
Все, кто слышал про Scrum, скорее всего слышали про его основные мероприятия: планирование, пятиминутка (stand-up), обзор спринта и ретроспектива. Многие слышали, инструментов для проведения ретроспектив много, «обучающих» материалов ещё больше, но всё как-то не выходит. Или вроде как выходит, но почему-то команда не хочет в этом участвовать. В этой статье я представлю свой рецепт проведения ретроспектив, не только представив конкретные и детальные шаги, но и попробовав объяснить, почему шаги именно такие и в такой формулировке.
Кто присутствует
Очень желательно на первых двух-трёх ретро присутствие профессионального скрам-мастера. Причём не сертифицированного, а именно профессионального, который не просто прошёл сертификацию и обучение, а применял свои навыки проведения ретроспектив на практике хотя бы год. При кажущейся простоте мероприятие очень просто сваливается в «не туда», и по его итогам даже не понятно, а почему и как это исправить.
В будущем проведение (фасилитацию) ретро можно передать члену команды, а через некоторое время выбирать нового фасилитатора для каждого нового ретро.
Когда
Ретроспектива должна проводиться регулярно. Вообще всё в Scrum должно делаться регулярно. И планирование, и обзор, и ретро. «Сила» методологии именно в том, чтобы превратить непредсказуемый творческий процесс разработки в предсказуемый и планируемый.
Ретро должно проводиться после обзора спринта. Чтобы на ретро команда могла обсудить в том числе и то, как результаты команды были представлены (успешно или нет) заказчикам. Ретро должно проводиться до планирования следующего спринта. Во-первых потому, что планирование следующего спринта, это уже следующий спринт, а во-вторых, потому что в числе результатов могут быть какие-то задачи, которые команда поставит самой себе. И они должны будут войти в следующий спринт.
Что нужно для ретро?
Если ретро проводится в «реальном мире», потребуются стикеры/листочки (по 6-10 штук на человека), ручки и доска с маркером.
В «виртуальном» мире достаточно обойтись расшаренным экраном с двумя/тремя блокнотами, либо одним экраном Confluence / MS Word с тремя полями. Условно их пока можно назвать «плюсы», «минусы» и «действия».
Для целей геймификации можно использовать онлайн-инструменты типа fun retro / easy retro, но пока что ни один из этих инструментов не вписался в тот рецепт, который будет описан ниже.
Начало ретро
(+) Не менее N таких вещей, которые им понравились в текущем спринте, и которые они не хотели бы терять в процессе предлагаемых в рамках ретро изменений.
(-) Не более N таких вещей, которые не нравятся, и хотелось бы поменять.
Другое важное назначение «+»-пунктов, это возможность позже, когда будут предлагаться действия по решению проблем (action point’ы), выбирать те из них, которые минимальным образом будут влиять на то, что команда не хочет потерять.
Важно, чтобы плюсы и минусы записывались на листочках независимо друг от друга. Тем самым мы избавляемся от «проблемы +1», когда люди вместо раздумывания над проблемой просто присоединяются к чужому ответу (аналогичная ситуация происходит, например, при планировании, от чёго защищает «слепое» покер-планирование).
Минусы. В идеале нужно, чтобы участники сразу записали что им не нравится. Не action point, не то, что они предлагают сделать, а то, что им непосредственно мешает в работе. Но в принципе на первые 4-6 ретроспектив достаточно, чтобы участники хоть что-нибудь записали. А далее ведущий уже вытянет из них всю правду (*дьявольский смех за кадром*).
Вполне можно и допустимо сюда писать что-то, что на первый взгляд кажется «внешним» по отношению к команде. Потому что потом на детальном разборе может оказаться, что при внешней причине мы можем что-то поправить в процессе внутри команды.
Анализ
Минусы. Самый сложный этап. Игра в доктора «наоборот».
Берём каждый стикер (присланный нам в персональные предложения пункт) и. не записываем его. А проверяем, что данный пункт описывает симптом, а не болезнь. Почему? Потому что потом мы должны будем предложить такое решение, которое будет наиболее эффективным способом избавиться от симптома. И «лечение» самой болезни может быть одним из, но не самым эффективным (с точки зрения усилий и времени) способом. Кроме того, данный симптом может быть вызван несколькими причинами, и возможно только одну из них нужно будет убрать, и это вовсе не та, которую изначально назвал член команды.
Ещё раз. Каждый пункт надо записать в виде симптома, а не болезни (и точно не в виде action point’а). Например. Член команды записывает на стикере «у нас неоптимальный CI-скрипт«. Если оставить как есть, единственным возможными способом решения данной проблемы будет, очевидно, переписать CI-скрипт. Но нужно ли?
Уточняем у члена команды, «[Олег], на что в твоей работе влияет то, что CI-скрипт не оптимален»? Внезапно оказывается, что:
скрипт медленно работает
медленная работа приводит к медленному прохождению pull request’ов
невозможность распарраллелить работу приводит к простою
это приводит к медленной работе члена команды
скрипт работает недетерминированно, иногда проваливаясь из-за фазы луны и положения Сатурна в созвездии козерога
это приводит к необходимости ручного перезапуска CI
это приводит к медленной работе члена команды
Но зато для каждого следующего более общего уровня можно предложить самые разные варианты решения проблем:
поставить больше CI-агентов для сборки и распараллелить его работу / сборку / разрешить параллельную работу нескольких сборок одновременно
поставить посильнее машину для CI
выкинуть часть действий из CI-скрипта, не переписывая его кардинально
полностью переписать CI-скрипт
научить пользователя переключаться между ветками в git, позволив ему распараллелить работу и не ждать CI
сделать простой скрипт для перезапуска failed-сценариев 2-3 раза
Но пока что возможный список даже не озвучиваем. Но мы должны (из своего опыта) как-то понять, что именно та формулировка, которая будет записана, может, хотя бы в теории, быть решена несколькими разными способами. И вот именно эту формулировку и надо записать в «минусы».
Очень важно при попытке вытащить из члена команды более общую проблему не задавить его авторитетом и не подложить свою проблему вместо его. Все мы люди, все мы субъективны, и можем увидеть в чужой проблеме вовсе не то, что беспокоит члена команды, а что беспокоит нас самих. Уметь оставлять свои проблемы в стороне и слушать (и слышать) другого человека, наверное, самое важное для того, кто собирается в IT работать с людьми. Но это очень и очень сложно. Ничего страшного, если Вас по началу будут поправлять и говорить, «нет, это вовсе не то, что меня беспокоит, меня беспокоит другое». Замечательно, если Вам будут это говорить. Гораздо хуже, если с Вами молча согласятся, чтобы не спорить и побыстрее закончить.
Голосование
Изначально считаем, что за каждый пункт подано столько голосов, сколько изначальных «минусов» было сгруппировано в него. Далее я предлагаю членам команды проголосовать дополнительно за 1 или 2 пункта (из сгруппированных 7-10), Но только за те, в которых нет пунктов, которые они формулировали сами (или в которые были переформулированы их «минусы»).
В результате формируется отсортированный «по голосам» список проблем.
Блиц-этап
60 секунд это скорее ориентир. На то, что не нужно тратить много времени на блиц-проблемы, которые не являются самыми больными местами в процессе.
Перерыв на кофе
Перед перерывом на кофе окончательно формулируем top3 проблем, которые нужно обсудить, и предлагаем членам команды пойти покурить/попить/выпить/отойти проверить почту.
Обсуждение. Action Points
Во-первых, не надо отбрасывать решения, которые не решают проблему целиком. Нас вполне устроят решения, которые решают проблему хотя бы частично. Хоть на 20%, но облегчают жизнь команды. Кто знает, может именно этих 20% хватит, чтобы в следующий раз проблему не включили в top3?
Во-вторых, решения должны проходить валидацию у тех, чьи проблемы были изначально сгруппированы в единый «пункт симптомов болезни». Хотя бы один из них должен подтвердить, что предложенное решение действительно сделает его жизнь проще.
В-третьих, формулировка. Формулировка должна быть такой, чтобы у команды был минимальный шанс не выполнить пункт.
Плохой вариант
Вариант получше
Нужно устроить встречу и обсудить розовых единорогов
[Олег] устраивает встречу во-вторник в 15 часов по обсуждению проблемы питания розовых единорогов
Ответственно подходить к ревью pull request’ов
— (или) при отклонении pull request’а оставлять комментарий
— (или) настроить бота, назначающего PR на ревью на членов команды
— (или) добавить в CI-скрипт автоматический линтер, а все проблемы в оформлении, которые им не покрываются не считать проблемами
заранее формулировать тикеты в jira до планирования
[Олег] заведёт в outlook еженедельный backlog grooming до планирования с участием владельца backlog’а, представителя аналитиков и solution-архитекторов смежных систем
Полученные шаги записываются в action point’ы.
Почему ретро может не помочь
Может так случиться, что сделали всё по рецепту, а огонёк в глазах команды всё тусклее и тусклее, а производительность команды падает. Потому что автор этого текста ни хрена не знает. Ретроспектива в этом случае позволяет найти часть этих причин, и задуматься, почему эти причины до сих пор не исправлены.
Признаками проблем являются:
Ретроспектива проводится за полчаса. Это не ретроспектива, это отчёт-доклад команды «как у нас всё хорошо, как здорово и дружно мы живём, дорогой дедушка Ленин«. Явный признак того, что мероприятие проводится для галочки, без той пользы, которую могло бы принести полноценное ретро.
Повторяющиеся в две-три ретроспективы похожие описания проблем. Команда предполагает, что теоретически эти проблемы можно было бы попытаться решить какими-то действиями внутри команды. Может быть даже предлагает action point’ы.Но в какой-то момент эти проблемы просто исчезают из анализа, потому что команда уже привыкла к тому, что высказывать их бесполезно. Но сами проблемы-то никуда не делись!
Если таких проблем много, то в какой-то момент появляются фразы «слишком много времени тратится на ретроспективы». Это прямо-таки прямой сигнал о том, что с ретроспективой всё плохо. И да, без изменения формата ретро далее проводить бессмысленно.
Невыполненные action point’ы (при том, что проблема не ушла). Возможно они были очень неудачно сформулированы. А возможно тот, кто должен был их выполнить, забыл/забил/не захотел их делать.
Антипаттерны ретроспективы в Agile-команде. Часть 1
Недавно я подсчитала, что за несколько лет работы в роли Скрам Мастера я провела более 100 ретроспектив в Agile-командах. О важности ретроспективы и том, как она отражает ситуацию в команде и влияет на ее развитие, хочу поговорить в этой статье.
Пару слов обо мне. С 2015 года я фокусно работаю над построением счастливых и эффективных Agile-команд в международных компаниях. Кроме того, мне нравится заниматься внутренним обучением. Помимо основной работы с командой я преподаю в школе Скрам Мастеров и провожу тренинги по направлениям Agile/Scrum/Agile testing.
С момента начала моей карьеры в роли Скрам Мастера, мне посчастливилось напрямую поработать с 10 очень разными и интересными командами. Каждая из них развивалась в своем уникальном темпе и все же было у них нечто общее — качество проведения ретроспектив сильно влияло на общую эффективность команды. При этом я заметила, что в любой команде ретроспектива рано или поздно перестает работать. Что-то происходит и этот самый популярный инструмент Инспекции и Адаптации ломается, т.е. перестает помогать команде адаптироваться и совершенствоваться.
Я систематизировала свои наблюдения и хотела бы поделиться 5 основными антипаттернами, которые я встречала в своих командах.
В рамках каждого антипаттерна хочу обсудить:
Антипаттерн № 1 «У нас все хорошо»
Команда ретроспективу проводит, но считает это формальностью. Антипаттерн проявляется в том, что команда в принципе решает ретроспективу не проводить (нет проблем, все хорошо – зачем собираться?). Но на моей практике этот случай встречался крайне редко и отказ от ретроспективы диктовался скорее другими причинами. О них я потом напишу отдельную статью. А пока вернемся к тому, как распознать этот антипаттерн.
Признаки и причины:
Команда собирается, открывает стандартный шаблон активности на ретроспективе (mad/sad/glad или start/stop/continue), записывает основные положительные моменты прошедшей итерации и через 20-30 минут расходится без обсуждения проблем и плана улучшений в команде. Команда либо избегает говорить о проблемах, либо убеждает Скрам Мастера и друг друга, что улучшаться уже просто некуда.
В чем может быть причина такого поведения?
В этой истории для меня многое зависит от того, насколько я, как Скрам Мастер, верю, что в команде все хорошо, или же у меня есть в этом сомнения.
Если есть ощущение, что в команде действительно все идет замечательно, можно действовать следующим образом:
— Предложить команде на ретроспективе сложный, выводящий из зоны комфорта вопрос. Например, «что мы, как команда, можем придумать, чтобы поставлять в 10 раз больше функциональности, чем сейчас, за то же время». Или «как можно полностью уйти от ручного прогона регрессии». Для некоторых моих команд второй вопрос звучал еще более неадекватным, чем первый.
Первая реакция на этот вопрос скорее всего будет ступор и удивление, но следующим шагом может стать интересный мозговой штурм, взгляд на систему в целом и интересные идеи оптимизации всего процесса поставки ценности.
— Воспользоваться возможностью членам команды узнать друг друга еще лучше и прокачать командную работу с помощью игр. Я не буду подробно останавливаться на теме игр, скажу лишь, что есть замечательные активности на работу с ценностями Скрама, для построения фокуса на общей цели, на построение доверия в команде. В открытых источниках есть множество описанных форматов игр. О тех, которые проводила я, делюсь у себя в профессиональном блоге Скрам Мастера.
Конечно, играми не стоит полностью заменять ретроспективы, но они могут стать «передышкой» для команды, возможностью сменить рабочий контекст и посмотреть на эффективность командной работы с другой стороны.
И все-таки, что делать Скрам Мастеру, если нет этой внутренней уверенности, что все хорошо? На этот случай у меня есть две идеи.
Первая – это расширить контекст ретроспективы для команды, т.е. расширить угол зрения на ситуацию в команде. Например, этого можно добиться добавлением на ретроспективу новых участников. Я видела много команд, которые проводили ретроспективы без участия владельца продукта в силу разных обстоятельств (он не хотел, так исторически сложилось, языковой барьер). Для таких команд ретроспектива с участием владельца продукта пройдет совершенно по-новому. Эту же идею можно реализовать, пригласив членов других смежных команд, которые стоят впереди или после команды в цепочке поставки ценности. Одна важная деталь – все это необходимо делать с согласия команды, приглашенный гость в качестве сюрприза скорее принесет боль и недоверие к Скрам Мастеру, чем поможет наладить ретроспективу.
Вторая идея – Скрам Мастеру или кому-то из членов команды предложить собрать данные, которые раньше никогда не собирали. У меня в опыте есть замечательный пример, когда анализ собранной статистики о количестве заведенных дефектов внутри спринта (а именно тренд этой метрики за 4 прошедших спринта), привел команду к очень продуктивным обсуждениям, как повысить качество тестирования у разработчиков и как организовать тесное взаимодействие тестирования и разработки внутри спринта. Зачастую случается так, что в целом команда отлично справляется и по своим ощущениям, и по обратной связи снаружи, но есть еще много моментов для улучшения, нужно просто обратить на них внимание команды.
Антипаттерн №2 «Ноем, жалуемся, плана нет»
История о том, что команда с готовностью приходит на ретроспективу жаловаться, возмущаться, горевать, ныть, но плана работы с проблемами, как и плана улучшений, в результате ретроспективы нет. Точнее, план у команды есть, набор действий составлен, есть ответственные, но этот план не помогает команде реально улучшаться, не помогает ставить эксперименты и проверять гипотезы с целью повышения эффективности работы или повышения качества продукта. Этот план скорее формальность, план ради плана.
Начнем по порядку. Чтобы в команде мог появиться план улучшений, прежде всего, нужно, чтобы повестка ретроспективы (а именно все ее фазы – регистрация, сбор идей, анализ идей, составление плана улучшений, завершение и обратная связь) была прозрачна команде, и в ней оставалось время на составление плана дальнейших действий. У меня были случаи, когда мы не успевали глубоко проработать план действий и тогда я назначала отдельную сессию, чтобы закончить ретроспективу и сформировать план. Я считаю, что лучше расширить выделенное на ретроспективу время, чем закончить вовремя, но выйти без результатов.
Если в команде проблемы с тем, чтобы укладываться в запланированное время встречи, есть подход установки нескольких таймеров, например, на 15, 8 и 5 минут. С самого начала команда знает, что обсуждение должно закончиться к концу третьего таймера и больше сфокусирована на том, чтобы договориться. Вообще техники фасилитации, организация работы в малых группах и фиксированное время на для обсуждений и отдельных фаз ретроспективы творят чудеса и помогают приводить к выработке решений даже группы со сложной динамикой.
Что же делать Скрам Мастеру, если команда приносит на ретроспективу в основном организационные темы и избегает реальных проблем? Есть несколько инструментов, которые по моему опыту помогали:
Антипаттерн №3 «План есть, но мы ничего не делаем»
Название говорит само за себя – у команды был составлен план, но придуманные действия или эксперименты не выполняются.
Признаки антипаттерна достаточно очевидные – на следующей ретроспективе команде нечем поделиться в качестве результатов выполнения придуманных ранее действий или договоренностей. У всех, конечно, есть уважительные причины – не успел, руки не дошли, занимался более важными делами, забыл. Но в результате продвижения в плане улучшений и экспериментов нет.
Говоря про этот антипаттерн, я хочу подробнее остановиться на «тревожных звоночках» на этапе составления плана, которые на моей практике чаще всего были сигналами, что действия из плана выполняться не будут:
1. Не понял
2. Не могу
3. Не умею
4. Не хочу
Мне эта мысль сильно помогает остановиться и подумать, можно ли исключить варианты «не понял, не могу, не умею», прежде чем начинать работать в области «не хочу» и разбираться с мотивацией человека, зачем он в команде и какие у него цели.
Давайте посмотрим, что конкретно можно сделать, в зависимости от того, в чем есть причина бездействия.
Причина 1: член команды, который согласился взять на себя какой-то action item действительно не понял, что от него ожидается.
Скрам Мастер может добавить самую главную активность из плана с ретроспективы в бэклог спринта (согласовав это с владельцем продукта на ретро или после), оценить ее, отметить, кто именно ей будет заниматься, сделать прозрачным для всех, что команда будет тратить на это время.
Причина 3: член команды вновь был бы рад выполнить то, на что подписался, потому что ему это правда интересно и важно (например, выбрать наиболее подходящий фреймворк для нагрузочного тестирования), да вот только он никогда с этим раньше дело не имел и никак не может понять, с чего начать. На этом он и заканчивает, так как может быть неприятно объяснить команде, зачем же он взял эту активность, если не умеет.
Скрам Мастер может уточнять у того, кто готов взять на себя активность в рамках плана ретро, приходилось ли ему делать что-то подобное раньше. Если нет, наверняка в команде есть кто-то более опытный в этом вопросе, кто смог бы помочь. А если у всей команды нет экспертизы в области, Скрам Мастер может взять на себя задачу поискать экспертов в других командах или сообществе.
Итак, я поделилась мыслями о первых трех антипаттернах ретроспективы в Agile командах, с которыми встречалась в своей практике, а впереди еще два, не менее интересных и не менее часто встречающихся антипаттерна.
Буду рада вашим историям и наблюдениям о ретроспективах, которые работают и которые нет. Расскажите, какие у вас есть техники и приемы построения эффективных ретроспектив. Вы догадываетесь, о каких двух антипаттернах я планирую рассказать в продолжении?