Гибкая методология разработки (Agile) в менеджменте качества

Источник: личный блог Стивена Томаса (Steven Thomas, – ред.). На сайте говорится, что он сам является руководителем в сфере IT (методология Agile в ней применяется особенно часто) и сам использует методы, о которых пишет на практике.

В контексте проектного менеджмента управление качеством понимается так: правильные процессы, обеспечивающие как качество конечного продукта, так и качество проекта. В этой статье будет рассмотрена разница между двумя подходами: с одной стороны у нас традиционный менеджмент качества плюс Agile, с другой – традиционный менеджмент качества плюс несколько отдельных подсистем – «Agile качества продукции» (Agile Product Quality, – ред.), «Agile качества проекта» (Agile Project Quality, – ред.), «Agile качества продукции» (Agile Product Quality, – ред.), «Agile обеспечения качества и контроля» (Agile Quality Assurance and Control, – ред.), «Agile улучшения качества» (Agile Quality Improvement, – ред.).

Традиционный менеджмент качества

Сразу хочу выразить Энтони Маркано и Анне Чаремзе благодарность за то, что они напомнили мне, что менеджмент качества и контроль и испытания образцов – разные вещи. Но это лирическое отступление. Напомню, что менеджмент качества в проектах – один из девяти областей знания, необходимых для управления проектами и перечисленных в стандарте PMBoK (Project Management Body of Knowledge, – ред.). Стандарт в 2004 году был выпущен Институтом проектного менеджмента (Project Management Institute, – ред.). Однако из этого вовсе не следует, что менеджмент качества является просто маленькой подтемой проектного менеджмента. Это полноценное самостоятельное и очень большое направление в менеджменте, зародившееся в недрах японской промышленности.

Политика в области качества, менеджмент, системы, обеспечение качества, контроль и так далее и так далее

Существует безумное количество терминов, включающих слово «качество», поэтому до того, как перейти к сути я позволю себе привести ряд определений из «Словаря ASQ» (ASQ: Glossary, – ред.), чтобы все мы понимали о чем идет речь.

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

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

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

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

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

План по качеству: документ или набор документов, которые описывают стандарты, лучшие практики, ресурсы и процессы компании в привязке к конкретному товару, услуге или проекту.

Аудит качества: систематическая независимая оценка, дающая возможность проанализировать ситуацию и ответить на ряд вопросов: соответствуют ли осуществляемые мероприятия по качеству и соответствующие результаты планам; эффективно ли внедрены эти планы с точки зрения задач, стоящих перед организацией.

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

Менеджмент качества

На удивление словарик ASQ обошел стороной проблематику улучшения качества. Ему в определении термина «менеджмент качества» уделяется не столько внимания, сколько концепция постоянного улучшения в действительности стоит. К счастью, Википедия восполняет данный пробел:

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

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

Качество продукции

В статье «Планирование качества в проекте» на сайте «Project Perfect» сказано следующее: «Качество продукции выводится из пригодности с точки зрения целей, для которых она была изготовлена. В этом уравнении также надо учитывать такие факторы, как то, насколько результат работы отвечает потребностям ее потребителя, а также так называемую совокупную стоимость владения. Впервые заговорил про «пригодность с точки зрения целей» классический специалист по качеству Джозеф Джуран. Этот инженер внес громадный вклад в формирование TQM (Total Quality Management, – ред.). Джуран верил, что объективно судить о качестве той или иной продукции легко, если принять во внимание ее пользу для потребителя. Причем вердикт, в представлении ученого, должен выносить именно он – потребитель. Надо сказать, что такая постановка вопроса годится и когда мы говорим о качестве продукции, и когда речь заходит про качество в проекте. С подходом Джурана контрастирует подход другого гуру качества – Филипа Кросби. По его словам, качество – не что иное, как соответствие требованиям. Проблема с прямым пониманием этого постулата в том, что требования очевидным образом не полностью отражают ожидания и потребности клиентов. Кросби утверждал, что в своей формулировке он имел в виду требования в более широком смысле, но некоторые люди исказили мысль и свели ее к буквальным и закрепленным на бумаге спецификациям. Да, во всем этом скрывается настоящий вызов для умов классических IT-разработчиков.

Качество проекта

Помните, менеджмент качества фокусируется не только на качестве продукции, но и на «средствах его получения», что в терминах проектного менеджмента звучит, как «качество проекта». Также качество проекта можно охарактеризовать так: «приложение верных практик проектного менеджмента к издержкам, времени, ресурсам, коммуникациям и так далее». Скажу от себя, что сюда же следует добавить управление изменениями в проекте. Просто поразительно насколько это близко к проблематике, которая находится в центре внимания Agile проджект-менеджмента!

Обеспечение качества

Кросби проводил параллель между обеспечением качества и человеком, у которого есть водительские права. Наличие прав дает некоторую уверенность в том, что человек не собьет кого-нибудь, но точно быть уверенными мы все равно не можем. Что мы делаем в рамках процессов обеспечения качества? Создаем план по качеству. Хороший план – как водительская лицензия – призван дать уверенность в том, что работа с качеством даст ожидаемые результаты. Если посмотреть на все это с точки зрения проектного менеджмента, то там детализируется, что план по качеству должен содержать:

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

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

Если честно, я был удивлен, когда узнал, что PMBoK дает «скукоженную» версию обеспечения качества, методически отделяя его от планирования качества. В стандарте обеспечение качества – скорее доказательство, свидетельство, а не полноценные процессы менеджмента качества, которые нужно поддерживать.

Управление качеством

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

Улучшение качества

Хочу поделиться своим наблюдением. Традиционный проектный менеджмент не озабочен улучшениями, все внимание обращено на достижение целей проекта. Улучшения внедряются на уровне организации, а не проекта. Как говорится на сайте «Praxion», в материале «ISO 9000:2015 – определения простым человеческим английским языком»: «под улучшениями в системе менеджмента нужно понимать любые меры, повышающие способность компании соответствовать требованиям к качеству». Другими словами, сюда стоит отнести и улучшения продукции, и улучшения процессов и работу с людьми. Добавлю, что на сегодняшний день существует множество методов улучшения качества с громкими и сложными названиями: ISO 9004:2000, Кайдзен, Шесть Сигм, TQM, Методы Тагути. Я лично был привлечен к созданию одного из таких методов в середине 90-х. Речь идет о методологии SPICE, для постоянных улучшений процедуры разработки ПО. Метод лег в основу подхода ISO оценке процессов создания программного обеспечения (ISO 15504, – ред.).

Agile против традиционного менеджмента качества

Мне кажется, что процессы в рамках подхода Agile (гибкая методология разработки, – ред.) находятся в полном соответствии с видением качества Джозефа Джурана. А вот традиционный подход ближе буквальной трактовке качества, как требований к результату работы. Цель «аджаилистов» – удовлетворить потребителя и создать востребованное программное обеспечение. Традиционалисты пытаются «дать» на рынок ПО, в которое «встроены» требования из контрактов и спецификаций. Последние игнорируют тот факт, что озвученные требования в форме спецификаций могут с сильным искажением передавать требования к продукции потребителя. Еще одной точкой расхождения между Agile и консервативно мыслящими IT-специалистами становится документация. Знаменитый «Agile-манифест» провозглашает: «Работающий продукт важнее документации». На деле это означает, что в работе Agile-команды разработчиков вы не найдете детализированных требований, спецификаций, планов по качеству, записей… Но Agile не отказывается от преимуществ документирования, просто в этом течении есть свой особый способ делать это, о котором мы поговорим ниже во всех подробностях.

Качество продукции Agile

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

Качество проекта Agile

А теперь вернемся к качеству проекта. Как мы помним – это «приложение подходящих методов проджект-менеджмента к проблемам издержек, времени, ресурсов, коммуникаций и так далее». И не забываем управление изменений в проекте. Учитывая определения качества проекта, мне кажется, что добиться этого качества можно путем внедрения группы методик проектного менеджмента по Agile, которые обязательно должны включать следующие подсистемы:

• Жизненный цикл Agile и «Agile Heartbeat»;
• Организационные роли и ответственность по Agile;
• Начало проекта по Agile;
• Определение границ, в пределах которых реализуется проект по Agile;
• Планирование проекта по Agile;
• Оценка проекта по Agile;
• Реализация проекта по Agile;
• Мониторинг и контроль по Agile;
• Риск-менеджмент по Agile;
• Управление изменениями по Agile;
• Завершение проекта по Agile.

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

Обеспечение качества и контроль по Agile

Я не устаю повторять, что обеспечение качества – это планирование действий, способных продемонстрировать его, а управление и контроль качества – внедрение созданных планов. Чтобы убедиться в получении ожидаемого результата в традиционном проектном менеджменте руководитель проекта должен сделать план по качеству. Ничего подобного не делается в проекте, основанном на методологии Agile. Дело в том, что если сам процесс проекта реализуется с соблюдением принятых в данной концепции фаз, то обеспечение качества и контроль приходят сами собой, как составляющая самой работы. Agile встраивает качество в продукцию через посредство своих подсистем: «Мониторинг и контроль по Agile» и «Реализация проекта по Agile» (Agile Project Execution, – ред.).

Роль «владельца продукта» в команде Agile-разработчиков

Команда разработчиков старается воплотить в жизнь намерения владельца продукта, а не требования, которые он подготовил к нему. Таким образом, в мире Agile этот человек становится участником команды разработки ПО для него и консультирует разработчиков. Порой владельцы продукта не могут посвящать работе над ним 100% своего времени, однако это не аргумент против Agile, так как классический проджект-менеджмент сталкивается с этой угрозой точно так же.

Подтверждение пригодности продукта (малые релизы) в каждом отрезке времени

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

• учесть ожидания клиента, учитывая выявленные ранее пожелания и результаты малых релизов кода до настоящего момента;
• получить уверенность, что написанный к определенному моменту код точно соответствует вначале согласованным стандартам;
• ответить на вопрос: «а выполнены ли разработанные к текущему моменту элементы программы наилучшим образом или есть лучший способ (посредством рефакторинга);
• программу легко обслуживать (посредством рефакторинга, – ред.);
• проверить, насколько удовлетворены ходом работы участники команды разработчиков и соответствующие заинтересованные стороны.

Внеплановая обратная связь по продукту

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

Плановая обратная связь по продукту

Официально ревизия продукта на разных стадиях готовности осуществляется через небольшие промежутки времени (timeboxes, – ред.) в ходе специальных совещаний. Можно задать более короткие промежутки сдачи готового кода или более длинные (например, 3-4 недели). Назначенный специалист отвечает за документирование совещаний… Лично я считаю, что это хорошая идея, но сам не очень много внимания и времени посвящаю документам. Мне кажется оптимальным документирование в том стиле, в котором я его описал выше, когда говорил о незапланированной обратной связи с потребителем. Email заинтересованным лицам – этого вполне достаточно.

Планерки по текущим вопросам для команды

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

Автоматизированное модульное тестирование

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

Приемочные испытания

Если вы действуете в соответствии с Адаптивным методом разработки систем (DSDM, – ред.) – то тогда у вас уже имеются документированные критерии качества для любого работающего продукта. Однако менее «развернутые» версии Agile оперируют понятием потребительских историй. Потребительские истории – это самые обобщенные описания внешних проявлений и условий бизнеса, в которых должна успешно реализовывать себя ваша программа. Каждая такая история должна содержать, по крайней мере, один критерий пригодности ПО, на соответствие которому ваш продукт можно проверить. Истории полезны тем, что дают лучшее представление о намерениях владельца продукта и очерчивают границы проекта, снабжая разработчиков конкретными примерами из той области, для которой они на этот раз работают. Попутно у команды специалистов появляется уверенность, что они движутся в верном направлении.

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

Разработка посредством тестирования

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

Регрессивное тестирование

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

Исследовательское тестирование

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

Специальное тестирование

Дополнительные тесты работоспособности программы назначают так же, как принимают и обрабатывают потребительские истории.

Анализ кода

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

Метрики программирования

Это не регулируется никакими подходами на основе Agile, но сами используемые понятия намекают на использование некоторых метрик по качеству кода. Например, метрики по отрезкам кода, затронутым модульным тестированием, метрики по установленным принципам разработки конкретного проекта: «Недостаточное согласование сервисов программы», «Эргономика основных функций программы».

Непрерывная интеграция

Непрерывная интеграция – это поддержка качества без сбоев на всех этапах проекта. Данный элемент включает как автоматическую интеграцию, так и выполнение регрессивных тестов каждый раз, когда кто-либо из заинтересованных в проекте сторон его проверяет. На практике это случается несколько раз в день. Регрессивное тестирование обычно приводит к тому, что дефекты в программе обнаруживаются практически сразу после того, как они возникли (Когда в программе появляются модули, выделенные тестами красным, вся команда переключается на решение задачи: как сделать код вновь «зеленым».

Информативная рабочая среда

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

Запланированные совещания анализа всего проекта

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

Улучшение качества по Agile

Один из принципов Agile-манифеста гласит: «Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы». Ретроспективный анализ – механизм, который большая часть Agile-групп разработчиков применяет для общих выводов о своей работе. Команда программистов обращает внимание на то, как хорошо была выполнена работа во временных отрезках-таймбоксах. Отсюда уже можно делать вывод о том, что можно скорректировать и как работать по-другому, если это нужно. Наиболее серьезные изменения становятся потребительскими историями и попадают в стратегические планы проекта. Так в общих чертах обычно выглядит внедрение новых процессов в русле концепции Agile.

Перевод: сотрудник «Единый Стандарт» Валентин Рахманов.