Что делать, если Scrum не работает?

Работайте со мной → https://healthydeveloper.com/ Каждый программист, кажется, испытывает тошноту, как только слышит слово «Scrum». Что же такого в Scrum, что заставляет программистов так ненавидеть программирование, и как этого избежать в вашей команде разработчиков программного обеспечения? В этом эпизоде ​​я расскажу о 7 причинах, по которым программисты ненавидят Scrum, и о том, как он делает нашу работу практически невыполнимой в проектах по разработке программного обеспечения, где Scrum-мастер, владелец продукта (или менеджер продукта) и остальная часть компании используют его для издевательств над программистами. В основном это связано с непониманием руководства по Scrum и человеческой природой! В первой части видео я объясняю, как руководство в проектах Scrum обычно фокусируется на скорости и видимых функциях до такой степени, что это ставит под угрозу качество продукта. Они относятся к читательским записям как к времени. Они сопротивляются инвестициям в такие вещи, как улучшенная архитектура, тестирование, развертывание и другие вещи, необходимые для того, чтобы разработчики не увольнялись, если их не контролировать. И они не принимают реальность, когда плохие пользовательские истории, отсутствие критериев приемки и злоупотребление диаграммой сгорания задач (и метриками скорости) превращают Scrum в игру чисел, а не в создание качественного программного продукта. Во второй части видео я делюсь 7 практическими советами о том, как изменить свою команду разработчиков, чтобы снова полюбить Scrum! Если программисты в вашей команде ненавидят Scrum, крайне важно четко разграничить, по каким вопросам могут и не могут принимать решения разработчики программного обеспечения и менеджеры проектов, менеджеры по продуктам, владельцы продуктов или Scrum-мастера. Но как программисты, мы также должны быть более внимательными к тому, как мы следуем процессам Scrum. Нам нужно тщательно проверять работу и двигаться вперед только при 100% выполнении критериев приемки. Мы не можем брать на себя обязательства по расплывчатым пользовательским историям. И мы должны перестать оценивать только время на программирование и включить время на все, что нам действительно нужно — контроль качества, автоматизированное тестирование, автоматизированное развертывание, инфраструктура как код, архитектура программного обеспечения — в общем, все то, что помогает проекту оставаться на правильном пути по мере его усложнения. Вот как современные команды внедряют непрерывную доставку и DevOps. Надеюсь, это видео даст вам пищу для размышлений. Scrum — сложная тема, но следование всему в точности по руководству Scrum — скользкая дорожка. Чтобы снова полюбить Scrum, программистам нужно работать с руководством и остальной частью компании, чтобы адаптировать процессы к тому, как все должны работать вместе для создания программного обеспечения. И это индивидуально для каждой команды! #scrum #programming #coding СВЯЗАННЫЙ КОНТЕНТ Ежедневное совещание Scrum: замаскированное совещание по статусу проекта?    • Daily Scrum Meeting: A Status Meeting In D...   Как старшие программисты НА САМОМ ДЕЛЕ пишут код    • How Senior Programmers ACTUALLY Write Code   Как распознать фальшивую Agile-команду менее чем за 7 минут!    • Spot A Fake Agile Team In Under 7 Minutes!   Могут ли пользовательские истории привести к задержке программных проектов?    • Can User Stories Make Software Projects Late?   Непрерывная доставка: не упускаете ли вы из виду главное?    • Continuous Delivery: Are You Missing The B...   МАРКЕРЫ ГЛАВ 0:00 Введение 0:36 7 причин, почему программисты ненавидят Scrum 0:58 #1 Ввод продукта на ежедневном совещании 1:36 #2 Превышение полномочий Scrum-мастера 2:15 #3 Одержимость функциями 3:38 #4 Использование пользовательских историй в качестве времени 4:42 #5 Отказ от отмены спринта 5:58 #6 Отсутствие критериев приемки 7:19 #7 Использование диаграммы сгорания задач в качестве аргумента 7:54 7 способов снова полюбить Scrum 8:16 #1 Убрать ввод продукта с ежедневного совещания 9:00 #2 Поставить Scrum-мастера на место 9:49 #3 Буферные оценки для качества кода 11:03 #4 Не брать на себя обязательства по нескольким спринтам 12:04 #5 Используйте диаграмму сгорания задач Разработчики 13:00 #6 Критерии приемки 100% 13:52 #7 Предоставляйте функции, которые радуют 15:16 Episode Groove Иконка пламени в миниатюре предоставлена ​​https://www.freeiconspng.com/img/696