Спасибо за ответ. Правда, выглядит он скорее как хорошая выдача нейросети по запросу “современные метрики в Agile” :) Жаль, что за теорией про DORA и SPACE ответа на мой изначальный вопрос так и не нашлось. Я ведь спрашивал не про то, какие метрики вообще бывают, а как вы лично на практике решали эту проблему. Видимо, реальным кейсом поделиться не выйдет.
В любом случае, картина окончательно ясна. Спасибо за уделенное время, вопросов больше не имею!
Спасибо за развернутый ответ! Вы совершенно правы, что самое сложное — это люди и сопротивление изменениям.
Вы спросили, какая реальность и что болит. Реальность как раз такая: есть процесс, в котором под предлогом адаптации постепенно “отвалились” оценка задач (команды не эстимируют) и общие демо.
Основная боль — бизнес начинает сомневаться в эффективности разработки, так как теряется прозрачность, а инженерам не хватает понимания ценности продукта, потому что они не видят итоговый инкремент.
Раз уж вы предложили прикинуть, с чего бы начали вы: как возвращать прозрачность и измерять эффективность в таких условиях? Как бы вы аргументировали бизнесу, что разработка работает хорошо, если нет классических метрик вроде burn-down, а результатами нельзя поделиться на демо? Проще говоря, какие бы метрики вы использовали?
Статья интересная теоретически, но хочется немного "приземлить" её на суровую реальность. Вы много говорите про масштабирование и сложные подходы.
Подскажите, а по каким метрикам вы оценивали реальную эффективность своей работы и работы команд при внедрении всех этих подходов? Если представить ситуацию, что команда не может оценить сложность задач (так как нет планирования/покера) и нет регулярной демонстрации инкремента бизнесу, как вы доказываете стейкхолдерам, что разработка эффективна и вы не жжете бюджет впустую? Были ли в вашей недавней практике случаи, когда выстроенный вами процесс признавался бизнесом неэффективным, и как вы с этим работали?
Да, я действительно для себя все решил. Принимайте комплимент.
Спасибо за ответ. Правда, выглядит он скорее как хорошая выдача нейросети по запросу “современные метрики в Agile” :) Жаль, что за теорией про DORA и SPACE ответа на мой изначальный вопрос так и не нашлось. Я ведь спрашивал не про то, какие метрики вообще бывают, а как вы лично на практике решали эту проблему. Видимо, реальным кейсом поделиться не выйдет.
В любом случае, картина окончательно ясна. Спасибо за уделенное время, вопросов больше не имею!
Спасибо за развернутый ответ! Вы совершенно правы, что самое сложное — это люди и сопротивление изменениям.
Вы спросили, какая реальность и что болит. Реальность как раз такая: есть процесс, в котором под предлогом адаптации постепенно “отвалились” оценка задач (команды не эстимируют) и общие демо.
Основная боль — бизнес начинает сомневаться в эффективности разработки, так как теряется прозрачность, а инженерам не хватает понимания ценности продукта, потому что они не видят итоговый инкремент.
Раз уж вы предложили прикинуть, с чего бы начали вы: как возвращать прозрачность и измерять эффективность в таких условиях? Как бы вы аргументировали бизнесу, что разработка работает хорошо, если нет классических метрик вроде burn-down, а результатами нельзя поделиться на демо? Проще говоря, какие бы метрики вы использовали?
Статья интересная теоретически, но хочется немного "приземлить" её на суровую реальность. Вы много говорите про масштабирование и сложные подходы.
Подскажите, а по каким метрикам вы оценивали реальную эффективность своей работы и работы команд при внедрении всех этих подходов? Если представить ситуацию, что команда не может оценить сложность задач (так как нет планирования/покера) и нет регулярной демонстрации инкремента бизнесу, как вы доказываете стейкхолдерам, что разработка эффективна и вы не жжете бюджет впустую? Были ли в вашей недавней практике случаи, когда выстроенный вами процесс признавался бизнесом неэффективным, и как вы с этим работали?