1С проекты и SCRUM: как было, и что стало после внедрения фреймворка
В данной статье мы расскажем о том,
-
почему решили использовать фреймворк Scrum в разработке программных продуктов,
-
какие отмечаем изменения в рабочем процессе.
Наша компания занимается комплексной автоматизацией предприятий на основе продуктов 1С и собственных решений с 2001 года. В последнее время мы пришли к необходимости использования гибкой методологии разработки. В этой статье мы поделимся своими впечатлениями от работы в фреймворке SCRUM.
Как было
Большую часть проектов в прошлом мы реализовывали с помощью каскадной методологии. Последовательное прохождение этапов разработки для нас привычно и понятно. Но с 2020 года мир стал другим. События развиваются стремительно, непредсказуемо. Все меняется очень быстро. Столь же быстро бизнесу необходимо реагировать на изменения. Те задачи, которые ставятся на входе в проект и включены в ТЗ, через шесть месяцев могут утратить свою актуальность. Следовательно, для заказчика ценность результатов проекта может снизиться.
Единственный способ этого избежать - подведение промежуточных итогов по ходу исполнения проекта, демонстрация результатов заказчику, быстрое внесение в них исправлений и корректировка задач.
Вдобавок слабое командное взаимодействие или, точнее, исключительно индивидуальная ответственность могут приводить к тому, что отдельные задачи в рамках проекта выполнены, а в общем необходимый функционал не работает. Суть - в том, что раньше перед разработчиками ставил задачу руководитель рабочей группы проекта. Он распределял задачи, и он же контролировал их исполнение. Соответственно, каждый разработчик нес ответственность только за конкретную задачу в рамках технического задания.
Еще одна исторически сложившаяся особенность в 1С:Франчайзи – это система мотивации сотрудников от «выработки часов», пусть даже «эффективных». На выполнение задачи обычно выделяется определенное количество часов. И у некоторых разработчиков, чья оплата труда привязана к часам, нет стремления решать эти задачи быстрее и качественнее.
Как стало
Для повышения гибкости, эффективности в работе мы решили использовать фреймворк Scrum.
Освоение SCRUM мы начали с отдела разработки. Основной акцент – на командной работе, потому что без нее шансов на успех нет. На текущий момент у нас несколько команд, каждая работает над отдельным проектом, и мы можем подвести промежуточные итоги.
Повысилась вовлеченность сотрудников. Она проявляется на всех SCRUM «церемониях»: совещаниях планирования спринта, на ежедневных стэндапах, на демонстрациях инкремента заказчику и в ходе ретроспектив. Каждый чувствует свой вклад в общее дело. Повысилась заинтересованность. В Scrum разработчики сами отвечают за тот продукт, который создают. Не за отдельную задачу, а за весь продукт. Поэтому они заинтересованы в том, чтобы весь продукт работал. Разработчик видит, что он выполнил, а чего не хватает. И если не хватает, то он сам ставит себе задачу на дальнейшую разработку. В Scrum больше возможностей для проявления инициативы.
SCRUM – это командная работа. Команды самоорганизуются, саморазвиваются. Их не нужно контролировать, не нужно указывать, что делать. Они сами определяют проблемы и генерируют идеи, как их решить.
Члены команды несут ответственность друг за друга и за результат в целом. Здесь не бывает так, что кто-то один сделал работу плохо, поэтому провалили спринт. Если спринт провален, значит, все не справились. На ретроспективах не кто-то извне, а сама команда отвечает на вопросы, что было сделано плохо, как это улучшить, и когда это будет улучшено. Причем этой командной работе присуща открытость. Если у членов команды есть вопросы друг к другу, например, кому-то кажется, что другие в меньшей степени погружены в проект, то все эти вопросы выносятся на открытое обсуждение.
Благодаря самоорганизации и командной работе задачи выполняются более эффективно. Они могут поэтапно переходить от одного разработчика к другому, и каждый будет выполнять свою часть работы. Возможно, ту часть, которая ему наиболее интересна, где у него больше наработок и компетенций. Таким образом, одна задача может решаться разными разработчиками для достижения наилучшего общего результата.
Да, SCRUM - это работа на результат. Есть срок, в течение которого необходимо его выдать. И оплата зависит только от результата, а не от количества часов, которые потрачены на выполнение задачи.
Бывает, что возникают технические сложности, которые не удается быстро решить. Поначалу из-за этого запланированные задачи накладывались друг на друга и в ходе спринта не выполнялись. Сейчас команды разработчиков действуют иначе. Если выполнение какой-то задачи затягивается, ее обсуждает Development team. Если совместное обсуждение не помогает, мы выносим ее за рамки спринта – на обсуждение Scrum команды с участием Product Owner в ходе демонстрации. В рамках завершенного спринта задача приостанавливается либо отменяется. Создается новая задача с расширенными требованиями, описанием, функционалом и подзадачами, которая планируется на следующий спринт.
В следующих статьях мы расскажем про стек технологий, который используем в разработке продуктов.
Спасибо! Ваша заявка отправлена
В ближайшее время мы с Вами свяжемся!
Капча введена не верно