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

Рекомендуемые правила для атомарной задачи

1. У атомарной задачи не может быть более одного исполнителя.

2. Атомарная задача должна вносить изменения не более чем в одну программную систему.

3. Длительность атомарной задачи – не более двух дней.

Одна задача – один исполнитель.

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

а) Концепт (дизайн, прототип) интерфейса. Исполнитель - проектировщик интерфейса.
б) Отрисовка интерфейса. Исполнитель – дизайнер (художник/оформитель).
в) Верстка. Исполнитель - верстальщик.
г) Программирование - программист.

Зачем это надо? Предположим, фиксируются только “фичи”. Напрмер, “Один клик”. Руководитель проекта уехал в отпуск в Гималаи, где нет сотовой связи. Верстальщик живет в Минске и заболел ангиной. Кто из отдела в 30 человек программистов отвечает за программирование конкретно этой страницы, в реестре не указано, а отдел программирования частью расположен в Москве, частью в Твери и частью еще в 6 городах. И интернет-магазин - не единственная задача, которой они занимаются. А оформитель ушла в декрет и из 70 висевших на ней задач передала не все. И передала их четырем другим оформителям. Внимание, вопрос. Как заказчику оперативно узнать, выйдет ли «один клик» в двенадцатом релизе? Поэтому: одна атомарная задача - не более одного исполнителя. Именно так она должна быть внесена в реестр задач. “Один клик” декомпозировать и декомпозировать.

Одна задача – одна система

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

Приведу конкретный пример. Пусть внешний заказчик заказал нам три фичи «А», «Б», «В». Заказчик умный и платит не за трудоемкость, а за свой профит. Цены:

•    «А» - $100k,
•    «Б» - $20k,
•    «В» - $10k.

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

Мы сейчас планируем сентябрьский релиз, а команда продукта «Л» запланировала работы по фиче «А» на ноябрьский релиз.
Оптимальным при этом будет сделать в сентябре фичу «Б», а «А» запланировать на ноябрь.

Но, не выполнив декомпозицию до «одна задача – не более одной системы», будет сложно «на лету» делать такое планирование. И на моей практике отсутствие такой декомпозиции  достаточно серьезно выбивало проект из сроков.
Атомарная задача – не более двух дней.

Эту идею я изначально нашел в статье Джоэла Спольски «Планирование программного обеспечения малой кровью», и впоследствии находил ей множество подтверждений. Человеку проще оперировать задачами, размер которых измеряется в часах. Проще держать в голове ее целиком. При оценке 2 – 16 часов ошибка оценки предположительно минимальна. Статья-гипотеза «Реальная оценка, или почему наступают дедлайны?» Кроме того, если атомарные задачи по факту окажутся в среднем четырехдневными, то вы успеете оперативно скорректировать планы. Таким образом, очень удобно отслеживать прогресс работ по фиче. При условии, что в среднем в один день верстается одна-две страницы, то после того, как вы составили реестр всех страниц – вы получили управляемый процесс верстки. Одна страница и будет для верстальщика одной атомарной задачей.

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

«Меняться необязательно. Выживание – дело добровольное» © Э. Деминг

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

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