О качестве требований в ИТ проектах, на чистоту (с позиции команды разработки). Часть 1

По мотивам моей статьи, изданной ранее…

Вступление

Получить бы медаль, а уж с обратной ее стороной найдем, что делать.
(Георгий Александров)

В подавляющем большинстве работ, посвященных управлению требованиями, которые мне довелось читать [1], [2], [3] и другие, авторы хороводят вокруг заказчика, акцентируя основное внимание читателей, на том, как максимально эффективно организовать работу именно с ним. Ну и конечно, львиная доля труда обычно посвящена вопросам преобразования собранной информации в некие проектные решения, моделирующие разрабатываемую систему, а также оформление их со спецэффектами, бантиками и рюшами. Разумеется это все важно и я ни в коем случае не хочу умолить значение этих аспектов формирования требований, но есть еще и обратная сторона. Ведь дальше требования должны попадать непосредственно в “цех” по производству программного обеспечения. И именно там они, до самого рождения целевого продукта, останутся основным сводом законов и правил, по которым он будет зарождаться и являться миру. Этот факт уже сам по себе определяет важность того, насколько точно требования должны соответствовать интересам специалистов, призванных воплотить их в конечном продукте.

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

Почему я взялся за написание этой статьи

Именно работа аналитика в ИТ проектах призвана показать заказчику — продукт его мечты.
Ибо программисты с этой задачей чаще всего не справляются.

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

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

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

Для чего и для кого написана эта статья

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

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

Цель статьи — помочь аналитикам (особенно молодым), совместно с командой, разрабатывающей ПО, найти свой идеальный вариант спецификаций требований, включая: состав, уровень детализации, форму, порядок представления информации и т.п.
Эффект должен быть достигнут за счет того, что члены команды не будут больше тратить время на разгадывание сути, используемых в требованиях артефактов и на преобразование их из формата, тешащего самолюбие аналитика, в формат максимально пригодный для собственного употребления. Им больше не потребуется выискивать нужную информацию «размазанную» по требованиям. Наоборот, материалы, которые будут предоставлены каждому участнику, шпаг за шагом будут заботливо вести их в процессе выполнения своей работы по проекту от релиза к релизу.

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

Обсуждение «конвейера» и технологической линии разработки ПО, само по себе достойно отдельной статьи.

Заманчиво? Тогда идем дальше…

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

1. Главные потребители спецификаций требований – разработчики. Для них важно насколько выгодно эти спецификации будут отличаться, с точки зрения быстрого и точного преобразования их в программный код.
2. Для менеджера проекта важно — насколько удобно он сможет «нарезать» спецификации на атомарные задачи для остальных членов команды. Атомарные задачи, должны с одной стороны — являться четким, однозначным заданием исполнителю, а с другой — быть прогнозируемым мерилом использования ресурсов, для составления детального плана проекта.
3. Для специалистов, обеспечивающих качество продукта — важно насколько удобно им будет формировать по требованиям – сценарии тестирования, карты приемки и т.д.

При такой расстановке акцентов, в процессе формирования требований необходимо очень четко ориентироваться на технологии, используемые командой разработчиков. Поскольку в одной статье тяжело охватить максимальный спектр предметных областей и применяемых технологий, я буду рассматривать в качестве примера — кластер учетных систем, использующих реляционные базы данных и технологические платформы, позволяющие применять готовые компоненты. Под компонентами, в данном случае, следует понимать шаблоны решений, агрегирующие функциональные возможности популярных сервисов (например: компонент работы со списками, компонент представления формы для редактирования данных, поисковая подсистема, подсистема разграничения прав доступа и т.д.). Для того чтобы изложение материала сделать более наглядным, я включил в него фрагменты спецификаций требований учебного проекта: «Автоматизация процесса Управления требованиями».

ОПРЕДЕЛИМ ПОДХОДЯЩИЙ ВАРИАНТ СТРУКТУРЫ ДОКУМЕНТА СПЕЦИФИКАЦИЙ

За некачественные требования всегда расплачивается заказчик. Иногда сразу, иногда в рассрочку

Возможно, после следующих утверждений у меня появится много критиков, но возьму на себя смелость рассмотреть спецификации требований, как интерфейс между аналитиками и разработчиками. Да есть “натяжка” в этом утверждении, и поэтому обратимся для уточнения термина к энциклопедии. «Интерфейс — совокупность возможностей, способов и методов одновременного действия (в том числе посредством обмена информацией между ними) двух имеющих общее разграничение, то есть не связанных линейно, информационных систем, устройств или программ, определяемая их характеристиками, а также характеристиками соединения, сигналов обмена и т. п.». Уже чувствуете схожесть?

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

Рисунок 1. – Укрупненная схема взаимодействия команды ИТ проекта

Для того чтобы отбросить все лишние артефакты, разработанные аналитиком (они на картинке обозначены как «Требования») и востребованные на этапе проектирования, но бесполезные, а иногда и вредные для представления их разработчикам, определимся с объектами, которые должны быть использованы в нашем интерфейсе (спецификациях). Для этого необходимо ответить на вопрос: чем же оперируют разработчики, создавая конечный продукт? Поскольку в качестве примера был выбрани вариант разработки ПО на базе платформы, то целевую систему можно представить в виде набора компонентов, постоянное слаженное взаимодействие которых и приводит к “эффекту работающей программы”, как показано на Рисунке 2.

Рисунок 2. Компонентная модель Целевой системы.

Таким образом в спецификациях для выбранного варианта обязательно должны быть подробно описаны экземпляры элементов, указанных на Рис. 2 и способы их реализации. То есть системный аналитик должен перевести плоды своей работы (или работы бизнес аналитика), на рельсы используемых разработчиками технологий, описав конкретные элементы, алгоритмы их поведения и т.д., в терминах и понятиях выбранной платформы. Степень глубины трансляции может варьировать, в зависимости от компетенции системного аналитика и потребности команды разработчиков.

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

Рисунок 3. Модель варианта основного процесса создания ПО.

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

Таким образом в наш вариант структуры документа обязательно должны войти следующие разделы:

1. Сущности предметной области;
2. Интерфейс пользователя;
3. Процедуры, связанные с событиями интерфейса пользователя;
4. Вспомогательные процессы (триггеры, постобработки и т.п.);
5. Периодические задания;
6. Шаблоны отчетов;
7. Права доступа;

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

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

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

Автор: ARadzishevskiy

Источник