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