ОЦЕНКА ЗАТРАТ И ТРУДОЕМКОСТИ РАЗРАБОТКИ ПО КАК СПОСОБ УЛУЧШЕНИЯ КАЧЕСТВА ТРЕБОВАНИЙ

28.02.2019 at 17:10 Оставьте комментарий

Grigory Grin

Предлагаю вниманию читателей статью, написанную Григорием Грином для он-лайн журнала Requirements Engineering Magazine на английском языке и опубликованную 27 февраля 2019г

When the rubber hits the road –  Improving requirements quality by effort estimates.

Мне показалось, что такой взгляд на оценку стоимости и затрат при разработке ИТ — проектов, в русскоязычных публикациях не встречается, и будет интересен нашим аналитикам и руководителям проектов. Перевод сделан мной и согласован с автором. Нэлли Грин 

Введение

Существует ряд критериев качества требований. IREB Syllabus (1) группирует критерии по трем параметрам: содержание, документация и согласованность. Группа согласованность включает следующие три критерия:

  • «согласованы»,
  • «согласованы после изменений»,
  • «разрешены конфликты».

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

В представляемой статье рассматриваются взаимосвязи между требованиями и оценками затрат и трудоемкости.
Статья написана для варианта разработки ПО, при котором:

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

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

Базовая концепция по оценке стоимости разработки ПО

Тем, кто только начинает работу по оценке программного обеспечения, можно порекомендовать отличную книгу по этому вопросу (2):
«Оценка программного обеспечения: демистификация черного искусства» от Стив Макконнелл, которая опубликована в 2006 году.
Ничто из этой классической работы не устарело в течение прошедшего более чем десятилетия. Это обязательное чтение для всех, занятых в отрасли разработки ПО.
Начнем с повторения некоторых основных концепций, представленных McConnell, а затем перейдем к другим темам, основанным на собственном опыте разработки автора статьи.

Сравнительно просто оценить параметры некоторых объективно существующих объектов. Например, высота дерева. Все становится сложнее при оценке чего-то в будущем, чего еще не существует. Для того же дерева — какова будет высота дерева через 5 лет? И еще более сложно, если оцениваемый показатель зависит от усилий, которые будут приложены в будущем.
В отношении разработки ПО обычно оцениваются общие затраты и/или трудозатраты, необходимые для реализации определенных требований или набора требований.

Здесь критически важно различать следующие понятия:
Estimate — Оценка — это прогноз, предположение или мнение. Например: мы можем быть готовы через 4-6 недель.
Target – Цель, которая может быть зафиксирована в плане или ином документе. Например: нам нужно представить релиз до начала сезона отпусков.
Commitment — Обязательство — это обещание (возможно, закрепленное договором). Например: релиз будет представлен к 1 ноября.

рис 1

Рисунок 1 – и оценка и цель влияют на обязательство

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

Другим важным моментом в определении оценок является то, что они не простые числа, они являются распределениями вероятностей. Если вы скажете, высота дерева через 5 лет составит 4,52 м, вы на 100% уверены? 60% уверены? Какова вероятность того, что дерево вырастет до высоты между 4,5м и 4,6 м? Насколько она отлична от вероятности того, что дерево будет находиться между 4 и 5 м? Всегда гораздо полезнее указать диапазон и задать вероятность того, что целевой параметр находится в этом диапазоне. Например. Я на 90% уверен, что дерево будет между 4 и 5 м.

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

рис 2

Рисунок 2 Оценка как распределение вероятностей. Рисунок из упоминавшейся книги McConnel-а (Рис.1-3)

Ещё один терминологический аспект, который важно отметить, это разница между (accuracy) правильностью, достоверностью оценок и их (precision) точностью.
Оценка, выраженная в виде интервала, является достоверной, если оценочный параметр действительно находится в указанном диапазоне (от 4 до 5 м в приведенном выше примере про дерево). Точность — это длина интервала (1 м в том же примере). Мы хотим, чтобы наши оценки были в первую очередь достоверными, и лишь потом – настолько точными, насколько это необходимо. Типичная проблема заключается в очень точной оценке, которая не является при этом достоверной. Проект займет 4-5 недель (для проекта, который займет 3 месяца).
Достоверность прогноза может быть оценена только ретроспективно, когда известна действительная величина прогнозируемой переменной. Точность может быть определена априорно.
В книге (2) подробно описываются и обсуждаются очень полезные методы оценки, которые выходят за рамки данной статьи.

Оценки и управление проектом

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

рис 3

Рисунок 3 Процесс оценки до подписания контракта.

Предварительная оценка стоимости в интервале 200 -250 тыс. евро, первоначальное предложение заказчику 230 тыс. евро, после согласования контракта окончательно утвержденная цена – обязательство – 210 тыс. евро.
Для проектной команды цена из контракта теперь является обязательной и переставая быть выходом, становится частью входа.

рис 4

Рисунок 4 Процесс после утверждения контракта – обязательство теперь часть входа, дополнительное требование для проектной команды.

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

Команда проекта может (и должна) выполнять переоценку предполагаемого объема работ и затрат и в начале проекта, и в дальнейшем — в ходе его продолжения. При этом, не достаточно лишь спрогнозировать, что проект с фиксированной ценой в 210тыс евро закончится с затратами в 300тыс евро. Необходимо своевременно обратить внимание на эту ситуацию, и принимать все необходимые контрмеры, чтобы вернуть проект в прибыльный форватер.
Можно, например :
• Целенаправленно выбирать способы решения с учетом минимизации трудоемкости разработки;
•    Активно управлять ожиданиями клиентов;
• Мониторить взаимоотношения с клиентами с целью своевременного формулирования запросов на изменение требований (CR) и получения дополнительного финансирования в случае значительного увеличения трудоемкости проекта;
• В худшем случае, повторно согласовать цену контракта с клиентом.

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

Представление оценки

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

tabl1
Рисунок 5 Таблица оценок с двухуровневым разбиением функций

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

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

tabl2
Рисунок 6 Таблица оценок с разбиением на функции и компоненты

Такую матрицу оценок можно сохранять в электронной таблице, например, используя Microsoft Excel. Важно, чтобы эта электронная таблица оценок изменялась синхронно с соответствующими спецификациями требований – каждой версии спецификаций требований должна соответствовать таблица оценок, им должен быть присвоен один и тот же номер версии. Даже без сложного инструмента управления конфигурацией отдельная версия файла оценок может быть сохранена с суффиксом версии в его имени, например. «Project_Estimate_v2.0.xlsx». Различия между версиями можно указать просто путем окраски изменяющихся / добавленных / значений. Это позволяет всем заинтересованным сторонам видеть, как изменились оценки в связи с изменениями требований. Если необходимо, история версий может храниться в одном файле отдельными листами таблицы.

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

Оценки в жизненном цикле управления требованиями

В последней части речь пойдет о сроках, когда процесс оценки должен быть запущен.
Автору часто приходилось видеть подход «водопада» в процессе обсуждения контракта:
• Мы начинаем с анализа. Мы говорим с клиентом, чтобы понять его потребности. Мы записываем все в длинный документ требований. Мы формулируем нефункциональные требования. Мы проводим несколько циклов обсуждений и согласований с клиентом. В конце концов мы получаем спецификацию требований в «согласованном» состоянии.
•Теперь мы оцениваем трудоемкость, основываясь на согласованных спецификациях.
• Дальше мы делаем коммерческое предложение с ценой, основанной на оценке трудоемкости и затрат.
• Наконец, мы надеемся получить подписанный контракт и не можем дождаться начала разработки.
Вместо этого мы часто удивляемся, когда клиент, впервые увидев цену, внезапно меняет свое мнение, исключает половину функций из объема работ, меняет требования, просит альтернативные решения и / или объяснения или, в худшем случае, просто отказывается от проекта или обращается к другому разработчику.
Это происходит, потому что для клиента польза (результат), которую он получит от нашего предлагаемого решения, очень сильно зависит от цены, которую он должен платить за это решение. Если цена слишком высока, начинается переосмысливание важности для клиента сформулированных требований. Это объясняет, почему во многих случаях клиент запрашивает цену (или хотя бы предварительную «оценку»), прежде чем исполнитель сможет провести разумный анализ.

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

Заключение

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

Ссылки
(1) IREB CPRE Foundation Level Syllabus: https://www.ireb.org/en/downloads/tag:syllabi
(2) Steve McConnel, “Software Estimation: Demystifying the Black Art”, Microsoft Press, 2006.

 

Реклама

Entry filed under: Копилка Мастерской, Методы и технологии анализа, Управление проектами. Tags: , .

Проект по разработке профессионального стандарта «Бизнес-аналитик» УСПЕШНО ЗАВЕРШЁН!

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход /  Изменить )

Google photo

Для комментария используется ваша учётная запись Google. Выход /  Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход /  Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход /  Изменить )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Подписка на новости сайта

Подпишитесь на новости сайта (RSS)

RSS

Архивы

Рубрики

Главные книги аналитика

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

Требования для программного обеспечения: рекомендации по сбору и документированию |Илья Корнипаев
Анализ требований к автоматизированным информационным системам | Юрий Маглинец
Пользовательские истории. Гибкая разработка программного обеспечения |Майк Кон


%d такие блоггеры, как: