Как рассчитать трудозатраты программиста

Оценка трудоемкости и сроков разработки программного обеспечения

Оценивать время и трудоемкость разработки можно двумя подходами:

основываясь на формулах и коэффициентах;

основываясь на своем личном опыте.

Кратчайшие сроки — это сколько дней?

Кратчайшие сроки — это минимальное количество из возможно затраченных дней на разработку продукта. Сколько это может быть дней — нужно считать, потому что длительность разработки проекта — это переменная величина, которая задается не точной датой, а какими-то временными рамками.

Кратчайшие сроки: технический подход в расчетах

Технические расчеты времени на разработку программного продукта ведутся на основании ГОСТ а 19.102-77 «Стадии разработки». Суть в том, что есть среднестатистические временные затраты на каждую отдельную стадию разработки и формула, как это все складывается. Результатом таких расчетов будет среднее время на разработку конкретного продукта.

Коэффициенты и обозначения, которые сопровождают технический расчет:

Т _бс — подготовка блок-схем алгоритмов. Рассчитывается по формуле Т _бс = Q/50*К.

Т _н — написание программного обеспечения. Расчет ведется по формуле Т _н =Q-1.5/50*К.

Т _д — документирование продукта. В ремя берется фактическое и обычно составляет 40 чел/часов.

Общее время на создание всего продукта подсчитывается по формуле:

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

Кратчайшие сроки: подсчет на основе личного опыта

Ключевые факторы при оценк е личным опытом

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

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

Заключение

Мы будем очень благодарны

если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.

Источник

Расчет трудозатрат на разработку программного продукта

Трудозатраты (трудоемкость) разработки компьютерной программыскладывается из целого ряда затрат:

где t_u – затраты труда на исследование алгоритма решения задачи;

t_n =- затраты на программирование;

t_отл – затраты на отладку программы на ПК;

t_д – затраты на подготовку документации по задаче.

Затраты труда на изучение описания задачи с учетом уточнения описания и квалификации программиста измеряются в человеко-часах и определяются по формуле:

, (2)

где Q – число условных операторов;

В – коэффициент увеличения затрат;

К – коэффициент квалификации разработчика (зависит от стажа работы программиста)

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

где q – предполагаемое число операторов;

с – коэффициент сложности программы (1…2);

р – коэффициент коррекции программы в ходе ее разработки (0,5…1).

При разработке учебных компьютерных программ, предполагаемое число операторов (q) включает количество студентов, преподавателей, техников-лаборантов, использующих программный продукт в учебном процессе.

Для расчета затрат на оплату труда разработчика можно взять средние значения с и р.

― предполагаемое число операторов q=130;

― коэффициент сложности с= 1,5;

― коэффициент коррекции р=0,75.

Исходя из этих условий, воспользовавшись формулой (3), определим число условных операторов Q:

Q = 130 * 1,5 * ( 1 + 0,75 ) = 341 чел.

В – коэффициент увеличения затрат характеризует увеличение затрат труда вследствие недостаточного полного описания задачи, уточнений и некоторой доработки. Этот коэффициент может принимать значения от 1,2 до 5. (можно взять среднее значение). Возьмем его среднее значение – 3,1.

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

б) от двух до трех К=1;

в) от трех до семи К=1,3…1,4;

г) свыше семи лет К=1,5. 1,6.

Программированием я занимаюсь не более двух лет, поэтому коэффициент квалификации принимает дискретное значение равное 0,8.

Рассчитаем затраты труда на изучение описания задачи с учетом уточнения описания и квалификации программиста, подставив выбранные значения в формулу (2):

t_u = ( 341 * 3,1 ) / ( 75 * 0,8 ) = 1057 / 60 = 18 чел.

t_a – затраты труда на разработку алгоритма решения задачи в человеко-часах и рассчитываются по формуле:

, (4)

где Q – число условных операторов;

К – коэффициент квалификации разработчика;

t_n –затраты времени на программирование определяются методом самофотографии и составляют примерно 20-30% от общих трудозатрат.

Подставляя Q=341, K=0,8, В=3,1 и принимая коэффициент при К равным 60, определим затраты труда на разработку алгоритма решения задачи:

t_a = ( 341 * 3,1 ) / ( 60* 0,8 ) = 1057,1 / 48 = 22 чел.час

Затраты на отладку программы на ПК при автономной откладке одной задачи определяется по формуле:

, (5)

где Q – число условных операторов;

К – коэффициент квалификации разработчика.

Подставляя Q=341, K=0,8, В=3,1 и принимая коэффициент при К равным 40, определим затраты на отладку программы на ПК при автономной отладке одной задачи:

t_{отл (авт)} = ( 341 * 3,1 ) / ( 40 * 0,8 ) = 1057,1 / 32 = 33 чел.час

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

Т_отл = 1,5 * 33 = 50 чел.час

Затраты труда на подготовку документации по задаче складываются из затрат труда на подготовку материалов в рукописи и затрат на редактирование, печать и оформление документации, определяются по формуле:

где t_дn – затраты труда на подготовку материалов в рукописи;

Затраты труда на подготовку материалов в рукописи определяются по формуле:

, (8)

где Q – число условных операторов;

К – коэффициент квалификации разработчика.

Подставляя Q=341, K=0,8, В=3,1 и принимая коэффициент при К равным 160, определим затраты труда на подготовку материалов в рукописи:

t_n = ( 341 * 3,1 ) / ( 160 * 0,8) = 1057,1 / 128 = 8 чел.час

Затраты на редактирование, печать и оформление документации прямо пропорционально зависят от затрат на подготовку материалов в рукописи. Эти затраты определяются по формуле:

, (9)

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

По формуле (7) определим затраты труда на подготовку документации по задаче:

Затраты времени на программирование, определены методом самофотографии и составляют 44 чел.час.

Используя рассчитанные данные, определим суммарную трудоемкость разработки по формуле (1), учитывая, что затраты труда непосредственно на программирование составляют 44 чел.час:

T = 18 + 22 + 44 + 33 + 14 = 131 чел.час

Расчет трудозатрат на разработку программного продукта сводится в таблицу 21.

Дата добавления: 2015-04-21 ; просмотров: 10782 ; ЗАКАЗАТЬ НАПИСАНИЕ РАБОТЫ

Источник

Оценка трудозатрат в разработке ПО для начинающих

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

Помню, как меня впервые попросили дать оценку…

Тогда это застало врасплох.

Меня завели в кабинет, где были мой начальник, его босс и кто-то из вышестоящего руководства, и мы сели за круглый стол, уставившись друг на друга.

Аналитики зачитали некоторые требования от клиента. Мы их коротко обсудили.

И тут мой начальник повернулся ко мне и спросил: «Сколько времени это займет?»

Я не знал, что сказать, — меня к этому не готовили. Мне не сказали, что на этой встрече нужно будет давать оценку — я думал, меня позвали поприсутствовать, чтобы я чему-то научился.

И вдруг на меня все смотрят и ждут ответа, а я растерялся и не знаю, что сказать.

Передо мной лежала бумага для заметок. Я взял один листок и начал писать какие-то числа — без понятия, для чего, но точно не для этой оценки.

Где-то через минуту, которая показалась мне часом, я решил просто сказать первое, что пришло в голову: «Не знаю… часов 600?»

Начальник рассмеялся, а затем сказал остальным рассчитывать на примерно 1200 часов.

Не очень люблю вспоминать тот день.

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

Цель проведения оценки

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

Оценка объема работы используется в основном в двух целях:

Выставление счета клиенту.

Планирование

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

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

Допустим, в вашей команде разработчиков три человека. Каждый работает по 40 часов в неделю — это примерно 160 часов в месяц, или 480 часов в квартал (на троих — примерно 1500 часов).

Представьте, что ваша команда должна выполнить пять проектов — с оценками объемов работ 800, 400, 300, 200 и 50 часов. Планируя загрузку, вы будете видеть, что не сможете к концу квартала выполнить все проекты. Менеджеры составят график, использующий определенный процент максимальной загрузки — на случай, если разработка займет больше времени, чем предполагалось.

С оценками из нашего примера можно было бы взяться за проекты на 800, 400 и 50 часов, и при этом осталась бы некоторая свобода для маневра.

Выставление счета клиенту

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

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

Примечание. Это применимо не ко всем компаниям — разработчикам ПО: не все занимаются разработкой на заказ. Если вы не разрабатываете ПО на заказ, то оценки объема работ будут использоваться в основном для планирования.

Ключевые факторы при оценке

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

Фото — AbsolutVision, площадка Unsplash

1. Не оценивайте, сколько времени понадобится ВАМ

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

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

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

2. Не занижайте — завышайте

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

Если разработчики выйдут за отведенный вами срок, это нарушит график работ.

Находиться в границах 20% — это нормально, но только если оценка оказалась завышена — а не занижена.

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

3. Повышение квалификации

Потребуется ли команде для выполнения проекта изучать что-то новое? Например, если вы обычно разрабатываете приложения для «толстых» клиентов, а новый проект — это создание веб-страницы.

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

Фото — Matheus Frade, площадка Unsplash

4. Примеры аналогичных проектов

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

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

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

5. Не забывайте об аналитиках

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

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

Также потребуется учесть время, необходимое отделу контроля качества для тестирования. Возможно, у вас есть какая-то система автоматизации, которую нужно настроить и для этого проекта тоже? На всё это нужно время, которое также включается в оценку.

Заключение

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

Со временем оценки будут даваться вам всё легче. Запомните перечисленные моменты, научитесь понимать, сколько времени занимает разработка определенных элементов, и полагайтесь на свой опыт.

Если резюмировать самое главное, запомните вот что:

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

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

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

О переводчике

Перевод статьи выполнен в Alconost.

Alconost занимается локализацией игр, приложений и сайтов на 70 языков. Переводчики-носители языка, лингвистическое тестирование, облачная платформа с API, непрерывная локализация, менеджеры проектов 24/7, любые форматы строковых ресурсов.

Мы также делаем рекламные и обучающие видеоролики — для сайтов, продающие, имиджевые, рекламные, обучающие, тизеры, эксплейнеры, трейлеры для Google Play и App Store.

Источник

Как разработчику оценить трудозатраты

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

В начале пути, когда давал оценку будучи разработчиком, я постоянно недооценивал. Каждый раз выявлялась работа, которую я не учел. Коллеги советовали умножать оценки на 2, на 3, на число ПИ — но это не помогало улучшить точность оценок, а только добавляло других проблем. Например, когда нужно было объяснить, откуда взялась высокая оценка.

С того времени прошло 10 лет. За это время я участвовал в оценке более 200 проектов, набил много шишек и хочу поделиться с вами мыслями на тему оценки проектов.

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

Зачем давать оценки?

Процент «успешных» проектов не превышает 29% (Исследование The Standish Group за 2015 год). Остальные 71% либо провальные, либо вышли за рамки тройного ограничения (сроки, функционал, бюджет).

Из этой статистики делаем вывод, что оценка проектов часто не соответствует действительности. Значит ли это, что оценку давать нет смысла? На просторах интернета даже появилось движение за то, чтобы не давать никаких оценок, а просто писать код — и будь, что будет. Что успеем, то успеем (поищите по тегу #noestimates).

Не давать никаких оценок — звучит заманчиво, но давайте отвлечемся и представим, что вы заказываете такси. Вы спрашиваете водителя: «сколько стоит доехать до такой-то улицы», а он отвечает: «не знаю, садись в машину, доедем — скажу, сколько заплатить по приезду».

Или, например, вариант в стиле Agile: «Ну, мы будем ехать, а ты будешь платить мне каждые 10 минут в дороге — и так пока не кончатся деньги) Как кончатся — высажу, но, возможно, мы доедем, или будем уже рядом. Ну, а если не рядом, то это твои проблемы — не повезло.»

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

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

Лезть в машину, совсем не понимая, чего ожидать — не то решение, которое принимают в здравом уме.

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

Причины недооценивания

Игнорирование теории вероятности

Давайте представим, что менеджер спрашивает разработчика, за сколько он сделает задачу. Разработчик уже делал подобное ранее и дает «наиболее вероятную» оценку. Пусть это будет 10 дней. Есть, конечно, вероятность, что задача займет 12 дней, но эта вероятность ниже, чем вероятность того, что задача займет 10 дней. Так же есть вероятность, что задача займет 8 дней, но и эта вероятность будет меньше.

Площадь под кривой дает суммарную вероятность в 100%. Получается, что если мы дадим наиболее вероятную оценку, то мы завершим проект/задачу в срок или ранее с вероятностью в 50% (площадь под графиком до оценки 10 часов — это половина площади фигуры, и равна 50%). Т.е., руководствуясь данным принципом и давая наиболее вероятную оценку мы должны срывать примерно 50% сроков.

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

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

Получается, что если взять «наиболее вероятную» оценку в 10 дней, то вероятность того, что задача будет готова в этот срок или раньше — меньше 50%.

Игнорирование текущего уровня неопределенности

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

Исследования Луиса Ларанхейра (PhD, Associate Professor at The University of Brasilia) также показывают, что точность оценки программного проекта зависит от степени проясненности требований (Luiz Laranjeira 1990). Чем более прояснены требования, тем точнее оценка. Оценка не точна, прежде всего, потому, что неопределенность заложена в самом проекте/задаче. Единственным способом сокращения неопределенности в оценке является сокращение ее в проекте/задаче.

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

Итак, основные причины недооценивания — это неопределенность и игнорирование теории вероятности.

Зависимость точности оценки от стадии проекта

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

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

Так, на стадии исходной концепции наиболее вероятная оценка может отличаться от оптимистической в 4 раза. На стадии готового UI разброс оценки уже варьируется от 0,8 до 1,25 относительно наиболее вероятной оценки.

Для удобства привожу эти же данные в виде таблицы:

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

Чтобы продвинуться по конусу в самую правую точку, где нет неопределенности, нам нужно создать готовый продукт 🙂 Получается, пока продукт не готов, неопределенность есть всегда, и оценка не может быть точной на 100%. Но на точность оценки можно повлиять, снижая неопределенность. При этом, любое действие, направленное на снижение неопределенности, снижает разброс оценки.

Данную модель используют во многих компаниях, в том числе и в NASA. Некоторые адаптируют ее, чтобы учитывать нестабильность требований. Более детально об этом можно прочитать в «Software Estimation: Demystifying the Black Art».

Что считать хорошей оценкой?

Есть много версий ответа на этот вопрос, но на практике, если оценка отклоняется от цели проекта более чем на 20%, то у руководителя проекта нет пространства для маневра. Если оценка колеблется в пределах 20%, то проект можно завершить успешно за счет управления функциональностью, сроками, размером команды и другими параметрами. Это звучит достаточно разумно, поэтому давайте для примера остановимся на этом определении хорошей оценки (это решение должно быть принято на уровне организации — кто-то рискует, и их устраивает отклонение в 40-50%, а кому-то и 10% много).

Итак для нас хорошей оценкой будет считаться та, что отличается от фактического результата не более чем на 20%.

Практика. Оцениваем проект на разных стадиях

Давайте представим, что к вам пришел менеджер проекта и попросил оценить какую-то функцию или проект.

Первым делом нужно изучить доступные требования и понять, на каком этапе жизненного цикла находится описание задачи или проекта (Исходная концепция, Согласованное определение, Завершенные требования, Готов UI, Спроектирована архитектура).

Дальнейшие действия зависят от того, на каком этапе мы находимся:

Стадия 1. Исходная концепция

Если к вам приходит менеджер или клиент и спрашивает: «Сколько времени займет сделать приложение, где доктора будут консультировать пациентов?», то вы точно на этапе «Исходная концепция».

Когда имеет смысл давать оценку на данном этапе?

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

Что нужно, чтобы дать оценку на данном этапе?

Нужно иметь данные фактических трудозатрат по похожему завершенному проекту.

Какие инструменты больше всего подходят на данном этапе?

Алгоритм оценки

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

Например, оценку можно озвучить как «Я не знаю сколько времени займет этот проект, так как данных недостаточно, но чем-то похожий на него проект Х занял Y времени. Чтобы дать хотя бы примерную оценку по данному проекту, нужно прояснить требования.»

Если данных по похожим завершенным проектам нет, то единственный возможный вариант дать оценку — снижать неопределенность и переходить на следующий этап.

Как перейти на следующий этап?

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

В идеале нужно иметь навыки сбора и анализа требований.

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

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

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

Стадия 2. Согласованное определение продукта

На данном этапе уже есть понимание, что приложение будет делать и что не будет. Хотя и без подробных деталей.

Когда имеет смысл давать оценку на данном этапе?

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

Что нужно, чтобы дать оценку на данном этапе?

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

Какие инструменты больше всего подходят на данном этапе?

Алгоритм оценки

Если такой же проект уже делали, то можно сразу озвучить в качестве примерной оценки то время, которое ушло на тот проект.

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

Так, например, в случае с приложением «где доктора будут консультировать пациентов» у нас могло бы получиться следующее:

И для оценки блока «Регистрация» можно взять оценку с одного проекта, а для оценки блока «Система отзывов» — с другого.

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

Так, например, модуль «Система отзывов» может нам показаться в 2 раза сложнее модуля «Регистрация». Соответственно, для этого модуля мы можем взять оценку, в 2 раза превышающую оценку на модуль «Регистрация».

Этот метод (оценка одного блока относительно другого блока) очень не точный, и его лучше использовать, только если количество блоков, которые никогда не делались, не превышает 20% от блоков, по которым есть исторические данные. В противном случае, это будет гадание на кофейной гуще.

После этой процедуры оценку по всем блокам нужно сложить, и это будет наиболее вероятная оценка. Пессимистичную и оптимистичную оценки можно рассчитать, используя коэффициенты, которые соответствуют текущему этапу — х0,5 и х2 (см. таблицу коэффициентов).

В идеале, это уже можно озвучить менеджеру, он должен разобраться, что с этим делать.

Если же так случилось, что разобраться менеджер не может и просит одно число — есть способы дать и одно.

Как из 3-х оценок (пессимистичная, оптимистичная и наиболее вероятная) сделать одну, я расскажу позже в разделе «Как из 3-х оценок получить одну?».

Как перейти на следующий этап?

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

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

Так, например, для блока «Система отзывов» после сбора и анализа требований мы могли бы получить следующее:

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

Прояснение этого будет означать переход на следующий этап.

Стадия 3. Требования собраны и проанализированы

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

Когда имеет смысл давать оценку на данном этапе?

Когда нужно дать примерную оценку на проект перед стартом работы по модели T&M. Оценки задач с данного этапа могут быть использованы для приоритизации конкретных задач на проекте, для планирования даты релиза и бюджета всего проекта. Также их можно использовать для контроля производительности команды на проекте и оценке ее эффективности.

Что нужно, чтобы дать оценку на данном этапе?

Какие инструменты больше всего подходят на данном этапе?

Алгоритм оценки

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

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

Например, для нашей User Story «Пациент может просмотреть все отзывы о выбранном докторе» могла бы получиться следующая картина (иллюстрации ниже специально сделаны от руки, чтобы показать, как процесс оценки может выглядеть на практике): Тут мы разделили задачу на 3 составляющие:

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

Если вы хотите повысить свои навыки в проектировании интерфейсов, неплохо бы прочитать «Интерфейс» Джеф Раскин и «Об интерфейсе. Основы проектирования взаимодействия» Алан Купер.

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

Если есть задачи, которые занимают более 8 часов, их нужно разбить на подзадачи.

Оценку, которую вы получили после описанной процедуры, можно считать оптимистической, так как, скорее всего, она учитывает кратчайший путь из точки А в точку Б (при условии, что вы ничего не забыли).

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

Один из возможных вариантов такого чек-листа вы можете посмотреть тут.

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

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

После того, как вы и это подсчитаете — ваша оценка, скорее всего, будет все ещё ближе к оптимистичной, чем к наиболее вероятной. Если посмотреть на конус, то эта оценка будет ближе к нижней его грани.

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

Оставшиеся две оценки можно рассчитать, используя коэффициенты, которые соответствуют текущему этапу — х0,67 и х1,5 (см. таблицу коэффициентов).

Если подсчитать оценку и приведенного выше примера, мы получим следующее:

Как перейти на следующий этап?

Чтобы перейти на следующий этап, нужно спроектировать интерфейс пользователя. Лучшим способом сделать это будет создание wireframes.

Для этого есть множество программ, но я бы порекомендовал обратить внимание на Balsamiq и Axure RP.

Прототипирование — это отдельная обширная тема, которая выходит за рамки данной статьи.

Наличие wireframe будет означать переход на следующий этап.

Стадия 4. Интерфейс спроектирован

На данном этапе есть wireframe и полный список того, что может делать каждый пользователь в системе, а также есть список не функциональных требований.

Когда имеет смысл давать оценку на данном этапе?

Для подготовки точной оценки по модели Fixed Price, но также можно и для всего того, что было перечислено на прошлом этапе.

Что нужно, чтобы дать оценку на данном этапе?

Какие инструменты больше всего подходят на данном этапе?

Алгоритм оценки

Такой же, как и на предыдущем этапе. Разница состоит в точности. Имея спланированный интерфейс, вам гораздо меньше придётся додумывать, и вероятность что-то не учесть будет гораздо меньше.

Как перейти на следующий этап?

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

Получаем из диапазона оценок одну

Если у вас уже есть наиболее вероятная, пессимистическая и оптимистическая оценки, то для того, чтобы получить одну оценку, можно использовать наработки Тома ДеМарко, который в своей книге «Вальсируя с медведями» поднял идею, что абсолютная вероятность может быть вычислена путём интегрирования площади под кривой (того самого графика асимметричного распределения вероятностей, что мы рисовали ранее). Оригинальный шаблон для подсчета можно скачать тут (также доступен без регистрации тут). В шаблон нужно просто подставить 3 числа и получить результат в виде списка оценок с соответствующими им вероятностями.

Например, для оценок 14, 20 и 31 мы получим следующий результат (скрин с шаблона excel):

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

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

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

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

Хороший менеджер всегда на вашей стороне, ведь вы в одной лодке, и его карьера зависит от того, уложитесь ли вы в срок, зачастую сильнее, чем ваша.

Многие организации и разработчики сами способствуют срыву собственных проектов только за счет того, что принимают на себя обязательства в слишком ранней точке конуса неопределенности. На ранней стадии, где возможный результат колеблется от 100% до 1600%, принимать решения и фиксировать сроки очень рискованно.

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

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

Ниже приводится иллюстрация улучшения качества оценок в проектах ВВС США при переходе на более зрелый уровень CMM (Lawlis, Flowe and Thodahl,1995). Думаю, тут есть о чем задуматься. Статистика по другим компаниям подтверждает эту корреляцию.

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

Выводы

Полезные книги

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

Источник