[soft.process] Погружение в Agile: записки на полях. В Agile под гибкостью понимается вовсе не свобода внутри проектной команды

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

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

Первая вещь, которую хочется зафиксировать, это осознание того, что в Agile сам термин "agile" относится не легкости изменения процессов, правил и практик, применяемых командой разработки. А легкости и скорости прогибания в отношениях с заказчиком.

А если сказать более грубо, но более точно, то "agile" -- это про гибкость в удовлетворении заказчика.

Образно выражаясь, до появления Agile исполнитель с заказчиком договаривались, после чего исполнитель исчезал с радаров и принимался делать то, о чем договорился. А заказчик остался в одиночестве ждать, пока ему принесут результат. Время от времени заказчика кормили завтраками и ему оставалось только надеяться, что все будет хорошо.

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

И вот в конце-концов заказчику доставляют результат и наступает одно большое удовлетворение. Или не большое. Или неудовлетворение. Но одно. И сразу.

Этого мало. А ждать этого приходится слишком долго.

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

Результаты показываются по чуть-чуть. Более того, по другому-то и нельзя. Ибо что будет в финале толком никто не знает, т.к. изначально договаривались только о том, что конкретика будет определяться по мере следования.

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

Именно это и подразумевается под "гибкостью" в Agile. Если вдруг заказчик решил, что удовлетворить его могут только перламутровые пуговицы, то мы гибко к этому приспособимся и удовлетворим заказчика по-новому.

Признаться, до сих пор я находился в заблуждении. Думал, что "гибкость" -- это именно гибкость в работе самой проектной команды. Захотели, стали проводить коллективные митинги каждый день. Захотели, свели общие митинги к одному в неделю. Захотели, сделали обязательными ежедневные коммуникации в режиме 1-к-1.

Ну а раз "гибкость" относится только к реакции на хотелки заказчика, то становится понятным, почему отход от канонического SCRUM-а объявляется ересью, предается анафеме и выжигается каленым железом.

---

Прошу простить мне мою отсталость в отношении Agile. В последний раз плотно с этой темой приходилось сталкиваться где-то в 2013-ом. Затем работать можно было так, как удобно, а не как модно-молодежно. Так что приход церкви святого Agile со SCRUM-ом в виде пророка остался за кадром :)

[prog.flame] В этих наших Интернетиках уже начали закапывать Rust?

Как я могу видеть, новость о том, что экспериментальный браузерный движок Servo, который долгое время был флагманской разработкой на Rust-е, передан под крыло Linux Foundation, вызвала разговоры о том, что к Rust-у постепенно приближается северный пушной зверек. Типа сперва Mozilla выгнала команду разработчиков Rust-а на мороз, теперь вот Servo отправили в могильник. И светлое будущее, о котором так много говорили растофанаты, неизбежно сменяется унылым настоящим с беспросветными перспективами...

Мое отношение к ситуации вокруг Rust-а после всего, что происходит с Mozilla, можно выразить известным афоризмом: Rust рискует простудится на наших похоронах.

Или, другими словами, Rust скорее всего переживет многих, кто ждет его смерти. Как это уже случилось с COBOL-ом и Fortran-ом.

Да, Rust лишается хорошей крыши. И вряд ли обретет другую такую же.

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

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

Так что если со временем популярность и распространенность Rust-а окажется на уровне нынешней популярности и распространенности Ruby, то Rust спокойно проживет еще не одно десятилетие.

---

Есть несколько моментов, которые лично меня заставляют думать о том, что будущее у Rust-а все-таки не такое радужное, как многим рисуется (хотя и быстрая смерть Rust-у не грозит).

Во-первых, это величина хайпа, который все еще сопровождает Rust. Я ничего подобного не могу припомнить со времен пришествия Java. Но там-то были миллионы долларов, целенаправлено вложенных Sun-ом в маркетинг. В случае же с Rust-ом хайп генерируют восторженные пользователи. И это странно. Ну не может быть у Rust-а такой армии активно использующих его программистов. Большая часть раздувателей хайпа -- это просто сочувствующие, не написавшие на Rust-е ничего сложнее очередного HelloWorld-а.

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

Во-вторых, это ниша применения Rust-а.

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

Поэтому полагаю, что для многих Rust является отдушиной после мира Java, C#, Python-а, JavaScript-а и Ruby. Которые либо не слишком быстрые, либо слишком тяжелые (в плане run-time). И Rust у этих людей вызывает восторг потому, что пока что не видно хорошего, простого и удобного языка с GC, который бы компилировался в нативный код и не требовал бы таскать за собой многомегабайтные JVM/.NET.

Таким языком мог бы в свое время стать D. Но не стал.

Зато таким становится Go. Хотя Go все-таки пока слишком убог и не нравится тем, кто привык к традиционному ООП, полноценным генерикам (шаблонам) и синтаксическому сахару.

В общем, думаю, что если бы на данный момент были полноценные и кросс-платформенные условные JavaNative, C# Native или KotlinNative, то и интерес к Rust-у со стороны нынешних JavaScript-еров и Python-истов был бы гораздо меньше.

А вообще, вот этот пост почти что двухлетней давности еще не утратил своей актуальности ;)

[life] Пора возвращаться в поле зрения радаров?

Промежуточная отметка в истории, начатой три месяца назад (предшествующие серии: раз, два).

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

Еще не ожидал, что все происходящее у нас сейчас настолько сильно будет напоминать брожение умов интеллектуалов и интеллигенции времен перестройки в СССР. Когда все ощущали себя пупом Земли и центром Мира, выкрикивали лозунги "Партия, дай порулить!", точно знали как жить, а потом едва-едва выживали в 90-е.

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

Это был какой-то трындец. Хорошо никаких заказов в это время не было, никого не подвел, репутацию не просрали. Хоть это радует.

С октября уже полегче. Пошли релизы наших собственных разработок. Очень надеюсь, что динамика сохранится :)

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

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

Так что постепенно пытаюсь вернуться в FB и VK.

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

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

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

Но делайте это, пожалуйста, без меня.

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

Сам постараюсь про политику ничего не писать. Работа, хобби, увлечения. Да просто о жизни... Есть же целая куча тем для нормального общения.

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

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

---

PS. Будут ли выходить кинообзоры не знаю. Я тут в последнее время заметок о просмотренных фильмах особо не делал. Да и смотреть как-то было нечего.

[prog.c++] Обработка событий агента с учетом приоритетов в SObjectizer: нужно, не нужно, если нужно, то как именно?

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

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

Сейчас появилась возможность вплотную заняться данным issue. Хотя с этой темой не так все просто.

Суть проблемы в том, что в SObjectizer-5 все события у агентов равноприоритетны. Т.е. если агенту отсылаются сообщения вот в таком порядке: msg_A, msg_B и msg_C, то обрабатываться эти сообщения будут в таком же порядке.

Если нужно обрабатывать поток входящих сообщений с учетом приоритетов, то в SObjectizer-5 есть приоритеты у агентов. Нужно создать несколько агентов-обработчиков с разными приоритетами, затем их нужно привязать к одному из тех штатных диспетчеров, которые реализуют обработку событий с учетом приоритетов обработчиков.

Но вот на практике одного из пользователей SObjectizer-а такая схема не устроила. Поэтому им был выбран другой подход: допиленная под себя версия SObjectizer-а, в которой при подписке агента может задаваться приоритет для события. Плюс к этому собственный диспетчер, который при получении новой заявки определяет ее приоритет и сохраняет заявку в std::priority_queue с учетом ее приоритета.

Получается, что у кого-то из пользователей SObjectizer есть потребность в приоритизированной обработке сообщений для одного агента. Которую либо нужно удовлетворить в самом SObjectizer (или в so5extra), либо нужно показать, как этого же эффекта достичь без допиливания SObjectizer-а под себя.

Пока есть более-менее свободное время хочется либо закрыть issue 17 добавлением в SO-5/so5extra новой функциональности, либо написанием примера (примеров) с демонстрацией получения искомого результата имеющимися средствами.

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

Так что если кого-то интересует SObjectizer и его возможности, то приглашаю присоединится к разговору. Либо прямо в обсуждении issue 17 на GitHub, либо же здесь в комментариях. А я под катом попытаюсь рассказать, что думаю по этому поводу.