Как настроить типы задач и не сойти с ума

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

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

Структура выделенных задач

В самой системе Jira , анализируя ее с точки зрения многоуровневости, предлагается просмотреть и провести анализ трех отдельных уровней задач. Это Epics, Stories/Tasks, Sub-task. Подобная система позволяет достаточно точно и оперативно кастомизировать между собой все указанные сущности, к примеру, изменять названия, используемые картинки, даже выполнять тщательную настройку своего workflow под конкретный тип задач. В этом и заключается самый важный момент, ведь чем больше кастомизировать используемую систему непосредственно под собственные нужды, не имея никакого согласования с тем, что чем является, значит, это вызовет больше вопросов, а также общее отторжение в данном приложении.
Некоторые наблюдения

Имея определенный уровень, сотрудники Софтлист смогли наблюдать за тем, каким образом все участники данного процесса работают над продуктом. Собственно, никто не может однозначно договориться о том, что стоит понимать под Epics, Stories/Tasks, Sub-task. Это были весьма ожесточенные дебаты, в вопросе которых никто не хочет менять соответствующий порядок, как в продукте, так и в команде в целом. Что же тут все же обсуждать? В своем роде, все выглядит следующим образом:

• Epics – представляет собой самую большую задачу по отдельному проекту.
• Stories/Tasks – это задача уровнем немного поменьше, что также необходимо учитывать потенциальному пользователю.
• Sub-task – представляет собой самые маленькие, совершенно не обязательные сущности, которыми также рекомендуется заняться, проработав их в полном объеме.

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

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

Это своеобразное понимание всех трех компонентов, которое вызывается различным интересом, выдвинутым самими пользователями. Менеджеру проекта важно иметь понятие о том, когда разработчики ставят ему задачи и какими они могут быть. В то же самое время, менеджеру продукта очень важно, как видеть, так и понимать саму карту продукта, а конечным исполнителям вообще ничего не хочется в этом отношении, они устали к этому времени от таких перемен в жизни своих руководителей.
Что же делать со всем этим?

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

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

Те, кто предпочитает UML сразу же станет все понятно, для тех, кому данные буквы буквально ни о чем не могут сказать, дальше дадим короткое объяснение. После того определения сотрудники компании смогли детально разложить указанное понимание в голове, после чего вплылись статьей тезки. Что же представляет собой прецедент в указанной системе? Зачастую, вырисовывается диаграмма вариантов использования, что по сути является одним и тем же. Достаточно часто речь заходит о многочисленных вариантах использования, после чего всегда можно привести в аргумент работу сетевого магазина, в этом отношении сотрудники компании не станут никаким исключением. Представим, что планируется разработать именно интернет магазин , который занимается вопросами продажи лицензионного программного обеспечения .

Кейс

• Epics – кейс описывает некоторый вариант использования, в котором, как показано на изображении, существует несколько отдельных actors, а также целый ряд различных действий. В данном случае принято понимать конкретный прецедент в самой системе, что достаточно удобно, ведь всю систему можно обязательно разбить на отдельные прецеденты, таким образом можно будет попробовать сформировать и сгруппировать наиболее мелкие задачи. Название данного решения будет «Приобретение софта на сайте нашего магазина».
• Story – а данном случае, невозможно выполнять оценку и планирование больших задач, они точно не влезут в выделенное для них пространство, потребуется научиться грамотно их декомпозировать. Данный прецедент можно разбить на более мелкие пользовательские истории. В частности, будет один «актор», одно действие и одна ценность.

Формирование критериев приемки

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

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