Таск что это в программировании
Перейти к содержимому

Таск что это в программировании

  • автор:

Что значит Task, когда говорят о языке программирования?

Доброй ночи, подскажите.
Как таковой Task перевело — задание.
Но как оно переводится по отношению к языку программирования?

  • Вопрос задан более трёх лет назад
  • 15372 просмотра

Комментировать
Решения вопроса 4

Зависит от конкретого языка программирования.

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

Типы задач в Jira — что такое Epic, Story, Task

Типы задач в Jira

  1. Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов
  2. История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт
  3. Задача (task) — техническая задача, которую делает один из членов команды
  4. Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды
  5. Баг (bug) — задача, которая описывает ошибку в системе

Если вы хотите узнать подробнее о типах задач в Jira — вы в правильном месте.

В этой статье мы разберемся с определениями issue, эпик (epic), история (story), задача (task), под-задача (sub-task) и баг (bug), посмотрим зачем они нужны и как они связаны.

Что такое Issue в Jira?

Все задачи, созданные в Jira, называются issue (или “проблема”).

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

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

Каждой проблеме присваивается уникальный ID, по которому ее можно легко найти.

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

Изначально в Jira есть 5 базовых типов проблем, но, при необходимости, их можно дополнять / изменять / удалять.

Что такое Эпик (Epic) в Jira?

Epic в Jira

Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов.

Для примера можем рассмотреть эпик “Разработать блог для сайта N”.

Под “разработать” может подразумеваться:

  1. Проработать структуру блога
  2. Создать дизайн
  3. Разработать, протестировать блог
  4. Подготовить аналитику
  5. Подготовить начальный контент
  6. Развернуть и запустить блог

Как мы видим, объем работ — большой. Количество людей, которые будут принимать участие в работе — большое. Время на реализацию — явно не 2 часа ��

Все характеристики эпика соблюдены)

Основное предназначение эпикаорганизация работ.

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

Из-за своего объема и абстрактности эпики всегда разбиваются на части, которые описывают более конкретные “шаги” для решения проблемы.

Эти части называются история и задача.

Если вы хотите разобраться в эпиках более детально:

  1. Эпики agile. Определение, примеры и шаблоны
  2. Узнайте, как использовать эпики в Jira Software

Что такое История (Story / User Story) в Jira?

Story в Jira

История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт.

Она описывает реализуемую работу (или функционал) с точки зрения конечного пользователя и, обычно, имеет заголовок вида:

Как [тип клиента], [хочу/могу то-то], [чтобы делать что-то]

Если продолжить рассмотрение примера эпика Разработать блог для сайта “N”, можно выделить такие истории:

  1. Как клиент, я могу связаться с суппортом компании, отправив заявку на странице /contact-us, чтобы решить возникшую проблему
  2. Как BA, я могу разделить посетителей сайта на 2 группы и провести А/Б тест для главной страницы, чтоб увеличить конверсию страницы
  3. Как контент-менеджер, я могу добавить интерактивный график на любую страницу блога, чтоб посты были более интерактивными

Теперь части работы стали меньше и они — более понятные. Их можно смело отдавать командам на оценку!

Истории оцениваются командой в story points.

Также в них обязательно должны быть критерии приемки (acceptance criteria), благодаря которым команда сможет понять, что работа сделана до конца.

Написание хороших историй — это целая наука!

Если вы хотите разобраться в историях более детально:

  1. Пользовательские истории с примерами и шаблоном
  2. How to Write Good User Stories in Agile Software Development
  3. Как писать User Story

Задача (Task) в Jira

Task в Jira

Задача (task) — техническая задача, которую делает один из членов команды.

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

Продолжаем пример с блогом)

Задачи, которые помогут в реализации:

  1. Создать репозиторий для проекта
  2. Настроить testing/production окружения
  3. Ежедневный просмотр логов ошибок

Как вы видите, задачи — это очень конкретные технические моменты, которые нельзя “преобразовать” в истории, так как ими занимается один человек.

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

Некоторые компании / команды оценивают задачи в часах

Как показывает моя практика — это пустая трата времени, сил и ожиданий.

Практически всегда оценка не совпадет с реальным временем выполнения, причем не важно, оценку делает Junior или Senior разработчик (у Senior отклонение меньше, но оно все равно есть)

Так, задачу оцененную в “два часа от силы” могут делать неделю, а задачу оцененную в “5 часов” — 30 минут ��

Вместо оценки задачи в часах — лучше просить разбивать задачу на под-задачи (о них — ниже)

  1. разработчику будет проще, потому что он сможет более точно понять суть и объем задачи
  2. менеджеру будет проще, потому что ход выполнения задачи будет перед глазами (в виде закрытых / открытых “кусочков”) и не нужно будет постоянно ходить к разработчику с вопросом “ну что там, когда будет готово?” и бесить его ����

Большое количество проблем с типом “задача” в беклоге может указывать на присутствие микро-менеджмента ☠️

В такой ситуации команда не участвует в проработке лучших вариантов решения реальных проблем!

Анализ и подготовка задач происходит “наверху”, задачи опускаются “вниз”, и чаще всего (ввиду не понимания корня проблемы) впоследствии ничего не решают!

Под-задача (Sub-task) в Jira

Sub-task в Jira

Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды.

Разбиение задач на под-задачи позволяет проводить более точное оценивание трудозатрат, потому что нам проще оценивать работу по частям ��

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

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

Например, для истории “Как клиент, я могу связаться с суппортом компании, отправив заявку на странице /contact-us, чтобы узнать больше о компании” под-задачи могут быть такими:

  1. Создать страницу /contact-us (Backend)
  2. Сверстать страницу /contact-us (Frontend)
  3. Интегрировать верстку и форму (Frontend)
  4. Интегрировать верстку и форму (Backend)
  5. Подготовить тестовую документацию (QC)
  6. Проверить страницу /contact-us (QC)
  7. Создать и настроить почту для суппорта (Admin)

Баг (Bug) в Jira

Bug в Jira

Задачи типа Баг (Bug) �� фиксируют ошибки, которые нужно проанализировать и может быть исправить️️️️ ❗️❗️.

Иногда, владельцу продукта сложно понять “суть” ошибки, приоритеты проставляются не правильно и баги “тонут” в беклоге. Это может приводить к постепенному ухудшению качества продукта.

Внедрение Zero Bug Policy помогает избавиться от этой проблемы раз и на всегда.

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

У нас есть отдельная статья о багах и баг-репортах в которой есть пример баг-репорта в Jira и много чего интересного ��

Выводы

Типы задач в Jira

Приведенные типы задач лишь базовые!

Jira — очень гибкий инструмент! Она позволяет добавить новые типы задач, которые нужны именно Вам!

Существуют команды, которые собирают эпики в большие “мега” проекты. Или те, кто создают требования как тип задач, для более удобной связи требований — тестов — задач/багов.

Главное — не бояться разбираться в чем-то новом и постоянно экспериментировать! ��⚗️��

Удачи в Ваших проектах ����

FAQ

Что такое Epic в Jira?

Эпик (epic) — большая задача, на решение которой команде нужно несколько спринтов

Что такое Story в Jira?

История (story) — часть большой задачи (эпика), которую команда может решить за 1 спринт

Что такое Task в Jira?

Задача (task) — техническая задача, которую делает один из членов команды

Что такое Sub-task в Jira?

Под-задача (sub-task) — часть истории / задачи, которая описывает минимальный объем работы члена команды

Что такое Bug в Jira?

Баг (bug) — задача, которая описывает ошибку в системе

Урок 25. Task. Что это такое и как формируется

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

Task

Мы уже знаем, что приложение может содержать несколько Activity. И что Activity умеет вызывать Activity из других приложений с помощью Intent и Intent Filter. Если вы хотите отправить письмо из вашего приложения, вы вызываете Activity почтовой программы и передаете ей данные. Письмо уходит и вы возвращаетесь в ваше приложение. Создается ощущение, что все это происходило в рамках одного приложения. Такая «бесшовность» достигается за счет того, что оба Activity (ваше и почтовое) были в одном Task.

Прежде, чем продолжу объяснять, хочу сразу привести аналогию, чтобы тему легче было понять. В скобках я буду давать понятия-аналоги из Android.

Механизм организации Activity в Android очень схож по реализации с навигацией в браузере. Вы находитесь в одной вкладке(Task) и открываете страницы (Activity) переходя по ссылкам (Intent). В любой момент можете вернуться на предыдущую страницу, нажав кнопку Назад. Но кнопка Вперед отсутствует, т.к. страница, на которой была нажата кнопка Назад, стирается из памяти. И надо снова нажимать ссылку, если хотим попасть на нее. Если вам надо открыть что-то новое, вы создаете новую вкладку и теперь уже в ней открываете страницы, переходите по ссылкам, возвращаетесь назад. В итоге у вас есть несколько вкладок. Большинство из них на заднем фоне, а одна (активная, с которой сейчас работаете) – на переднем.

В итоге список аналогий браузера и Android таков:

Теперь вам будет более понятен текст про Task.

Task – группа из нескольких Activity, с помощью которых пользователь выполняет определенную операцию. Обычно стартовая позиция для создания Task – это экран Домой (Home).

Находясь в Home вы вызываете какое-либо приложение из списка приложений или через ярлык. Создается Task. И Activity приложения (которое отмечено как MAIN в манифест-файле) помещается в этот Task как корневое. Task выходит на передний фон. Если же при вызове приложения, система обнаружила, что в фоне уже существует Task, соответствующий этому приложению, то она выведет его на передний план и создавать ничего не будет.

Когда Activity_A вызывает Activity_B, то Activity_B помещается на верх (в топ) Task и получает фокус. Activity_A остается в Task, но находится в состоянии Stopped (его не видно и оно не в фокусе). Далее, если пользователь жмет Back находясь в Activity_B, то Activity_B удаляется из Task и уничтожается. А Activity_A оказывается теперь на верху Task и получает фокус.

В каком порядке открывались (добавлялись в Task) Activity, в таком порядке они и содержатся в Task. Они никак специально не сортируются и не упорядочиваются внутри. Набор Activity в Task еще называют back stack. Я буду называть его просто — стэк.

Схема (с офиц.сайта) демонстрирует пример:

В верхней части то, что видит пользователь. В нижней – содержимое Task. Видно, как при вызове новых Activity они добавляются в верх стэка. А если нажата кнопка Назад, то верхнее Activity из стэка удаляется и отображается предыдущее Activity.

Допустим у нас есть Task с несколькими Activity. Он на переднем фоне, мы с ним работаем сейчас.

— если мы нажмем кнопку Home, то ничего не будет удалено, все Activity сохранятся в этом Task-е, а сам Task просто уйдет на задний фон и его всегда можно будет вызвать оттуда, снова вызвав приложение, Activity которого является корневым для Task-а. Либо можно удерживать кнопку Home и мы увидим как раз список Task-ов, которые расположены на заднем фоне.

— если же в активном Task-е несколько раз нажимать кнопку Назад, то в итоге в стэке не останется Activity, пустой Task будет удален и пользователь увидит экран Home.

Там еще как всегда куча нюансов и сложностей, но мы пока остановимся на этом и в дебри не полезем. Этих знаний вполне хватит, чтобы ответить на вопросы предыдущего урока: почему на шаге 2 MainActivity исчезло с экрана, но осталось висеть в памяти и не было уничтожено? Ведь на шаге 3 было уничтожено ActivityTwo после того, как оно пропало с экрана. А на шаге 4 было в итоге уничтожено и MainActivity. Почему шаг 2 стал исключением?

Теперь вы знаете, почему. Потому, что на шаге 2 MainActivity осталось в стэке, а ActivityTwo вставилось на верх стэка и получило фокус. Ну а на шаге 3 и 4 были удалены Activity из верха стэка, в Task не осталось Activity, и мы увидели экран Home.

Если бы мы на шаге 3 нажали не Back, а Home, то Task с обоими Activity ушел бы задний фон и ничего не было бы уничтожено.

Paused

Теперь давайте откроем проект с прошлого урока P0241_TwoActivityState. Мы хотели поймать состояние Paused для Activity. Это состояние означает, что Activity не в фокусе, но оно видно, пусть и частично. Мы можем этого добиться, если присвоим диалоговый стиль для ActivityTwo. Оно отобразится как всплывающее окно и под ним будет частично видно MainActivity – оно и будет в статусе Paused. Давайте реализуем.

Для этого открываем AndroidManifest.xml, вкладка Application, находим там ActivityTwo и справа в поле Theme пишем такой текст: @android:style/Theme.Dialog

Все сохраняем и запускаем приложение.

MainActivity: onCreate()
MainActivity: onStart()
MainActivity: onResume()

MainActivity: onPause()
ActivityTwo: onCreate()
ActivityTwo: onStart()
ActivityTwo: onResume()

Видим, что не был вызван метод onStop для MainActivity, а значит приложение не было переведено в состояние Stopped и находится в режиме Paused.

ActivityTwo: onPause()
MainActivity: onResume()
ActivityTwo: onStop()
ActivityTwo: onDestroy()

MainActivity восстановилось одним лишь вызовом onResume, а onStart не понадобился, т.к. оно было в состоянии Paused, а не Stopped.

Мы четко увидели разницу между этим примером и им же на прошлом уроке. И MainActivity у нас был в состоянии Paused.

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

Чтобы вернуть ActivityTwo нормальный режим отображения, зайдите снова в манифест и удалите строку из поля Theme.

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

На следующем уроке:

— вызываем Activity используя неявный вызов и Intent Filter

Присоединяйтесь к нам в Telegram:

— в канале StartAndroid публикуются ссылки на новые статьи с сайта startandroid.ru и интересные материалы с хабра, medium.com и т.п.

— в чатах решаем возникающие вопросы и проблемы по различным темам: Android, Compose, Kotlin, RxJava, Dagger, Тестирование, Performance

— ну и если просто хочется поговорить с коллегами по разработке, то есть чат Флудильня

Зачем нужен таск-трекер и баг-трекер

Если вам доведётся работать в компании крупнее чем три человека, наверняка часть работы будет в таск-трекере. Сейчас покажем, что это такое.

Что такое таск-трекер

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

В общем, таск-трекер — это бесконечная мучительная планёрка для айтишников. Или не мучительная.

Зачем нужен таск-трекер и баг-трекер

Бизнес-процессы в таск-трекере

Часто таск-трекер настраивают так, что задачи автоматически двигаются между разными участниками в зависимости от их роли в команде. Например, это может быть так:

  1. У фронтенд-разработчика появляется в трекере задача «Добавить стиль для новой кнопки поиска в меню».
  2. Фронт берёт её в работу, делает и нажимает в трекере внутри задачи кнопку «Готово».
  3. Задача относится к категории «Фронтенд», поэтому она автоматически попадает в работу к тестировщику сайта. Срок выполнения тоже меняется автоматически.
  4. Тестировщик открывает задачу, смотрит, что от него нужно, и идёт прогонять новый стиль через тесты.
  5. Если все тесты прошли удачно — он закрывает задачу и она улетает дальше в отдел релизов. Если тест не пройден — в задачу ставится пометка и она снова возвращается фронтендеру, который ей занимался.

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

Таск-трекеры могут интегрироваться с другими системами: гитами, средами тестирования, средами разработки и т. д. Это нужно для крупных компаний, где любой шаг нужно стандартизировать.

Что такое баг-трекер

Баг-трекер — это трекер багов или ошибок, которые нужно исправить в программе. Там есть много из того, что есть в таск-трекере:

  • задача (описание ошибки),
  • степень критичности,
  • когда появилась,
  • кто ответственный.

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

Но баг-трекере есть свои нюансы: в зависимости от степени критичности ошибки они могут двигать другие задачи и внезапно становиться важнее всех остальных.

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

Зачем нужен таск-трекер и баг-трекер Зачем нужен таск-трекер и баг-трекер

Почему программисты не любят таск-трекеры

На самом деле здесь всё зависит от продакт-менеджера.

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

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

Зачем нужен таск-трекер и баг-трекер

А можно как-то без всего этого?

Если вы пишете программу или сервис один — то можно: вы сами решаете, что делать сейчас, а что потом. Если вас двое-трое, то тоже всё можно решить в чатиках и при личном общении.

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

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

Получите ИТ-профессию

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *