Большинство компаний следуют какому-то типу процесса Scrum. Обычно это включает спринты продолжительностью 2 или 3 недели. В конце каждого спринта изменения демонстрируются, проводятся ретроспективы и выполняется уход за бэклогом. Во время каждого спринта фиксируется время выполнения задач, что позволяет руководству прогнозировать, когда проекты будут завершены.
Во многих проектах Scrum, в которых я участвовал, подчеркивается “обязательство” перед задачами или “принятие ответственности”. В конце спринта многие инженеры несут ответственность за незавершенные задачи. Скорость спринта — еще одна идея, которая постоянно повторяется. Мы должны сохранять нашу скорость! Это как если бы создание программного обеспечения было гонкой, но это не так. Если инженеры несут ответственность по метрике, они будут оптимизировать под эту метрику, а это не то, что вам нужно.
Scrum создает легко понимаемую структуру для команд и дает руководству инструменты для прогнозирования будущего. Команды, которые практиковали водопадный метод, легко воспринимают Scrum.
Многие практики Scrum не нужны. Например, большинство программ отслеживания проблем позволяют менеджерам запускать отчеты о частоте завершения тикетов. Имея эту информацию, менеджеры могут вывести скорость, вместо того чтобы встраивать скорость в процесс и делать из нее большое дело. Принятие ответственности — это фарс, мы делаем это естественно, делать это явным — оскорбительно. Во всех проектах, в которых я участвовал, каждый инженер имел свой уголок приложения.
Другие способы улучшить доставку программного обеспечения:
- Если вам нужны еженедельные развертывания, запланируйте их. Развертывайте то, что готово.
- Поддерживайте бэклог в порядке; тогда инженеры никогда не останутся без работы.
- На мой взгляд, ретроспективы — это наиболее важный вид деятельности, не связанный с разработкой. Без них у вас нет шанса стать более эффективной организацией.
- Автоматизируйте, автоматизируйте, автоматизируйте
- Обязательство перед списком функций — это абсурд. Ранжируйте задачи и выполняйте то, что можете. Беспокойство о том, почему “задача A” не была выполнена, — это пустая трата времени. Ясно, что задача была либо слишком большой, либо была взята более приоритетная работа.
- Демонстрации — пустая трата времени, если только клиент не заинтересован и не предоставляет обратную связь.
- Ежедневные встречи могут быть нужны, а могут и не быть. Я предпочитаю встречаться раз в пару дней.
В конце концов, речь идет о предоставлении ценности клиенту наиболее эффективным способом.
Автор: Chuck Conway — инженер AI с почти 30-летним опытом разработки программного обеспечения. Он создает практические системы AI — конвейеры контента, агенты инфраструктуры и инструменты, которые решают реальные проблемы — и делится тем, что он узнает на этом пути. Свяжитесь с ним в социальных сетях: X (@chuckconway) или посетите его на YouTube и на SubStack.