Ведь, если лампочки зажигают –
значит – это кому-нибудь нужно?

Кому-нибудь из тех, кто не мыслит жизни без свободы… от наличия на небе естественных светил. А ведь наши далёкие предки, в большинстве своём, безальтернативно посвящали ночное время глубокому сну. Да, чего уж там! Говорят, пока лампа Эдисона не завоевала популярность, люди спали по 10 часов в сутки. Лично я, находясь в потоке, не могу спать больше пяти. Но даже этого слишком много! Часто бывает достаточно трёх. Только без удобного и безопасного искусственного света о подобном оставалось бы лишь мечтать.

И хотя Томаса Эдисона называют королём изобретательства ^[1], идея электрической лампы накаливания принадлежит не ему. Зато ему удалось воплотить её в жизнь. Стать батарейкой, позволившей лампочке идеи зажечься. Обеспечить решающий эффект для прорывной технологии.

За несколько лет работы аналитиком, я придумал массу прекрасных ламп программных систем… чтобы потом, с обливающимся кровью сердцем, наблюдать их безжизненные нити. Никакой самоотверженный труд в рамках отведённой роли не позволял увидеть свет в конце проектного туннеля.

В минувшем году я окончательно пришёл к тому, что ныне склонен называть Advanced Agile Analysis. То, что помогло мне, подобно Эдисону, стать человеком-батарейкой, обеспечивая эффект технологических проектов вместо традиционного поклонения краткосрочным успехам, процессам и инструментам.

11 февраля 2001 года в США на горнолыжном курорте штата Юта встретились 17 «странных» людей ^[2], ведомые ещё более «странными» идеями. Это были истовые практики программной индустрии, не желавшие мириться с накопившимися системными проблемами домена и предлагавшие собственные подходы к их решению. И хотя подходы эти немало разнились между собой, к 13 числу собравшимся удалось сформулировать 4 ценности ^[3] и 12 принципов ^[4], которые их всех объединяли. Полученные тезисы они назвали Манифестом гибкой разработки программных продуктов (Manifesto for Agile Software Development) и это стало началом больших перемен. Вот уже 12 лет с тех пор, как парадигма Agile победоносно шагает по планете, обрастая новыми идеями, последователями и практиками. И пусть некоторые фактические утверждения Манифеста начинают терять свою актуальность ^[5] (или, по крайней мере, универсальность), суть его принципов остаётся неизменной.

Внедряя Scrum ^[6] у себя в компании, я свёл эти принципы в свой аджайл-будильник ^[7], чтобы сверяться с ним каждый раз, когда ситуация перестаёт быть для команды прозрачной, и в проекте начинают раздаваться тревожные звоночки. Как аналитику, мне близок и понятен каждый его час, выросший из типичных проблем консервативных подходов, на которые мне вдоволь довелось насмотреться на самых разных проектах, проектных стадиях и стадиях жизненного цикла различных продуктов.

Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

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

Каждый человек, освобождённый от унылой рутины и переходящий на более высокий уровень спиральной динамики ^[8], становится в разы ценнее и полезнее для общества, а если вы знакомы с Этическим кодексом программной инженерии ^[9], то наверняка помните, что «программные инженеры должны действовать неукоснительно в интересах общества».

В мире Agile у владельца продукта (Product Owner — одна из скрам-ролей) есть целый арсенал разнообразных инструментов ^[10] для обеспечения максимального эффекта от разрабатываемого ПО. Главным из них на сегодняшний день я считаю карты эффекта (Impact Maps ^[11]), активно продвигаемые в последние годы Гойко Аджичем ^[12]. У него даже книга ^[13] в октябре вышла.

Эффект состоит в достижении целей, осуществляемом людьми (персонами) посредством определённых деятельностей (поведения). Нам нужно лишь понимать, как мы можем способствовать этой деятельности своими технологиями, и, исходя из этого понимания, формировать и актуализировать бэклог (состав) нашего продукта. Для более высокоуровневой картины мы можем использовать шаблон бизнес-модели (Business Model Canvas ^[14]) и дорожную карту (Roadmap ^[15]), для более детальной — карты историй (User Story Maps ^[16]) и карты пути пользователя (Customer Journey Maps ^[17]). Если вам всё это интересно, советую почитать блог ^[18] и полистать презентации ^[19] Артёма Сердюка. Он здорово продвинулся в развитии и взаимной интеграции всех перечисленных (и многих других) техник.

Как бы то ни было, сами по себе инструменты никогда не позволят вам эффективно следовать завету Гойко: «Make an impact, not just ship software». Для этого нужна высокая предметная ориентированность всей скрам-команды, которая зависит от конкретных людей, их культуры и ценностей, их понимания ситуации и умения принимать взвешенные коллективные решения. Только основательно работая с людьми, можно ожидать действительно регулярных и ранних поставок по-настоящему ценного ПО. Более того, в моей практике были случаи, когда необходимый эффект для организаций достигался без единой строки кода — совершенствованием бизнес-процессов или дополнительным обучением сотрудников. Не софтом единым.

Изменение требований приветствуется, даже на поздних стадиях разработки. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.

Да-да, задачи, заставляющие разработчиков с нецензурщиной и проклятьями переписывать существенные части системы, чаще всего возникают не по дьявольской прихоти или злому умыслу заказчика. «Panta rhei» — так писал Гераклит Эфесский. Частые изменения в абстрактных системах неизбежны, поскольку постоянно меняется реальный объект их приложения — окружающий нас мир. И неуёмное менеджерское желание жёстко зафиксировать всё и вся в рамках двух магических букв лично мне набило оскомину ещё в первые месяцы работы аналитиком.

Классическое ТЗ, как показывает практика, с заданием, а уж тем более техническим, имеет мало общего. Это даже не Точка Зрения, как кто-то недавно удачно пошутил. Практика говорит о том, что ТЗ — это многократно вычитанные и завизированные Табуированные Задницы менеджмента с обеих сторон контракта. И ничего более. Только вот традиционное заказческое «Это соответствует моим требованиям, но не решает мою проблему», как правило, ни одну из этих сторон в конце концов не устраивает. Так, что же делать?

В бережливом подходе к разработке ПО ^[20] (Lean software development) есть один замечательный принцип: «Decide as late as possible». На русский его перевели, как «предельно отсроченное принятие решений». Согласно этому принципу вы не должны в первый же день знакомства ставить заказчика к стенке и пытать до тех пор, пока не выудите все «требования» и поверх них подпись с печатью. Если вы так поступите, большая часть принятых решений будет основана на предположениях отдельных лиц. И чем больше таких предположений будет сделано, тем меньше вероятность того, что ваш продукт выстрелит. Не забывайте, что зачастую мы приходим в отрасли, которые десятилетиями ожидали технологий, а вы хотите за два часа опроса получить от работающих там людей конечное видение продукта. Это форменный формальный бред.

Lean предполагает, что вы будете принимать окончательные детализированные решения лишь в тот момент, когда в этом возникнет непосредственная необходимость, то бишь при переходе вашей истории ^[21] (User Story) из плана (бэклога) в разработку (а бывает, и того позже). Это позволяет протестировать возникающие идеи и предположения до того, как они станут неотъемлемой частью функционала вашей системы, тем самым минимизировав уровень потерь (waste) и максимизировав уровень эффекта от выпуска продукта.

Что касается самого магического двухбуквенного документа, то на этот счёт отлично выразился в своём «User Stories Applied» Майк Кон ^[22]: «A requirements document should be written only when it helps achieve the real goal of delivering some software». Классическое ТЗ таким документом не является. Поверьте мне, как аналитику. Но если бумажного идола от вас требуют некие бизнес-правила (условия договора с международной организацией или государственные регламенты, не важно), всегда можно обернуть ваши истории в привычную для кого-то целлюлозную упаковку. Только делать это нужно умеючи. У меня получалось. Работает.

Сложнее всего, конечно, с теми изменениями, необходимость в которых возникает именно «на поздних стадиях разработки». Но о них мы поговорим… часов через семь.

Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

Тот самый принцип, фактическое утверждение которого о периодах релизов на сегодняшний день потеряло свою актуальность. 12 лет назад проекты по разработке ещё могли длиться годами до первого выпуска продукта. Это, по большей части, было дурным наследием типичных госзаказов и военных разработок, для которых столь долгое ожидание «не вызывало каких-либо проблем» и дополнительно было окутано целым туманом бюрократических процедур. Но для 17 авторов Манифеста проблемы были очевидны. И релизы раз в несколько недель казались тогда настоящей революцией. В сущности, так оно и было.

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

Руководство по скраму ^[23] (Scrum Guide) предписывает эту активность скрам-мастеру в качестве обязанности по отношению к владельцу продукта. В действительности, любое планирование в эмпирической среде является делом коллективным. Чем больше релевантных людей вы подключите к планированию, тем выше точность получаемого плана.

Сопоставить производительность (velocity) команды с фактической диаграммой прогресса (burn-down || burn-up chart) может каждый, а вот комплексно спроецировать это на события реального мира в состоянии лишь коллектив заинтересованных профессионалов. Рост и падение фокус-фактора, планируемые мероприятия заказчика и состояние предметной среды, возможные отгулы и отпуска в команде — всё это просто физически не может поместиться в голове одного человека. Лично для меня планирование релизов — абсолютно не механическая процедура, а серьёзный интеллектуальный анализ многопараметрической системы методом мозгового штурма.

Частные поставки являются одним из основополагающих принципов всех гибких подходов к разработке. Это постоянная проверка и адаптация вашего продукта и процесса, которые при наличии третьего фактора — прозрачности — обеспечивают устойчивость и стабильность всей системы разработки. Впрочем, об этом тоже ещё будет несколько слов.

На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе

И точка. Сколько раз мне приходилось играть роль [неизбежно испорченного] телефона между заказчиком и командой разработки, столько я в этом безапелляционно убеждался.

Другое дело, что во многих случаях идеальная аджальная физическая доступность заказчика маловозможна и «нерентабельна». Тогда в процесс нужно подключать современные средства коммуникации: видео-конференции (желательно в купе с инструментами совместной работы; например, Google Hangouts + Docs или Rizzoma), телефонные переговоры или, по крайней мере, постоянный живой чат. Как только вы в той или иной мере разрываете связь между двумя полюсами эволюции продукта, происходят две непоправимые вещи: заказчик перестаёт чувствовать прогресс (нарушается принцип прозрачности), а команда перестаёт получать быструю обратную связь (существенно уменьшается количество проверок и адаптаций).

Только не забывайте, что тут есть также и два очень важных «но». Во-первых, коммуникация инициируется исключительно со стороны разработчиков, когда им нужно принимать решение и без мнения заказчика не обойтись. Во-вторых, «доступность» не означает «присутствие». Бизнес нужно держать в зоне досягаемости, но не подпускать слишком близко. Обратная ситуация грозит неизбежными попытками «вброса» дополнительных фич и прочими неприятными моментами, которые скрам не приемлет. За всем этим следит скрам-мастер. Если же заказчику действительно необходимо что-то изменить в бэклоге спринта, то это решается путём честного обмена историями: сколько добавляем, столько и снимаем с доски. Лишь бы цель итерации не менялась. Впрочем, всё это довольно доходчиво описано в Гиде. Не будем углубляться.

Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

На мой взгляд, это самый важный принцип. Два года назад, на 10-летний юбилей подписания Манифеста, Кен Швабер, соавтор Скрама, очень метко озаглавил ^[24] свой отзыв: "It’s About People". «I think we have started a quiet revolution toward people no longer being thought of as resources». Вы же помните: «Люди и взаимодействие важнее процессов и инструментов».

Это то, что сложнее всего объяснить классическому менеджеру (но, к счастью, возможно). Люди — не ресурсы. Их не нужно «контролировать». Ими не нужно «управлять». Им нужно обеспечивать поддержку и доверять. Мотивированные профессионалы не прилетают с Криптона в развевающихся плащах, пусть вас не обманывает иллюстрация. И мотивация, и профессионализм во многом зависят от того, кто эти люди (какие у них ценности и способности) и в каких условиях они работают (с кем, где, над чем, сколько и т.д.).

Вообще, я не знаю, что означает «мотивировать» кого-то. Я знаю, как вдохновить человека ярким и захватывающим видением продукта, как объяснить ему правильные вещи ^[25], которые предстоит разработать, на языке визуального мышления ^[26] и понятных лаконичных формулировок, наконец, как помочь справиться с технологическим затруднением программированием в паре и ревью кода. Давайте работать с людьми именно так, а «мотивирование» оставим отважным дрессировщикам диких животных.

Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

Проверено многолетней практикой. Особенно меня напрягают моменты, когда в ответ на какой-то вопрос заказчик начинает посылать команду на те самые магические буквы, о которых речь шла выше. Это означает только то, что человек либо недостаточно заинтересован в выпуске продукта, либо просто не понимает, что документ никогда не сможет заменить живое общение. В таких случаях я обычно ответно посылаю его на три слова аллитерации из всё того же «User Stories Applied»: Card, Conversation, Confirmation. В аджайле есть очень чёткое разграничение между манифестацией истории, её обсуждением и проверкой. Но об этом, я надеюсь, мы в подробностях поговорим в мае на питерском Analyst Days. Единственно, приведу два ключевых тезиса об ограничениях классического документа.

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

Во-вторых, классический документ — это типичный информационный рефрижератор ^[27], в котором информация устаревает быстрее, чем его дочитывают до конца. Аджальный же бэклог — это живой «документ» (в наглядном виде — информационный радиатор ^[28]), который развивается одновременно с развитием проекта. Об этом тоже неплохо написано в Руководстве по скраму. Советую взглянуть.

Ну, и, наконец, аджайл часто обвиняют в отсутствии возможности глубокого ретроспективного анализа проектов, ввиду отсутствия подробной документации. Как обходится это ограничение я рассказывал на киевском Agile Base Camp в начале текущего месяца. Могу даже ссылку на презу ^[29] дать. Но без Conversation, думаю, мало что будет понятно. Постараюсь зарелизить статью весной. Только уже не на Хабре, а на analyst.by, потому как вся эта кухня гораздо интереснее аналитикам, нежели широкой хабраобщественности.

Работающий продукт — основной показатель прогресса.

Все помнят фильм «Изгой» с Томом Хэнксом в главной роли? Думаю, да, потому что фильм очень достойный. А помните такого «персонажа», как мистер Уилсон? Да, тот волейбольный мяч, который стал для человека, обречённого на длительное одиночество, единственным «другом» и способом не сойти с ума.

Программные системы, которые мы создаём, перестают быть немыми абстракциями в тот самый момент, когда соприкасаются с миром реальных людей, решая их повседневные задачи, а порой и самые сокровенные проблемы. Как вы определяете, что ваш продукт «работает»? По подписи заказчика на акте выполненных работ? Или, может, исходя из того факта, что все требования заказчика реализованы и всё «работает без сбоев»?

В мире аджайла нет понятия «реализованных требований», зато есть персоны, для которых пишутся истории, и критерии готовности для каждой такой истории, в соответствии с которыми истории проверяются (Confirmation), и принимается решение о готовности каждой из них в отдельности, и системы в целом.

Работая в основном в корпоративном секторе, для которого обязательной частью поставки программных продуктов являются руководства пользователя и администратора, я пришёл к одной хорошей практике. Я стал создавать руководства и показывать их будущим пользователям, начиная с самых ранних стадий разработки, чтобы оперативно получать обратную связь. Сначала это короткие описания с каркасами интерфейсов (wireframes), потом макеты постепенно увеличиваются в уровне детализации (mockups) и, в соответствии с этим, детализируется описание возможностей. В конечном итоге заказчику передаётся полноценный документ, с содержанием которого пользователи уже прекрасно знакомы.

Я обычно сравниваю руководства с инструкциями к лекарствам. Если инструкции нет или она написана из рук вон плохо (обычно о руководствах вспоминают в последний момент перед поставкой и делают его кое-как), пациент, в лучшем случае, не получит от препарата никакого эффекта. В худшем — отравится и умрёт. Но мы ведь работаем не для того, чтобы убивать людей или организации, верно?

Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.

Устойчивость процесса — одна из основных целей применения гибких подходов. Если вы рассчитываете на быстрый однократный результат, не используйте аджайл. Лучшее вообще не разрабатывайте программные продукты, потому что в этой индустрии не бывает ничего быстрого и однократного.

Каждая программная система — это живой организм с собственной «судьбой», и то, какой след оставляет эта судьба в судьбах тех людей, которые сталкиваются с вашим продуктом, во многом определяет и судьбу вашей деятельности. Иными словами, любая программная система в той или иной мере развивается, и вот как раз поддержка её развития вызывает наибольшие затруднения у тех организаций, которые не стремятся к устойчивому процессу, а ориентируются на сиюминутный результат.

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

Как правило, мы расписываем все предполагаемые истории на карточках, обсуждаем их и классифицируем по уровню важности: H (hight — истории высокой важности), M (medium — истории средней важности), L (low — истории низкой важности). Потом разработчики ориентировочно классифицируют те же истории по сложности разработки: H, M, L. Далее, сравнивая эти показатели и сопоставляя с временной шкалой, мы совместно приходим к дорожной карте развития продукта, которая, как правило, состоит уже из нескольких проектов. Это происходит мирно и продуктивно. Так формируются доверие и прозрачность. Так же они должны и поддерживаться на протяжении всего периода сотрудничества. Итеративность и инкрементальность процесса позволяют этого достичь. Но сотрудничество здесь — ключевое слово.

Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

Как и обещал, через 7 часов мы вернулись к вопросу об изменениях, возникающих на поздних стадиях разработки. Думаю, все понимают, что единственная возможность их безболезненно вносить — это качественно проектировать вашу систему. И речь в первую очередь идёт о «внутреннем качестве», как это назвал Хенрик Книберг в своих «Заметках с передовой». К изменениям нужно готовиться изначально, потому что они неизбежны.

Но точно так же, думаю, все понимают и то, что, если проектировать и разрабатывать «абсолютно гибкую систему», на это уйдёт гораздо больше времени, и далеко не факт, что это время окупится. Ни один заказчик не согласится переплачивать и ждать дольше, чем это смог бы предложить ему ваш конкурент. Это «логично» (если не понимать, что за этим стоит).

Именно поэтому и нужна коллективная работа. Не нужно, да и невозможно, подготовиться ко всем изменениям; изменения нужно прогнозировать, причём совместно — заказчику, разработчикам и пользователям. Для этого у нас есть живой бэклог продукта, для этого у нас есть планирования спринтов и груминг сессии, для этого у нас есть голова на плечах. На всём протяжении проекта люди задаются вопросом — что может быть дальше. Без этого вопроса вы создадите такой же «рефрижератор ситуации», каким рефрижератором информации является традиционное техническое задание. Не пытайтесь замораживать время, у вас всё равно ничего не выйдет. Думайте, общайтесь и проявляйте своё техническое мастерство — только так создаются живые, готовые к изменениям, продукты.

Простота — искусство минимизации лишней работы — крайне необходима.

Всё, что есть в гибкой разработке — подчиняется этому правилу. Лично для меня Agile это, в первую очередь, искусство оперативного управления вниманием (Attention manaGement In reaL timE). Потому что внимание — самое дорогое, что только может быть у человека, занимающегося интеллектуальным видом деятельности. «Дорого не время, дорого — внимание», если перефразировать известную поговорку. У вас может быть полно времени, но, если вы не сможете на всём его протяжении сконцентрироваться на задаче, вы её не решите.

Именно поэтому в гибких подходах вы не найдёте сложных ролей, мероприятий или артефактов. Все они изначально ориентированы на минимальную формальную инфраструктуру: «просты в понимании и чрезвычайно сложны в овладении». Потому что все остающиеся «пробелы» вам придётся заполнять своим профессионализмом, креативностью и стойкостью. Это гарантирует, что вы никогда не впадёте в инструментопоклонничество, а всегда будете думать своей головой и работать собственными руками. Будьте человеком-батарейкой ^[30], а не человеком-снежинкой ^[31]!

Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

Кто-то в этом сомневается? Попробуйте, тогда поговорим.

Самоорганизация предполагает, что людям не нужды указания извне, чтобы справиться со своей работой. Самоорганизация предполагает, что люди умеют принимать коллективные решения и приходить на помощь друг другу даже в самой критической ситуации. Самоорганизация предполагает, что ваша команда — это единый организм, способный адекватно реагировать на любые проявления внешней среды. Самоорганизация предполагает, что ваша команда — это вся ваша компания.

Но самоорганизация, как и гибкость в целом, это направление, а не место. И обрести это направление помогает последний и самый важный принцип…

Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы.

Всё написанное выше не имеет ни малейшего значения… если не сопровождается непрерывным процессом самосовершенствования. Всего четыре ценности и двенадцать принципов. Разве могут они ответить на все вопросы, которые ежедневно ставит перед нами эмпирический процесс? Естественно, нет. Они предназначены не для этого. Если звонит какой-то час будильника, это не команда к какому-то предопределённому действию, это сигнал к тому, что нам нужно сконцентрировать общее внимание над чем-то и постараться это улучшить. С учётом коротких итераций и небольших сплочённых команд, в долгосрочной перспективе это обеспечивает гарантированный эффект: ощущение контроля, ощущение прогресса, ощущение значимости и глубокие человеческие отношения. Именно эти факторы, по мнению одного из ярчайших предпринимателей современности — Тони Шея, позволяют нам «доставлять счастье».

Именно над этим бьются передовые практики нашей отрасли, и именно это я хотел до вас донести. Я считаю, что это — [бирюзовое] будущее. И я буду бороться за него до последнего ампер-часа. Потому как, если мы бросаем вызов времени и пространству, если мы желаем оставить во Вселенной импакт…

Значит – это необходимо,
чтобы каждый вечер
в окнах
загоралась хоть одна лампа?!

Автор: VadimMusteata

Источник ^[32]