I don't know what #less is trying to do, here, without looking at the source; but there's not a terminal in existence that I know of where using CUB to overprint "ESC" with "ESC" actually achieves something.

write(1,"\^[[m\n:\^[[K",8) = 8 (0x8)
write(1,"\r\^[[K \^[[KESC\^[[D\^[[D\^[[DESC",23) = 23 (0x17)
write(1,"\^[[K[\^[[D[",8) = 8 (0x8)
write(1,"\^[[KB\^[[DB\r\^[[K",12) = 12 (0xc)

#ECMA48

I have recently re-discovered #most, having used #less, BSD #more, or (in idle moments) a freeware clone of #pg over recent years.

One interesting thing is how its screen updates operate compared to less.

less does not set a scrolling region that excludes its status line, so has to keep re-drawing its status line.

most uses DECSTBM to set a scrolling region, and wouldn't have to keep changing its status line at all if it didn't keep changing it to "Reading..." at the drop of a hat. (-:

🚀 NBA28 – Im Gespräch: @FelixStein – Agile at Scale

In a nutshell:
1️⃣ Agile-Transformation braucht Top-Down-Mandate & Bottom-Up-Teams.
2️⃣ Bürokratie abbauen & Kommunikationsaufwand minimieren für autonome Einheiten.
3️⃣ Pragmatismus statt Dogma: SAFe, LeSS & Nexus je nach Kontext kombinieren.

❓ Wie skaliert ihr Agilität in großen Organisationen?

👉 Jetzt hören: https://no-bullshit-agile.de/nba28-im-gespraech-felix-agile-at-scale.html

#NoBullshitAgile #Agile #Agil #SAFe #LeSS #Podcast

Alt...

Agile-Transformation braucht Top-Down-Mandate & Bottom-Up-Teams

Почему ваши JIRA Velocity и Sprint Reports вероятно ошибочны

Вы когда-нибудь задумывались, какие именно задачи учитываются при расчёте velocity - и как на самом деле работают Velocity и Sprint Reports ? Если нет, скорее всего ваши репорты не отражают реальную картину. Вот 4 распространённых нюанса, которые могут серьёзно исказить ваши Velocity и Sprint Reports - и как моё приложение Multi-team Metrics & Retrospective может во многом автоматически устранить из них: Вы удаляете задачи из спринта только если они были действительно деприоритизированы? Если вы вручную убираете незавершённые задачи из спринта (например, чтобы перенести в бэклог или следующий спринт) до его завершения вместо того, чтобы проследовать по workflow, который запускается после нажатия на кнопку 'Complete sprint', то Jira не посчитает их как "незавершённые" в Sprint Report . В результате ваш velocity оказывается искусственно завышен. Удалять следует только те задачи, которые действительно деприоритизированны. Все остальные должны остаться и быть перенесены соответствующим образом. Все ли выполненные задачи действительно входят в спринт? Метрика Issues completed outside of this sprint в Sprint Report учитывает только те задачи, которые были завершены вне спринта И затем вручную добавлены в него. На практике многие команды закрывают задачи, но забывают их класть в спринт. Если вы проанализируете хотя бы квартал, то скорее всего найдёте несколько задач, которые были решены, но так и не вошли ни в один спринт. В результате Velocity и Sprint Reports не учитывают часть задач. А как насчёт дубликатов? Работа с дубликатами - это каверзная активность. Если не включить их в спринт - они теряются из поля зрения. Если включить - нужно строго следить, чтобы у них не было эстимейта, иначе они искажают метрики. В энтерпрайз компаниях иметь дюжину дубликатов не является чем-то особенным - это незамечаемый, но ощутимый источник искажений. Оцениваете ли вы повторно одну и ту же работу? Пример: вы эстимируете Story в спринте, а позже появляется баг, созданный вашей же или другой командой - и он тоже получает эстимейт. Но на деле этот баг часто является продолжением той же задачи. В итоге работа считается дважды, а метрики искажаются лишними оценками.

https://habr.com/ru/articles/908494/

#jira #scrum #scrum_master #kanban #agile #velocity #jira_plugin #safe #less #project_manager

Скрам-мастер vs мастер реальности

“Здравствуй, мама, я руководитель! Сейчас как все разрулю! как бы так всех организовать, чтобы больше ничего не делать.. Тем более когда есть такой выбор!” _________________________________________________________________________ А что же организовывала я? И кто я такая вообще? Меня зовут Яна. Мой стаж в ИТ 13+ лет, а начался еще в университете, ведь я инженер-программист, решивший, что сфера огонь, но вот код писать это не его. У меня почти 7 лет опыта работы с международными телеком операторами, среди которых Vodafone, Telefonica, Cox, GCI, GTD Chile, T-Mobile и еще ряд других. За этот период я не только прошла опыт от QA инженера до руководителя команды тестирования 70+ человек, но и погрузилась в задачи проектного управления крупными интеграционными проектами с миграцией данных, научилась строить экологические и конструктивные деловые отношения с заказчиками, и еще много чего о чем расскажу как нибудь в другой раз. Потом был и опыт работы в Яндексе с почти чистыми скрам процессами, и несколько лет работы в SberDevices, где я кончательно сменила сферу тестирования на управления проектными командами, а также прикоснулась к прекрасному миру разработки устройств со всеми его вытекающими в плане организации работ разрабатывающих их команд. А теперь я участвую в создании низкоорбитальной спутниковой системы. С таким багажом я вряд ли когда-нибудь впишусь в шаблонную позицию такую как scrum-master, да и роль среднестатистического проектного менеджера явно не про меня. И кто же тогда я? Кажется, я ближе всего к мастеру реальности 😄

https://habr.com/ru/articles/907698/

#scrum #project_management #agile #организация_процессов #kanban #анализ_процессов #less #lean #управление_проектами