Публикуем статью на основании доклада Сергея Поволяшко (Харьков, Украина) с конференции менеджеров проектов в ІТ Software Project Managment Conference
Начнем с аналогии. Вы заказываете новую мебель, хотите, чтобы было сколько-то тумбочек, шкафчиков, полочек. Определенных размеров, из определенных материалов, в определенный срок, за определенную сумму. И вам все равно, сколько человек, какой квалификации, какими инструментами и в какое время суток это будут делать, правда?
Важен результат — количество, материалы и размеры всех компонентов.
Рассмотрим в моем докладе следующие моменты:
— что такое размер ПО и почему он важен;
— методики его определения;
— когда имеет смысл его определять и применять;
— модель размера;
— для чего полезен размер;
Мы не будем говорить о научных методиках, так как о них можно почитать и без меня, поговорим о практическом применение. Я бы хотел вести доклад в интерактивном формате, чтобы мы вместе оценивали ситуацию. Итак, начнем.
Для ответа на этот вопрос, вы соотносите его с какой-то базовой величиной. Например, история, ожидания заказчика, количество сотрудников, критичность багов, стадия разработки приложения. О них и поговорим более подробно.
Вот обратите внимание на данные картинки, как вы думаете, что в этих схожих процессах действительно важно? Нам важен результат, для конкретного случая он измеряется в кубометрах. Например, вы заказываете фундамент для своей дачи. Естественно, исходя из ваших ресурсов, у вас будет один из двух вариантов, но, в конечном итоге, вам важно, чтобы было вырыто определенное количество кубометров. Мы получаем первый вывод, в любой работе, стартапе, проекте важен результат, следовательно, Результат (размер результата) – первичен, а способ достижения результата – вторичен.
Давайте снова глянем на схожие картинки и найдем ряд важных критериев и на них.
Определив следующие важные критерии, давайте взглянем на формулу. Она достаточно условна и нужна для понимания.
Количество = (производительность * размер) / качество
, где Размер, еще раз подчеркну, условная единица объема работы.
Чем хуже делаем, тем больше исправляем – яркий пример этой формулы.
Это все плавная прелюдия к тому, чтобы поговорить о методиках и единицах с точки зрения размера.
Первым пунктом идет самая древняя и самая неправильная методика – строки кода, это всем ясно почему. Потом идет также старая методика – функциональные точки, более научные, и если честно, до недавнего времени я не встречал человека, который бы пользовался им. Не буду впадать в подробности, только отмечу, что они основаны на отличиях с точки зрения пользователей системы. В конце я предоставлю слайд со ссылками на более подробную информацию о затронутых в докладе темах.
Следующий пункт – use case points. Это тоже достаточно замудренная методика, но, по моим ощущениям, она ближе к жизни, ближе к реальности. Она основана на диаграммах Использования. Если в спецификации написано описание тест-кейсов, то преобразую сложность тест-кейсов и, добавляя сложности поправочного коэффициента (есть даже специальный софт, который позволяет это сделать), тоже можно получить case points, которые тоже приводят к человеко-часам. Story points располагаются внизу. Почему? Потому что Story points могут отличаться внутри проекта и внутри команды, в зависимости от объемов проекта до настроения команды и формата ее работы.
И собственно, последний пункт — Специфичные единицы и методики, осмысленно отражающие объем работ или его существенную часть, по поводу которой у меня в конце презентации будет описание. Специфические означают, что есть определенный род деятельности, где есть стандартные типичные операции, которые можно вывести с учетом размера проекта, о котором я буду попозже говорить.
Хорошо, а теперь давайте выделим почему важен размер?
- Отображение реального объема работ;
- Абстрагирование от уровня знаний и опыта исполнителей(все сотрудник выполняют задачу за разное время);
- Использование в метриках для оценки производительности (качества, количества, SLA, KPI (надо учитывать и размер, без него не работает));
- Постановка и контроль ожиданий по «отдаче» (допустим, все знают, что раз в неделю от команды тетсирования ждут тест-репорт раз в неделю);
- Последующий расчет трудозатрат, сроков;
- Прогнозирование времени, сроков, качества;
- Использование в Модели Размера (все эти function points, user case points, story points и т.д. и составляют такие модели размера)
Без такого «веса», который дают критерии и метрики, сам по себе размер тоже не имеет значение. Поэтому нужно понимать, в каких случаях размер нужен. Коротко можно указать на слайде.
Примерами могут стать регрессионное тестирование, оценка количества сотрудников в команде, предоставление бюджета проекта и т.д. Если мы говорим о том, что размер нужен, значит, существуют ситуации, когда размер не важен. Итак, для справедливости, давайте их отметим.
С учетом новых знаний давайте перейдем к кейсу из реальной жизни, который сделали ребята в нашем «Стратоплане», заранее хочу выразить им свою благодарность, что они это сделали. В чем заключается кейс? В чем заключается работа?
Есть некоторый продукт, у которого есть ядро, такое вот симпатичное хорошее ядро, на этот продукт есть конечный заказчики, которые хотят его конфигурировать. Сам по себе продукт включает высоко конфигурированное ядро, на которое можно написать формы, поля и тд.
Каждый заказчик приходит и просит, чтобы это ядро было сконфигурировано под определенные нужды бизнес-процесса. Что они под этим понимают? Например, дополнительно конфигурируют формы экрана, бизнес-логика, отчеты, запросы и т.д. Это ядро получается некоторой базой, к которой применяются некоторые конфигурационные инструментарии и получают определенный продукт. Хоть это и звучит сложно, это довольно просто.
В результате эта конфигурация разворачивается на это ядро. Повторюсь, что необходимость в таком продукте возникает, когда деятельность типична и часто повторяется, есть дискретный элемент. Подумали, собрали данные, сколько человеко-часов занимает то или иной инструмент сконфигурированной логики и что получилось?
Получилась такая модель Размера, которой достаточно для предварительной оценки. Она полностью передает всю идею.
В первой строке описаны, какие дискретные элементы у нас есть: экранные формы, отчеты, бизнес объекты и т.д. Это количество условных единиц в столбцах, «х2» и «х3» — это то, во сколько раз увеличится время для такого дискретного элемента и, следовательно, количество кейсов. В зависимости от спецификации берутся данные и считаются, составляя чистый размер. Затем идет Калибровка, где учитываются требования, где 1 – «хорошо», а 3- нет. Учитываем, были ли прошлые наработки, затем насколько высок уровень исполнителя. Затем все перемножается и получается калиброванный размер. И взяв для примера, 1 ед. за 2 человека-часа, мы получаем конечный критерий, учитывающий особенности для нескольких спецификаций. В реальной жизни у этой модели больше коэффициентов, но для наглядности модели достаточно и этих. Модель Размера хороша, когда позволяет срочно предоставить данные по срокам для заказчика, например.
Как и обещал полезные ссылки, которые могли быть полезны для более глубокого изучения темы:
- Подборка материалов о подходах оценки трудозатрат it-tuning.com/?p=1537
- Сравнение методов оценки стоимости проектов www.ntrlab.ru/publications/190/
- International Function Point User Group – IFPUG (www.ifpug.org)
- csse.usc.edu/csse/research/COCOMOII/cocomo_main.html
- sunset.usc.edu/csse/research/COQUALMO/
- Поиск по FPA, UCP, COCOMO, Story Points
Автор: Polazhenko
