В 2015 году подразделение программного обеспечения и информатики компании Agilent столкнулось с проблемами. Близилась дата выпуска основной версии нового продукта, а команда не успевала по графику. Это не было чем-то из ряда вон выходящим; лишь около 20 % релизов подразделения укладывались в срок.
Из-за сорванных сроков выпуска давление на команды разработчиков существенно возросло. «Находясь под давлением, команды принимают неверные решения, — говорит Джон Сэдлер, вице-президент и главный управляющий подразделения программного обеспечения и информатики компании Agilent. — Они поступаются качеством, и это в конечном счете создает дополнительные проблемы. В общем и целом, команда была морально истощена и ей с трудом удавалось выполнить что-либо в срок».
Отчасти трудности возникали из-за того, что в подразделении программного обеспечения и информатики Agilent было занято 150 человек, которые находились на двух континентах и взаимодействовали с подрядчиками на третьем континенте. Пропасть между разработчиками, маркетологами, специалистами по обеспечению качества, работниками службы технической поддержки и отдела продаж разрасталась. Компания испытывала потребность в новых подходах к работе команды, которые помогли бы ей быстрее поставлять ценный продукт, повысить качество, прогнозируемость и адаптируемость. Короче говоря, ей нужно было совершить переход на Agile.
Подготовка к переходу на Agile
В 2015 году компания Agilent составила план перехода на Agile. В нем были обозначены следующие цели:
- ориентация на прогнозируемость;
- разработка надежного графика релизов;
- создание воспроизводимого цикла поставки;
- стремление к непрерывному совершенствованию.
Главный приоритет Agile-подхода — обеспечение качества. Второй по значимости приоритет — создание воспроизводимого графика, а третий — определение объема работ. «Когда команды не соблюдают эту очередность, для них важнее всего становится определить объем работы, затем они назначают крайний срок, а качество обеспечивается по остаточному принципу», — говорит Сэдлер.
Компания Agilent хотела наладить Agile-процессы, чтобы разработчики стали неукоснительно соблюдать приоритеты. Когда главной ценностью было объявлено непрерывное совершенствование, произошел культурный сдвиг, заложивший почву для преобразования. Поскольку первоочередной задачей является обеспечение качества, растет удовлетворенность как внешних, так и внутренних клиентов. В Agilent были готовы пожертвовать объемом работ, лишь бы оправдать ожидания клиента от продукта в процессе эксплуатации.
Второй по важности задачей, стоявшей перед подразделением, было создание предсказуемого цикла релизов, который со временем можно было бы скорректировать. Продолжительность цикла разработки должна была сократиться, а его надежность повыситься. Количество проблем и рисков уменьшилось бы, а скорость реагирования команды стала бы приемлемой.
Переход на Agile: шаг за шагом
В августе 2015 года компания Agilent договорилась о поддержке со стороны консалтинговой компании cPrime, имеющей опыт оказания помощи организациям в переходе на Agile, а позднее — со стороны TCGen, ведущей консалтинговой компании, помогающей усовершенствовать процесс разработки продуктов.
Первым шагом стало внедрение инструмента для управления продуктами в соответствии с принципами Agile — Jira. Решение Jira служит единой системой записей для всех работ по разработке Agilent, которую используют распределенные по миру команды. Это решение привносит прозрачность в процессы компании, поскольку является единым достоверным источником информации о запланированных функциях, предполагаемых сроках их выпуска и выполненной работе в каждой команде.
Адаптировано с разрешения компании cPrime, Inc.
Следующей важной задачей стало обучение методике Agile, целью которого было преподать принципы и понятия Agile, а также закрепить единую терминологию. Компания cPrime продемонстрировала свою модель «Подходы к организации управления согласно принципам Agile на предприятии» (RAGE), в которой были обозначены ключевые собрания, в том числе собрания по планированию релизов, собрания команды Scrum of Scrums, собрания владельцев продукта Scrum of Scrums, собрания для ведения бэклога релиза, обзоры релизов и ретроспективы.
Кроме того, после введения ролей владельца продукта по области и руководителя программы компания Agilent оценивала ход работы при помощи диаграмм Burnup. Компания также взяла на вооружение приемы простого принятия решений, проводила собрания, использовала Agile-артефакты в Scrum и внедрила другие методики Agile.
Agile в действии
В ноябре 2015 года подразделение программного обеспечения и информатики Agilent провело «Нулевой спринт», двухнедельный сеанс планирования в соответствии с принципами Agile, в котором приняли участие 14 обученных команд. В результате был подготовлен план выпуска продуктов, который охватил восемь месяцев разработки системы для обработки хроматографических данных OpenLAB.
Мероприятия, которые проводились в ходе «Нулевого спринта», можно разделить на три категории:
- информирование команд о коммерческих и технических целях, определяющих свойствах системы OpenLAB и общих требованиях к ней посредством презентаций и карт;
- использование освоенных методов для разработки требований и оценки сложности историй, эпиков и дефектов;
- размещение историй, эпиков и дефектов на доске «Планирование релиза» и маркировка всех зависимостей между командами.
Компания Agilent вскоре обнаружила, что положительное влияние следования принципам Agile не ограничивается пилотным проектом. Один из первых показателей успеха проявился в отношениях между командами. «Поскольку нам приходилось сотрудничать с другими подразделениями Agilent, стало невероятно важно выполнять свои обещания», — рассказывает Сэдлер.
Положительный эффект проявился и во взаимоотношениях с клиентами. Благодаря отзывам клиентов выросла скорость реагирования команд Agilent на рыночные изменения. Их мнения стали учитываться уже на первых этапах процесса разработки, благодаря чему качество ПО Agilent возросло, а риски, связанные с выводом продукта на рынок и интеграцией, снизились.
Одна из идей Agilent заключалась в том, что работа должна считаться готовой, только если в каждый эпик Agile включена история обновления. Бабита Джайн, директор по качеству программного обеспечения, и Стефан Вайс, руководитель интеграции программного обеспечения, из компании Agilent отвечали за совершение перехода и помогали командам понять весь масштаб проекта. По словам Джайн, эпик считался завершенным, только если в него входили обновления.
В результате перехода на Agile повысилось не только качество, но и надежность. В 2016 году точно по графику была поставлена система обработки хроматографических данных OpenLAB. С тех пор как компания Agilent начала следовать принципам Agile, ПО выходило стабильно по графику, а количество дефектов, выявленных в ходе эксплуатации, снизилось.
Оценка успеха
В компании Agilent, по словам Сэдлера, критерием успеха Agile-инициативы является низкая частота отказов в процессе эксплуатации и высокая лояльность клиентуры. Удержание клиентов тоже имеет большое значение. На сложившемся рынке, в условиях высокой конкуренции медико-биологической отрасли отток покупателей чреват огромными проблемами. Важно иметь возможность продать старым клиентам новую систему.
Модель производительности, которую компания Agilent разработала на основе Jira, позволила отслеживать следующие четыре важнейших показателя.
Диаграммы Burndown/Burnup
Раньше в Agilent объем работы измеряли в часах технического сопровождения, человеко-днях и баллах оценки сложности. Сейчас все отслеживают объем завершенной работы и общий объем работы с помощью диаграмм Burnup. С помощью диаграмм Burndown можно увидеть, сколько работы осталось выполнить.
Доля производительности, затраченная на продукт (полезная нагрузка)
Возможность моделировать и отслеживать производительность играет важную роль в оценке успеха компании Agilent. Благодаря Jira компания Agilent смогла разработать подробную модель производительности. «Теперь, когда у нас есть эта модель, на этапе планирования мы можем сообщить в маркетинговый отдел, какой объем работы (в баллах сложности) им необходимо выполнить для релиза. Маркетинговый отдел оценивает задачи в бэклоге так, чтобы выделить ресурсы под этот объем», — говорит Сэдлер.
Расчет и медианное время поставки исправлений
Модель производительности дала более полное представление о работе, и компания Agilent узнала, сколько усилий тратится на устранение критических или серьезных неисправностей, обнаруженных в ходе эксплуатации, а сколько — на устранение неисправностей, которые выявляет и регистрирует команда по обеспечению качества.
Доля времени, затраченная на устранение неисправностей, выявленных при тестировании вручную
С помощью модели производительности Agilent измеряет, сколько времени уходит на создание возможностей, которые клиенты считают полезными, и сколько — на обслуживание существующих продуктов и поддержание их работоспособности.
Чуть более чем за три года подразделение увеличило долю производительности, которая приходится на работу, связанную с созданием ценности, более чем в два раза — с 30 до 65 %. Поскольку в результате перехода на Agile повысилось качество программного обеспечения, количество неисправностей, которые нужно исправлять, уменьшилось.
Через год после начала процесса перехода на Agile участники команды Agilent начали подмечать различные изменения.
 | До: объем работы измерялся в часах технического сопровождения, человеко-днях или баллах оценки сложности. |
|---|---|
 | До: команды, находящиеся на разных этапах изучения Agile, использовали разные определения эпиков, историй и подзадач. |
 | До: Scrum-мастера писали код, проводили командные собрания и участвовали в принятии решений касательно приоритетов работы над функцией. |
 | До: бывало, утверждались возможности с ошибками, и неисправности переходили на следующие этапы разработки. |
 | До: проблемы часто возникали в последний момент, что порождало панику и приводило к значительным задержкам. |
 | До: не было инструмента для оценки производительности команды. |
Будущее Agile в Agilent
В Agilent, как и в любой другой организации, где ценится непрерывное совершенствование, не останавливаются на достигнутом и продолжают свое Agile-преобразование. Компания планирует и дальше сокращать время цикла и совершенствовать возможность получения аналитических данных из отзывов клиентов на ранних этапах разработки, а также основных составляющих показателей DevOps.
Компании Agilent уже удалось значительно сократить время цикла, когда ежегодные релизы были разбиты на два шестимесячных цикла — несмотря на то, что компания выводит релизы на рынок раз в год. Компания планирует снова сократить время цикла вдвое и создавать новые версии каждый квартал.
Еще одной целью продолжающегося совершенствования является частое использование мнения клиентов на ранних этапах разработки. По наблюдениям Сэдлера, когда в его группе обсуждают объем работ по продукту, люди, отстаивающие противоположные интересы, быстрее находят общий язык при наличии веских доказательств, полученных в результате изучения отзывов клиентов. Приоритетным направлением работы неизменно остается обеспечение стабильно высокого качества и удобства использования продукта на практике. Благодаря постоянному контакту с пользователями усилия распределяются в полном соответствии с приоритетами: в первую очередь — обеспечить качество, затем — создать график релизов и придерживаться его, и наконец — правильно определить объем работ.
Полученный опыт
Сэдлер по достоинству оценил работу своей команды, в том числе руководителей процесса Джайн и Вайса, которые внедрили принципы Agile в разработку, тем самым поспособствовав быстрому и непрерывному совершенствованию. С помощью правильно выбранных инструментов, таких как Jira и Confluence, команда получила возможность объединить рабочие процессы и оценивать прогресс в целом.
Компания Agilent обнаружила, что для перехода на Agile необходима сторона, которая курировала бы научно-исследовательский отдел, отдел входящего маркетинга и отдел обеспечения качества. «Только преобразовав все эти три направления, можно добиться успеха, — утверждает Сэдлер. — Нельзя перейти на Agile только за счет исследований и разработки». Самое главное — не работа в отделах, а взаимодействие между ними.
Agilent считает ключевым решение отказаться от идеи, что исчерпывающее представление о потребностях клиентов можно составить, не покидая организацию. В соответствии с принципами Agile, нужно выпускать продукты согласно четкому графику, а затем узнавать мнения клиентов, взаимодействуя с ними напрямую. Для этого сроки релиза должны быть неизменными, и при их наступлении команда должна поставлять продукт как есть.
Наконец, размышляет Сэдлер, методология Agile помогает выявлять проблемы. Например, при следовании принципам Agile становится заметным недостаток производительности. Обнаруживаются те части процесса, которые не нацелены на создание ценности, являются причиной задержек и признаком проблем с качеством. Для перехода от каскадной модели к методике Agile требуется не только изменение принципов работы команд, но и культурный сдвиг. Agile — это основа культуры непрерывного совершенствования, которая распространяется с поразительной скоростью.
