На первый из них автор успел ответит ещё в статье в лайфхаке номер 3 - за это спасибо. Кмк, использование "прокси" ИБ архитекторов будет весьма и весьма оправдано. Особенно, если у продуктов уже есть ИТ архитекторы - как будто в их стек компетенций некоторый уровень ИБ архитекторы ложится очень удачно. Когда разработка выходит на плато и нет такого, что каждую неделю к продукту приделывают новый костыль, задачи становятся типовыми. А к типовым задачам можно применять типовые решения. Тогда и ИБ архитектора можно привлекать реже, ведь такие вопросы закроет и его "прокси".
Второй вопрос остался актуальным. В статье говорится о том, что надо очерчивать зоны ответственности и стараться вписать активности безопасной разработки в существующий продуктовый флоу. На практике часто возникает дилемма, мол, безопасники - они просто рекомендуют или согласовывают/запрещают? Вот видит ИБ архитектор критичный риск, а его фикс может быть сложным/дорогим и владелец продукта не готов заносить его в бэклог. Как быть? Ладно, с критами ещё может быть попроще, но как быть с менее судьбоносными задачами?
Опять же, на практике у вас могут быть процессы, роли и общее согласие по применению концепции безопасной разработке. Но в моменте бизнес часто использует аргумент "мы зарабатываем бабки, значит мы правы". Что в таком случае делать ИБ архитектору? Имеет ли он право вето? Исходя из опыта автора.
Хотелось бы узнать, если ли ещё менеджеры в команде кроме автора? Как будто в статье добавлены функции за пределом роли чистого продакта. Можно предположить,что менеджера проекта или некого коуча больше нет?
Ещё я не особо понял, зачем в команде, которой доверяешь и которая обладает экспертизой, обладать пониманием архитектуры и т.п., чтобы выполнять роль фасилитатор. Фасилитация - это в целом опосредованная от темы обсуждения вещь. Хотя суровые разработчики сейчас могут прибежать в комменты и рассказать, что не будут считать за человека и признавать менеджером любого, что не отпахал на их стеке минимум десятку лет)
Кмк на базе одного хаоса построили другой хаос. Если он работает, то ок, это победа. Значит ли это, что "традиционный Agile" не работает? Нет.
Команда всё равно пришла к релизам по плану, оценке и приоритезации задач. Кто-то выполняет функции продакта, кто-то поддерживает прозрачную коммуникацию. Планировать релиз на основе мощности QA? Так это чистый лимит WIP из Канбана.
Автор правильно называет такой подход "конструктором". Команда взяла какие-то отдельные элементы и некоторым образом "адаптировала" их. Почему это "победа" над "неработающими" Agile методологиями? Потому что так говорить круче/приятнее, чем "мы не умеем в Scrum/Kanban/XP и т.д., но пытаемся".
Но есть момент, на который я хочу обратить внимание автора. Допустим вы купили шкаф в IKEA и он приехал естественно в разобраном виде. Вы можете собрать из него самые разные штуки. Даже скворечник. Но это штука задумана как шкаф и проще всего её собрать как шкаф, и лучше всего она вам будет служить как шкаф. Вам нужно где-то хранить вещи, вы знаете это. Вы можете положить вещи стопкой на нераспакованную коробку со шкафом. Можете собрать каркас, но не вставлять внутрь полки, а просто сложить вещи одной высокой стопкой. А можете собрать его должным образом и хранить свои вещи удобно и эстетично.
На какой стадии сборки шкафа находится команда на данный момент?
Я что-то запутался. Почему вы убеждены, что всем нужны слёзы? И почему вы считаете, что раз всем нужны слёзы, даже неискренние слёзы - это эмпатия?
Это выглядит как очень грубое упрощение. Человек грустит - грусти с ним. Человек радуется - радуйся с ним. Но это не эмпатия, это мимикрия. Чистый рефлекс.
Мне импонирует определение эмпатии от Маршалла Розенберга:
эмпатия это уважительное понимание того, что переживают другие, это опустошение ума и слушание всем своим существом.
Эмпатичный человек не ориентирован на то, чтобы отгрузить собеседнику свои эмоции в ответ. И тем более он не навязывает советы, оценки или личный опыт в ответ на проявление эмоций собеседником. Эмпатия это про умение слушать и помогать собеседнику выражать свои эмоции и переживания. А ещё про "понимание", а не переживание своих эмоций.
Не соглашусь. Утверждение, что эмпатия это эмоциональная реакция, смещает фокус со способности воспринимать собеседника на внутреннее (эмоциональное) состояние эмпата. Это нас довольно быстро приведёт к тому, что, условно, более эмпатичным мы будем считать того человека, который слушает грустную историю со слезами на глазах, а не того, что не проявляет таких ярких эмоций.
Сразу скажу, что QA не являюсь и богатого опыта самостоятельной оценки затрат времени на тестирование не имею. Возможно из-за этого вопросы и возник)
А можно хотя бы грубо раскладку по часам? Что сколько времени заняло? Тут грубо говоря получилось, что один-единственный тестировщик затащил разработку мобильного приложения с нуля (ну ок, при готовых требованиях) за три месяца, работая на 0.2 ставки 0_о
Немного подушню: сторипоинты - это не часть Скрама. И соглашусь: однажны абстрактные оценки должны соотнестись с реальными трудозатратами.
И вот эти два момента часто приводят к ситуации, когда люди теряют веру в Скрам да и в Аджайл в целом. На самом деле вы можете использовать голую астракцию или трекать всё до каждой минуты. Важно найти такой способ, который подходит вам и приближает вас к цели.
Сами сторипоинты к этому моменту тоже сильно искажены. Как уже отмечено выше, "замешивание" в оценку в сторипоинтах времени полностью рушит концепцию. В целом, то, что автор описывает в статье как своё достижение, это убийство сторипоинтов.
Что делать? Опять же, сказано выше: перестать называть свою оценку сторипоинтами. Отделить оценку реальных трудозатрат от оценки... эм... инженерной сложности задачи.
Зачем это делать? И вновь, сказано выше: сторипоинты помогают с оценкой в условиях высокой неопределённости. Даже опытная команда на стабильном проекте может ВНЕЗАПНО получить от заказчика такой фича-реквест, что всем дружно придётся чесать затылок. И тут поможет абстракция. Потом уже декомпозированные задачи можно будет оценить ещё раз, в реальных трудозатратах будь то фокус-часы или ещё что.
Авторы Скрама - хитрые и в то же время логичные жуки. Они не принимают на себя ответственность ни за какие адаптации и "на практике". С одной стороны, Скрам существует не в вакууме, нам нужно как-то вписывать его в реальную картину мира. С другой, как авторы могут предугадать всё разнообразие вариантов внедрения и ещё принимать ответственность за то, как и что мы подкрутим?
Поэтому, подчеркну ещё раз, чаще всего получается как в анекдоте: «Вот все говорят: «Карузо! Карузо!» А я послушал – так ничего особенного» – «Вы слышали Карузо?!» – «Нет. Мне Рабинович напел».
Заголовок статьи гласит "Реквием по SCRUM". Если смыть налёт кликбейта, то останется "Реквием по нашей адаптации SCRUM".
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
"Скрам с некоторыми адаптациями" - это не Скрам.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме, это не его неотъемлемые части. Если эти приёмы вам не подходят, вы можете отказаться от них и заменить чем-то другим.
В Скраме нет проджект менеджера. И скрам мастер не может ничего "навязывать", он вообще не имеет никакой административной власти.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно. Все члены команды должны постигать Скрам и действовать в соответствии с его ценностями и подходами.
Если в компании команда разработки внедрила Скрам, а вся остальная компания работает по совершенно другим лекалам - ждите нестыковок, конфликтов и битвы мировозрений. И дело тут не в самом Скраме, он при этом может прекрасно работать.
Скрам мастер действительно может быть не нужен команде... на фултайм. Также, роль скрам мастера может выполнять кто-то из разработчиков. Это норма. Если команда зрелая и устойчиво движется по рельсам Скрама, тратить деньги на выделенного фултайм скрам мастера нет нужды. Скрам лишь запрещает отказываться от роли целиком.
"Фокус на результате, а не на процессе". Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты. В Скраме не так много сущностей. Вы справитесь меньшим количеством? Попробуйте построить эффективную разработку на основе одного только "Делай хорошо, а плохо не делай".
"Минимизация бюрократии" - от создателей "документация не нужна". К сожалению, мы не получаем кристально ясные задачи из космоса. Документация, митинги внутри команды и с заказчиками это неизбежные фиксы в нашем неидеальном мире. Если в вашей команде не умеют проводить эффективные митинги - надо учиться. Сорян.
"Поддержка долгосрочного планирования" - вашему вниманию предлагается Product Goal. Если вашей команде, работающей по Скраму, не хватает глобальных целей, пните продакт оунера. Или он ранее от тоже казался ненужным?)
Такие дела. Очень часто Скрам становится жертвой либо карго культа, когда люди слепо верят в то, что толком не понимают, либо "адаптаций", когда под вывеской Скрама внедряется кое-что и кое-как, а итоговое фиаско списывают на недостатки "этих ваших Скрамов".
При этом я ни в коем случае не называю Скрам серебряной пулей. Да, он может не подойти. Да, какой-то другой подход может сработать лучше. Всем желаю найти свой путь и добиться успеха.
Мы живём в реальном мире и, к сожалению или к радости, используют эти самые часы. Сложно продать заказчику контракт на Х стори пойтов, если ты аутсорс и работаешь по T&M контракту. Сложно доказать эйчару, что тебе в команду нужен дополнительный разработчик, потому что тебе нужно увеличить производительность на Х стори пойнтов.
Безусловно, стори пойнты рабочий инструмент. Про то, что 1 SP должен быть равен 1 часу вообще речи не идёт. И любая оценка, хоть в стори пойнтах, хоть в часах, хоть в попугаях, должна оценивать риски, сложность и т.д.
Мой вопрос вытекает из того, что по мере того, как разработка перестаёт быть "вещью в себе" и должна быть вписана в другие процессы компании, кому-то и как-то придётся делать эту "бухгалтерию".
Спасибо за развёрнутую, но не перегруженную статью. Пара вопросов от меня:
1) Правильно ли я понял, что в Тикетленде сейчас несколько команд и один коуч? Который поочерёдно работает с отдельными командами? Или же коуч делит своё время между всеми командами?
2) В начале статьи говорилось, что старая организация команд была ориентирована на приложения, а сейчас команды кросс-функциональные - а в чём разница?
3) Переводятся ли в итоге строи поинты в человекочасы? Со временем производительность команды выравнивается и по итогу X дней спринта равны Y сторипойнтам. Перейти в мир "реальных" величин кажется логичным шагом. Или же вы продолжаете использовать строи пойнты?
Надо определиться, за что отвечает тимлид? Максимизация продуктивности команды? Ресурсные вопросы комплектации команды входят в его зону ответственности? И так далее. Это поможет сфокусироваться тимлиду на тех областях, где "кто, если не он?". Вопросы по другим областям нужно подсветить ответственным и дальше решать сообща.
Кто вообще сказал, что разработчик отвечает только за свой код? Это прописано в каких-то корпоративных политиках, гайдах для разработчиков и т.д.? Это дезинтеграция. Если разработчик приходит в КОМАНДУ с мыслью "моя хата с краю", то он не приходит в КОМАНДУ. Плёвые вопросы вроде "немного неточных" тикетов разработчик мог бы прояснить сам, всё остальное он отгружает человеку, которые отвечает за "понятные тикеты". Да, возможно будут одна-две волны митинг, уточнение критериев ясности - но потом всё должно стать красиво. Если не становится - это беда и не проблема митингов, а проблема менеджмента.
Использовать ретро для разборок "кто виноват" - это ещё более дезинтегрирующая идея. Никто не любит быть виноватым и как правило люди не стремятся стать виноватыми. А для исправления непреднамеренных ошибок публичные бичевания не очень подходят. Попробуйте внедрить культуру "blameless" ретро. Оперируйте такими понятиями как "улучшения", а не "исправление ошибок". Жизнь - это то, как мы к ней относимся. Если тимлид программирует команду на разборки на ретро, ждите срачей.
Если говорить про сами созвоны, то не стоит выносить их в какую-то супер-отдельную категорию. Вот есть созвоны. А групповые чаты? А разговоры у стола коллеги? А письма? Всё это инструменты и все они должны служить благим целям. Вопрос не в самих созвонах, а в их эффективности. Приносят ли они пользу? Эта польза получается максимальной именно в такой форме? Иногда тебе не нужен созвон, вопрос можно решить в чате. А иногда переписка заходит в тупик и проще созвониться и проговорить всё голосом. Начните с манагеров, обучите их пользоваться каждым инструментом коммуникации, выбирать подходящий в зависимости от ситуации.
Наверное, вкратце ситуацию можно было бы описать таким образом. Есть симптомы, а есть заболевания. Есть баг, а есть корневая причина. Бесполезные митинги - это симптом. Будет тимлид лечить симтом или само заболевание - вот, в чём вопрос.
По ходу чтения статьи возникло два вопроса.
На первый из них автор успел ответит ещё в статье в лайфхаке номер 3 - за это спасибо. Кмк, использование "прокси" ИБ архитекторов будет весьма и весьма оправдано. Особенно, если у продуктов уже есть ИТ архитекторы - как будто в их стек компетенций некоторый уровень ИБ архитекторы ложится очень удачно. Когда разработка выходит на плато и нет такого, что каждую неделю к продукту приделывают новый костыль, задачи становятся типовыми. А к типовым задачам можно применять типовые решения. Тогда и ИБ архитектора можно привлекать реже, ведь такие вопросы закроет и его "прокси".
Второй вопрос остался актуальным. В статье говорится о том, что надо очерчивать зоны ответственности и стараться вписать активности безопасной разработки в существующий продуктовый флоу. На практике часто возникает дилемма, мол, безопасники - они просто рекомендуют или согласовывают/запрещают? Вот видит ИБ архитектор критичный риск, а его фикс может быть сложным/дорогим и владелец продукта не готов заносить его в бэклог. Как быть? Ладно, с критами ещё может быть попроще, но как быть с менее судьбоносными задачами?
Опять же, на практике у вас могут быть процессы, роли и общее согласие по применению концепции безопасной разработке. Но в моменте бизнес часто использует аргумент "мы зарабатываем бабки, значит мы правы". Что в таком случае делать ИБ архитектору? Имеет ли он право вето? Исходя из опыта автора.
Ничего себе локализация! Заменить облачный офисный пакет Майкрософт и антивирус!
(нет, это не впечатляет)
Хотелось бы узнать, если ли ещё менеджеры в команде кроме автора? Как будто в статье добавлены функции за пределом роли чистого продакта. Можно предположить,что менеджера проекта или некого коуча больше нет?
Ещё я не особо понял, зачем в команде, которой доверяешь и которая обладает экспертизой, обладать пониманием архитектуры и т.п., чтобы выполнять роль фасилитатор. Фасилитация - это в целом опосредованная от темы обсуждения вещь. Хотя суровые разработчики сейчас могут прибежать в комменты и рассказать, что не будут считать за человека и признавать менеджером любого, что не отпахал на их стеке минимум десятку лет)
Кмк на базе одного хаоса построили другой хаос. Если он работает, то ок, это победа. Значит ли это, что "традиционный Agile" не работает? Нет.
Команда всё равно пришла к релизам по плану, оценке и приоритезации задач. Кто-то выполняет функции продакта, кто-то поддерживает прозрачную коммуникацию. Планировать релиз на основе мощности QA? Так это чистый лимит WIP из Канбана.
Автор правильно называет такой подход "конструктором". Команда взяла какие-то отдельные элементы и некоторым образом "адаптировала" их. Почему это "победа" над "неработающими" Agile методологиями? Потому что так говорить круче/приятнее, чем "мы не умеем в Scrum/Kanban/XP и т.д., но пытаемся".
Но есть момент, на который я хочу обратить внимание автора. Допустим вы купили шкаф в IKEA и он приехал естественно в разобраном виде. Вы можете собрать из него самые разные штуки. Даже скворечник. Но это штука задумана как шкаф и проще всего её собрать как шкаф, и лучше всего она вам будет служить как шкаф. Вам нужно где-то хранить вещи, вы знаете это. Вы можете положить вещи стопкой на нераспакованную коробку со шкафом. Можете собрать каркас, но не вставлять внутрь полки, а просто сложить вещи одной высокой стопкой. А можете собрать его должным образом и хранить свои вещи удобно и эстетично.
На какой стадии сборки шкафа находится команда на данный момент?
Я что-то запутался. Почему вы убеждены, что всем нужны слёзы? И почему вы считаете, что раз всем нужны слёзы, даже неискренние слёзы - это эмпатия?
Это выглядит как очень грубое упрощение. Человек грустит - грусти с ним. Человек радуется - радуйся с ним. Но это не эмпатия, это мимикрия. Чистый рефлекс.
Мне импонирует определение эмпатии от Маршалла Розенберга:
эмпатия это уважительное понимание того, что переживают другие, это опустошение ума и слушание всем своим существом.
Эмпатичный человек не ориентирован на то, чтобы отгрузить собеседнику свои эмоции в ответ. И тем более он не навязывает советы, оценки или личный опыт в ответ на проявление эмоций собеседником. Эмпатия это про умение слушать и помогать собеседнику выражать свои эмоции и переживания. А ещё про "понимание", а не переживание своих эмоций.
Не соглашусь. Утверждение, что эмпатия это эмоциональная реакция, смещает фокус со способности воспринимать собеседника на внутреннее (эмоциональное) состояние эмпата. Это нас довольно быстро приведёт к тому, что, условно, более эмпатичным мы будем считать того человека, который слушает грустную историю со слезами на глазах, а не того, что не проявляет таких ярких эмоций.
Искусственный интеллект, перелогинься, мы тебя узнали.
Сразу скажу, что QA не являюсь и богатого опыта самостоятельной оценки затрат времени на тестирование не имею. Возможно из-за этого вопросы и возник)
А можно хотя бы грубо раскладку по часам? Что сколько времени заняло? Тут грубо говоря получилось, что один-единственный тестировщик затащил разработку мобильного приложения с нуля (ну ок, при готовых требованиях) за три месяца, работая на 0.2 ставки 0_о
Вроде начинали за здравие, а в итоге... Просто перечисление практик и артефактов ITIL? С минимумов примеров реализации(
Немного подушню: сторипоинты - это не часть Скрама. И соглашусь: однажны абстрактные оценки должны соотнестись с реальными трудозатратами.
И вот эти два момента часто приводят к ситуации, когда люди теряют веру в Скрам да и в Аджайл в целом. На самом деле вы можете использовать голую астракцию или трекать всё до каждой минуты. Важно найти такой способ, который подходит вам и приближает вас к цели.
Сами сторипоинты к этому моменту тоже сильно искажены. Как уже отмечено выше, "замешивание" в оценку в сторипоинтах времени полностью рушит концепцию. В целом, то, что автор описывает в статье как своё достижение, это убийство сторипоинтов.
Что делать? Опять же, сказано выше: перестать называть свою оценку сторипоинтами. Отделить оценку реальных трудозатрат от оценки... эм... инженерной сложности задачи.
Зачем это делать? И вновь, сказано выше: сторипоинты помогают с оценкой в условиях высокой неопределённости. Даже опытная команда на стабильном проекте может ВНЕЗАПНО получить от заказчика такой фича-реквест, что всем дружно придётся чесать затылок. И тут поможет абстракция. Потом уже декомпозированные задачи можно будет оценить ещё раз, в реальных трудозатратах будь то фокус-часы или ещё что.
Я нигде не утверждал, что чистый Скрам работает и я знаю такие команды.
Я утверждаю, что вы делаете вывод "Скрам не работает" на основе ложных посылок.
Более того, что случится, если я назову команду, где чистый Скрам работает? Вы уверуете и удалите эту статью?
Меня привлекла аргументация "Почему Скрам не работает". Собственно, разбору этих аргументов и посвящены мои комментарии. Не более того.
Это не какой-то конкретный монстр. У каждого этот монстр свой.
Как видится мне, основная проблема во внедрении Скрама заключается в изначальном желании "адаптировать" Скрам, а не инициировать изменения в компании.
В итоге компания, которая недовольна текущей орагнизацией работы, протаскивает эту неэффективность в свою "адаптацию" Скрама.
Авторы Скрама - хитрые и в то же время логичные жуки. Они не принимают на себя ответственность ни за какие адаптации и "на практике". С одной стороны, Скрам существует не в вакууме, нам нужно как-то вписывать его в реальную картину мира. С другой, как авторы могут предугадать всё разнообразие вариантов внедрения и ещё принимать ответственность за то, как и что мы подкрутим?
Поэтому, подчеркну ещё раз, чаще всего получается как в анекдоте: «Вот все говорят: «Карузо! Карузо!» А я послушал – так ничего особенного» – «Вы слышали Карузо?!» – «Нет. Мне Рабинович напел».
Заголовок статьи гласит "Реквием по SCRUM". Если смыть налёт кликбейта, то останется "Реквием по нашей адаптации SCRUM".
Тезисами и по делу:
Скрам не методология.
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
"Скрам с некоторыми адаптациями" - это не Скрам.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме, это не его неотъемлемые части. Если эти приёмы вам не подходят, вы можете отказаться от них и заменить чем-то другим.
В Скраме нет проджект менеджера. И скрам мастер не может ничего "навязывать", он вообще не имеет никакой административной власти.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно. Все члены команды должны постигать Скрам и действовать в соответствии с его ценностями и подходами.
Если в компании команда разработки внедрила Скрам, а вся остальная компания работает по совершенно другим лекалам - ждите нестыковок, конфликтов и битвы мировозрений. И дело тут не в самом Скраме, он при этом может прекрасно работать.
Скрам мастер действительно может быть не нужен команде... на фултайм. Также, роль скрам мастера может выполнять кто-то из разработчиков. Это норма. Если команда зрелая и устойчиво движется по рельсам Скрама, тратить деньги на выделенного фултайм скрам мастера нет нужды. Скрам лишь запрещает отказываться от роли целиком.
"Фокус на результате, а не на процессе". Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты. В Скраме не так много сущностей. Вы справитесь меньшим количеством? Попробуйте построить эффективную разработку на основе одного только "Делай хорошо, а плохо не делай".
"Минимизация бюрократии" - от создателей "документация не нужна". К сожалению, мы не получаем кристально ясные задачи из космоса. Документация, митинги внутри команды и с заказчиками это неизбежные фиксы в нашем неидеальном мире. Если в вашей команде не умеют проводить эффективные митинги - надо учиться. Сорян.
"Поддержка долгосрочного планирования" - вашему вниманию предлагается Product Goal. Если вашей команде, работающей по Скраму, не хватает глобальных целей, пните продакт оунера. Или он ранее от тоже казался ненужным?)
Такие дела. Очень часто Скрам становится жертвой либо карго культа, когда люди слепо верят в то, что толком не понимают, либо "адаптаций", когда под вывеской Скрама внедряется кое-что и кое-как, а итоговое фиаско списывают на недостатки "этих ваших Скрамов".
При этом я ни в коем случае не называю Скрам серебряной пулей. Да, он может не подойти. Да, какой-то другой подход может сработать лучше. Всем желаю найти свой путь и добиться успеха.
Обнял.
По третьему пункту.
Мы живём в реальном мире и, к сожалению или к радости, используют эти самые часы. Сложно продать заказчику контракт на Х стори пойтов, если ты аутсорс и работаешь по T&M контракту. Сложно доказать эйчару, что тебе в команду нужен дополнительный разработчик, потому что тебе нужно увеличить производительность на Х стори пойнтов.
Безусловно, стори пойнты рабочий инструмент. Про то, что 1 SP должен быть равен 1 часу вообще речи не идёт. И любая оценка, хоть в стори пойнтах, хоть в часах, хоть в попугаях, должна оценивать риски, сложность и т.д.
Мой вопрос вытекает из того, что по мере того, как разработка перестаёт быть "вещью в себе" и должна быть вписана в другие процессы компании, кому-то и как-то придётся делать эту "бухгалтерию".
Спасибо за развёрнутую, но не перегруженную статью. Пара вопросов от меня:
1) Правильно ли я понял, что в Тикетленде сейчас несколько команд и один коуч? Который поочерёдно работает с отдельными командами? Или же коуч делит своё время между всеми командами?
2) В начале статьи говорилось, что старая организация команд была ориентирована на приложения, а сейчас команды кросс-функциональные - а в чём разница?
3) Переводятся ли в итоге строи поинты в человекочасы? Со временем производительность команды выравнивается и по итогу X дней спринта равны Y сторипойнтам. Перейти в мир "реальных" величин кажется логичным шагом. Или же вы продолжаете использовать строи пойнты?
Давайте по порядку.
Надо определиться, за что отвечает тимлид? Максимизация продуктивности команды? Ресурсные вопросы комплектации команды входят в его зону ответственности? И так далее. Это поможет сфокусироваться тимлиду на тех областях, где "кто, если не он?". Вопросы по другим областям нужно подсветить ответственным и дальше решать сообща.
Кто вообще сказал, что разработчик отвечает только за свой код? Это прописано в каких-то корпоративных политиках, гайдах для разработчиков и т.д.? Это дезинтеграция. Если разработчик приходит в КОМАНДУ с мыслью "моя хата с краю", то он не приходит в КОМАНДУ. Плёвые вопросы вроде "немного неточных" тикетов разработчик мог бы прояснить сам, всё остальное он отгружает человеку, которые отвечает за "понятные тикеты". Да, возможно будут одна-две волны митинг, уточнение критериев ясности - но потом всё должно стать красиво. Если не становится - это беда и не проблема митингов, а проблема менеджмента.
Использовать ретро для разборок "кто виноват" - это ещё более дезинтегрирующая идея. Никто не любит быть виноватым и как правило люди не стремятся стать виноватыми. А для исправления непреднамеренных ошибок публичные бичевания не очень подходят. Попробуйте внедрить культуру "blameless" ретро. Оперируйте такими понятиями как "улучшения", а не "исправление ошибок". Жизнь - это то, как мы к ней относимся. Если тимлид программирует команду на разборки на ретро, ждите срачей.
Если говорить про сами созвоны, то не стоит выносить их в какую-то супер-отдельную категорию. Вот есть созвоны. А групповые чаты? А разговоры у стола коллеги? А письма? Всё это инструменты и все они должны служить благим целям. Вопрос не в самих созвонах, а в их эффективности. Приносят ли они пользу? Эта польза получается максимальной именно в такой форме? Иногда тебе не нужен созвон, вопрос можно решить в чате. А иногда переписка заходит в тупик и проще созвониться и проговорить всё голосом. Начните с манагеров, обучите их пользоваться каждым инструментом коммуникации, выбирать подходящий в зависимости от ситуации.
Наверное, вкратце ситуацию можно было бы описать таким образом. Есть симптомы, а есть заболевания. Есть баг, а есть корневая причина. Бесполезные митинги - это симптом. Будет тимлид лечить симтом или само заболевание - вот, в чём вопрос.
Тезис о прогрессивной экономике поверх фотографии Минска - это та ещё ирония)
Ещё раз. Скрам эту метрику не включал. Велосити - не часть скрама. Тчк.