Чтобы новые сервисы могли писать куда-то новые данные, нужно добавлять в таблицы колонки, создавать новые таблицы, удалять старые. Модифицировать хранимые процедуры, функции и триггеры, если применяются.
Подскажите, релизы БД каким-то образом удалось затянуть в описанную концепцию? Если нет, то было бы здорово узнать, как у вас решаются задачи, связанные с релизами БД.
Некоторые соображения про большой запрос (в основном из контекста MSSQL, но кое-что в доках Postgresql перепроверил и там вроде всё то же самое):
В блоке Levels UNION, который даёт доп. сортировку и DISTINCT, кажется, что можно смело заменить на UNION ALL, потому как по крайней мере колонка node_level точно ни на каком уровне иерархии не совпадет. Фрагмент concat(coalesce(concat(prev.parents, '-'), ''), cast(Mapping.parent_node_id as varchar)) Можно бы упростить: CONCAT игнорирует NULL и COALESCE выглядит просто лишним. Такой же coalesce есть в блоке FineTree. Конвертацию инта в строку вроде бы concat в postgres тоже делает автоматически, т.е. как будто достаточно concat(prev.parents, '-', Mapping.parent_node_id). Если хочется единообразия, то можно сделать по аналогии со строчкой нижеconcat_ws('-', prev.parents, Mapping.parent_node_id)
В блоке Branches два схожих фрагмента:
case
when root_node_id is null then
case
when node_id = last_value(node_id) over WindowByParents then '└── '
else '├── '
end
else ''
end as node_branch,
если перевернуть первое условие, то код станет более прямолинейным:
case
when root_node_id is not null then ''
when node_id = last_value(node_id) over WindowByParents then '└── '
else '├── '
end as node_branch,
В Tree UNION тоже больше похож на UNION ALL. Финальную сортировку корректнее в финальном же запросе и разместить, а то cte FineTree как сортированная вьюха получается. В Branches сортировка выглядит просто лишней.
Множественные джойны на RootNodes кажется, что не нужны - у всех корневых узлов nest_level = 0 и можно пользоваться этим знанием. Избавиться от этого джойна возможно в Branches и в Tree. Вместе с этим можно будет выкинуть два CTE: Mapping и RootNodes. Фильтр `parent_node_id is null / node_id in (3, 10, 17)` идеально подходит для первого запроса рекурсивного CTE Levels. И в кейсах (рассмотренных чуть выше) получится более естественное для восприятия условие when nest_level = 0 then ''
И очень желательно во всех запросах колонкам алиас источника расставить: СУБД разберётся, где чьё, а человеку читать тяжело. Большую часть, если не всё, из того, что происходит в Branches и Tree, как будто можно сделать ещё в Levels и повторно большую рекурсию не гонять.
ничто из перечисленного не "методология". По ссылке - стандартная копипастовая лажа, собранная для объёма текста и прочих SEOшных дел человеком, который вообще не понимает, что пишет.
скучные повторяющиеся встречи, без осязаемых решений...
Сосредоточение на постепенных шагах ...
Правильно ли понимаю, что предложенные 10 шагов с шаблонами - это сценарий одного ретро и такой сценарий, каждый шаг которого приводит к осязаемым решениям?
"Спринт как фильм", "спринт в мемасиках" - очень не хватает примеров осязаемых решений. И, правильно ли понимаю, что и одно и другое случается в одну сессию ретро и сначала каждый "показывает кино", а потом показывает мемасики?
Подскажите, как давно вы проводите ретро по предложенному сценарию, сколько вы таких ретро уже успели провести, какое число людей участвуют каждый раз, в какое время вы укладываетесь со всеми предложенными десятью шагами и в скольки командах такой формат прижился.
Start / Stop / Continue
Могу что-то путать, но это вроде бы про процессы, инструменты, ритуалы. Дискуссия вроде "давайте бросим ту задачу и начнем вот эту" выглядела бы странной. Это не вопрос отношения коллектива, а вопрос распределения ресурсов и приоритезации задач - это дело лидов, менеджеров и владельца продукта.
ретроспектива – это стадия «плана» цикла PDCA
Может всё-таки Check? А то, что у вас названо "Поручения" - Act.
Последний скрин многообразием представленной информации намекает, что функционала много и он, скорее всего, хороший и полезный... но интерфейс - адовейшая каша. Так выглядит карточка любой задачи?..
Просто вывалено всё, что есть. Главный акцент отсутствует, всё подряд тянет на себя внимание. Здесь всё скомкано, несвязанное контекстом, семантикой свалено в кучу. А тут нам завезли пустого места. Очень много текстовой и графической информации, которая в моменте не имеет и не может иметь никакого значения.
Вы сами всех запутали и себя в первую очередь. Миграциями называется только то, что вы называете изобретенным термином "добивочные миграции".
Вариантов организации исходников БД и построения Continuous Delivery два:
вы храните только миграции (alter table add, alter trigger) и конечное состояние понять можно только прогнав все миграции что есть; это удобно при работе через ORM, когда нет хранимок и триггеров, а таблицы определены классами в ООП
вы храните определения объектов, а скрипт миграции для деплоя генерируется утилитой вроде liquibase налету и нигде не хранится; этот вариант удобен, когда у вас полноценная разработка на стороне БД: в GIT лежат финальные версии определений таблиц и хранимок, при возникновении конфликта по изменениям, он, во-первых, очевиден, во-вторых решается штатным образом как с нормальными исходниками
Если утилита не умеет в alter table, то вариантов нет и нужно для таблиц (дополнительно к определению) создавать и хранить файлы миграций. Для функций у вас хранятся не миграции, а определения (definition), миграция возникает налету, когда liquibase понимает, что файл с CREATE FUNCTION изменился и генерирует ALTER FUNCTION.
Это просто яркое название или где-то действительно прописан некий путь, который должна пройти задача? Контроль прохождения и заполнение поля делегированы автоматике или, так сказать, под честное слово того, кто это поле заполнит руками?
QAD
Выглядит шикарно! Подскажите, это точно функционал "просто дашборда" или скорее плагин, ваша внутренняя разработка? Возможно зависит от версии JIRA, но мне кажется даже вкладку на дашборде сделать штатными средствами невозможно.
Но коллектив действительно своеобразный: все опытные, проактивные, часть с прошлым опытом работы руководителем или тимлидом - пинать некого, разжевывать некому. Иногда нужно посоветоваться или получить помощь от того, кто больше знаком с технологией или инструментом - двое договариваются и созваниваются. Многие задачи изолированы, каждый тащит на себе от начала до конца. С управлением задачками, пониманием текущего статуса у нас заметно получше, чем у "соседей". Теребить никого не нужно, можно открыть подходящий борд и посмотреть. Суть работы команды - вариация на тему enabling team.
Вокруг - вся характерная специфика "оранжевых" организаций. Среднее звено, руководители управлений из созвонов не вылезают. "Соседи" созваниваются каждый день, мы раньше тоже так делали, пока не перехотели.
Некоторые представители "дальних соседей" считают нормальным взять и нажать кнопку созвона просто потому, что она есть. Или в рандомный момент закинуть бесцельный созвон в календарь на толпу людей.
Противодействуем всем знакомыми методами:
укажите пожалуйста программу встречи и ожидаемый результат
обозначьте пожалуйста цель моего присутствия, зачем нужен именно я
предоставьте материал по проблеме, чтобы я смог подготовиться
если у вас есть вопрос, пожалуйста, сформулируйте его в виде букв с вопросительным знаком в конце и отправьте ответом на это письмо
Надо ли говорить, что возвращается со сформулированными мыслями, тезисами, целями и вопросами приблизительно никто.
В календаре зачем-то на вообще всех перманентно закинуты демо неких фич от команд, про которые я знать не знаю. Пятничное "мы гордимся этими кейсами" на полтора часа, где 200+ человек смотрят на презенташку от сейлзов и подобное. Если не сопротивляться, то абсолютно легально, даже не будучи руководителем, половину недели спускать в созвонную трубу вполне возможно. Ван-ту-ваны мне за каким-то лешим опять пытаются навязать. На два года сделал вид, что забыл закинуть их в календарь, но теперь меня вычислили. Видимо, придется раз в неделю протирать этот соломенный аэроплан.
Экспериментирование с днём тишины на сегодняшний момент привело наш небольшой коллектив сюда:
Пн - daily утром (до 15 минут)
Ср - daily утром (до 15 минут)
Пт - refinement вечером (15-30 минут)
Применимо не ко всем коллективам, но если проблема осознана, то отрезать можно пробовать и кусками побольше. Как говорят опытные эджайлисты-евангелисты, дэйлик - это про цель и формат, не про расписание. Если каждый день обсуждать нечего, то может и незачем. Но, как вы справедливо заметили, сначала необходимо качнуть культуру управления задачками, проведения самих совещаний, коммуникации как таковой.
Чтобы избавиться от тупняков в конце каждого созвона "может кому есть что сказать дополнительно?" и, как следствие, расползания разговора "по древу", договорились, что ведущий в спец-чате про напоминания и созвоны чуть загодя заводит тред про конкретный созвон (например, Daily 2024-03-19). Если у кого есть что-то сверх регламента, то он закидывает тему в этот тред. Ведущий решает, для дейлика эта тема или нет. Для обсуждений, требующих от участников погружения в материал, сначала обозначается цель и предоставляется материал. Созвон планируется с учетом времени, нужного на подготовку.
Покер-сессии делаем асинхронно. Где померяли более-менее ровно, ведущий сам фиксирует оценку. Обсуждение расхождений приклеиваем к хвосту ближайшего дейлика.
По критичным сбоям мы организуем Post mortem — подробный разбор хронологии инцидента с привлечением сотрудников, устраняющих сбой, руководителей ИТ и ситуационным центром.
Это же административное, не культурное. Авария - ну-ка быстро все на созвон! Механизм распространённый, но это про иерархию, обязаловку, подчиненность, доставку информации наверх. С применением такой практики лучше, безусловно, становится, если раньше ничего подобного не было. Как конкретно проводится процедура, с чем на неё приходят и с чем уходят - да, тут могут быть элементы культуры. Если все договорились руками на проде не шурудить, не деплоить в обход пайплайна и соблюдают эти договорённости - это элемент культуры. Если раньше была обратная картина, то чтобы прийти к подобному состоянию нужен серьезный культурный сдвиг. Чтобы созваниваться после аварии - не нужен. Если раньше все просто суетились и где-то что-то как-то фиксили, а после решения проблемы не могли вспомнить, где чего поменяли, какими действиями фактически устранили последствия инцидента, и в чем он заключался - это отсутствие культуры. Если все дружно стали вести в правильных местах хронологию своих манипуляций, большую часть манипуляций до возникновения инцидента и проделываемых после возникновения перевесили на автоматику, которая ведёт подробный лог, и потом это можно как-то склеить и получить ту саму хронологию - это высокий и технический, и культурный уровень. А созвониться можно и без всего этого.
Мы регулярно мониторим статусы всех задач, поставленных на ретроспективе или при проведении Post mortem, а также организовываем Problem‑борды — встречи по задачам и проблемам, которые выполняются длительное время.
Есть дейлик, на котором нужно озвучивать проблемы и трудности в решении задач. Есть ретро, где нужно разбирать в том числе проблемы и трудности. И потом еще отдельный регламентно-ритуальный созвон, теперь уж точно по проблемам и трудностям? "Пахнет" не очень хорошо. И точно не про культуру, а опять про администрирование.
Мы регулярно мониторим статусы всех задач ... при проведении Post mortem
Подозрительное совмещение в одном предложении. Тоже "пахнет" не очень.
Цель F#ckUp Review не только обсуждение произошедшего, но и извлечение системных выводов, которые могут быть полезны и для других команд.
Больше созвонов богу созвонов. Кросс-командное ретро/пост-мортем? Вероятно, здравое зерно есть. Может даже и не связанное напрямую с самой разбираемой проблемой. Не менее вероятным кажется и то, что некоторые заросли малины хоть и выглядят со стороны свежо и соблазнительно, выжить смогут только в присутствии уверенной руки с секатором.
Не складывается у меня картинка того, о чем вы рассказываете. Если есть возможность, дайте пожалуйста пояснения.
О какого рода проектах, продуктах идет речь, что вы называете "хотелками"? Если вы продаёте продукт или доступ к нему, то кто такие стейкхолдеры и заказчики? Если это пользователи и клиенты, то вроде бы неоткуда взяться частым встречам с ними. Если это заказчик, который платит деньги за реализацию нужных ему задач, то непонятно про статус "хотелок" и отказ в выполнении. Если, обратно, не заказчик, а рандомные люди заводят хотелки, то что делают в этих хотелках сроки, как их угораздило сюда затесаться?
Фиксация всех “хотелок” заказчика, что не даёт финальной реализации отклониться от первоначальной задумки и критично выходить за бюджет. Это исключает ситуации, когда заказывали велосипед, а получили мопед по цене автомобиля.
Если хотелку завёл хотельщик, то не очень понятно про бюджет и тем более про задумку. На гитхабе я закинул фича-реквест. Мне либо ответили "спасибо, но нет", либо решили что-то да сделать. Что именно - полностью остаётся на той стороне. Я попросил что-то небольшое, но они осознали бОльшую картину и там, где мне виделся одноколесный велосипед, они соорудили космолёт, держа в голове свои какие-то цели. Про учёт именно "хотелок" - как будто много лишнего в описании и некоторые подробности, что называется, не отсюда. Если это работы, выполняемые по контракту, то опять не понятно, что здесь делают фрагменты сценариев про фича-реквесты от рандомных персонажей. А хотелось бы понять
Дальше набор задач с первичной оценкой попадает на CAB (Change Advisory Board) — совет по изменениям. В состав обязательно должны входить представители всех заинтересованных сторон помимо представителей разработчика.
Слегка попахивает инструкцией, как потратить кучу времени толпы людей на бессмысленные созвоны. Но возможно я чего-то не знаю или вы так называете процедуры, которые мне привычнее называть иначе. Интересует судьба Product Owner'а в такой картине мира. Он же ничем не владеет, получается. Возможно понятнее станет, если опишете, что за продукт, кто все эти люди, которые друг с другом постоянно ходят на совещания.
ps
вы найдёте пошаговую инструкцию по подготовке к проектированию и разработке продукта
Ирина, шикарная статья, спасибо! По-взрослому. Здорово, что потратили время и нарисовали бордов-пустышек - с этими иллюстрациями получилось наглядно, система управления задачами прослеживается, воспринимается.
Подскажите, насколько кастомной, кустарной была настройка описанного многообразия бордов? Инструментом кайтен не пользовался, интересует, что из этого там есть из коробки. В том числе риски. И получается ли где-то совместить задачи эпика/инкремента и его риски.
На примере борда конкретной команды: разбивка на "срочно" и "стандартно" - это по ценности родительского эпика или через какой атрибут?
Таски из-под эпика как попадают на борд команд-исполнителей и в колонку "запланировано": подвинули эпик в работу и все таски толпой вывалились на бордах задействованных команд? Или у них тоже происходит некое своё внутреннее планирование, оценка полезности, сложности?
При том, что каждому эпику навешивается воспринимаемая ценность от продактов и/или менеджмента, удаётся ли как-то в этих условиях отрабатывать техдолг?
Бизнесы в эпиках ценность ставят "от фонаря" или делаете покер-сессии и/или меряете по RIC(E) или схожей методике?
Пример нашей системы работы с эпиками, проектами и задачами.
У меня голова сломалась в попытках состыковать эту подпись к картинке с самой картинкой и текстом вокруг неё.
Вот статическая структура. Это наша динамическая система.
Мы наводим порядок в своих внутренних процессах, пишем документацию, фиксируем дизайн-гайдлайны. Благодаря этой системе управления проектами теперь проекты укладываются в дедлайны.
Был бы здорово что-то узнать именно о выстроенной системе управления задачами и проектами. За счёт каких динамических процессов управления проектными задачами и самими проектами достигается эффект синхронизации усилий многих команд, получается контролировать загрузку и прогнозировать сроки. Табличку с колонками "старт" и "финиш" увидел. Если прочее построено на похожих табличках, то вопрос снимается.
Мысль понятна, но во второстепенную инфу эти штуки относить - возможно не лучшая идея. Подробности про конкретный баг и как его воспроизвести - это первоочередная информация, тут споров нет. Но без привязки к общему контексту толпой багов и такой же толпой задач осмысленно управлять очень сложно. Если из бага можно сходить в предыдущий инцидент по той же проблеме, в релиз, в котором опять вылезло, в задачу, под которой трогали проблемный код - это одна обстановка. Если баг/задача тупиковый, как лист отрывного календаря в вакууме, самбля без ансамбля - это совсем другая и гораздо менее комфортная для работы и с конкретным багом, и со всем бэклогом обстановка.
Если б оно могло быть работоспособным и выдавало что-то осмысленное - без вопросов было бы здорово. А так остаётся только поиграться как со странными генерируемыми картинками и пойти дальше делом заниматься.
> Есть куда расти
Всё что в блоке про рост и развитие - это же основная проблематика и есть. Обёртка в виде плагина или не плагина станет нужна, когда будет что оборачивать.
В тексте есть ответ, и это поведение задокументировано. У ошибок предусмотрен разный уровень серьезности, обычные ошибки к прерыванию пакета команд и откату транзакции не приводят. Если только сам программист не сделал обработку ошибок так, чтобы прерывалось и откатывалось. Такое поведение а) скорее оставлено для обратной совместимости б) позволяет пользоваться сейв-пойнтами и иногда действительно игнорировать ошибки в стиле "а, ну и ладно, потом проапдейчу" в каких-то отдельностоящих сценариях; тот же дэдлок с повтором в цикле.
Для более однозначного поведения придумана опция XACT_ABORT (там в конце страницы как раз пример с ошибками по FK), но она выставлена в OFF по умолчанию - снова из соображений обратной совместимости. И выражение THROW, призванное заменить RAISERROR, по поведению как раз больше похоже на генерацию исключений в других языках: вылетаем либо в CATCH, либо весь батч прерывается, если находимся вне TRY-CATCH. RAISERROR (на котором написано всё легаси) ничего не прерывает, потому приходилось после него писать RETURN. THROW же превращает этот RETURN в unreachable code. Нюансов - толпа. Об том и вопрос.
В контексте durability и в еще более конкретном контексте про "городские легенды" - в тексте заход вроде бы достаточно прозрачный.
И всяких других граблях ... TRUNCATE
значения локальных переменных, даже табличных, в него явно не входят
Это и есть слова, рассуждения, ради которых вбрасываются подобные примеры, задаются такие вопросы. Ровно как рассуждения о том, что в таком-то режиме изоляции будет так-то, а в другом вот так. Это же не тест с бинарным выхлопом: угадал/не угадал.Все примеры или "унаследованы" из реальных собеседований, или сформированы на основе реальных ответов кандидатов с этих собеседований.
Ошибки можно и через механизм raiserror передавать
Это уже почти сформулированная распространённая задачка с собеседований: сколькими способами можно вернуть целочисленное значение из хранимки.
Рандомный код возврата хоть при успехе, хоть при неуспехе - такая же не соблюдённая базовая гигиена, как NOCOUNT и прочие мелочи. На скорость выполнения запросов не влияет, но про отношение к аккуратности, готовность соблюдать соглашения и причесывать старьё немного намекает.
несложный запрос с рекурсией и оконными функциями
такая ветка в описанной схеме собеседования присутствует.
Чтобы новые сервисы могли писать куда-то новые данные, нужно добавлять в таблицы колонки, создавать новые таблицы, удалять старые. Модифицировать хранимые процедуры, функции и триггеры, если применяются.
Но, видимо, вопрос задан не по адресу.
Подскажите, релизы БД каким-то образом удалось затянуть в описанную концепцию? Если нет, то было бы здорово узнать, как у вас решаются задачи, связанные с релизами БД.
Некоторые соображения про большой запрос (в основном из контекста MSSQL, но кое-что в доках Postgresql перепроверил и там вроде всё то же самое):
В блоке Levels UNION, который даёт доп. сортировку и DISTINCT, кажется, что можно смело заменить на UNION ALL, потому как по крайней мере колонка
node_levelточно ни на каком уровне иерархии не совпадет. Фрагментconcat(coalesce(concat(prev.parents, '-'), ''), cast(Mapping.parent_node_id as varchar))Можно бы упростить: CONCAT игнорирует NULL и COALESCE выглядит просто лишним. Такой же coalesce есть в блоке FineTree. Конвертацию инта в строку вроде бы concat в postgres тоже делает автоматически, т.е. как будто достаточноconcat(prev.parents, '-', Mapping.parent_node_id). Если хочется единообразия, то можно сделать по аналогии со строчкой нижеconcat_ws('-', prev.parents, Mapping.parent_node_id)В блоке Branches два схожих фрагмента:
если перевернуть первое условие, то код станет более прямолинейным:
В Tree UNION тоже больше похож на UNION ALL. Финальную сортировку корректнее в финальном же запросе и разместить, а то cte FineTree как сортированная вьюха получается. В Branches сортировка выглядит просто лишней.
Множественные джойны на RootNodes кажется, что не нужны - у всех корневых узлов
nest_level = 0и можно пользоваться этим знанием. Избавиться от этого джойна возможно в Branches и в Tree. Вместе с этим можно будет выкинуть два CTE: Mapping и RootNodes. Фильтр `parent_node_id is null / node_id in (3, 10, 17)`идеально подходит для первого запроса рекурсивного CTE Levels. И в кейсах (рассмотренных чуть выше) получится более естественное для восприятия условиеwhen nest_level = 0 then ''И очень желательно во всех запросах колонкам алиас источника расставить: СУБД разберётся, где чьё, а человеку читать тяжело. Большую часть, если не всё, из того, что происходит в Branches и Tree, как будто можно сделать ещё в Levels и повторно большую рекурсию не гонять.
Чёрт с ними, с "тогглами", но что вы там режете всё время? Что такое "отрезка", "автоотрезка", кто с чем что делает?
ничто из перечисленного не "методология". По ссылке - стандартная копипастовая лажа, собранная для объёма текста и прочих SEOшных дел человеком, который вообще не понимает, что пишет.
Правильно ли понимаю, что предложенные 10 шагов с шаблонами - это сценарий одного ретро и такой сценарий, каждый шаг которого приводит к осязаемым решениям?
"Спринт как фильм", "спринт в мемасиках" - очень не хватает примеров осязаемых решений. И, правильно ли понимаю, что и одно и другое случается в одну сессию ретро и сначала каждый "показывает кино", а потом показывает мемасики?
Подскажите, как давно вы проводите ретро по предложенному сценарию, сколько вы таких ретро уже успели провести, какое число людей участвуют каждый раз, в какое время вы укладываетесь со всеми предложенными десятью шагами и в скольки командах такой формат прижился.
Могу что-то путать, но это вроде бы про процессы, инструменты, ритуалы. Дискуссия вроде "давайте бросим ту задачу и начнем вот эту" выглядела бы странной. Это не вопрос отношения коллектива, а вопрос распределения ресурсов и приоритезации задач - это дело лидов, менеджеров и владельца продукта.
Может всё-таки Check? А то, что у вас названо "Поручения" - Act.
Спасибо, мысль понял. Писалось без SSMS в онлайн-редакторе, потому не очень аккуратно. И GO тот редактор не понимает. Попозже причешу.
Последний скрин многообразием представленной информации намекает, что функционала много и он, скорее всего, хороший и полезный... но интерфейс - адовейшая каша. Так выглядит карточка любой задачи?..
Просто вывалено всё, что есть. Главный акцент отсутствует, всё подряд тянет на себя внимание. Здесь всё скомкано, несвязанное контекстом, семантикой свалено в кучу. А тут нам завезли пустого места. Очень много текстовой и графической информации, которая в моменте не имеет и не может иметь никакого значения.
Вы б прибрались бы. Весна, время субботников.
Вы сами всех запутали и себя в первую очередь. Миграциями называется только то, что вы называете изобретенным термином "добивочные миграции".
Вариантов организации исходников БД и построения Continuous Delivery два:
вы храните только миграции (alter table add, alter trigger) и конечное состояние понять можно только прогнав все миграции что есть; это удобно при работе через ORM, когда нет хранимок и триггеров, а таблицы определены классами в ООП
вы храните определения объектов, а скрипт миграции для деплоя генерируется утилитой вроде liquibase налету и нигде не хранится; этот вариант удобен, когда у вас полноценная разработка на стороне БД: в GIT лежат финальные версии определений таблиц и хранимок, при возникновении конфликта по изменениям, он, во-первых, очевиден, во-вторых решается штатным образом как с нормальными исходниками
Если утилита не умеет в alter table, то вариантов нет и нужно для таблиц (дополнительно к определению) создавать и хранить файлы миграций. Для функций у вас хранятся не миграции, а определения (definition), миграция возникает налету, когда liquibase понимает, что файл с CREATE FUNCTION изменился и генерирует ALTER FUNCTION.
Это просто яркое название или где-то действительно прописан некий путь, который должна пройти задача? Контроль прохождения и заполнение поля делегированы автоматике или, так сказать, под честное слово того, кто это поле заполнит руками?
Выглядит шикарно! Подскажите, это точно функционал "просто дашборда" или скорее плагин, ваша внутренняя разработка? Возможно зависит от версии JIRA, но мне кажется даже вкладку на дашборде сделать штатными средствами невозможно.
Удалёнка, инхаус, энтерпрайз.
Но коллектив действительно своеобразный: все опытные, проактивные, часть с прошлым опытом работы руководителем или тимлидом - пинать некого, разжевывать некому. Иногда нужно посоветоваться или получить помощь от того, кто больше знаком с технологией или инструментом - двое договариваются и созваниваются. Многие задачи изолированы, каждый тащит на себе от начала до конца. С управлением задачками, пониманием текущего статуса у нас заметно получше, чем у "соседей". Теребить никого не нужно, можно открыть подходящий борд и посмотреть. Суть работы команды - вариация на тему enabling team.
Вокруг - вся характерная специфика "оранжевых" организаций. Среднее звено, руководители управлений из созвонов не вылезают. "Соседи" созваниваются каждый день, мы раньше тоже так делали, пока не перехотели.
Некоторые представители "дальних соседей" считают нормальным взять и нажать кнопку созвона просто потому, что она есть. Или в рандомный момент закинуть бесцельный созвон в календарь на толпу людей.
Противодействуем всем знакомыми методами:
укажите пожалуйста программу встречи и ожидаемый результат
обозначьте пожалуйста цель моего присутствия, зачем нужен именно я
предоставьте материал по проблеме, чтобы я смог подготовиться
если у вас есть вопрос, пожалуйста, сформулируйте его в виде букв с вопросительным знаком в конце и отправьте ответом на это письмо
Надо ли говорить, что возвращается со сформулированными мыслями, тезисами, целями и вопросами приблизительно никто.
В календаре зачем-то на вообще всех перманентно закинуты демо неких фич от команд, про которые я знать не знаю. Пятничное "мы гордимся этими кейсами" на полтора часа, где 200+ человек смотрят на презенташку от сейлзов и подобное. Если не сопротивляться, то абсолютно легально, даже не будучи руководителем, половину недели спускать в созвонную трубу вполне возможно. Ван-ту-ваны мне за каким-то лешим опять пытаются навязать. На два года сделал вид, что забыл закинуть их в календарь, но теперь меня вычислили. Видимо, придется раз в неделю протирать этот соломенный аэроплан.
Экспериментирование с днём тишины на сегодняшний момент привело наш небольшой коллектив сюда:
Пн - daily утром (до 15 минут)
Ср - daily утром (до 15 минут)
Пт - refinement вечером (15-30 минут)
Применимо не ко всем коллективам, но если проблема осознана, то отрезать можно пробовать и кусками побольше. Как говорят опытные эджайлисты-евангелисты, дэйлик - это про цель и формат, не про расписание. Если каждый день обсуждать нечего, то может и незачем. Но, как вы справедливо заметили, сначала необходимо качнуть культуру управления задачками, проведения самих совещаний, коммуникации как таковой.
Чтобы избавиться от тупняков в конце каждого созвона "может кому есть что сказать дополнительно?" и, как следствие, расползания разговора "по древу", договорились, что ведущий в спец-чате про напоминания и созвоны чуть загодя заводит тред про конкретный созвон (например, Daily 2024-03-19). Если у кого есть что-то сверх регламента, то он закидывает тему в этот тред. Ведущий решает, для дейлика эта тема или нет. Для обсуждений, требующих от участников погружения в материал, сначала обозначается цель и предоставляется материал. Созвон планируется с учетом времени, нужного на подготовку.
Покер-сессии делаем асинхронно. Где померяли более-менее ровно, ведущий сам фиксирует оценку. Обсуждение расхождений приклеиваем к хвосту ближайшего дейлика.
Это же административное, не культурное. Авария - ну-ка быстро все на созвон! Механизм распространённый, но это про иерархию, обязаловку, подчиненность, доставку информации наверх. С применением такой практики лучше, безусловно, становится, если раньше ничего подобного не было. Как конкретно проводится процедура, с чем на неё приходят и с чем уходят - да, тут могут быть элементы культуры. Если все договорились руками на проде не шурудить, не деплоить в обход пайплайна и соблюдают эти договорённости - это элемент культуры. Если раньше была обратная картина, то чтобы прийти к подобному состоянию нужен серьезный культурный сдвиг. Чтобы созваниваться после аварии - не нужен. Если раньше все просто суетились и где-то что-то как-то фиксили, а после решения проблемы не могли вспомнить, где чего поменяли, какими действиями фактически устранили последствия инцидента, и в чем он заключался - это отсутствие культуры. Если все дружно стали вести в правильных местах хронологию своих манипуляций, большую часть манипуляций до возникновения инцидента и проделываемых после возникновения перевесили на автоматику, которая ведёт подробный лог, и потом это можно как-то склеить и получить ту саму хронологию - это высокий и технический, и культурный уровень. А созвониться можно и без всего этого.
Есть дейлик, на котором нужно озвучивать проблемы и трудности в решении задач. Есть ретро, где нужно разбирать в том числе проблемы и трудности. И потом еще отдельный регламентно-ритуальный созвон, теперь уж точно по проблемам и трудностям? "Пахнет" не очень хорошо. И точно не про культуру, а опять про администрирование.
Подозрительное совмещение в одном предложении. Тоже "пахнет" не очень.
Больше созвонов богу созвонов. Кросс-командное ретро/пост-мортем? Вероятно, здравое зерно есть. Может даже и не связанное напрямую с самой разбираемой проблемой. Не менее вероятным кажется и то, что некоторые заросли малины хоть и выглядят со стороны свежо и соблазнительно, выжить смогут только в присутствии уверенной руки с секатором.
Не складывается у меня картинка того, о чем вы рассказываете. Если есть возможность, дайте пожалуйста пояснения.
О какого рода проектах, продуктах идет речь, что вы называете "хотелками"? Если вы продаёте продукт или доступ к нему, то кто такие стейкхолдеры и заказчики? Если это пользователи и клиенты, то вроде бы неоткуда взяться частым встречам с ними. Если это заказчик, который платит деньги за реализацию нужных ему задач, то непонятно про статус "хотелок" и отказ в выполнении. Если, обратно, не заказчик, а рандомные люди заводят хотелки, то что делают в этих хотелках сроки, как их угораздило сюда затесаться?
Если хотелку завёл хотельщик, то не очень понятно про бюджет и тем более про задумку. На гитхабе я закинул фича-реквест. Мне либо ответили "спасибо, но нет", либо решили что-то да сделать. Что именно - полностью остаётся на той стороне. Я попросил что-то небольшое, но они осознали бОльшую картину и там, где мне виделся одноколесный велосипед, они соорудили космолёт, держа в голове свои какие-то цели. Про учёт именно "хотелок" - как будто много лишнего в описании и некоторые подробности, что называется, не отсюда. Если это работы, выполняемые по контракту, то опять не понятно, что здесь делают фрагменты сценариев про фича-реквесты от рандомных персонажей. А хотелось бы понять
Слегка попахивает инструкцией, как потратить кучу времени толпы людей на бессмысленные созвоны. Но возможно я чего-то не знаю или вы так называете процедуры, которые мне привычнее называть иначе. Интересует судьба Product Owner'а в такой картине мира. Он же ничем не владеет, получается. Возможно понятнее станет, если опишете, что за продукт, кто все эти люди, которые друг с другом постоянно ходят на совещания.
ps
но статья же не об этом.
Ирина, шикарная статья, спасибо! По-взрослому. Здорово, что потратили время и нарисовали бордов-пустышек - с этими иллюстрациями получилось наглядно, система управления задачами прослеживается, воспринимается.
Подскажите, насколько кастомной, кустарной была настройка описанного многообразия бордов? Инструментом кайтен не пользовался, интересует, что из этого там есть из коробки. В том числе риски. И получается ли где-то совместить задачи эпика/инкремента и его риски.
На примере борда конкретной команды: разбивка на "срочно" и "стандартно" - это по ценности родительского эпика или через какой атрибут?
Таски из-под эпика как попадают на борд команд-исполнителей и в колонку "запланировано": подвинули эпик в работу и все таски толпой вывалились на бордах задействованных команд? Или у них тоже происходит некое своё внутреннее планирование, оценка полезности, сложности?
При том, что каждому эпику навешивается воспринимаемая ценность от продактов и/или менеджмента, удаётся ли как-то в этих условиях отрабатывать техдолг?
Бизнесы в эпиках ценность ставят "от фонаря" или делаете покер-сессии и/или меряете по RIC(E) или схожей методике?
У меня голова сломалась в попытках состыковать эту подпись к картинке с самой картинкой и текстом вокруг неё.
Вот статическая структура. Это наша динамическая система.
Мы наводим порядок в своих внутренних процессах, пишем документацию, фиксируем дизайн-гайдлайны. Благодаря этой системе управления проектами теперь проекты укладываются в дедлайны.
Был бы здорово что-то узнать именно о выстроенной системе управления задачами и проектами. За счёт каких динамических процессов управления проектными задачами и самими проектами достигается эффект синхронизации усилий многих команд, получается контролировать загрузку и прогнозировать сроки. Табличку с колонками "старт" и "финиш" увидел. Если прочее построено на похожих табличках, то вопрос снимается.
Вышел из отпуска... и захотел обратно.
Мысль понятна, но во второстепенную инфу эти штуки относить - возможно не лучшая идея. Подробности про конкретный баг и как его воспроизвести - это первоочередная информация, тут споров нет. Но без привязки к общему контексту толпой багов и такой же толпой задач осмысленно управлять очень сложно. Если из бага можно сходить в предыдущий инцидент по той же проблеме, в релиз, в котором опять вылезло, в задачу, под которой трогали проблемный код - это одна обстановка. Если баг/задача тупиковый, как лист отрывного календаря в вакууме, самбля без ансамбля - это совсем другая и гораздо менее комфортная для работы и с конкретным багом, и со всем бэклогом обстановка.
Если б оно могло быть работоспособным и выдавало что-то осмысленное - без вопросов было бы здорово. А так остаётся только поиграться как со странными генерируемыми картинками и пойти дальше делом заниматься.
> Есть куда расти
Всё что в блоке про рост и развитие - это же основная проблематика и есть. Обёртка в виде плагина или не плагина станет нужна, когда будет что оборачивать.
В тексте есть ответ, и это поведение задокументировано. У ошибок предусмотрен разный уровень серьезности, обычные ошибки к прерыванию пакета команд и откату транзакции не приводят. Если только сам программист не сделал обработку ошибок так, чтобы прерывалось и откатывалось. Такое поведение а) скорее оставлено для обратной совместимости б) позволяет пользоваться сейв-пойнтами и иногда действительно игнорировать ошибки в стиле "а, ну и ладно, потом проапдейчу" в каких-то отдельностоящих сценариях; тот же дэдлок с повтором в цикле.
Для более однозначного поведения придумана опция XACT_ABORT (там в конце страницы как раз пример с ошибками по FK), но она выставлена в OFF по умолчанию - снова из соображений обратной совместимости. И выражение THROW, призванное заменить RAISERROR, по поведению как раз больше похоже на генерацию исключений в других языках: вылетаем либо в CATCH, либо весь батч прерывается, если находимся вне TRY-CATCH. RAISERROR (на котором написано всё легаси) ничего не прерывает, потому приходилось после него писать RETURN. THROW же превращает этот RETURN в unreachable code. Нюансов - толпа. Об том и вопрос.
В контексте durability и в еще более конкретном контексте про "городские легенды" - в тексте заход вроде бы достаточно прозрачный.
Это и есть слова, рассуждения, ради которых вбрасываются подобные примеры, задаются такие вопросы. Ровно как рассуждения о том, что в таком-то режиме изоляции будет так-то, а в другом вот так. Это же не тест с бинарным выхлопом: угадал/не угадал.Все примеры или "унаследованы" из реальных собеседований, или сформированы на основе реальных ответов кандидатов с этих собеседований.
Это уже почти сформулированная распространённая задачка с собеседований: сколькими способами можно вернуть целочисленное значение из хранимки.
Рандомный код возврата хоть при успехе, хоть при неуспехе - такая же не соблюдённая базовая гигиена, как NOCOUNT и прочие мелочи. На скорость выполнения запросов не влияет, но про отношение к аккуратности, готовность соблюдать соглашения и причесывать старьё немного намекает.
такая ветка в описанной схеме собеседования присутствует.