Быстрая и простая оценка первоначальных усилий для программных проектов


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

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

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

Вам также может понравиться: Как оценить небольшие задачи для большого клиента

проблема

Давайте рассмотрим оценку концепции (POC) на предпродажной стадии. Риск провала проекта на данном этапе выше, потому что:

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

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

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

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

Решение

Хотя предприятие по подготовке к ЕТА кажется пугающим, давайте будем конструктивными и приступим к определению того, что у нас есть на этом раннем этапе POC, включая, в большинстве случаев:

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

Это уже что-то!

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

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

  • Создайте модель бизнес-домена до начала разработки.
  • Планирование функций / пользовательских историй с высокой степенью детализации.

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

анализировать

Представьте себе разработку мобильного приложения со следующими требованиями:

  • Приложение для iOS, помогающее размещать текст, фотографии и видео для ленивых пользователей в различных социальных сетях (Twitter, Facebook, Instagram, Snapchat и т. Д.) Одним щелчком мыши.
  • Серверная сторона для хранения аутентификационных данных и учетных записей, связанных с пользователями.
  • Бэк-офисная система для доступа к пользовательским данным и наблюдения за работой системы.

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

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

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

модель

Каждая диаграмма варианта использования начинается с определения роли. Здесь у нас есть два из них: пользователь приложения iOS и администратор бэк-офиса.

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

  • Войти в приложение – Эта функция позволяет пользователю зарегистрироваться или авторизоваться в нашей системе из приложения iOS.
  • Войдите во внешнюю систему – Внешняя система – это целевая система, которую пользователи будут публиковать (например, Twitter, Instagram и другие, поддерживаемые приложением). Пользователь iOS должен войти в систему из нашего приложения, чтобы он мог получить токены безопасности для публикации от своего имени.
  • Выйти из приложения – Пользователь iOS должен выйти из приложения, чтобы войти с другими учетными данными.
  • Выйти из внешней системы – Пользователь iOS должен отключить внешнюю систему от своей учетной записи (т.е. пользователи должны решить прекратить использование Instagram из приложения).
  • Отправить сообщение – Дело в том, чтобы приложение iOS отправляло сообщение во внешнюю систему (например, Twitter) от имени пользователя.

Действия высокого уровня для администратора бэк-офиса включают в себя:

  • Войти в бэк-офис – Администратор бэк-офиса должен иметь возможность выполнять административные действия в нашей системе бэк-офиса.
  • Просмотр списка пользователей – Администратор должен иметь возможность контролировать зарегистрированных пользователей.
  • Просмотр действий для пользователя – Администратор должен иметь возможность подобрать конкретного пользователя и посмотреть, какие действия он выполнил и когда.
  • Блокировать пользователя – Администратор должен иметь возможность ограничить вход определенного пользователя.
  • Выйти из бэк-офиса – Из соображений безопасности администратор бэк-офиса должен иметь возможность полностью выйти из приложения.

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

  • Какие сообщения можно публиковать?
  • Какие внешние системы разрешены.

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

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

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

Анализ результатов

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

  • Внешний интерфейс – Это само приложение для iOS.
  • Задний конец – Это серверная часть, которая отвечает за регистрацию пользователей, вход в систему и взаимодействие с поддерживаемыми внешними системами, такими как Twitter.
  • Документация – Это документация, которую инженерная группа готовит на этапе внедрения. Предположим, что заинтересованные стороны согласились с тем, что этот результат будет легковесным и сузится до внутренней спецификации API. Это определяет, как приложение iOS взаимодействует с серверной частью.

Давайте назначим каждому результату письмо: В за назад end, F за внешний интерфейс, и D за документация, Теперь мы попросим нашу команду разработчиков просмотреть диаграмму прецедентов UML и пометить каждый прецедент маркером результата, добавив соответствующее письмо, относящееся к этому результату.

Вот пример того, как это можно сделать:

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

Оценить

В игру вступает самая захватывающая часть – давайте сделаем оценку!

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

  • низкая сложность Вариант использования прост в реализации, не пересекается с другими вариантами использования, не имеет серьезных зависимостей и может быть реализован одним инженером.
    • Цвет: зеленый
    • Символ: L
  • средней сложности Вариант использования имеет умеренную сложность, требует инфраструктурных работ, которые в дальнейшем будут использоваться другими инженерами, и занимает значительно больше времени, чем выполнение задач с низкой сложностью.
    • Цвет: желтый
    • Символ: M
  • высокая сложность Вариант использования включает в себя множество зависимостей с другими вариантами использования / модулями, требует серьезной инфраструктуры и требует значительного времени для реализации.
    • Красный цвет
    • Символ: H

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

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

  • Низкая сложность (L, зеленый) – 1 неделя
  • Средней сложности (М, желтый) – 2 недели
  • Высокая сложность (Ч, красный) – 3 недели

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

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

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

После того, как риски добавлены, мы можем рассчитать результат. Вот краткое резюме того, что мы имеем:

  • 3 варианта использования высокой сложности (H), 2 из которых имеют 30% буферов риска.
  • 4 варианта использования средней сложности (M).
  • 16 вариантов использования низкой сложности (L).

Суммируя недели в зависимости от сложности задачи, мы получаем оценку 35 недель. Это представляется как:

ETA = (3 * 3 + 3 * 0,3 + 3 * 0,3) + (4 * 2) + (16 * 1) = ~ 35 Вт

То есть примерно три месяца для команды из трех инженеров.

Теперь мы закончили и можем получать удовольствие от детального планирования проекта, используя Gannt и PERT для планирования выполнения и продолжительности проекта.

Вывод

Мы описали методику быстрого и простого предоставления ETA для проектов разработки программного обеспечения на ранней стадии, перед разработкой. В Plexteq мы использовали этот подход в течение ряда лет и всегда получаем релевантные и точные результаты.

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

Как только оценка усилий рассчитана, команда управления проектом может формализовать это ETA в подход Ганта / PERT, изучить варианты использования и включить проект в любую методологию разработки программного обеспечения Agile.

Удачной оценки!

Дальнейшее чтение

Прекратить оценку: движение #NoEstimates в Agile

Гибкая оценка – предпосылки для более точных оценок

Оценка проекта в Agile: как мы это делаем