Нейросети инструмент, позволяющий аналитику делать больше, в случае если у аналитика скилл промт-инженера, заменить аналитика ии сможет лишь отчасти, по крайней мере пока. Спасибо за статью.
Эм. Для этого стажировки за три копейки для джунов существуют... Как-то так. Никто в профессию с опытом не приходил, ну, кроме вчерашних фрилансеров, которые на галеры устроились после того, как сами себе работодателями трудились.
Адекватном менеджере, у которого достаточно компетенций в продукте (проекте, портфеле проектов)
Менеджере с достаточным уровне проф. эмпатии.
Наличии у менеджера хард скиллов, чтобы объяснять и доказывать что-то подчинённым, если речь о техническом вопросе (обычно уровень технических компетенций ниже).
И ещё.Признаки в таблице реакций на обратную связь крайне спорные. Причины описанных реакций могут быть очень вариативными, жестко привязывать к "принял" "не принял" , большая ошибка, которая ведёт к ненужной формализации реакций сотрудников и ошибкам в понимании фидбека от сотрудника.
Коллеги, мы в том же положении, ожидаем пока вендор (дорогой наш 1С) исправит эту ошибку. Мы будем признательны если вы проголосуете за её решение https://bugboard.1c.ru/?state=prj-plt8gen-er-70123389 / Смею надеяться, что это ускорит процесс.
В качестве шутки: "фронтендеры ждут, пока сделают бэкенд" Странное утверждение, а у вас точно Agile?) Если серьёзно, то ждут они только в случае если надо интегрировать одно с другим, т.е. в конце спринта (если речь про скрам), когда нужно выдать инкремент с готовой функциональностью, а могут и не ждать и к моменту интеграции нужные эндпоинты могут быть уже готовы. Если планирование адекватное, требования достаточно полные (однозначные, непротиворечивые ect) то так даже получается). Чаще ждут UI-дизайнеров и UX-специалиста, чтобы стартовать с вёрсткой. Что до sp, то в моей практике работало в 1-м проекте из 10, и только с феноменально скиллованным скрам-мастером (который, не кисло так, кушал ФОТ). Мой вывод - использование sp чаще приводит к необъективной оценке сроков, что выливается в недовольство заказчиков и боссов, чем к ожидаемому гибкому управлению процессами оценки, иными словами - инструмент малоэффективный в суровой действительности, при всех потенциальных достоинствах абстрагирования. Ни в коей мере не хочу умалить достоинства автора, как опытного скарм-мастера, вероятно у него получается использовать абстрактные оценки в sp, попугаях и т.п., лучше чем у меня и многих моих коллег. Однако есть ключевая и фундаментальная проблема sp, субъективность в оценке сложности, что неизбежно приводит к невозможности стандартизации процесса оценки в отдельно взятом проекте, а значит снижает его управляемость.
Да, вы правы, но возможно вы не верно поняли посыл материала. Есть порог необходимой сложности. И в промышленных системах он безусловно выше, я лишь пишу о том, что с такие системы: первое - должны быть минимально удобными в смысле структуры организации данных в интерфейсе (это не означает упрощения до уровня интернет-магазина), второе - близкими по расположению, внешнему виду элементов управления, демонстрации данных и т.п. к тому с чем оператор системы привык работать, особенно если речь о замене физических устройств интерфейсом, третье - безопасными, минимальная защита от идиота также всегда нужна - это касается визуального отражения критических ошибок, режимов, прочих ахтунгов, а также полноценной обратной связи и логирования. Остальное вариабельно и зависит от конкретных задач системы.
Т.е заново проводим груминг, спринтплэнинг, вносим в спринт уже вносившиеся задачи, занимаемся перерасчетом времени команды, вместо оптимизации текущего спринта?
Почитал о том, адепты чистого скрам считают причинами скрамбатов. Там огромное количество "истинных причин" вполне соответствуют распространённому когнитивному искажению - предвзятости подтверждения. Т.е. любую попытку модифицировать методологию под конкретные условия и отойти от догмы, объявляют следствием причины, которая существует лишь в рамках парадигмы того, что скрам в чистом виде лучший фреймворк на земле и обладает достоинствами, которых нет у других фреймворков и методологий (главное правильно молиться соблюдать ритуалы). Т.е. таки "серебряной пулей", но то, что "осиновый кол" с "чесноком" в ряде случаев работают значительно лучше и без танцев с бубнами скрам-мастера, никто не из них не пишет.
Так с адаптацией как раз всё ок (если речь конкретно о нашей). Назовите мне компанию или команду, где scrum не адаптирован и используется в точности как предписано скрамгайде?
Где-то работает, где-то не работает. Например если речь идёт о бизнесе с крупными инкрементами (нейросети, анализ больших данных, промышленное программирование) не работает. Популярность - не является критерием. Например в 19-м веке был очень популярен детский сироп от кашля с героином.
Спасибо, ценно. И красиво написано. И всё же есть несколько комментов)
Чтобы "отказаться от Скрама" надо сначала полноценно внедрить Скрам.
И это верно, но вопрос оправданы ли риски такого внедрения.
В Скраме нет проджект менеджера.
В теории, на практике эта роль существует, включена в процессы компании (команды) и почти никогда не пропадает при внедрении scrum.
Юзер стори, эпики, стори пойнты - всего этого нет в Скраме
Опять же, в Скрам Гайд не прописаны, на практике почти всегда есть. Как и покер скрам.
Перекладывать всю ответственность за "скрамность" команды на мастера - неправильно.
Тогда возникает вопрос в чем в принципе его ответственность?
Скрам лишь запрещает отказываться от роли целиком.
Очень гибко)
Любой фреймворк, любая методолгия - это процессы, ритуалы, артефакты.
Процессы и артефакты - да, ритуалы - нет. Нет необходимости возводить обыденное до уровня сакрального.) Любые процессы могут и должны адаптироваться под цели и условия бизнеса(компании, команды), они первичны, содержание определяет форму, а не наоборот. Ритуалы же фиксируют команду на форме, даже в тех случаях, когда она избыточна.
"Минимизация бюрократии" - от создателей "документация не нужна".
Таки нет. Документация нужна, но если мы про Agile, она по определению вторична, что куда-то делось в SCRUM.
Если в вашей команде не умеют проводить эффективные митинги
В моей умеют, но их эффективность оценивается в конечном итоге заказчиком продукта и пользователями, а не скрам-мастером).
Или он ранее от тоже казался ненужным?)
Напротив, очень полезный человек)
либо "адаптаций"
По моему субъективному нерепрезентативному опыту, адаптации в 90% случаев эффективнее, т.к. ближе процессам конкретного бизнеса.
При этом я ни в коем случае не называю Скрам серебряной пулей
Проблема в том, что очень многие таки считают Скрам серебряной пулей
Не готов согласиться. В малых командах он избыточнее чем в больших. Парадоксально, но успешно скрам работает в больших проектах, где много меняющихся требований. При этом на 5 команд можно нанять одного скрам мастера, а также сэкономить на внедрении процесса. Также в объёмном и длительном процессе можно увидеть и оценить изменения. Сами преимущества ощутимее в масштабе, даже если прирост скорости разработки или условного KPI отдельного сотрудника ничтожен. Большой проблемой в крупных командах является совместная оценка сложности задач, но это решаемо за счет отхода от базовых принципов и разделения команды на спринтплэннингах на субкоманды, фронты оценивают своё, бэкенд своё, девопс своё и т.д. Он не гибок по факту везде, но традиционно считается Agile-методологией.
Аутстаф сам по себе зло. "Продали" тут одного товарища в " рабоство" заказчику. По итогу недовольны все. Пока работал у нас и делал заказ для того же заказчика - всех всё устраивало. Проблема в том, что когда есть "голый" результат и деньги, которые ты за него заплатил - это совсем не то же самое, когда ты заплатил за специалиста и потом цацкаешся с ним чтобы получить этот результат.
На самом деле заметят все, так как на разработку свалится прорва работы с требованиями, да и прямая коммуникация разработчика с источниками требований скажется не лучшим образом на скорости поставки ценности.
Нейросети инструмент, позволяющий аналитику делать больше, в случае если у аналитика скилл промт-инженера, заменить аналитика ии сможет лишь отчасти, по крайней мере пока. Спасибо за статью.
Эм. Для этого стажировки за три копейки для джунов существуют... Как-то так. Никто в профессию с опытом не приходил, ну, кроме вчерашних фрилансеров, которые на галеры устроились после того, как сами себе работодателями трудились.
Это всё работает, при:
Адекватном менеджере, у которого достаточно компетенций в продукте (проекте, портфеле проектов)
Менеджере с достаточным уровне проф. эмпатии.
Наличии у менеджера хард скиллов, чтобы объяснять и доказывать что-то подчинённым, если речь о техническом вопросе (обычно уровень технических компетенций ниже).
И ещё.Признаки в таблице реакций на обратную связь крайне спорные. Причины описанных реакций могут быть очень вариативными, жестко привязывать к "принял" "не принял" , большая ошибка, которая ведёт к ненужной формализации реакций сотрудников и ошибкам в понимании фидбека от сотрудника.
В посте слишком много вредных упрощений.
Это я как практикующий PM, если что...)
Коллеги, мы в том же положении, ожидаем пока вендор (дорогой наш 1С) исправит эту ошибку.
Мы будем признательны если вы проголосуете за её решение
https://bugboard.1c.ru/?state=prj-plt8gen-er-70123389 /
Смею надеяться, что это ускорит процесс.
В качестве шутки: "фронтендеры ждут, пока сделают бэкенд" Странное утверждение, а у вас точно Agile?)
Если серьёзно, то ждут они только в случае если надо интегрировать одно с другим, т.е. в конце спринта (если речь про скрам), когда нужно выдать инкремент с готовой функциональностью, а могут и не ждать и к моменту интеграции нужные эндпоинты могут быть уже готовы. Если планирование адекватное, требования достаточно полные (однозначные, непротиворечивые ect) то так даже получается). Чаще ждут UI-дизайнеров и UX-специалиста, чтобы стартовать с вёрсткой.
Что до sp, то в моей практике работало в 1-м проекте из 10, и только с феноменально скиллованным скрам-мастером (который, не кисло так, кушал ФОТ). Мой вывод - использование sp чаще приводит к необъективной оценке сроков, что выливается в недовольство заказчиков и боссов, чем к ожидаемому гибкому управлению процессами оценки, иными словами - инструмент малоэффективный в суровой действительности, при всех потенциальных достоинствах абстрагирования. Ни в коей мере не хочу умалить достоинства автора, как опытного скарм-мастера, вероятно у него получается использовать абстрактные оценки в sp, попугаях и т.п., лучше чем у меня и многих моих коллег. Однако есть ключевая и фундаментальная проблема sp, субъективность в оценке сложности, что неизбежно приводит к невозможности стандартизации процесса оценки в отдельно взятом проекте, а значит снижает его управляемость.
Да, вы правы, но возможно вы не верно поняли посыл материала. Есть порог необходимой сложности. И в промышленных системах он безусловно выше, я лишь пишу о том, что с такие системы: первое - должны быть минимально удобными в смысле структуры организации данных в интерфейсе (это не означает упрощения до уровня интернет-магазина), второе - близкими по расположению, внешнему виду элементов управления, демонстрации данных и т.п. к тому с чем оператор системы привык работать, особенно если речь о замене физических устройств интерфейсом, третье - безопасными, минимальная защита от идиота также всегда нужна - это касается визуального отражения критических ошибок, режимов, прочих ахтунгов, а также полноценной обратной связи и логирования. Остальное вариабельно и зависит от конкретных задач системы.
Полезно, спасибо за материал!
Спасибо, судя по интересу комьюнити целевых хабов, не слишком популярная тема)
Т.е заново проводим груминг, спринтплэнинг, вносим в спринт уже вносившиеся задачи, занимаемся перерасчетом времени команды, вместо оптимизации текущего спринта?
Почитал о том, адепты чистого скрам считают причинами скрамбатов. Там огромное количество "истинных причин" вполне соответствуют распространённому когнитивному искажению - предвзятости подтверждения. Т.е. любую попытку модифицировать методологию под конкретные условия и отойти от догмы, объявляют следствием причины, которая существует лишь в рамках парадигмы того, что скрам в чистом виде лучший фреймворк на земле и обладает достоинствами, которых нет у других фреймворков и методологий (главное правильно
молитьсясоблюдать ритуалы). Т.е. таки "серебряной пулей", но то, что "осиновый кол" с "чесноком" в ряде случаев работают значительно лучше и без танцев с бубнами скрам-мастера, никто не из них не пишет.Ну в нашем случае со скилованностью заказчика были таки сложности.
Спасибо, я стремился описать именно этот скрам. Только автор статьи я, а не @ozzyBLR
Так с адаптацией как раз всё ок (если речь конкретно о нашей). Назовите мне компанию или команду, где scrum не адаптирован и используется в точности как предписано скрамгайде?
А если спринт трёхнедельный, так как поставка ценности в другие сроки невозможна?
Где-то работает, где-то не работает. Например если речь идёт о бизнесе с крупными инкрементами (нейросети, анализ больших данных, промышленное программирование) не работает.
Популярность - не является критерием. Например в 19-м веке был очень популярен детский сироп от кашля с героином.
Спасибо, ценно. И красиво написано. И всё же есть несколько комментов)
И это верно, но вопрос оправданы ли риски такого внедрения.
В теории, на практике эта роль существует, включена в процессы компании (команды) и почти никогда не пропадает при внедрении scrum.
Опять же, в Скрам Гайд не прописаны, на практике почти всегда есть. Как и покер скрам.
Тогда возникает вопрос в чем в принципе его ответственность?
Очень гибко)
Процессы и артефакты - да, ритуалы - нет. Нет необходимости возводить обыденное до уровня сакрального.) Любые процессы могут и должны адаптироваться под цели и условия бизнеса(компании, команды), они первичны, содержание определяет форму, а не наоборот. Ритуалы же фиксируют команду на форме, даже в тех случаях, когда она избыточна.
Таки нет. Документация нужна, но если мы про Agile, она по определению вторична, что куда-то делось в SCRUM.
В моей умеют, но их эффективность оценивается в конечном итоге заказчиком продукта и пользователями, а не скрам-мастером).
Напротив, очень полезный человек)
По моему субъективному нерепрезентативному опыту, адаптации в 90% случаев эффективнее, т.к. ближе процессам конкретного бизнеса.
Проблема в том, что очень многие таки считают Скрам серебряной пулей
Искренне рад, что вы нашли свой путь. Обнял.
Не готов согласиться. В малых командах он избыточнее чем в больших. Парадоксально, но успешно скрам работает в больших проектах, где много меняющихся требований. При этом на 5 команд можно нанять одного скрам мастера, а также сэкономить на внедрении процесса. Также в объёмном и длительном процессе можно увидеть и оценить изменения. Сами преимущества ощутимее в масштабе, даже если прирост скорости разработки или условного KPI отдельного сотрудника ничтожен. Большой проблемой в крупных командах является совместная оценка сложности задач, но это решаемо за счет отхода от базовых принципов и разделения команды на спринтплэннингах на субкоманды, фронты оценивают своё, бэкенд своё, девопс своё и т.д. Он не гибок по факту везде, но традиционно считается Agile-методологией.
Аутстаф сам по себе зло. "Продали" тут одного товарища в " рабоство" заказчику. По итогу недовольны все. Пока работал у нас и делал заказ для того же заказчика - всех всё устраивало. Проблема в том, что когда есть "голый" результат и деньги, которые ты за него заплатил - это совсем не то же самое, когда ты заплатил за специалиста и потом цацкаешся с ним чтобы получить этот результат.
Гибриды - топ, чистый скрам - зло, дно и мрак.
На самом деле заметят все, так как на разработку свалится прорва работы с требованиями, да и прямая коммуникация разработчика с источниками требований скажется не лучшим образом на скорости поставки ценности.