Большое спасибо Артему из @SysadminNotes за рекомендацию.

Мальчики и девочки, я ухожу в оффлайн на 2 недели.
Если у вас есть какие-то идеи и пожелания - пишите в личку @ThomasStorm или на ящик thomas.storm@pm.me

Всем любви и увидимся в июле.

Отпуск это конечно офигенно, но вас, ребята, стало довольно много (внезапно) и игнорировать вас тяжело, да и не хочется.

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

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

Оставайтесь на связи.

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

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

Дальше была стажировка и Леха Зорин. Леха открыл для меня увлекательный мир трудоголизма американского типа (это как обычный трудоголизм, но ты еще веришь, что тебе за это зачтется). Потом Леха ушел из Рено, а я получил диплом и оформился в штат.

Дальше были первые ИТ курсы, увольнение из Рено, устройство в Аспект, Украина, Крым, девальвация, кризис, закрытие офиса в Москве, переезд в Нидерланды и очередная смена работы - все эти истории вы и так знаете.

А после был Ловел фон Урле - хорвато-голландец, открывший мне увлекательный мир follow the money. Если я только-только начинал понимать, что миром управляют старые и жадные кретины, то Ловел в этом был уверен (и потому активно лез в биточек). Это был второй звоночек.

И если Леха открыл мою внутреннюю «темную» энергию, благодаря которой я быстро учидся и эффективно работал, то Ловел направил ее в нужное русло. Эти двое бы подружились.

Третьим и последним звоночком стала смерть Лехи.

Что же получилось в итоге? Тебе говорят, что конторы хотят денег, один твой друг говорит тебе, что надо пахать, а другой - что надо пахать ради денег. В финале тот первый друг погибает при непонятных обстоятельствах, оставляя тебя с острым чувством несправедливости.

Потом ты читаешь книгу Маркова «Хулиномика» и Мэнсона «A subtle art of not giving a fuck», чтобы понять почему вообще все так по-дебильному, а потом наступает волшебная осознанность.

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

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

Я ловил себя на мысли, что я не хочу быть счастливым. Я хочу быть как мистер Вульф, хочу решать проблемы и «pretty please with a sugar on top».

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

Пока Остапа не понесло, давайте вернемся к основной теме канала.

Мне недавно написал один из подписчиков, и среди прочего была просьба написать свое мнение про DevOps. Некий известный инженер-сетевик утверждает (пруфов на руках нет), что код стад хуже, любой фиговый коммит идет сразу в прод и так далее.

Я с эти инженером и согласен, и несогласен. На следующей неделе напишу краткую историю DevOps, что из этого получилось, и что, на мой взгляд, будет дальше.

В “далеком” августе 2008-ого 2 парней на конференции в Торонто впервые в истории произнесли слово DevOps. Сейчас этой практике почти 10 лет, и я думаю, самое время поговорить о том, во что превратилась эта культура, и что нас ждет дальше. Но сейчас чуть-чуть назад во времени.

Давным давно, когда главными инструментами сисадминов были bash и python, а общение между разработчиками и инженерами велось через системы управления проектами и тикеты, обновление приложений было неприятным и долгим процессом. Разработчики писали новый код, тестировщики прогоняли по нему тесты, а инженеры в ограниченный промежуток времени, именуемый maintenance window, выкатывали новую версию. Код не всегда работал как задумано, инженеры ругали разработчиков, разработчики ругали инженеров, проблема не на нашей стороне, вот это вот все. В последствии люди стали кое-как автоматизировать свою работу, кто-то делал это на коленке, изобретая велосипед, кто-то написал и стал продавать Hudson (папа Jenkins’а).

По сути, что тогда, что сейчас, проблема одна - разработчики просто хотят писать код, а инженеры просто хотят, чтобы оно работало. В итоге люди поняли, что так “оно” работать не может, и придется “дружить”. Так и появился DevOps - культура, в которой инженеры и разработчики работают вместе.

Как бывает с каждый новшеством, DevOps столкнулся с большой проблемой - его никто не понимал.

Во-первых, ИТшники обнаружили, что они “уже” делают DevOps - у них есть автотесты, CI (между прочим, этот термин впервые появился в 1991-году), автоматизированное развертывание и даже управление конфигурациями (самый старая тулза, насколько я знаю - CFEngine, релиз которого состоялся аж в 1993-ем, и им до сих пор пользуется IBM).

Во-вторых, управленцы решили, что DevOps это отдельная роль (и это, пожалуй, самое главное заблуждение), и стали искать под это дело DevOps инженеров, с 5+ лет опыта. Это было на минуточку в 2009-ом, когда культуре еще не исполнилось и года.

Однако были и те, кто понимал суть DevOps (это в основном были те, кто его и придумал) и пытались его адаптировать.
С тех пор особо ничего не изменилось, люди до сих пор ищут silver bullet, “правильный” DevOps, а на сайтах поиска работы до сих пор присутствуют вакансии DevOps инженер. Но это, как я думаю, нормально и врядли изменится.

Первое и самое главное, что люди усвоили, адаптируя DevOps, это совместное использование практик разработки и системного администрирования в работе друг друга. Это, на мой взгляд, главное достижение.

Разработчики впервые начали смотреть на приложение с точки зрения админа - оно может ломаться, оно будет ломаться, и надо написать его так, чтобы оно “чинилось” как можно скорее (SRE) . Инженеры же пытались придумать, как можно описать настройку сервера в одном файлe (и желательно не в Bash скрипте), чтобы не ходить руками на каждый сервер (Infra-as-Code), да чтоб его еще и протестировать можно было.

Все это требовалось, чтобы превратить 3 отдела (Dev, QA, Ops) в одну структуру, работающую как часы. Вдохновленные историей про 10 релизов в день, люди стали придумывать разные методы достижения этой цели. Выделились 2 аспекта: технологический и организационный.

Что касалось техники, то тут все было более менее просто. И у инженеров, и у разработчиков уже были необходимые инструменты для работы, оставалось только их “подружить”. Так, например, инженеры стали хранить свои скрипты в системе контроля версий, а разработчики отправлять логи не локально, а на централизованное хранилище (как logstash). Стали совершенствовать мониторинг приложений с помощью отправки метрик, выделять конфиги приложения и держать их в отдельном месте, добавлять в приложения API для проверки работоспособности.
Микросервисная архитектура позволила упростить релизы и ликвидировать центральную точку отказа. CI/CD автоматизировал полную цепочку от коммита до развертывания в staging (а иногда и в prod). Amazon и прочие облачные провайдеры становился все популярнее, вышел Docker, а вслед за ним Kubernetes и Mesos, популярные сервисы для разработки Jira, Slack, Github и т.д. стали теснее интегрироваться друг с другом - медленно, но верно, наступала технологическая ИТ утопия.

С организационной точки зрения дела шли чуть похуже. Не смотря на то, что DevOps подразумевал совместную работу 3 разных ролей, большинство контор формировало отдельные группы DevOps - специалистов, отвечающих за весь спектр DevOps инструментов.
Такой подход не только не помогал, но и мешал: главной целью DevOps было уничтожить так называемые “silo” - роли с ограниченным доступом и зоной ответственности. Хуже всего было то, что разработка и эксплуатация не всегда могли “синхронизироваться” из-за разных методов управления проектами. Если разработка была проактивной и пыталась “доставить” определенный функционал за “спринт”, то Ops оставался реакционным и реагировал на входящие тикеты от разработки, по сути превратившись в helpdesk для разработчиков.

Софт доставлялся все быстрее. Аппетиты бизнеса росли, и если “хорошие” топ-менеджеры (насколько топ-менеджеры могут быть хорошими) стали использовать возросшую производительность для занятия своей ниши на рынке раньше конкурентов, а освободившиеся ресурсы разработчиков выделить на R&D или другие проекты, интересные самим разработчикам, то “плохие” (читай почти все) стали радостно резать расходы, оставляя минимальное количество людей для работы над проектом, используя освободившийся бюджет под маркетинг и продажи.

DevOps несомненно помог многим проектам, но его развитие совпало с общемировым повышением спроса на ИТшников. Люди не из сферы ИТ решили попробовать что-то новенькое (а тут на радость пришел JS с миллионом фреймворков), и на рынок пришло очень и очень много разработчиков с 3 месяцами работы. Чуть позже, с развитием DevOps направления, на рынок пришло такое же количество DevOps инженеров, которые знают, как написать Ansible playbook, но не знают, что такое load average.

Как я уже сказал, это ожидаемо, естественно и даже хорошо. Но проблемы, которые были у DevOps (точнее у людей, которые его пытались применять) никуда не ушли. Люди считают, что у них DevOps, потому что они проводят много встреч, а новому человеку выдают ноутбук с предустановленными IDE и Slack. Другие считают, что у них DevOps, поскольку они используют Kubernetes. У третьих, потому что разработчики имеют root доступ на серверы.

Лучше всего все беды DevOps, сам того не замечая, описал Дмитрий Столяров из Flant (https://youtu.be/CgCLPYJRxbU). “Если вкратце, мы занимаемся DevOps’ом. Давайте по-простому, внедряем Kubernetes.”
И никто не спрашивает, а нужен ли клиенту Кубер в принципе, если у них админ никак не сделает удобную морду для развертывания разработчикам, а разрабы никак не начнут отправлять метрики приложения в мониторинг.

В чем-то сетевик-пессимист прав. Качество кода упало. Некачественный код все чаще попадает в production. Но виновата ли в этом культура?
Обвинять DevOps в том, что код резко стал плохим, это как винить поп-музыку за то, что у нас есть Ольга Бузова и “Розовое вино”.

У нас (у ИТшников в целом) есть очень много проблем, которые нам надо решить, чтобы делать свою работу хорошо. Никакие системы, тулзы, провайдеры и DevOps с Agile не помогут, пока мы сами не поймем природу проблемы и найдем в себе силы с ней бороться.

В будущем все у нас будет хорошо. Но об этом я напишу чуть позже.

Между делом, хочу наконец научиться пользоваться голосованием в Телеграм. Давайте вместе протестируем. Про что больше писать?
🤖 - больше про технику
🤡 - больше про процессы и практики
👽 - больше про прочее

Это тестовая голосовалка, ну и поможет узнать свою аудиторию получше. Буду ли я ей следовать и как, пока не могу сказать.

Удалось потрогать портал обучения от LinkedIn. Ценник у него такой же, как у Pluralsight, и меньше, чем у LinuxAcademy.
Из плюсов - огромный выбор курсов, в том числе и не связанных с ИТ. Дизайн, маркетинг, вот это вот все.

Из минусов - в основе обучения лежат видеолекции с небольшими лабами, которые качаются и делаются локально. Закрепленность знаний проверяется небольшими тестами, не дающими понимания, что полученная информация закреплена на практике. Но этим же страдает и Pluralsight.

Правда, открыл курс основ по веб-разработке и дизайну (совсем нулевый), и в первой же секции идет дубовое пояснение основ HTML, CSS и, простите, JavaScript.
Особенно раздражает, когда лектор с сияющими глазами говорит: “Да, это выглядит довольно сложно, но, поверьте, это очень легко!”
Вот… честно, не люблю таких преподавателей. Их мотивация понятна - им нужно стимулировать все больше новичков входить в сферу ИТ, но так не делается.

В последнем голосовании, люди 10 раз нажали на инопланетянина. Я позволю себе предположить, чтобы вы либо имеете косвенное отношение к ИТ, либо вам интереснее, когда я пишу про свои приключения с газовыми компаниями.

Но на всякий случай, если вы однажды захотите начать (или продолжить) карьеру в ИТ: неважно, какое направление вы выберете, будь то дизайн, разработка или системная инженерия - ИТ это НЕ легко.
Как и любая другая интеллектуальная деятельность, ИТ требует навыков и знаний, которые необходимо приобрести, прежде чем начать бороздить просторы рекрутинговых сайтов. Это не значит, что нужно бросать все и поступать в МГТИ имени Баумана, но придется инвестировать в себя деньги и время.

Любой, кто скажет вам “ИТ это легко” - лжец и подлец. “Гоните его, насмехайтесь над ним.”

Продолжаю играть с голосовалками. Опрос для ИТ спецов и всех, кто с ними связан.
Какого рода вы ИТ спец (разработка или администрирование)
- 😃 - если вы по Microsoft (Windows Server, Powershell, OctopusDeploy, etc).
- 😍 - если по Linux (RedHat, Ubuntu, bash, etc).
- 😳 - если оба.

Яндекс индексирует документы в Google Drive. Если у вас там что-то важное - убедитесь, что это хорошо спрятано за настройками приватности. Яндекс вроде это дело исправил, но береженого Бог бережет.

Ну и помним, что хранить пароли и явки где-то в облаке у Гугла - absolutely haram.

Теперь, когда мы поговорили о том, к чему пришел DevOps в наши дни, самое время написать о том, что полезного (помимо уже сказанного) он нам принес.

Компании стали применять DevOps по-разному. Те, кто уже использовал популярные framework’и Agile, например Scrum, поставили инженеров в “продуктовые” команды. То есть у вас есть команда - разработчики, тестировщики, инженеры. Поскольку Scrum подразумевает кросс-функциональные команды, на выходе мы имеем разрабов, которые немножко сисадмины, и сисадминов, которые немножко разрабы.

В целом неплохо, и такая модель хорошо работает, правда у нее есть и свои недостатки. Например, когда у вас продуктовая команда как вещь-в-себе, она пилит проект так, как ей удобно. Платформа, ОС, язык программирования, DevOps tools - все выбирается самой командой и строго под ее нужды. Если у вас много продуктовых команд, то вы получаете потрясающий бардак и зоопарк, где команда А уже сидит в Кубере с этими вашим докером, а команда Б все еще делает golden AMI в AWS во время релиза новой версии приложения. Сравнить KPI (а топы очень любят KPI) таких команд тяжело, поэтому проверить эффективность той или иной команды становится тем еще приключением.

Другие конторы, чаще всего крупный сектор с headcount в 5000+ человек и миллиардным оборотом, стали делать отделы - отдел FrontEnd разработки (их может быть много), Baсkend разработки (тоже может быть много), отдел инфраструктуры и, простите, отдел DevOps.
Вроде silo - все сидят в своих уголках и что-то там делают. Взаимодействие уже не такое шустрое, люди могут сидеть в разных офисах, если не городах или странах - сложно просто подойти и поговорить ртом. Но и такой подход имеет право на жизнь, и вот почему.

Когда вы инженер в DevOps отделе, вы “поддерживаете” разработчиков. В ваших интересах, чтобы разрабы спокойно и без лишних проблем выкатывали новый код в production, а вы, если что, быстро его откатите обратно. Если вы инженер инфраструктурного отдела (допустим у вас в 2018-ом до сих пор свой ЦОД), то вам нужно, чтобы серверы и сеть работали без перебоев.
Такие потребности позволяют создать сервисно-ориентированные команды. Infra-команда не предоставляет железо - она предоставляет сервис, где каждый может “заказать” себе виртуалку. DevOps команда не предоставляет тулзы - она предоставляет сервис для управления приложениями.

Поскольку такие команды обладают бОльшей экспертизой в инструментарии, нежели сами разработчики, то они дают им один инструмент под определенную задачу, например, Puppet/Ansible/Chef для управления серверами, Terraform/Cloudformation для создания новых ресурсов, Jenkins/Teamcity для CI/CD, Github/Gitlab/GitUNameIt для хранения исходников, ну и всякие Linter’ы и прочие финтифлюшки. У разрабов особо нет выбора, и они пишут приложения, придерживаясь каких-то общих, зачастую навязанных административным ресурсом, стандартов.

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

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

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

Неоднозначную реакцию общественности вызвала парадигма разработки serverless - якобы приложения без серверов. Если не язвить, что говорят так люди, не знающие, как устроены компьютерные программы, то можно увидеть идею за следующим.
Serverless дает возможность разрабатывать и запускать приложения без предварительной настройки платформы (будь то ОС, веб сервер или сервер приложений). Написал код - прогнал тесты - запаковал - отправил на AWS Lambda. Хочешь на Python, хочешь на Java/JavaScript, хочешь на C#. Та же Lambda вкупе с другими managed сервисами AWS позволяет нам писать полноценные приложения с минимумом компьютеров в обслуживании.

Вот, например, мой любимый интернет магазин плюшевых хомячков. Написали статичный сайт, положили его в S3. Нажали на нем кнопочку “Добавить в корзину”, делается API вызов на Lambda через API Gateway. Lambda отработала, и вы видите цифру “1” напротив вашей корзины. Нажали “Заказать” - отработало. “Оплатить” - отработало. Несколько маленьких программ, выполняющих свою работу, небольшой сайт c JavaScript, S3, чтобы держать там ваш сайтик, и какое-нибудь хранилище - для пользовательских данных, товаров и прочего. Ни одного сервера под непосредственным управлением. Красота.

Далеко не все приложения сегодня могут действовать по-похожему принципу. Автоматизированные банковские системы, ERP/CRM системы и прочие до такого не скоро дойдут. Большие компании тоже - уж слишком много денег и времени вбухано на текущие разработки.

Тем не менее, начало положено. Кто-то сразу смекнул, что из этого можно сделать, кто-то не понял, но на всякий случай “заорал” и написал про NoOps, кто-то поморщился и пошел дальше админить свой сервер Ubuntu. Ну или кластер Kubernetes (кому как нравится).

С другой стороны управление инфраструктурой все больше отодвигается, давая дорогу к управлению приложениями. Немало сил приложил к этому сам Kubernetes, который может расширяться сам, без сторонней помощи инженерных групп. К нему уже придумали Helm - пакетный менеджер для приложений Kubernetes (аналог Universe для DC/OS). Если так дальше пойдет, то кроме Кубера ничего и знать не нужно будет.

Не отстает от прогресса и сам Amazon. Сервис Fargate, который позволяет развертывать Docker приложения на ECS/EKS кластеры без надобности управлять теми самими кластерами, лишает нас необходимости думать о “железной” части. К приложению легко цепляется ELB/ALB/NLB, что дает нам какой-никакой Service Discovery. Просто прелесть.

Что нас ждет дальше? Docker будет потихоньку превращаться из контейнера в своеобразную очень легкую виртуальную машину со своим state, что навсегда уничтожит границы между контейнерной и гипервизорной виртуализацией. Serverless будет находить своих поклонников среди маленьких стартапов, где не хотят тратиться на инженеров-инфраструктурщиков. Архитекторы решений потихоньку переобуются в архитекторов систем, и будут проектировать приложения вместо инфраструктур. Сисадмины будут мониторить и логгировать приложения, а не серверы. Железячники и сетевики, конечно, никуда не денутся (кто-то же сидит в ЦОДах Амазона, Гугла и Микрософта), но количество предложений на рынке труда уменьшится.

А мы с вами будем сидеть на Безусловном Базовом Доходе, потому что наша работа будет не нужна. Имея необходимые средства к существованию, мы посвятим себя науке, искусству и творчеству, пока искусственный интеллект и роботы за нас пишут код, собирают и обслуживают оборудование. Бизнес будет заказывать приложения “голосом” через voice recognition, а бездушная железяка будет их создавать.

Тем и спасемся.

Посвящается Валере и @DevOpsOnCall. Контора решила не отставать от прогрессивных компаний и внедряет дежурства.

Говоря о будущем, нельзя не упомянуть всеми любимую (и нелюбимую) криптуху.

Как некоторые из вас знают, помимо основной работы у меня есть сторонний проект, связанный с автоматизированной торговлей на криптовалютных биржах. Я стараюсь о нем писать редко, так как он не имеет прямого отношения к моему каналу, а в проекте я использую навыки, полученные на основной работе (и крайне редко - наоборот).

Поскольку проект запустился в открытом бета режиме с мая 2018-ого, мы получили рост пользователей выше прогнозируемого и были вынуждены переехать на AWS раньше срока (старый ДЦ не давал возможностей для расширения). Пока мы не начали «агрессивный» «маркетинг» пользователи приходили через сарафанное радио, а значит были достаточно опытными (большая часть была в крипте еще до 2013-ого). Было у нас порядка 200 человек, 100 с лишним из которых были в группе «пожизненно бесплатно» - эти товарищи первыми рискнули вложить свои средства в торговлю на GSMG, тем самым показав нам свое доверие и завоевав наше. Этим ребята стали «адвокатами»: они продвигают робота среди своих тусовочек и помогают новичкам в общих чатах.

Но надо как-то зарабатывать деньги, и мои партнеры по бизнесу начали сотрудничать со всякими голландскими криптосообществами, чтобы привлечь побольше людей. Что же из этого получилось? Как и раньше, в этих ваших интернетах все еще огромное количество «dumb money» (глупых денег). Люди, вложившие в крипту на волне общего «хайпа», ожидают бешеного роста и прибылей в 100-150% в первые несколько дней. Среди таких самый стандартный вопрос - почему робот работает полчаса и до сих пор не заработал на Ламбо.
Хуже того, люди абсолютно не умеют (или не хотят) читать и отправляют деньги на наш кошелек, не зная о его предназначении (средства на нем «оплачивают» работу платформы, а не участвуют в торгах). Люди отправляют от 5 до 10 эфиров (от 2000 до 4000 $), а потом слезно просят их обратно. «Я отправил, а потом прочитал руководство, верните, пожалуйста!»
Все это раздражает, ведь от людей, которые реально часть своих сбережений держат в крипте (нет лучше способа спрятать их от налоговой), ожидаешь какой-никакой финансовой и технической грамотности.

Не помогает “бизнесу” и испортившие репутацию торговых платформ финансовые пирамиды, например BitConnect, и платформы, не сумевшие вовремя подстроиться под изменившийся рынок и обвинившие в этом биржи (TraderDaddy, по сути наш основной конкурент). Из-за таких кадров на 10 человек приходится 2-3 гения, утверждающих, что мы лжецы и подлецы и хотим забрать все ваши деньги (Хотя наша платфома технически на это неспособна).

Ловел (тот самый друг хорват, посадивший меня на этот веселый криптокорабль), относится к ним с состраданием. Какой бы ни был человек, умный или глупый, клевый или занудный - он все еще наш клиент, и если он не заработает, то и мы не заработаем (наша бизнес-модель заключается в “сжигании” суммы, равной 25% от прибыли с торговой пары из “топлива” пользователя, пользователь “платит” за робота, отправляя средства на наш кошелек, тем самым пополняя “топливо”).

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

Очередной опросик. С платформами и пожеланиями людей опредилились, теперь интересно, как вы связаны с криптухой.
Без холиваров типа “биток против альтов” и прочего.
Вопрос простой - есть ли у вас крипта?
🤖 - есть.
😳 - нет.

Раз тут аж больше 20 человек, то милости прошу к нашему шалашу: https://gsmg.io

За помощью сюда: https://help.gsmg.io
Телеграм тусовочка тут: https://t.me/GSMG_Bot (говорим по-английски).

У Скрама (один из фреймворков Agile) есть одна такая процедура, называется “Daily Scrum” (или Daily StandUp).
Заключается в простой встрече членов команды, где каждый рассказывает о достижениях вчерашнего дня и делах на “сегодня”. Простенькая встреча, которая должна всех друг с другом синхронизировать, ну и можно поднять животрепещущие вопросы.

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

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

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

В интернете очень много споров на тему правильно и неправильно приготовленного Скрама, о важности роли Скрам-мастера и кому это роль нужно давать, но я не встречал обсуждений утренних стендапов. (Хотя тех, кто их не любит, я встречаю часто).

Больше всего мне понравился подход, который реализовали в одной смежной команде: у них стендапов нет, но каждое утро, во время когда должен быть стендап, все члены команды пишут небольшое письмо со своими “делами” своему тимлиду. Тимлид эти письма мельком читает и в случае конфликтных или потенциально конфликтных ситуаций назначает предметные встречи. Времени затрачивается минимум, переговорку искать не нужно, кто работает удаленно, не должен сломя голову бежать за микрофоном. Утопия.