Анализ внедрения гибкого фреймворка Scrum в процесс разработки программного обеспечения

Кудрявцев Сергей Сергеевич
Выпускник ITM-25B
Школы IT-Менеджмента
РАНХиГС при Президенте РФ
Сертифицированный Скрам-мастер

Scrum – мощный и гибкий фреймворк для построения процесса разработки программного обеспечения. Однако для его внедрения требуется не только коренная перестройка самого процесса разработки, но также и подстройка всей организации под этот процесс. Поэтому внедрение Scrum’а не всегда удаться осуществить в полном объеме. Для таких производных от Scrum’а процессов есть полуофициальное название ScrumBut.
Этот термин обозначает, что использование Scrum’а ограничено некоторыми условиями, то есть “мы используем Scrum, но (but) не делаем какие-то из его предписаний”.

Надо понимать, что любое отступление от правил Scrum’а лишает его целостности, и в этом случае его создатели не гарантируют полной отдачи от его внедрения. Тем не менее, из этого не вытекает, что при наличии объективных причин, вследствие которых становится невозможным точное следование каким-либо из предписаний Scrum'а, организации следует от него отказаться. Даже не полное внедрение Scrum'а может принести значительную отдачу. Но надо четко понимать, чем вызваны отступления от правил, какие негативные последствием могут быть от этого, и стараться по мере возможностей, устранять причины, приведшие к этому.

Данная работа посвящена краткому описанию опыта внедрения Scrum’а в процесс разработки программного обеспечения одного из отделов крупнейшей телекоммуникационной компании России. В ней рассмотрены допущенные отступление  от правил, предписанных Scrum’ом, причины этих отступлений, негативные последствия этого и остаточная польза от внедрения.

Мероприятия

Планирование Спринта

Во время Планирования Спринта совмещались активности, как самого планирования, так и часть активностей поддержки Беклога Продукта, а именно оценка и уточнение его элементов, что является отступлением от правил Scrum’а.

Данное отступление вызвано не полным осознанием того, в каком из мероприятий Scrum’а должна осуществляться активность по поддержке Беклога Продукта.

В связи с этим самому планированию уделялось недостаточно много времени. Но это было не критично, потому что, во-первых, декомпозиция заданий не требовалась, так как Беклог Продукта был составлен не из пользовательских историй, а из технических заданий (что, хотя и является плохой практикой, но в данном случае сыграло положительную роль). Во-вторых, на момент внедрения, все задания из которых был сформирован Беглог Продукта, были практически полностью сформулированы и оценены, поэтому его поддержка занимала мало времени.

Из положительных моментов следует отметить, что команда начала вести учет своей производительности.

Также к проблемам планирования можно отнести такой фактор, как малое участие в нем Владельца Продукта. Такое положение дел было связано с его высокой занятостью и малой заинтересованностью в бизнес результатах от продукта.  Это порой приводило к неправильной оценке объема работ Командой Разработки.

Упущением в Планировании Спринта было отсутствие поставленной цели Спринта. По сути, Беклог Продукта представлял собой набор слабо связанных друг с другом технических заданий, что делало составление цели Спринта трудновыполнимой задачей. Отсутствие Цели лишало Команду Разработки гибкости.

Ежедневный Скрам

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

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

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

Обзор Спринта

К сожалению, в проекте Обзор Спринта не проводился. Причиной этого служило отсутствие в этом заинтересованных сторон. Сторона Заказчика была территориально удалена от команды, поэтому занималась самостоятельным просмотром текущего Инкремента на тестовом сервере.

Не проведение Обзора Спринта было не критичным, так как в момент внедрения Scrum’а все требования к проекту уже были составлены и зафиксированы, а сторона Заказчика была ограничена рамками контракта и ей было проблематично вводить дополнительные изменения в проект.

В связи с этим адаптация Беклога Продукта после получения обратной связи от всех заинтересованных лиц, которая должна проходить в рамках этой встречи, не требовалось. Конечно, жесткие рамки контракта сводили на нет некоторые из главных идей гибкой разработки, а именно “сотрудничество с заказчиком важнее согласования условий контракта” и “готовность к изменениям важнее следования первоначальному плану”, но контракт по проекту, во время разработки которого внедрялся Scrum, был объективной данностью, и как-либо повлиять на его условия не представлялось возможным.

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

Ретроспектива Спринта

Ретроспектива Спринта проводилась не в полном объеме. Из-за недостатка опыта не был налажен сбор обратной связи от команды по предыдущему Спринту, то есть, инспекция уже внедренных практик не производилась, хотя это необходимо.

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

Спринт

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

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

Роли

Владелец продукта

При текущем распределении ролей, присвоение роли Владельца Продукта начальнику отдела разработки не являлось оптимальным, но в момент внедрения было единственно возможным. В идеальном варианте, Владельцем Продукта должен быть человек со стороны Заказчика, или же аналитик со стороны Разработчиков. Как уже было сказано выше, требования по проекту были уже собраны до начала внедрения Scrum’а, контракт не допускал легкого внесения изменений в ход работ, и поэтому заказчик не был заинтересован в предоставлении своего человека для роли Владельца Продукта. У начальника отдела разработки, взявшего на себя роль Владельца Продукта, было слишком мало времени для выполнения обязанностей данной роли.

Команда разработки

Несмотря на то, что Команда Разработки была кросс функциональна, некоторыми техническими навыками обладали только отдельные члены команды, что ставило в зависимость от них как Команду, так и весь проект в целом. Чтобы нивелировать данную проблему были налажены некоторые практики обмена знаниями и навыками внутри Команды Разработки. Рассмотрения этого вопроса выходит за рамки данной статьи.

Скрам-мастер

Основной проблемой Скрам Мастера был недостаток времени в связи с тем, что параллельно исполнению этой роли, он был задействован в составе Команды Разработки.

Также сказался и факт отсутствия опыта по внедрению Scrum’а.

Артефакты

Беклог Продукта

Особенностью Беклога Продукта было то, что он оперировал не пользовательскими историями, а техническими заданиями.

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

Некоторые незафиксированные в Беклоге Продукта задания вносились и описывались в технических терминах. Это происходило из-за того, что Беклогом Продукта пользовались только Владелец Продукта и Команда Разработки. Все другие заинтересованные лица, хоть он им и был доступен, не уделяли Беклогу Продукта особого внимания.

В этом случае Владельцу Продукта (человеку технического профиля) и Команде Разработки было удобнее заполнять Беклог Продукта, оперируя техническими заданиями, так как они не ориентировались на посторонних заинтересованных лиц.

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

Беклог Спринта

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

Определение Готовности
Единого определения готовности не было, в связи с этим возникала некоторая неопределенность в определении объема работ и требованиям к элементам Беклога Продукта. Временами случались ситуации, когда “сделанные” элементы Беклога снова возвращались на доработку в связи с тем, что разработчики не полностью понимали объем работ.
В момент внедрения Scrum’а Команда не придала значение данной практике, но опыт показал, что она является весьма существенным элементом данного фреймворка.

Выводы:

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

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