Почему pipeline behaviors - это зло, и как лучше сделать логирование контекста или повтор всей application layer транзакции для произвольного, постоянно меняющегося интерфейса методов-команд, которые используются произвольными же клиентами - ASP.NET, RabbitMQ, Quartz.NET etc? Bridges до middleware-функциональности driving-адаптеров? Кодогенерация декораторов? DynamicProxy?
Что делать с метриками, опирающимися только на количество продуктовых гипотез (или функциональности, соответствующей INVEST; например, параметр 3.1 из вашей таблички), при сильной волатильности *емкости последних? Скажем, cycle time одной истории - один день от взятия в работу до релиза на продакшне, другой - три спринта по две недели (иначе потеряем valuable и testable - не получим адекватную ОС и не провалидируем, что сделанное реально закрывает потребности), и так постоянно в течение нескольких лет. Переводить такие метрики на стори-поинты, как это сделано в соседях? (например, параметр 1.2)
Каким параметром можно проконтролировать "инфляцию стори-поинтов/историй"? Скажем, команда неосознанно начала резать бизнес-хотелки на истории поменьше (например, договорившись, что "влезает в один спринт" важнее "функциональность реализована end-to-end, пусть и без множества деталей, и ее можно не только деплоить, но и релизить - включать для пользователей"), назначать им стори-поинтов побольше ("в прошлый раз были подводные камни, давайте с запасом", и так каждый спринт), и делать их настолько медленней, чтобы burnout как поинтов, так и историй таки продолжал расти, но на субъективном уровне чувствовалось, что происходит что-то не то
каждая команда сама для себя устанавливает шкалу оценки в стори-поинтах, как ей удобно
Может быть, какие-нибудь команды смогут поделиться принципами, по которым они выбирали и калибровали свою шкалу? Если они сложнее, чем "взяли случайную, понравилось", конечно. Использование story points зачастую связано с операцией сложения (да хотя бы velocity), и мне кажется, что шкала может сильно влиять на результаты. Я знаю пример, в котором 3 <> 1 + 2 <> 1 + 1 + 1 - в результате velocity осциллировала аки хвост трясогузки, и о предсказуемости не могло идти и речи
Согласен, сравнивать шкалы и скорости команд между собой - крайне скользкая дорожка. Более того, шкала одной и той же команды из 2021 и из 2022 года уже могут значительно отличаться. Переоценка важна - меняются задачи, меняется состав команды, появляются новые скиллы
Я придерживаюсь оценки в story points как относительной сложности задачи
"Да кто такая эта ваша сложность нафиг?" :) Мы так и не нашли ответа на этот вопрос. Сопоставить миллион человеческих профилей между Excel-файлом и БД - это сложно? А ускорить систему в два раза? А пробросить поле через 7 сервисов разной степени "микровости" и разными процессами разработки и релизов? А раскатить новую функциональность, опробованную на небольшой группе любителей bleeding edge, на 1000 клиентов из 10 стран ("пфф, кнопку нажал, и готово", или "когда все может пойти не так")? Опять же, чем крупнее задачи в спринте, тем меньше будет пользы от эффекта "где-то недооценили, где-то переоценили - в итоге само выровнялось"
На самом деле разброс (cycle time по типам задач) достаточно большой
Тогда вопрос - почему текущий набор типов задач именно такой, и были ли мысли его пересмотреть на основе кластеризации по cycle time? Или из-за невысокой точности этой метрики пользы также будет немного?
разброс (длин бэклогов) по командам очень большой, зависит от процессов
Нет ли команд, у которых в бэклоге задач на год вперед? Как они к этому относятся, нет ли ощущения "мы никогда это не сделаем"?
Initial Scope Drop
Бывает ли (и как часто) "отрицательный scope drop" (когда команда была слишком пессимистична на планировании)?
Какую шкалу стори-поинтов вы используете? (количество и распределение элементов - степени двойки, числа Фиббоначи etc)
Используете ли golden story? Другими словами, есть ли зафиксированная история с неким количеством SP, чтобы команды на грумингах говорили "история A вполовину проще эталонной, а история B в четыре раза сложнее"?
Когда команды дают оценку в SP, что в нее вкладывают?
• трудоемкость в time units (вплоть до "идеальных человекодней"),
• риски недооцененности "непонятно, как это делать - может вырасти в два раза",
• риски простоев "может ждать другую команду, ответ от бизнеса, maintenance window etc"
Какие разбросы по cycle time внутри отдельных типов задач? Другими словами, насколько пессимистичен 85-й перцентиль?
Насколько длинные бэклоги команд (в количестве задач и в спринтах по текущей velocity)?
Шаг 1 ... введение нового требования к оформлению коммитов внутри команды, чтобы они соответствовали соглашению выше
Обычно это - самый сложный этап :) Точнее, сложно не ввести, а поддерживать его соблюдение на больших интервалах. Конечно, в коммите можно ограничиться ссылкой на задачу, а changelog строить по данным таск-трекера (теперь можно и коммитить раз в 15 минут, и squash'ить ветки), но это все еще требует дисциплины (адекватных названий карточек, которые и суть отразят, и пользователям показать не стыдно). У вас, насколько я понял, библиотеки сугубо для внутреннего использования, поэтому из-за случайно проскочившего слова "жопа" или изменения "this solves it" если и расстроятся, то не очень сильно. Или я неправ, и ваши процессы как-то гарантируют, что данные для changelog'ов всегда будут близки к идеалу?
Обычно я смотрю меридиану потраченного времени для разных весов задач - 0.5SP/ 1SP/ 2SP/ 3SP
Если я правильно понял, то речь идет о медиане, она же 50th percentile. Физический смысл - "половина задач будет сделана за это или меньшее время". Вам достаточно того, что вы прогнозируете только половину задач? Или вы (вообще кто-то кроме тебя ходит на эти экраны Jira?) проверяете и другие характеристики распределения? Боюсь, я не настолько дружу со статистикой, чтобы что-то предполагать...
1. Кажется, я замудрил с вопросом, поэтому позволь переобуться на ходу. Как именно вы проверяете, попадаете вы в оценки или нет? Если используете реально затраченное время - откуда его берете и как обеспечиваете его адекватность?
Немного контекста моего интереса. У нас есть проблемы а-ля "недожарили задачу, а стейкхолдеры не могут ответить прямщаз" и "делали задачку, и вдруг прод загорелся - отвлеклись на 2-3 дня". Мы пытались помечать unexpected-задачи, чтобы на основе статистики понять процент рисков для такой же "закладки" и отработать их причины - вышло по-бюрократически муторно и не очень точно ¯\_(ツ)_/¯ Например, мы забываем двигать или тегать карточки, таск-трекер не считает, сколько времени задача была в статусе "заблокировано", ну и ситуации бывают куда гибче и хитрее этих ваших процессов и инструментов :)
4. Я не могу не спросить. Бывает такое, что в стремлении сделать как можно лучше разработчики слишком увлекаются "игрой со шрифтами" и в итоге продалбывают какой-нибудь важный кусочек функциональности?
Наверняка у вас встречаются ситуации, когда одна задача становится заблокированой на некоторое время (нужно чего-то дождаться, отвлечься на срочное - да тот же отгул на день). Вы как-то учитываете это при проверках "попадаем в оценки или нет"? Сколько суммарно времени может уходить на "задача в работе, но не делается"?
Как много у вас задач-прилетов "все в огне, нужно сделать вчера", не связанных с бэклогом итерации? Какое соотношение между ними и выявленными "подводными камнями" задач в работе, без которых не запуститься?
Также кажется, что у найденного подводного камня есть две судьбы - либо без него вообще нельзя, и на задачу будет потрачено больше времени (и это вы не только закладываете заранее, но и проверяете впоследствии), либо это "можно отложить". Вопрос - есть ли у вас в бэклоге такие фиче- и технические долги? Как вы их приоритизируете относительно новых фич-реквестов, по какому принципу набираете в бэклог итерации?
И есть ли у вас какие-нибудь best practicies и прочие трюки, чтобы сформулировать Definition of Done, с которым все (разработчики и стейкхолдеры) будут иметь в виду одно и то же? (что также должно минимизировать расхождение между прогнозируемой сложностью и фактическими затратами, ведь nice to have, который не подразумевался заранее, можно с чистой совестью отложить или даже выкинуть)
На основе чего вы рассчитываете Capacity команды? Вы ведете time sheets или что-то более простое для учета времени, потраченного на задачи? Просто считаете количество задач (тогда как вы суммируете задачи разных размеров)? Заранее оцениваете в "не-временнЫх" единицах вроде "берем идеальную задачу и сравниваем остальные с ней - такая же, дольше, проще" или "прогноза подводных камней - просто, нужно подумать, вообще не понятно" (а есть переоценка во время work in progress)?
Как вы измеряете Complexity? Эти единицы можно складывать? Как они сопоставляются с Capacity?
Рассматривали ли вы trivariate analysis/estimation (не смог найти корректного перевода)? Взять среднюю референсную задачу (скорее всего, уже выполненную), оценить ее трудоемкость (sic) в среднее же количество Nebulous Unit of Time из выбранной шкалы, а затем каждой новой задаче давать не одну оценку в тех же NUT, а три, уже "с учетом сложности и рисков" - оптимистичную (сколько NUT мы потратим с гарантией/вероятностью в 5%, если все пойдет как по маслу - будет ли эта задача немного меньше референсной, больше раза в 2-4 etc), реалистичную (с вероятностью 50%, если наткнемся на парочку подводных камней) и пессимистичную (95%, если встретим швабры, вентилятор и воздушный шар). Таким образом, вы помимо рисков (по сути разброса между оценками) получите больше данных для прогноза сроков завершения epic'ов командой с учетом ее velocity. Или затраты на подобные сессии оценок (в три раза дольше) превысят выгоду?
И второй вопрос - что и каким образом вы с вашим подходом к планированию отвечаете стекйхолдерам на вопрос "когда будет готов очередной epic"? Есть ли у вас сейчас какой-либо способ прогнозировать сроки, пусть и с точностью трамвайной остановки, имея на руках только сложность и важность/срочность задач?
Я правильно понимаю, что вы используете Flows только для ручных проверок во время активной разработки, но НЕ в основном наборе авто- и ручных тестов (необходимых для принятия решения, можно ли релизить приложение или нет, включая юзабилити-тесты вроде "не перекрывают ли компоненты друг друга")? Или, может быть, вы смогли успешно применить подход а-ля фрактального тестирования?
Про опытных сеньоров, с которыми эффективней «пообщаться за жизнь», вы написали, но что вы думаете о собеседовании с кандидатом, опыт которого, скажем, 1-3 года? Он видел всего пару мест, работал не с самым лучшим кодом под эффектом «разбитых стекол» (и оттого не всегда знает, что можно «лучше», а главное — как это сделать), да и в бизнес особо не погружался. Как рассмотреть в нем потенциал, отличить человека, которому достаточно показать новые пути и слегка подтолкнуть (периодически устраивая обсуждения о прагматизме и «меньшем из двух зол» какого-нибудь архитектурного решения), от того, кто останется на том же уровне и еще через 3 года? Или вы не выращиваете собственных сеньоров, предпочитая брать готовых на рынке?
Про отстаивание своих прав вы правильно говорите, но здесь есть один нюанс.
Деятельность Uber запрещена в некоторых странах, водителей Uber штрафуют за нарушение законов.
Политика Uber с самого начала не предполагала наличие лицензий у водителей.
Рядом с тобой открыли магазин, но в нем нет кассы, а товары приходят через черный рынок. С ними борется государство, но пока не прикрыло лавочку до конца. Собственно, по причине незаконности товары в этом магазине стоят на порядок дешевле, что мешает всему остальному рынку. Что делать простым смертным? В идеале — ждать реакции государства, на практике же они теряют деньги, которые потом им никто не вернет.
Говорю сразу — я не могу поддержать или выбрать ни один из этих вариантов (ждать у моря погоды или громить Uber), ни к чему не призываю и никакую точку зрения не навязываю.
Пожалуйста, уточните причину убийства. Я, например, с острым предметом в руках нервно кошусь на Lenovo, которая обожает помещать Fn перед Ctrl, а в данном случае не вижу ничего криминального (Fn рядом с правым Shift — фиговенько, но не смертельно).
На паре сайтов (точнее вспомнить не могу) видел блоки комментариев, сообщения в которые отправлялись посредством SMS — суть те же платные комментарии. Что самое интересное, троллинга и флуда там было в разы больше каких-либо осмысленных сообщений. Правда, там это можно объяснить общесайтовым характером комментариев (они не привязывались к конкретной статье).
Если сильно захотеть, можно сделать из 272.1 УК РФ вариант «VNC-сервер отправил вам копию экрана — информация была скопирована, два года». Прокуроры такие прокуроры.
Почему pipeline behaviors - это зло, и как лучше сделать логирование контекста или повтор всей application layer транзакции для произвольного, постоянно меняющегося интерфейса методов-команд, которые используются произвольными же клиентами - ASP.NET, RabbitMQ, Quartz.NET etc? Bridges до middleware-функциональности driving-адаптеров? Кодогенерация декораторов? DynamicProxy?
Что делать с метриками, опирающимися только на количество продуктовых гипотез (или функциональности, соответствующей INVEST; например, параметр 3.1 из вашей таблички), при сильной волатильности *емкости последних? Скажем, cycle time одной истории - один день от взятия в работу до релиза на продакшне, другой - три спринта по две недели (иначе потеряем valuable и testable - не получим адекватную ОС и не провалидируем, что сделанное реально закрывает потребности), и так постоянно в течение нескольких лет. Переводить такие метрики на стори-поинты, как это сделано в соседях? (например, параметр 1.2)
Каким параметром можно проконтролировать "инфляцию стори-поинтов/историй"? Скажем, команда неосознанно начала резать бизнес-хотелки на истории поменьше (например, договорившись, что "влезает в один спринт" важнее "функциональность реализована end-to-end, пусть и без множества деталей, и ее можно не только деплоить, но и релизить - включать для пользователей"), назначать им стори-поинтов побольше ("в прошлый раз были подводные камни, давайте с запасом", и так каждый спринт), и делать их настолько медленней, чтобы burnout как поинтов, так и историй таки продолжал расти, но на субъективном уровне чувствовалось, что происходит что-то не то
Может быть, какие-нибудь команды смогут поделиться принципами, по которым они выбирали и калибровали свою шкалу? Если они сложнее, чем "взяли случайную, понравилось", конечно. Использование story points зачастую связано с операцией сложения (да хотя бы velocity), и мне кажется, что шкала может сильно влиять на результаты. Я знаю пример, в котором 3 <> 1 + 2 <> 1 + 1 + 1 - в результате velocity осциллировала аки хвост трясогузки, и о предсказуемости не могло идти и речи
Согласен, сравнивать шкалы и скорости команд между собой - крайне скользкая дорожка. Более того, шкала одной и той же команды из 2021 и из 2022 года уже могут значительно отличаться. Переоценка важна - меняются задачи, меняется состав команды, появляются новые скиллы
"Да кто такая эта ваша сложность нафиг?" :) Мы так и не нашли ответа на этот вопрос. Сопоставить миллион человеческих профилей между Excel-файлом и БД - это сложно? А ускорить систему в два раза? А пробросить поле через 7 сервисов разной степени "микровости" и разными процессами разработки и релизов? А раскатить новую функциональность, опробованную на небольшой группе любителей bleeding edge, на 1000 клиентов из 10 стран ("пфф, кнопку нажал, и готово", или "когда все может пойти не так")? Опять же, чем крупнее задачи в спринте, тем меньше будет пользы от эффекта "где-то недооценили, где-то переоценили - в итоге само выровнялось"
Тогда вопрос - почему текущий набор типов задач именно такой, и были ли мысли его пересмотреть на основе кластеризации по cycle time? Или из-за невысокой точности этой метрики пользы также будет немного?
Нет ли команд, у которых в бэклоге задач на год вперед? Как они к этому относятся, нет ли ощущения "мы никогда это не сделаем"?
Бывает ли (и как часто) "отрицательный scope drop" (когда команда была слишком пессимистична на планировании)?
Какую шкалу стори-поинтов вы используете? (количество и распределение элементов - степени двойки, числа Фиббоначи etc)
Используете ли golden story? Другими словами, есть ли зафиксированная история с неким количеством SP, чтобы команды на грумингах говорили "история A вполовину проще эталонной, а история B в четыре раза сложнее"?
Когда команды дают оценку в SP, что в нее вкладывают?
• трудоемкость в time units (вплоть до "идеальных человекодней"),
• риски недооцененности "непонятно, как это делать - может вырасти в два раза",
• риски простоев "может ждать другую команду, ответ от бизнеса, maintenance window etc"
Какие разбросы по cycle time внутри отдельных типов задач? Другими словами, насколько пессимистичен 85-й перцентиль?
Насколько длинные бэклоги команд (в количестве задач и в спринтах по текущей velocity)?
Обычно это - самый сложный этап :) Точнее, сложно не ввести, а поддерживать его соблюдение на больших интервалах. Конечно, в коммите можно ограничиться ссылкой на задачу, а changelog строить по данным таск-трекера (теперь можно и коммитить раз в 15 минут, и squash'ить ветки), но это все еще требует дисциплины (адекватных названий карточек, которые и суть отразят, и пользователям показать не стыдно). У вас, насколько я понял, библиотеки сугубо для внутреннего использования, поэтому из-за случайно проскочившего слова "жопа" или изменения "this solves it" если и расстроятся, то не очень сильно. Или я неправ, и ваши процессы как-то гарантируют, что данные для changelog'ов всегда будут близки к идеалу?
Большое спасибо за ответы! Кажется, одно это обсуждение уже тянет на еще одну статью :)
Если я правильно понял, то речь идет о медиане, она же 50th percentile. Физический смысл - "половина задач будет сделана за это или меньшее время". Вам достаточно того, что вы прогнозируете только половину задач? Или вы (вообще кто-то кроме тебя ходит на эти экраны Jira?) проверяете и другие характеристики распределения? Боюсь, я не настолько дружу со статистикой, чтобы что-то предполагать...
1. Кажется, я замудрил с вопросом, поэтому позволь переобуться на ходу. Как именно вы проверяете, попадаете вы в оценки или нет? Если используете реально затраченное время - откуда его берете и как обеспечиваете его адекватность?
Немного контекста моего интереса. У нас есть проблемы а-ля "недожарили задачу, а стейкхолдеры не могут ответить прямщаз" и "делали задачку, и вдруг прод загорелся - отвлеклись на 2-3 дня". Мы пытались помечать unexpected-задачи, чтобы на основе статистики понять процент рисков для такой же "закладки" и отработать их причины - вышло по-бюрократически муторно и не очень точно ¯\_(ツ)_/¯ Например, мы забываем двигать или тегать карточки, таск-трекер не считает, сколько времени задача была в статусе "заблокировано", ну и ситуации бывают куда гибче и хитрее этих ваших процессов и инструментов :)
4. Я не могу не спросить. Бывает такое, что в стремлении сделать как можно лучше разработчики слишком увлекаются "игрой со шрифтами" и в итоге продалбывают какой-нибудь важный кусочек функциональности?
Спасибо! Хотя я еще вопросов принес :)
Наверняка у вас встречаются ситуации, когда одна задача становится заблокированой на некоторое время (нужно чего-то дождаться, отвлечься на срочное - да тот же отгул на день). Вы как-то учитываете это при проверках "попадаем в оценки или нет"? Сколько суммарно времени может уходить на "задача в работе, но не делается"?
Как много у вас задач-прилетов "все в огне, нужно сделать вчера", не связанных с бэклогом итерации? Какое соотношение между ними и выявленными "подводными камнями" задач в работе, без которых не запуститься?
Также кажется, что у найденного подводного камня есть две судьбы - либо без него вообще нельзя, и на задачу будет потрачено больше времени (и это вы не только закладываете заранее, но и проверяете впоследствии), либо это "можно отложить". Вопрос - есть ли у вас в бэклоге такие фиче- и технические долги? Как вы их приоритизируете относительно новых фич-реквестов, по какому принципу набираете в бэклог итерации?
И есть ли у вас какие-нибудь best practicies и прочие трюки, чтобы сформулировать Definition of Done, с которым все (разработчики и стейкхолдеры) будут иметь в виду одно и то же? (что также должно минимизировать расхождение между прогнозируемой сложностью и фактическими затратами, ведь nice to have, который не подразумевался заранее, можно с чистой совестью отложить или даже выкинуть)
Расскажите подробней про Capacity и Complexity
На основе чего вы рассчитываете Capacity команды? Вы ведете time sheets или что-то более простое для учета времени, потраченного на задачи? Просто считаете количество задач (тогда как вы суммируете задачи разных размеров)? Заранее оцениваете в "не-временнЫх" единицах вроде "берем идеальную задачу и сравниваем остальные с ней - такая же, дольше, проще" или "прогноза подводных камней - просто, нужно подумать, вообще не понятно" (а есть переоценка во время work in progress)?
Как вы измеряете Complexity? Эти единицы можно складывать? Как они сопоставляются с Capacity?
Рассматривали ли вы trivariate analysis/estimation (не смог найти корректного перевода)? Взять среднюю референсную задачу (скорее всего, уже выполненную), оценить ее трудоемкость (sic) в среднее же количество Nebulous Unit of Time из выбранной шкалы, а затем каждой новой задаче давать не одну оценку в тех же NUT, а три, уже "с учетом сложности и рисков" - оптимистичную (сколько NUT мы потратим с гарантией/вероятностью в 5%, если все пойдет как по маслу - будет ли эта задача немного меньше референсной, больше раза в 2-4 etc), реалистичную (с вероятностью 50%, если наткнемся на парочку подводных камней) и пессимистичную (95%, если встретим швабры, вентилятор и воздушный шар). Таким образом, вы помимо рисков (по сути разброса между оценками) получите больше данных для прогноза сроков завершения epic'ов командой с учетом ее velocity. Или затраты на подобные сессии оценок (в три раза дольше) превысят выгоду?
И второй вопрос - что и каким образом вы с вашим подходом к планированию отвечаете стекйхолдерам на вопрос "когда будет готов очередной epic"? Есть ли у вас сейчас какой-либо способ прогнозировать сроки, пусть и с точностью трамвайной остановки, имея на руках только сложность и важность/срочность задач?
Я правильно понимаю, что вы используете Flows только для ручных проверок во время активной разработки, но НЕ в основном наборе авто- и ручных тестов (необходимых для принятия решения, можно ли релизить приложение или нет, включая юзабилити-тесты вроде "не перекрывают ли компоненты друг друга")? Или, может быть, вы смогли успешно применить подход а-ля фрактального тестирования?
Рядом с тобой открыли магазин, но в нем нет кассы, а товары приходят через черный рынок. С ними борется государство, но пока не прикрыло лавочку до конца. Собственно, по причине незаконности товары в этом магазине стоят на порядок дешевле, что мешает всему остальному рынку. Что делать простым смертным? В идеале — ждать реакции государства, на практике же они теряют деньги, которые потом им никто не вернет.
Говорю сразу — я не могу поддержать или выбрать ни один из этих вариантов (ждать у моря погоды или громить Uber), ни к чему не призываю и никакую точку зрения не навязываю.