В жизненном цикле программного продукта сопровождение следует за фазой передачи его в эксплуатацию.

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

Сопровождение программного продукта стандартизовано, есть национальные стандарты Российской Федерации, идентичные международным (ISO/IEC 12 207:2008, ГОСТ Р ИСО/МЭК 12 207−2010, ГОСТ Р ИСО/МЭК 14 764−2002; IEEE 1219).

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

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

Какую скорость исправления ошибок можно считать быстрой? Формальный ответ простой — ту, которая указана в SLA. Я рекомендую придерживаться другого определения: исправление ошибки на целевом стенде до обнаружения её заказчиком.

SLA (соглашение об уровне обслуживания) — термин методологии ITIL, обозначающий формальный договор между заказчиком услуги и её поставщиком, содержащий описание услуги, права и обязанности сторон и, самое главное, согласованный уровень качества предоставления данной услуги.

Для этого в соглашении нужно привести классификацию ошибок по степени важности, правила отнесения ошибок к каждому классу и регламентные сроки исправления ошибок каждого класса. Самой распространённой является классификация ошибок по важности. Она выглядит следующим образом:

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

Какое исправление ошибки можно считать эффективным? Частично я на этот вопрос уже ответил.

Эффективное исправление ошибки — её выявление и локализация до того, как это сделал заказчик.

Однако мало просто исправить ошибку, необходимо выполнить мероприятия по предотвращению аналогичных ошибок в будущем. Для этого нужно:

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

Примеры возможных мероприятий по минимизации ошибок в будущем:

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

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

Локализация ошибки — означает обнаружение точного места её возникновения в исходном коде с информацией о контексте выполнения операции. Как правило, под контекстом понимаются значения входных и выходных параметров процедур и функций, значения атрибутов классов, порядок и стек вызова процедур и функций.

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

Зачем я так подробно это расписал? Чтобы показать основные причины, приводящие к затягиванию сроков исправления ошибок.

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

Отдельно остановлюсь на недостатках частой практики разделения ответственности за реализацию функционала и его сопровождение. Она ведёт к снижению качества продуктов по целому ряду причин.

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

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

Можно ли не вносить изменения в промежуточные релизы? Можно, если вы точно знаете, что их не будут ставить на рабочий стенд. Иначе он получит регресс — то есть отсутствие ранее работавшей функциональности. Зрелые организации, во-первых, не переходят сразу на новые, непроверенные релизы и обычно меняют релиз один-два раза в год. Во-вторых, приёмка нового релиза занимает длительное время, что связано с внутренними регламентами испытаний. В нашем примере заказчик может перейти на третий или четвертый релиз, а вовсе не на пятый. Поэтому в зрелых организациях внесение изменений в промежуточные релизы носит обязательный характер.

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

Рекомендации по минимизации ошибок при реализации и выпуске новой функциональности.

Подробное описание практик сопровождения является темой отдельной книги.

Технология разработки программных продуктов — это совокупность процессов и методов их создания. Термин «технология» подчёркивает аналогию между созданием продукта и промышленным производством. Программирование, несмотря на свой интеллектуальный и творческий характер, нуждается не только в организации и регламентировании, наборе соглашений и правил, но и в инструментальном обеспечении. Применение процессного подхода помогает системно решить эту задачу и перейти от деятельности, носящей хаотичный и случайный характер, к повторяющейся и предсказуемой.

Процесс — совокупность взаимосвязанных и взаимодействующих видов деятельности, которые преобразуют входы в выходы (ГОСТ Р ИСО 9000−2001). Действия процесса должны быть повторяющимися, а не случайными.

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

Цели процессного подхода:

Для моделирования и визуализации процессов применяются графические нотации в форме блок-схем:

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

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

СМК опирается на следующие принципы:

Основная задача системы менеджмента качества — постоянное улучшение качества разрабатываемых продуктов и предоставляемых услуг и снижение затрат на его обеспечение путём использования цикла PDCA (цикл Деминга), состоящего из планирования, действия, анализа и корректировки (имеется в виду устранение причин несоответствия, а не просто коррекция полученных результатов).

По сложившейся практике за основу системы менеджмента качества берут международный стандарт, регламентирующий управление качеством ISO 9001−2015, или выпущенный на его основе в России стандарт ГОСТ Р ИСО 9001−2015. В управлении качеством разработки программных продуктов очень популярна модель CMMI.

Capability Maturity Model Integration (комплексная модель производительности и зрелости) — набор моделей (методологий) совершенствования процессов в организациях разных масштабов и видов деятельности. CMMI содержит набор рекомендаций в виде практик.

Основная задача модели CMMI — построение стандартной структуры процессов для выполнения проектов, измерение при помощи формальных показателей их эффективности и постоянная оптимизация.

Одно из главных достоинств модели CMMI — концепция уровней зрелости, которая в простой и наглядной форме позволяет оценить зрелость процессов, выстроенных в организации, и соотнести её с аналогичными организациями, занимающимися разработкой программных продуктов.

Ни стандарт ISO 9001, ни CMMI не описывают каких-либо конкретных процессов разработки. Организация может использовать любую модель разработки и при этом соответствовать стандарту.

Важно понимать, что внедрение СМК, как по стандарту ISO 9001, так и по модели CMMI, не гарантирует выпуск качественного программного продукта. Это лишь возможность делать работу хорошо, необходимое, но недостаточное условие для выпуска качественного программного продукта, соблюдения сроков и бюджета проектов. Организации, формально соответствующие пятому уровню модели CMMI, могут выпускать некачественные продукты, не соблюдать сроки проектов и существенно превышать их бюджеты. Есть глубинные причины такого положения.

Роль — в широком смысле, описание ограниченного множества действий, выполняемых кем-то или чем-то в рамках определённого процесса.

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

Ответственность — ключевое слово, которое определяет роль в рамках процессного управления. Именно отталкиваясь от зоны принимаемой ответственности, устанавливается конкретная роль сотрудника в реализации процесса.

Роль определяет необходимый набор компетенций для успешного выполнения обязанностей. Сотрудник может исполнять несколько ролей в рамках процессов производства программных продуктов. Например, совмещать роли тестировщика и DevOps-инженера. Роль определяет, во-первых, базовый набор компетенций, который должен иметь каждый сотрудник, её исполняющий, а во-вторых, дополнительные наборы компетенций, специализированные под определённые потребности. Например, аналитик, знающий предметную область «кредиты», специализируется на кредитных продуктах, а тот, чья сфера «депозиты», соответственно — в реализации депозитных продуктов. Программисты чаще всего специализируются по стеку технологий, включающему языки программирования, например, Java или C++, фреймворки, например, Spring Boot или Angular, СУБД, например, PostgreSQL или MS SQL Server, и так далее.

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

Фреймворк Scrum вводит дополнительные роли и сферы ответственности каждой.

В компании «Диасофт» сотрудники совмещают роли лидера команды и scrum-мастера в рамках должности «руководитель команды».

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

Жизненный цикл программного продукта — период, который начинается с момента принятия решения о необходимости создания продукта и заканчивается в момент его полного изъятия из эксплуатации. Стандарт ГОСТ 34.601−90, регламентируя основные этапы создания автоматизированной системы, допускает исключать и объединять некоторые из них. Поэтому ниже я приведу только самые часто встречающиеся этапы.

Этапы могут называться по-разному и дробиться на более мелкие. Разработка программного продукта знает много достойных моделей — иначе говоря, устоявшихся практик разработки программных продуктов:

Code and Fix — одна из самых старых моделей разработки, очень простая и подойдёт небольшим, слаженным командам. Команда знает, что хочет сделать и как.

Правила модели просты:

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

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

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

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

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

Эта модель даёт возможность делать продукт по частям — инкрементам (от англ. increment, приращение). Каждая часть представляет собой готовый модуль итогового продукта. Каждый модуль проходит через этапы определения требований, проектирования, кодирования, внедрения и тестирования. Процесс разработки по инкрементной модели предполагает выпуск на первом этапе продукта в базовой функциональности, а затем — последовательное добавление новых функций и модулей в виде инкрементов. Процесс продолжается до тех пор, пока не будет создана полная система. Инкрементная модель позволяет существенно сократить срок ввода в эксплуатацию частей системы.

RAD-модель — разновидность инкрементной. В ней компоненты или функции разрабатываются параллельно несколькими командами. Временные рамки одного цикла жёстко ограничены. Созданные модули интегрируются в один рабочий прототип. Технология RAD предусматривает активное привлечение заказчика уже на ранних этапах: в обследовании организации и выработке требований к системе. Демонстрация заказчику рабочих прототипов позволяет получать обратную связь и вносить изменения.

Итеративный подход (англ. iteration, повторение) предполагает выполнение работ короткими циклами (итерациями) параллельно с непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Продукт при этом подходе в каждой фазе развития проходит повторяющийся цикл: планирование — реализация — проверка — оценка (англ. plan-do-checkact cycle). Для того чтобы начать создание продукта по этой модели, не нужно иметь полной спецификации требований — они уточняются с каждой итерацией при активном участии заказчика в разработке.

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

Гибкие модели разработки призваны минимизировать риски путём сведения разработки к серии коротких циклов по две-три недели, называемых итерациями.

Основные идеи:

К гибким моделям разработки относят множество фреймворков. Среди самых известных — Scrum, Kanban, экстремальное программирование (XP), Lean. На основании анкетирования State of Agile, проведённого сайтом Digital. ai в 2020 году, чаще всего среди Agile-фреймворков применяется Scrum — в 75% организаций.

Согласно Scrum, разработка подразделяется на отдельные итерации — спринты. Каждый из них длится от одной до четырёх недель и заканчивается выпуском части продукта. Фреймворк включает обязательные командные встречи: планирование спринта, ежедневный митинг, демонстрация (демо) и ретроспективная встреча (ретро).

Как уже сказано выше, он — самый популярный. А главными стимулами внедрения Scrum являются:

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

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

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

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

Стоит перечислить наиболее часто встречающиеся при внедрении Scrum ошибки и заблуждения.

По сути, осознанный Scrum ничем не отличается от того, что изложено в Agile-манифесте разработки программных продуктов 2001 года (https://agilemanifesto.org/iso/ru/manifesto.html). Мы просто делаем акцент на том, что применять изложенные в манифесте фундаментальные принципы нужно, глубоко их осознавая. Иначе применение гибких методологий перерастает в cargo-культ, когда все говорят вроде бы правильные вещи, тщательно выполняют все ритуалы, но при этом без видимого результата.

Самая простая аналогия — как научить ребёнка мыть руки. Вроде бы он говорит правильные вещи: я мою руки. И все ритуалы выполняет — открывает кран, берёт кусок мыла, подставляет руки под струю воды, а руки остаются грязными. Почему? Потому что малыш не понимает, как и, главное, зачем использовать мыло, как именно нужно мыть руки и как контролировать результат.

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

Первый важный шаг — осознать принцип: работающий продукт важнее исчерпывающей документации и его расширения.

Фокусировка команды на правильном результате — ключ к высокой эффективности. Результатом работы команды или создаваемой ценностью является работающий продукт. Но что это значит? Работающим является продукт, установленный на рабочий стенд заказчика и функционирующий согласно ожиданиям заказчика и без ошибок. Команда должна осознать, что написанное техническое задание, закодированный функционал и даже выпущенный, но не установленный на рабочий стенд заказчика продукт не является достигнутым результатом. Если на выходе из спринта команда демонстрирует только подготовленное техническое задание, результат спринта смело можно назвать нулевым. Мысль вроде бы простая для восприятия, но невероятно сложная для осознания. И, судя по практике, команды довольно долго пытаются разными способами этот принцип «пробить».

Приведу несколько распространённых примеров, демонстрирующих непонимание командой данного принципа.

Первый из них условно назову «водопадным agile». Если команда привыкла работать по водопадной модели, ей довольно тяжело перестроиться на итерационный лад. И в рамках итерационной модели то и дело проявляются пережитки водопадной. Этапы разработки функциональности раскладываются в отдельные спринты. В первом спринте создаётся техническое задание, во втором — код, в третьем проходит тестирование. И команда будет упорно и аргументированно доказывать вам, что невозможно работать по-другому. Нужно объяснять командам, что в этом случае заказчик впервые увидит функционал не раньше, чем через 1,5 месяца, если спринты двухнедельные. Устранение замечаний заказчика может потребовать ещё 1,5 месяца, далее — выпуск и установка на рабочий стенд заказчика. В итоге, от постановки задачи до получения работоспособного продукта может пройти от 4 до 6 месяцев. Вы уверены, что через полгода задача, которую клиент просил решить оперативно, осталась для него актуальной? Вряд ли. Так что придётся учиться тому, чтобы полностью реализовывать задачу в рамках одного спринта. Все стадии разработки задачи, включая техническое задание, код, тестирование и даже выпуск, нужно уместить в рамки одного спринта.

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

Вот почему важно сделать показатель прироста функциональности продукта основным — он постоянно напоминает командам, что есть ценный для заказчика результат, а что таковым не является.

А теперь разберёмся, какой результат команда должна выдавать каждый спринт. Классическая формула расчёта максимально возможного результата выглядит так: работа команды за спринт = Мощность команды * Время спринта. Время спринта — это его длительность в днях. Чтобы упростить расчёты, возьмём для примера спринт длительностью в 10 рабочих дней, или две недели. Допустим, команда состоит из 7 человек, тогда максимально возможное значение работы будет равно 70 человеко-дням. Наша задача состоит в том, чтобы они были потрачены, в основном, на создание ценности, то есть на реальный прирост продукта в интересах заказчика. Для этого спринт должен заполняться типовыми задачами так, чтобы общее нормативное время выполнения их было равно 70 человеко-дням.

В действительности, команда не может все 100% времени потратить на создание ценностей. Потому что в этот промежуток входит выполнение scrum-активностей, таких как «планирование спринта», «ежедневные встречи», «обзор результата» и т. д. Хорошим может считаться результат, когда 70% мощности команды направлены на создание новых ценностей и только 30% — на всё остальное. Отношение реальной мощности, направляемой на создание ценности, к максимально возможной называется фокус-фактором. Фокус-фактор — критически важный показатель эффективности команды, он должен быть в каждом спринте не ниже 0,7 — то есть не менее 70% времени команда направляет на создание ценности.

Обращу ваше внимание на несколько важных факторов.

Приведу пример планирования типового двухнедельного спринта команды фронт-энд разработки, состоящей из 7 человек. Допустим, норматив на разработку простой интерфейсной формы равен одному дню. На создание ценностей команда должна потратить 49 дней — это как раз 70% от 70 дней. Значит, команда каждый спринт должна планировать разработку 49 новых простых форм. Если взять в план меньше, спринт фактически будет недогружен. Если команда не может справиться с таким планом, то на ретроспективе необходимо разобрать причины этой «слабости» и наметить мероприятия, которые уже в следующем спринте помогут приблизиться к выполнению плана, а в конечном счёте — выполнить его полностью. Разумеется, надо избегать мероприятий, целью которых будет уменьшение плана.

Производственная практика — навык, приобретённый командой для достижения поставленной перед ней определённой цели. Казалось бы, куда разумнее использовать лучшие практики, чем всякий раз «изобретать велосипед». Вот только в реальности не всё так радужно и очевидно — слишком многими мифами обросла эта в целом здравая идея.

Миф номер 1. «О лучших практиках знают все». В этой фразе сразу несколько заблуждений. Во-первых, вы нигде не найдёте полного списка «лучших практик», нет такого места, в котором можно узнать обо всех «лучших практиках». Более того, в этой книге описана сложная структура производства программных продуктов, каждый элемент которой имеет свой набор «лучших практик». Поэтому правильнее говорить о практиках широко известных и часто цитируемых в различных источниках. Во-вторых, не стоит даже надеяться на то, будто даже широко известные «лучшие практики» известны всем командам. А среди тех, кому они известны, бытуют самые разные представления об их сути.

Миф номер 2. «Команды, использующие лучшие практики, эффективны». Считается, что если команда использует одну из лучших практик по снижению количества ошибок, то в этой команде ошибок меньше, чем могло бы быть. Но это далеко не так. Для примера приведу практику рецензирования кода. Почему-то считается, что сама по себе практика уже гарантирует успех: если команда использует эту практику, то есть ожидание, что высококвалифицированные разработчики глубоко вникают в предлагаемые изменения кода и возвращают их с подробным описанием проблем и способов его исправления. Далеко не у всех так получается. Где-то у рецензентов элементарно нет времени на детальный разбор, у кого-то не хватает высококвалифицированных программистов, кто-то проверяет только правила оформления кода, а есть и те, кто вообще подтверждает не глядя. Не забудем и одну особенность программистов — у них, как правило, плохо с коммуникационными навыками, и их комментарии далеко не всегда полны и понятны даже коллегам.

Миф номер 3. «Команды заинтересованы во внедрении лучших практик, так как они повышают их эффективность». Одним из следствий данного мифа стало ожидание того, что команда, узнав о какой-то практике, тут же ринется её использовать. Увы, нет — и люди, и команды консервативны в своих привычках и пристрастиях и склонны сопротивляться любым переменам. Внедрение редко проходит гладко, уже хотя бы потому, что этот процесс — по сути, вторжение чужеродного объекта в тело. Должно быть освоение. Ещё одна бытовая аналогия: если нет привычки вечером чистить зубы, заставить себя очень сложно, даже понимая очевидную пользу процедуры. Требуется создать привычку усилием воли, на что нужно определённое время. Так и с командой — ей тяжело перейти на новую практику и, главное, не бросить её через несколько спринтов. Потому что эффект не проявится моментально, отсюда — разочарование и неверие в успех. Хотя чаще люди выступают против изменений, искренне не понимая, какую пользу изменения могут принести им и компании.

Кроме широко известных «лучших практик», есть менее известные и те, что наработаны внутри компании. И если уж в компании «изобрели велосипед», то пусть это будет общий «велосипед», а не для каждой команды в отдельности.

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

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

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

Ведение реестра производственных практик — тоже производственная практика, и у него должны быть заказчик, владелец и главная цель. В компании «Диасофт» его заказчиком являюсь я — как директор по производству и главный архитектор. Владелец практики — центр по управлению производственными командами. Но и сам он (центр) является командой, определяющей результат внедрения практики. В ситуационном центре выводятся значения количественных показателей всех занесённых в реестр практик — в разрезе команд и продуктовых центров. Это позволяет оценивать уровни зрелости, эффективности и результативности команд. Главная же цель — управляемое повышение эффективности и результативности команд.

Как понять, насколько хорошо выполняется практика? Остаётся ли необходимость в дальнейшем повышении качества выполняемых действий? Или уже достигнут максимальный результат?

Для оценки эффективности бизнес-процессов применяют модель уровней зрелости. Её удобно применять и оценивая зрелость применяемой командой практики, но там своя версия — модель уровней зрелости практик. Модель строится таким образом, что по мере роста уровня зрелости улучшается эффективность работы команды, под которой мы понимаем повышение вероятности выполнения главной цели практики при снижении затрат на её выполнение. Хорошая, на мой взгляд, жизненная аналогия — получение навыков вождения автомобиля. После сдачи экзамена и получения прав большинство водителей оказывается на начальном уровне зрелости — с точки зрения практики вождения. Достижение цели практики — «доехать до пункта назначения» — требует от начинающего водителя серьёзных эмоциональных, умственных и физических усилий. Как правило, в память об этом периоде у каждого остаётся целая серия курьёзных историй. После нескольких лет постоянной практики за рулём «зрелый» водитель порой даже не вспоминает, каким образом и по какому маршруту он добрался до места назначения. То есть имеет место автономный характер выполнения практики. То же самое и с практиками командной работы.

Модель зрелости практик имеет пять уровней.

Именно на четвёртом, осознанном, уровне зрелости практика устойчиво закрепляется в действиях команды. Вероятность того, что команда откажется от практики, здесь минимальна: люди отлично понимают, какую выгоду приносит им практика и чего они могут лишиться, отказавшись от неё. Более того, команда станет активно сопротивляться попыткам отмены практики, а новых членов команды будет обучать своими силами. Другими словами, у команды заработает «внутренний мотор» по воспроизведению практики. Для сравнения: на втором и третьем уровнях команде для продолжения практики требуется поддержка, она, как правило, либо ложится на плечи одного из вовлечённых членов команды, верящего в результативность практики, либо носит внешний характер — настойчивый регулярный менеджмент.

В Scrum есть специальная роль scrum-мастера, в чьи обязанности входит, в том числе, и постоянное воздействие на команду для воспроизведения практик методологии. Как только воздействие слабеет или вовсе исчезает (например, в связи с уходом вовлечённого участника команды, неактивной позицией scrum-мастера или нерегулярным менеджментом), команда очень быстро перестаёт выполнять практику. Таким образом, на втором и третьем уровне «внутренний мотор» команды по воспроизведению практики ещё не работает. Что касается второго, управляемого, уровня, команда выполняет практику ради самой практики. И если не видит результата своих усилий, фактически отодвигает её в сторону. В отсутствии измерений практика просто перестаёт выполняться, незаметно для менеджмента компании. На третьем уровне во главе угла (в понимании команды) — хорошие показатели, не более того. Но если люди не видят своей выгоды, то и отслеживание показателей начинают воспринимать как навязываемое «неумным» менеджментом. Вот почему на втором и третьем уровнях столь важно помочь команде увидеть свою выгоду от внедрения практики, выйти на четвёртый уровень — и запустить собственный «мотор».

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

В осознанности нет полутонов — тут либо действие выполняется сознательно, либо нет. Например, одна из главных задач DevOps — успешная сборка, доставка и развёртывание микросервиса на целевом стенде, один из признаков сознательного применения этой практики — время, в течение которого команда исправляет неуспешную сборку. Когда команда не видит для себя ценности в DevOps, она не стремится быстро исправить недочёты. Эмпирически получено, что, если команда исправляет «упавшую» сборку быстрее, чем за 4 часа, она понимает ценность DevOps и сознательно его применяет. Другой признак осознанности — команда старается, чтобы все коммиты (выкладка исходного кода в репозиторий) запускали CI/CD-конвейер. Если команда видит для себя ценность в применении CI/CD-конвейера, то при создании нового микросервиса сразу подключит к нему CI/CD-конвейер. Если нет — команда будет вести локальную сборку микросервиса, пока на это не обратят её внимание.

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

Осознанный уровень зрелости применения практики в организации определяется количеством команд, сознательно её применяющих. То есть тех, у которых три из четырёх признаков выполняются каждый спринт. Если таких команд 80%, это говорит о достижении осознанного уровня практики в организации. И «внутренний мотор» команд работает без необходимости внешнего воздействия. Более того, осознав ценность практики для себя, команда будет активно сопротивляться попыткам её отменить. Проще говоря, налицо полное освоение практики. Когда соответствовать всем четырём признакам будет постоянно более 90% команд, можно говорить о достижении пятого уровня зрелости.