Why Does Scrum Make Programmers HATE Coding?

Summary

Множество разработчиков испытывают разочарование от применения Scrum, когда процесс используется неправильно. В видео обсуждаются основные проблемы, такие как вмешательство владельца продукта в ежедневные встречи, неправильное использование очков сложности как оценки времени, отсутствие критериев приемки и недооценка важности технических задач. Автор предлагает 7 практических шагов для улучшения процесса, включая сохранение Scrum как инструмента для командной работы, а не для микроуправления, и создание четких ожиданий в отношении задач. Эти изменения помогут восстановить доверие и любовь к Scrum, улучшив качество работы и коммуникацию в команде.

Takeaways

• 😀 Программисты ненавидят Scrum, когда владелец продукта присутствует на ежедневных стендапах, что превращает их в статусные встречи, а не в место для прозрачности и честности.
• 😀 Скрам-мастер не должен вмешиваться в технические решения команды, так как это не его роль. Его задача — помогать команде в рамках Scrum, а не разрабатывать продукт.
• 😀 В Scrum важно учитывать не только функциональные задачи, но и задачи по качеству, автоматизированному тестированию и архитектуре, чтобы продукт был устойчивым и масштабируемым.
• 😀 Преобразование story points в часы или дни — это ошибка, которая нарушает принципы Scrum и возвращает команду к жестким срокам и предсказуемости Waterfall.
• 😀 Когда Sprint не может быть завершен из-за неопределенности или новых требований, Sprint должен быть отменен и пересмотрен, а не продолжаться без учета реальных возможностей команды.
• 😀 Без четких критериев приемки для пользовательских историй сложно оценить выполнение задач и достичь целей спринта. Неопределенность ведет к срыву сроков и потере продуктивности.
• 😀 Использование графика burn-down как показателя эффективности отдельных сотрудников снижает мораль команды и противоречит духу Scrum.
• 😀 Чтобы полюбить Scrum снова, важно исключить владельца продукта из ежедневных стендапов и ограничить его участие только до обзора результатов спринта.
• 😀 Скрам-мастер не должен вмешиваться в технические решения и предлагать изменения в коде или процессе. Это нарушает автономию разработчиков.
• 😀 Разработчики должны всегда закладывать дополнительное время для инфраструктуры, тестирования и автоматизации, чтобы сохранить высокое качество кода и непрерывность доставки.
• 😀 Важно не планировать несколько спринтов вперед и не использовать предсказания на основе предыдущих показателей. Scrum должен ориентироваться только на текущий спринт и реальные возможности команды.

Q & A

Почему разработчики ненавидят Scrum?

Основные причины — это вмешательство владельца продукта в ежедневные стендапы, когда скрам-мастер вмешивается в технические решения, фокус на функциональности, а не на важной инфраструктуре, преобразование story points в часы, отсутствие критериев приемки, использование диаграмм сгорания как метрики производительности, и отказ отменить спринт, если цель спринта под угрозой.

Что говорит Scrum Guide о роли владельца продукта в ежедневных стендапах?

Согласно Scrum Guide, владелец продукта не должен присутствовать на ежедневных стендапах, если он не является разработчиком, работающим непосредственно над проектом.

Какую роль должен выполнять скрам-мастер в проекте?

Скрам-мастер должен фокусироваться на содействии Scrum процессу и поддержке команды в выполнении Scrum, а не вмешиваться в технические решения и разработку программного обеспечения.

Что происходит, когда компания фокусируется только на функциональности, игнорируя инфраструктуру и тестирование?

Игнорирование инфраструктуры, тестирования и других важных аспектов приводит к накоплению технического долга и снижению качества программного обеспечения, что делает проект более уязвимым к проблемам в будущем.

Почему преобразование story points в часы является неправильным подходом?

Story points измеряют сложность задач, а не время. Если их преобразовывать в часы, это превращает Scrum в водопадную модель и разрушает гибкость и предсказуемость, которые предполагает Scrum.

Что следует делать, если цель спринта под угрозой?

Если цель спринта под угрозой, спринт следует отменить, и начать новое планирование с реальной, достижимой целью, а не пытаться закончить все задачи, чтобы просто соблюсти сроки.

Почему важно иметь чёткие критерии приемки для каждой истории пользователя?

Чёткие критерии приемки позволяют точно определить, что будет считаться завершённой задачей, исключая неопределенности и помогая разработчикам точно оценивать работу и соблюдать сроки спринта.

Что такое диаграмма сгорания и как её правильно использовать?

Диаграмма сгорания отображает прогресс команды по выполнению задач в спринте. Она должна использоваться для отслеживания выполнения работы, а не как метрика производительности сотрудников. Делать её доступной для высшего руководства может привести к неправильной интерпретации данных.

Что нужно сделать, чтобы начать любить Scrum снова?

Некоторые способы вернуть любовь к Scrum: держать владельца продукта вне ежедневных стендапов, не разрешать скрам-мастерам вмешиваться в технические решения, выделять время на тестирование и инфраструктуру, не делать долгосрочные прогнозы, и гарантировать, что у всех историй пользователей есть чёткие критерии приемки.

Почему важно не начинать работу в спринте без 100% принятия критериев для всех историй пользователей?

Без ясных критериев приемки разработчики не смогут точно оценить работу и это приведёт к растущему объему неопределённости и трудностей при выполнении задач, что сделает выполнение цели спринта невозможным.