Настольная книга тимлида разработки ПО - Виктор Большаков

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

— Технические задания по ГОСТу или нет — ёмкие опросники со множеством вопросов, которые раскрывают перечень различных требований.

— Есть еще некоторый набор интересных подходов CLEAR, PURE, CPQQRT

Какой же метод выбрать? В чем компромисс?

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

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

— Задачи, имеющие высокую ценность для бизнеса

— Задачи, ошибка в которых будет дорого стоить для бизнеса

Методы оценки задач, риски

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

— Для планирования и понимание того, когда и какой функционал может появиться

— Для оценки экономической целесообразности реализации этой задачи

— Для оценки эффективности работы команды

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

Как происходит оценка:

— Ознакомление с требованиями задачи, уточнение вопросов.

— Проектирование решения, валидация спроектированного решения.

— Декомпозиция спроектированного решения.

— Оценка сложности и объема исполнения, а также рисков, связанных с реализацией и процессом.

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

Оценка НЕ РАВНО (#=) срок реализации. Оценка — это длительность выполнения задачи. Срок реализации — это результат процесса планирования оцененных задач.

Единицы измерения оценки задач:

— Человеко-часы или человеко-дни, реже недели или месяцы

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

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

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

— У разных команд будет разный размер Story point. Не стоит приводить их в соответствие без особой необходимости.

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

— Без оценок

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

Существуют различные техники оценки задач:

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

— Диаграмма сходства (Affinity Mapping) — объединения схожих по трудности/объему/рискам задач в группы.

— Дерево декомпозиции — классическое разбиение задачи на части и их оценка.

— Сортировка задач — упорядочивание задач по шкале времени.

Планирование и декомпозиция задач

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

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

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

Обычно необходимо ответить на вопросы — какие задачи будут решены за следующую итерацию (спринт) или когда будет завершен проект?

Планирование проектов — это отдельная область, описанная в РМВОК, Prince2 и других гибких методологиях. В основном такое планирование опирается на:

— выявление задач

— нахождение и выстраивание параллельной работы

— нахождение зависимых задач и решение задач критической цепи

Планирование проектов производится с помощью Диаграммы Ганта.

Для планирования итераций (спринтов) можно также применить принципы планирования проектов, но в упрощенном варианте. Однако будет полезным не только выявлять зависимости и критический путь, но и распараллелить работы. В повседневном планировании вы занимаетесь распределением задач между исполнителями или установкой определенных правил распределения задач.

Декомпозиция нужна для задач, которые велики по размеру (и это несет большие риски для планирования). Работы задачи можно распараллелить или синхронизировать их исполнение и ожидания бизнеса. Задачу можно разбить на бизнес-ценные части (что рекомендует Scrum) или технические подзадачи. Обычно разделение на бизнес-ценные части нужно для промежуточной валидации с бизнесом, чьи ожидания мы выполняем. Техническая декомпозиция задач зачастую нужна для точного планирования, она упрощает работу с зависимостями и позволяет распараллелить некоторые задачи.

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

Делегирование и эскалация

Делегирование — процесс передачи части функций другим членам команды.

Принципы делегирования:

— ожидаемые результаты

— обозначить ответственность

— наделить необходимыми правами (всестороннее делегирование, но без избыточных прав)

— делегирование лицу, имеющему необходимые компетенции

— своевременность делегирования

— отсутствие конфликтов по части ответственности

— поддержка при выполнении функций

— возврат полномочий (обозначить время/событие и процесс)

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

Эскалация — передача ответственности