1С проекты и SCRUM: как было, и что стало после внедрения фреймворка

В данной статье мы расскажем о том,

• почему решили использовать фреймворк Scrum в разработке программных продуктов,
  

• какие отмечаем изменения в рабочем процессе.

Наша компания занимается комплексной автоматизацией предприятий на основе продуктов 1С и собственных решений с 2001 года. В последнее время мы пришли к необходимости использования гибкой методологии разработки. В этой статье мы поделимся своими впечатлениями от работы в фреймворке SCRUM.

Как было

Большую часть проектов в прошлом мы реализовывали с помощью каскадной методологии. Последовательное прохождение этапов разработки для нас привычно и понятно. Но с 2020 года мир стал другим. События развиваются стремительно, непредсказуемо. Все меняется очень быстро. Столь же быстро бизнесу необходимо реагировать на изменения. Те задачи, которые ставятся на входе в проект и включены в ТЗ, через шесть месяцев могут утратить свою актуальность. Следовательно, для заказчика ценность результатов проекта может снизиться.

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

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

Еще одна исторически сложившаяся особенность в 1С:Франчайзи – это система мотивации сотрудников от «выработки часов», пусть даже «эффективных». На выполнение задачи обычно выделяется определенное количество часов. И у некоторых разработчиков, чья оплата труда привязана к часам, нет стремления решать эти задачи быстрее и качественнее.

Как стало

Для повышения гибкости, эффективности в работе мы решили использовать фреймворк Scrum.

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

Повысилась вовлеченность сотрудников. Она проявляется на всех SCRUM «церемониях»: совещаниях планирования спринта, на ежедневных стэндапах, на демонстрациях инкремента заказчику и в ходе ретроспектив. Каждый чувствует свой вклад в общее дело. Повысилась заинтересованность. В Scrum разработчики сами отвечают за тот продукт, который создают. Не за отдельную задачу, а за весь продукт. Поэтому они заинтересованы в том, чтобы весь продукт работал. Разработчик видит, что он выполнил, а чего не хватает. И если не хватает, то он сам ставит себе задачу на дальнейшую разработку. В Scrum больше возможностей для проявления инициативы.

SCRUM – это командная работа. Команды самоорганизуются, саморазвиваются. Их не нужно контролировать, не нужно указывать, что делать. Они сами определяют проблемы и генерируют идеи, как их решить.

Члены команды несут ответственность друг за друга и за результат в целом. Здесь не бывает так, что кто-то один сделал работу плохо, поэтому провалили спринт. Если спринт провален, значит, все не справились. На ретроспективах не кто-то извне, а сама команда отвечает на вопросы, что было сделано плохо, как это улучшить, и когда это будет улучшено. Причем этой командной работе присуща открытость. Если у членов команды есть вопросы друг к другу, например, кому-то кажется, что другие в меньшей степени погружены в проект, то все эти вопросы выносятся на открытое обсуждение.

Благодаря самоорганизации и командной работе задачи выполняются более эффективно. Они могут поэтапно переходить от одного разработчика к другому, и каждый будет выполнять свою часть работы. Возможно, ту часть, которая ему наиболее интересна, где у него больше наработок и компетенций. Таким образом, одна задача может решаться разными разработчиками для достижения наилучшего общего результата.

Да, SCRUM - это работа на результат. Есть срок, в течение которого необходимо его выдать. И оплата зависит только от результата, а не от количества часов, которые потрачены на выполнение задачи.

Бывает, что возникают технические сложности, которые не удается быстро решить. Поначалу из-за этого запланированные задачи накладывались друг на друга и в ходе спринта не выполнялись. Сейчас команды разработчиков действуют иначе. Если выполнение какой-то задачи затягивается, ее обсуждает Development team. Если совместное обсуждение не помогает, мы выносим ее за рамки спринта – на обсуждение Scrum команды с участием Product Owner в ходе демонстрации. В рамках завершенного спринта задача приостанавливается либо отменяется. Создается новая задача с расширенными требованиями, описанием, функционалом и подзадачами, которая планируется на следующий спринт.

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