![Закрыть [x]](http://dw1.s81c.com/i/c.gif){kind=small}
На написание этой статьи автора подвиг личный опыт. Когда перед автором была поставлена задача организовать группу контроля качества процессов разработки программного обеспечения, из-за отсутствия целостного методологического материала ему пришлось из отрывочных материалов собирать необходимые компоненты. Была разработана система показателей качества процесса, поставлены задачи и оговорены работы, выполняемые группой. В конечном итоге проект группы был утверждён, и созданная группа в настоящее время успешно функционирует в рамках крупного подразделения с перспективой расширения на весь департамент.
По причине того, что эта задача видится автору достаточно актуальной, а также вследствие успешного развития идей, на основе которых было создано подразделение, полученный опыт излагается в данной статье. В материалах статьи даны общие рекомендации по созданию подобного подразделения, приведены примеры из практики автора.
Моменту постановки перед автором вопроса о создании группы предшествовали два года адаптации и внедрения методологии и инструментальных средств поддержки методологии разработки ПО. В течение двух лет организация проходила путь поиска и создания своей уникальной методологии, по истечении которых возникла необходимость контроля выполнения внедрённых правил. То, что было запланировано в ходе внедрения методологии, подлежало выполнению участниками процессов, контролю и воздействиям со стороны руководства (рисунок 1).
Рисунок 1. Цикл Деминга
Задачи группы в этом процессе – осуществление механизма контроля и предоставление руководству информации для принятия решений, контроль выполнения участниками процессов методологии (рисунок 2). Эти задачи связаны, так как некачественное выполнение процессов ведёт к получению искажённых, неактуальных данных по процессам или, в худшем случае, к невозможности получения информации вообще.
Рисунок 2. Задачи группы
Была необходима основа в виде системы показателей качества процессов, на основании которой можно было бы строить саму группу контроля.
Организация штата подразделения
На организационно-штатном уровне группа была сформировано из специалистов по процессам разработки программного обеспечения, с прямым подчинением руководителю всего подразделения по разработке ПО. Независимость группы от непосредственных исполнителей работ по проектам разработки является дополнительной гарантией достоверности информации, производимой группой, и необходимым условием для предупреждения оказания какого-либо давления со стороны менеджеров команд проектов. Этим также повышается статус группы в организации и значимость выдаваемых ею рекомендаций, отчётов и сводок.
В настоящее время, в связи с планируемым расширением сферы влияния группы за пределы своего подразделения, рассматривается вопрос о выводе её в подчинение менеджменту департамента.
Разработка системы показателей
Формирование системы показателей качества процессов было выполнено так, что верхний уровень составили сами процессы. Далее они были детализованы там, где это потребовалось, и на основе детализованных процессов были приняты контролируемые показатели процессов.
Например, процесс управления изменениями был представлен в системе показателей как показатель прозрачности выполняемых работ и стандартизации информационных потоков. В таблице 1 представлено описание этого критерия с детализацией.
Таблица 1. Прозрачное управление изменениями
| Прозрачное управление изменениями | Регистрация и поддержание актуализации сведений о поступающих запросах и работах, выполняемых по этим запросам, создают прозрачную картину работы подразделений. Имея такую картину, руководство получает достоверные данные для принятия оперативных решений, составления прогнозов, получения показателей для мотивации персонала. Далее требования к процессу управления изменениями разбиты на 3 группы с описанием и детализацией по параметрам, которые подлежат контролю. |
|---|---|
| Прозрачность работы с заказчиком | Регистрация всех поступающих от заказчика заявок. |
| Корректная регистрация всех входящих запросов | Содержание описательной части запросов, ссылки на источник и заказчика. |
| Обеспечение актуальной информации по запросам в системе УИ | Своевременное отражение состояния работ по запросам в системе управления изменениями. |
| Унифицированная форма хранения запросов | Формат оформления запроса определён в схеме обязательными для заполнения полями. Для отдельных проектов могут контролироваться и не обязательные поля. |
| Прозрачность работы с субподрядчиком | Регистрация всех заданий, передаваемых в работу субподрядчику. Организация взаимодействия с субподрядчиком через систему управления изменениями. |
| Регистрация всех работ субподрядчика | Субподрядчик получает задания только через систему управления изменениями. Передача иными путями, в обход системы, является нарушением процесса. |
| Обеспечение механизма получения отчёта от заказчика в "реальном времени" | Организация обратной связи от субподрядчика о выполненных работах. Частота синхронизации устанавливается с учётом имеющихся договоренностей о сроках выполнения заданий. |
| Прозрачность работы подразделений | Распределение работы по запросам внутри подразделения регистрируется в системе управления изменениями. |
| Регистрация работ подразделения | Задания исполнителям выдаются через систему управления изменениями. Задачу для исполнителя назначает руководитель подразделения или руководитель проекта. |
| Обеспечение актуальной информации по выполнению работ | Своевременные отчёты по выполненным задачам. Данные в системе отражают реальное состояние работ. |
После составления системы показателей были определены уровни воздействий, оказываемых группой на участников процесса всех категорий.
Определение типов и уровней воздействия на процесс
Во-первых, непосредственные исполнители работ. На этом уровне необходимо контролировать выполнение поставленных задач в соответствии с указанными сроками. Для напоминания исполнителям о назначенных им работах была организована автоматизированная рассылка электронных писем с перечислением назначенных задач в системе управления изменениями.
Во-вторых, менеджеры по направлениям, ответственные за рассмотрение поступающих от заказчика запросов. В соответствии с принятыми в организации правилами, на принятие решения по запросу был отведён определённый лимит времени. При отсутствии реакции на запрос в течение оговоренного времени менеджер и ведущие специалисты направления получали оповещения об имеющихся в системе управления изменениями запросах. При отсутствии изменений в запросе после этого, вопрос должен эскалироваться на уровень менеджера подразделения.
Качество заполнения информационных сущностей системы управления изменениями подлежало контролю на регулярной основе, с оповещениями в случае некорректного заполнения инициатору и его менеджеру.
Задания на выполнение работ с неуказанным внешним источником, вызвавшим инициацию этих работ, изначально трактовались как внутренние издержки организации. Позднее было выявлено, что сотрудники могут оформить работу по заявке заказчика без регистрации самой заявки, в связи с чем таким заданиям стало уделяться более пристальное внимание.
Контроль выполнения описанных процессов обеспечивает получение достоверных данных о показателях работы всего подразделения из системы управления изменениями.
Руководству департамента ежемесячно представляется на рассмотрение отчёт по данным системы – количественные метрики по поступившим и обработанным запросам пользователей, по дефектам, выявленным на стадии тестирования и эксплуатации, метрики времени обработки запросов и т.д. (таблица 2).
Таблица 2. Метрики для отчета руководству
| # | Показатель | Комментарии |
|---|---|---|
| 1. | Число запросов за отчётный период | Общее число поступивших запросов |
| 2. | Состояния жизненного цикла запросов | Общее число поступивших запросов с разбивкой по состояниям жизненного цикла запросов на отчётный момент. |
| 3. | Соотношение поступивших и обработанных (из этого числа) запросов за отчётный период | Соотношение поступивших и обработанных (из этого числа) запросов. |
| 4. | Число дефектов, найденных на стадии тестирования и на стадии эксплуатации | Мониторинг качества тестирования разрабатываемого программного обеспечения и качества передаваемого заказчику продукта. |
| 5. | Число запросов от каждого заказчика | Выборки запросов по заказчикам услуг. |
| 6. | Выборки запросов по стадиям жизненного цикла | Статистика по запросам, находящимся на стадии реализации, отложенным, уточнённым и т.д. |
| 7. | Число запросов с временем первичной реакции в рамках регламента и с временем, превышающим регламентную норму | В регламенте оговорен временной лимит на принятие первичного решения по поступившему запросу – определение ответственного исполнителя, который проводит уточнение запроса и собирает при необходимости дополнительную информацию для вынесения запроса на уровень совета по контролю изменений. |
Подборка данных для отчёта не статична, есть ряд базовых показателей, которые стабильно интересуют руководство, но, в зависимости от тех или иных условий, регулярно появляются новые требования к представляемому отчёту.
Утверждённые показатели добавляются в автоматизированный отчёт применяемой среды формирования отчётов.
Приложение. Система показателей качества процессов разработки ПО
Рисунок 3. Система показателей качества процессов разработки ПО
Зайдуллин Рустам работает в области информационных технологий с 2005 года. Имеет опыт адаптации и внедрения RUP и инструментальных средств IBM Rational. Сертифицированный специалист по следующим продуктам: IBM Rational ClearCase, Microsoft Project 2003. Является ведущим инженером группы контроля качества процессов разработки программного обеспечения управления "ТатАСУнефть" ОАО "Татнефть".
Новичков Александр работает в области информационных технологий с 1994 года. Является руководителем отдела консалтинга и внедрения IBM Rational. Участвовал более чем в 20 успешных проектах внедрения IBM Rational в таких организациях как Банк внешней торговли, ОАО «Татнефть», Национальный банк «ТРАСТ», Банк «Русский стандарт», ОАО «Иркут Авиа», ЗАО «АйТи», ЗАО «Аплана», Сбербанк России, Центральный банк Российской Федерации, ОАО «Русский алюминий» и многих других. Имеет более 30 публикаций научных и научно-популярных материалов. Является сертифицированным специалистом по следующим продуктам IBM Rational: ClearCase for Windows, ClearQuest for Windows и UCM Essentials. За время работы в консалтинге им обучено более 500 специалистов ведущих IT-компаний России и СНГ. Является руководителем отдела внедрения и консалтинга в компании СМ-Консалт (www.cmcons.com). Связаться с ним можно по адресу rational.tools.info@gmail.com
Содержание
Теги
КнопкаПопулярные теги отображает самые распространенные теги для данной области контента (например: Java, Linux, WebSphere).
Кнопка Мои теги отображает Ваши теги для данной области контента (например: Java, Linux, WebSphere).
Популярные теги статьи |
Мои теги статьиПерейти к списку тегов
Популярные теги статьи |
Мои теги статьи