Внедрение гибкой методологии в условиях стихийной разработки программного обеспечения

Павел Владимирович Байбаков
Выпускник группы MBA CIO-69
Школы IT-менеджмента Института ЭМИТ
РАНХиГС при Президенте РФ

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

Несмотря на естественное человеческое желание сохранять всё как есть, «работает – не трогай», «всегда так делали», компания не может останавливаться в своем развитии, экстенсивно применяя уже привычные подходы и методы. Если в процессах реализации программных продуктов для всех очевидно, что нужно поспевать за технологиями, использовать эффективные средства разработки, отладки, сборки, паттерны, подходы, языки, фреймворки ведь это же понятным образом повышает качество, скорость, удобство разработки программ, то для организационных процессов внутри предприятия не всё так явно и часто требует взгляда со стороны, демонстрации накопившихся проблем, современного подхода к их решению. Уместным в данной ситуации, хоть и, возможно, несколько банальным будет цитата из произведения «Алиса в стране чудес» «Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!». Именно это является неотъемлемым требованием ко всем аспектам жизни современной ИТ компании, занимающейся разработкой программных продуктов в условиях глобальной конкуренции и рынка, которая в свои стратегические планы закладывает дальнейший рост, развитие, расширение, завоевание новых ниш.
Чтобы обособить и выявить проблемы, которым посвящена данная работа, без лишних обобщений, был проведен анализ текущего состояния подразделения, занимающегося непосредственно разработкой программного обеспечения, в контексте организационных процессов предприятия. Анализу подверглись процессы, происходящие как внутри подразделения, так и затрагивающие взаимодействие сотрудников подразделения с внешними структурами, такими как отдел внедрения, отдел тестирования, руководство компании, заказчики. Для описания существующего состояния и объективизации демонстрации существующих проблем использовались такие средства как диаграммы потока данных, матрица ответственности, экспертная оценка наблюдателя, внутренние опросы и интервью.

Выявление проблем заключалось как в констатации самой проблемы, ее выражении и последствиях, так и в поиске первопричин, повлекших видимые последствия. Например, ситуация в которой на одном разработчике оказывается несколько десятков неупорядоченных активных задач, часть из которых ждет очереди на тестировании, часть из которых являются срочными, а еще часть не закрыта, потому что требуется доработка вне первичных требований, явно ощущается как ненормальная. Но почему это ненормально? Ведь задачи всё равно будут выполнены, вероятно даже с приемлемым качеством и в нужный срок. Дело в том, что в такой ситуации есть несколько очень важных негативных моментов, а именно: переключение контекста специалистов требует времени и может стать причиной дополнительных ошибок, а незавершенные задачи являются потенциальным местом возникновения ошибок в других местах кода, косвенно связанных с кодом, относящимся к незавершенным задачам. Также немаловажным фактором, влияющим на конечный результат, является состояние самого разработчика, который не может долго получить положительную обратную связь по своей работе, вынужден постоянно переключаться между задачами и работать в напряжении от срочных задач, иногда оставаясь на выходные и задерживаясь по вечерам.
Причины таких проблем совсем не новы, и вытекают из того, что развитие системы управления не успевает за ростом компании, которая привыкла к определенному стилю менеджмента и опасается изменений или не видит в этом необходимости. Поэтому в данной работе после анализа проблем рассмотрены известные гибкие подходы, появившиеся в результате созревания отрасли, эволюции методов организации работ в достаточно новой сфере человеческой деятельности – разработке программных продуктов. Разработка ПО отличается от других сфер деятельности возможностью и необходимостью постоянных изменений в производимых продуктах, «мягкостью» и податливостью программ. Таким образом базовыми принципами управления в разработке программных продуктов стали принципы гибкой разработки – Agile.
Реализация таких принципов может быть различной, но все они придерживаются тезисов, изложенных в agile-манифесте:
• Люди и взаимодействие важнее процессов и инструментов.
• Работающий продукт важнее исчерпывающей документации.
• Сотрудничество с заказчиком важнее согласования условий контракта.
• Готовность к изменениям важнее следования первоначальному плану.
Несмотря на популярность такого фреймворка как Scrum, целевым состоянием, которое выбрано в данной работе, является подход на основе принципов Kanban. У этого подхода есть несколько преимуществ относительно других. Например, его можно внедрять постепенно, подстраивая существующие процессы под его принципы, такие как ограничение незавершенных задач, сосредоточение на потоке задач, постоянное улучшение. Отсутствие необходимости процедуры оценки трудоемкости также делает этот подход привлекательным, т.к. трата времени на оценку трудоемкости не снижает эту трудоемкость, а только увеличивает. Но это не исключает оценку сроков выполнения, т.к. в процессе работы набираются статистические данные, позволяющие с достаточно высокой точностью оценить срок завершения запланированного объема работ. Используемый в Kanban поток задач стимулирует сотрудников работать в постоянном темпе, чтобы не оказаться блокирующим очередь задач, стимулирует взаимодействовать сотрудников для решения возникающих проблем.
Для перехода от стихийного подхода к разработке программного обеспечения на гибкие методологии в данной работе рассмотрен проектный подход поэтапного осуществления такого перехода. Введена система метрик для объективизации оценки влияния изменений, описано целевое состояние в терминах этих метрик. План перехода от текущего состояния к целевому представлен в виде списка последовательных операций и контрольных событий. Также проведена оценка рисков, источников рисков, вариантов реагирования при наступлении рисков. Ввиду того, что проект должен быть реализован в рамках операционной деятельности участников, для оценки стоимости проекта составлен план использования трудовых ресурсов, на основании которого вычислена оценочная стоимость проекта.

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