Работа над задачей

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

Что важно

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

С другой стороны решение задачи чаще всего остаётся строками кода в репозитории продукта. Чаще всего эти строки усложняют продукт. Неважно сам ли автор этих строк будет читать их через пару месяцев или другой разработчик на следующий день после того как автора собьёт автобус, редко когда чтение чужого кода или даже выдержанного своего доставляет удовольствие или полностью раскрывает суть происходящего. А если код не покрыт тестами? Или тесты написаны так, что любое изменение их ломает? То, что обычно называют «легаси», хотя может оказаться, что это наследство оставлено вами буквально на прошлой неделе впопыхах починки бага на проде. Или по прихоти одного из клиентов, а потом выясняется, что другие клиенты ожидают совершенно другого. К чему это я? При решении задачи должно оставаться как можно больше артефактов, которые можно будет привязать к конкретным строкам кода.

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

Методологии

С первой частью требований помогают справляться различные Agile-методологии, например, Scrum, Kanban или их миксы. Все эти подходы основываются на понятных шагах при решении задач, которые можно оценить. Что же делать, если задача совершенно новая и как её решать непонятно. Как оценить сроки? Как разбить на понятные шаги? Первое правило не бежать вперёд самолёта. Ниже описываются этапы работы над задачей от абстрактной «хотелки» заказчика до мерджа изменений в master-ветку. Дать оценку шага сложно, не доведя предыдущий до конца. Хотя в начале каждого шага оценить его не составит большого труда.

Роли

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

Этапы

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

• исследование или аналитика;
• проектирование;
• реализация;
• приёмка;
• сопровождение;

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

Виды задач

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

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

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