Понятие атомарной задачи, часть 1

Дисклеймер

Я не могу научить управлять разработкой ПО в одной статье.

Я не могу дать все определения в одной статье. Голдратт для определения понятия «Критическая цепь» написал книгу. Генри Нив для определения понятия «Операционные определения» и для описания их важности написал главу книги.

Также я не уверен, что одних статей достаточно. Возможно, нужны тренинги.

В любом случае ждите другие статьи.

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

Аудитория статьи – в первую очередь операционный менеджмент.

Проблематика

От менеджеров часто приходится слышать:

  • А почему так дорого?
  • А почему так долго?
  • А почему, если фактическая трудоемкость всего 60 часов, выпустили только через три месяца? Другая команда в другом продукте должна была внести изменения и внесла только сейчас? Почему я узнаю об этом только сейчас?

И, конечно же, одно из самых популярных: «У нас ни один проект не завершается в расчетный срок. Планировать не умеете?»

Некоторые операционные определения и ограничения статьи

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

На текущий момент практически стандартом де-факто стали следующие положения:

  • Есть два типа задач. Разработка новой функциональности и исправление ошибок.
  • Обобщающий термин - запрос на изменение (ЗНИ).

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

1.    Найти товар.
2.    Просмотреть свойства товара.
3.    Купить.

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

Фичи это то, по поводу чего удобно договариваться с заказчиком. В одном случае вы услышите: «Какая корзина? У нас розничная торговля холодильниками. Не покупают люди пять холодильников сразу. Сначала делайте один клик. Через полгода, может быть, вернемся к идее корзины». Может быть и обратная картина: «Мы книгами торгуем. Не будет человек одну книгу за 200 рублей заказывать при стоимости доставки заказа в 300 рублей. Сначала корзина».

Декомпозиция и суперпозиция фич отдельная большая тема, а пока вернемся к атомарной задаче. Возьмем фичу «купить в один клик». В среднем и большом бизнесе (оборот сети магазинов - сотни миллионов долларов и выше) этот самый бизнес обслуживают десятки и сотни систем, взаимодействующих друг с другом. Если брать «М-Видео», то у них очень значимый сегмент (более 10%) - торговля через интернет. Но такие фичи интернет-магазина, как, например, программа «постоянный покупатель» (накопление и трата бонусов) должна быть общей и для онлайна и для оффлайна. Скорее всего, это не часть интернет-магазина и не часть оффлайн -магазина, а отдельный программный продукт. Фича «один клик» может потребовать внесения в несколько систем, работы множества программистов (в том числе из разных команд, а иногда и из разных фирм), а также верстальщика, оформителя и т.д. И трудозатраты на нее получаются немалые. Заказчика интересует прогресс и прогнозируемая дата выпуска. И одной большой задачи для координации множества людей, тем более из разных отделов и/или фирм, оказывается недостаточно.

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

  • Оценить трудоемкость исполнения фичи и проекта в целом. Главное – проекта в целом.
  • Оценить календарное время исполнения фичи и проекта в целом.
  • Перевести разработку ПО в статистически управляемое состояние.
  • Сократить время проекта за счет работы по «Критической цепи».

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

В моей практике есть примеры:

  • Введение реестра атомарных задач позволяло рассчитать время проекта с точностью до 5-10%. Неплохо?
  • Введение реестра атомарных задач позволяло сократить время проекта.
  • Введение реестра атомарных задач позволяло уменьшить напряженность в отношениях заказчик – исполнитель.

Оставьте комментарий

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