В Agile команде оформлением задач занимаются все – QA (по совместительству - тестировщики, аналитики, техподдержка), PM (в теории – главный аналитик, а на деле – только регулятор работ), разработчики (в основном понятии слова их первоочередной обязанностью и является конкретизация условий задачи). А поскольку у каждого человека свой "почерк" (забывчивость правил и отсутствие знаний как признак индивидуальности), то на понимание задачи у программиста и тестировщика уходит не мало времени (см. "Дорогие trivial-ы"). Дабы ускорить общекомандное время разработки продукта нужна унификация оформления. Jira частично помогает автоматизировать процесс, но кроме обязательных полей ускоряют понимание и некоторые пользовательские поля.
Проверку новооформленных задач можно разделить на ступени: достаточность обязательных полей, необходимость данных во вспомогательных полях, лингвистическая грамотность. Не обязательно, а даже желательно, разделить степени ответственности за оформление на разных сотрудников – от тех.писателя до заказчика.
Рассмотрим поля в Jira, заполняемые в команде Conquest Software Solutions при создании задач.
* Project Name. Корректность выбора продукта может проверять любой член команды, знающий все разрабатываемые продукты команды, чтобы идентичная задача была выполнена во всех глобальных и интеграционных модулях. Если вовремя не оформить задачу на все связанные продукты, то на доработку может потребоваться в несколько раз больше времени, нежели программист продумает один алгоритм для всех продуктов в едином скрипте.
* Issue Type. У тестировщиков постоянная дилема – баг или фича. От типа задачи зависят тексты заголовка и описания: для бага заголовок пишется в утвердительном наклонении (Проблема есть там-то при таких-то условиях), для новшества – в повелительном (Сделать что-то где-то по другому, новому). В зависимости от правильно выбранного типа задачи можно автоматизировать создание текста в поле Description. Проверка корректности поля Issue Type неразделима с проверкой полей Summary, Description. От типа задачи зависит список бэклога спринта: планирование новой версии в Conquest Software Solutions с помощью эдона Structure зависит только от объёма разработок, Project Manager при выполнении обязанностей scrum-master не включает ни старые, ни новые баги в план выпуска, эстимация фиксов багов не проводится и для публикации фикс-билда. В первую очередь тип задачи должен проверять на корректность Project Manager или Product Lead.
* Summary. Текст заголовка задачи надо проверять лингвисту, тем более, что его содержимое зависит от типа задачи, а чаще заменяет даже полное описание (Description). Текст должен быть в повелительном наклонении для предложений об усовершенствовании или новинок (Сделать что-то где-то иначе), и в утвердительном – для багов (Проблема такая-то есть там-то при таких-то условиях). Удобно создавать Summary беря за подсказку два правила "Что-Где-Когда" (в одном предложении вся суть) и "краткость – сестра таланта" (текст не должен быть более 5-7 слов и без знаков препинания). Единовременно человек запоминает не более 7 символов. Хорошим тоном у публицистов считается однозначность восприятия заголовка при отсутствии знаков препинания.
* Components. Список модулей, в которых проявляется баг или нужны дополнения, лучше других проверит сотрудник, кто проверяет и Project Name. Программисту дешевле составить сразу один алгоритм на все модули, нежели дорабатывать их после возврата задачи. Тестировщику тоже дешевле составить комплексный тест-план, зная полный список мест для интеграционной задачи.
* Affect Versions. Точное соответствие версии продукта, где был выявлен баг, а также наличие бага в текущей разрабатываемой версии сокращает время программисту для поиска причин ошибки или истории её появления. При составлении Release Notes по импрувам точный номер билда, отличный от текущего опубликованного, показывает временность предложения. Для техподдержки и QA точный номер билда, в котором импрува не было, сокращает время поиска билда, работавшего благополучно, без регрессии.
* Priority. Blocker-Critical-Major-Minor-Trivial. Каждая команда определяет свой список приоритетов. О смысловой нагрузке лучше договориться заранее, так как руководитель или заказчик понимают даже слово Blocker/Fatal по разному: кто-то блокером/фаталом считает лишь ту проблему, при которой продукт не запускается, а кому-то достаточно грамматической опечатки. Сочетание с Business Value и Issue Type проверяется старшим по продукту.
* Business Value. Пользовательское числовое поле, аналогично Severity. Со значениями обязательно договориться внутри команды. Старая BTS имела простую систему – от 0 до 99, новая была усложнена Project Manager: наивысший 10 может быть только у Blocker, Critical и в случае "пятиминутки" (см. "Дорогие trivial-ы" ) у Trivial; 11 разрешено давать Critial или Major, 12 как минимальное только для Major, Minor могут быть со значениями 13, 14, 15, и т.д.; Trivial в большинстве должны быть 15 и более. Логичнее и проще, конечно, основываться на обычных баллах от 0 до 100 или от 1 до 10(5). Но если выбрана сложная зависимость от Priority, то проверка на корректность оформления обязательна, и лучше от имени старшего программиста или заказчика.
* Environments. Не для всех задач нужны особые условия, но если их не упомянуть (продублировать) в собственном поле, то при кодировании и проверке тестировщиком будет перерасход времени. На этапе оформления задачи системное окружение лучше проверять разработчикам или системным аналитикам.
* Labels. Система пользовательских лейбл упрощает фильтрацию задач в Jira. Наличие или отсутствие особых лейбл при оформлении может быть тесно связано со значениями полей Affect Versions, Fix Versions, Priority, Business Value, Issue Type. Композицию этих полей следует модерировать в несколько стадий. Примеры лейбл:
actual (отмечаются задачи во время процесса актуализации после выпуска очередной версии, не может быть у новооформленной),
internal (задача с такой отметкой не входит в Release Notes, имеет невысокий приоритет проверки, содержимое нужно только для внутреннего использования командой),
fix_in_component (отметка об особенности правки, влияющей на множество иных модулей и продуктов, требует полного перечисления модулей/продуктов/скриптов с исправленным компонентом для полноценных интеграционных тестов),
fix_in_official (фикс должен войти в текущую опубликованную версию, лейбла помогает фильтровать задачи перед выпуском фикс-билда, фикс и тестирование проводятся в первую очередь, обязательно наличие последнего опубликованного билда в Affect Versions),
fix_in_previous (фикс должен войти в предыдущую опубликованную и до сих пор поддерживаемую версию, лейбла помогает фильтровать задачи перед выпуском фикс-билда, фикс и тестирование проводятся в первую очередь, обязательно наличие предыдущей версии в Affect Versions),
fix_in_rc (фикс должен войти в ближайшую публикуемую версию, лейбла помогает фильтровать задачи перед выпуском новой версии, фикс и тестирование проводятся в первую очередь, обязательно наличие планируемой версии в Fix Versions для импрувов),
non_actual (отмечаются задачи во время процесса актуализации после выпуска очередной версии, не может быть у новооформленной, признак для автозакрытия программистом или старшим по продукту),
rare (редкие задачи могут иметь только Minor или Trivial приоритет и Business Value не выше 15, фикс и тестирование в таком же низком приоритете, обязательно упоминание условий редкости в Description и Environments),
regression (проблемы, как следствие нововведений, должны исправляться в первую очередь, не может иметь Affect Versions равным опубликованным билдам без исходного импрува, обязательно наличие линков с исходным импрувом),
temporary (не может быть у новооформленной задачи, пометка нужна для отсеивания из Release Notes, промежуток между Affect Versions и Fix Versions не должен перекрывать опубликованные билды),
waiting_for_feedback (некоторые задачи невозможно полноценно оформить без подтверждения заказчика или какого-то специалиста, наличие лейблы оправдывает незапланированный Status).
* Status. Баги планирует оформитель задачи, импрувы – только скрам-мастер и добавляет их в Structure. Любой может проверить корректность оформления совокупности полей Status-Issue Type-Fix Versions-Structure и сообщить о проблемах оформителю или PM.
* Bug_Hunter. Пользовательское поле в помощь к Reporter и Creator. Не всякого пользователя продукта можно добавить в список для выбора в поле Reporter, поэтому строковое Bug_Hunter помогает отсеить задачи конечных пользователей. За оформление поля отвечает сотрудник тех.поддержки, если поле не пустое, то в Description или Comments указывается способ связи с клиентом или его контакты.
* Assignee. Столь удобное автозаполнение по продукту или компоненту не всегда получается актуальным. В одной задаче можно обозначить несколько модулей, а связка с ответственным сделается по одному из модулей в алфавитном порядке. Назначенность задания надо перепроверять старшему программисту или руководителю команды.
* Fix Versions. Трёхзначный номер версии (без билда, только [Major-Minor-Release]) оформляется для импрувов, входящих в бэклог выпуска. Новооформленные баги должны быть с пустым значением. Актуальность поля лежит в ответственности QA.
* Resolution. У новооформленной задачи через клонирование может получиться некорректное значение, сбивающее с толку руководство и исполнителя. Сменить его можно во время перехода статусов.
* Description. Один из самых важных параметров задачи необходимо проверять в несколько этапов. Для ускорения работы и унификации текстов в Conquest Software Solutions были настроены два шаблона Баг и Импрув с точным использованием заголовков, стилей и фонтов, межстрочных интервалов. Для срабатывания (автовставка текста в поле Description) шаблонов необходимо создавать задачу в два этапа: сначала выбрать Product, Issue Type, Components, напечатать что-нибудь в поле Summary, создать задачу в Jira, при этом якобы пустое поле Description автоматически будет оформлено шаблоном в зависимости от выбранного типа задачи:
шаблон для типа BUG:
шаблон для типов NEW FEATURE, IMPROVEMENT:
При проверке на соответствие стандарту Project Manager отказывал в планировании импрувов, если не хватало пустой строки между абзацами или заголовок не был bold, либо банально удалял задачу и передавал оформление "дубликата" иному сотруднику без пояснения несовпадений с шаблоном и не принимая во внимание возможность смены типа задачи после её создания. Ещё один неудобный момент использования шаблонов заключается в автоматическом перевыборе Assignee в момент применения шаблона, но при этом в истории задачи логгируются изменения от имени автора шаблона.
Кроме соответствия стандарту, текст обязательно проверять тех.писателю или хорошему лингвисту, чтоб исключить последующие отвлекания оформителя и задержки разработки. Для удобства проверок необходимо договориться с командой о создании глоссария, словаря спец.слов и сокращений.
На полноценность текста влияют многие поля: Product (задача может быть склонирована для нескольких продуктов), Issue Type (шаблон зависит от типа задачи), Summary (не должно быть логического противоречия в кратком и подробном описаниях), Affect Versions (в примечаниях указываются отличия версий), Attachments (наличие и соответствие имён упомянутых прикреплений), Components (нет необходимости дублировать модули в полном описании, но есть смысл перечислить затрагиваемые скрипты в комментариях для облегчения составления плана фикса и проверки), Environments (особые настройки желательно перечислять в блоке Notes), Labels (некоторые из лейбл требуют детализации), Bug_Hunter (если в поле есть ID конечного пользователя, то строка про номер OSD не может быть пустой в описании; к сожалению, поиск в текстах Jira подразумевает своё определённое совпадение символов, поэтому фильтр по задачам от юзеров сложный).
* Attachments. Большинство задач невозможно описать только словами, поэтому для интерфейсных модулей обязательно наличие хотя бы одного снимка экрана с местом правки или прототипом новшества. Видеоролик бага часто заменяет множество описаний. Копии писем пользователей удобнее иметь в архивированном виде. В задаче от конечного пользователя должны быть оригинальные прикрепления из юзерского отчёта, чтобы у исполнителя не было причин отвлекать оформителя.
* Comments. Для новооформленной задачи комментарии не нужны, но проверяющий может указать имя оформителя или иного члена команды через символ "@" для более быстрого реагирования на замечания к описанию.
* Links. "Проверка одной задачи порождает как минимум две новые". У любого бага существует задача-импрув, породившая его. Даже отчёт от конечного пользователя не был бы создан, если бы не появилось что-то новое в продукте. Связь бага с породившим его импрувом – 50% помощи программисту для исправления. TestSession в режиме исполнения и функция клонирования линкуют автоматически. Список линков может быть расширен Jira-пользовательскими настройками, например, "Устаревшая задача + Отменяющая задача".
* TestSession. При подключенном плагине Capture в Jira появляется возможность более подробно описать и выполнить проверку фикса. Оформлением тест-сессии занимается тест-лид, расписывает тест-план и назначает тестировщика-исполнителя. Тест-сессия создаётся только для сложных задач, подразумевающих комплексное тестирование. Полноценность тест-плана проверяет Team Lead.
* Structure. По необъяснимому и упрямому желанию Project Manager в компании Conquest Software Solutions в Structure добавляются задачи только типов Improvement и New Feature. Каждая задача включается в бэклог при оформлении, а не при планировании ближайшей версии продукта. В бэклог задача добавляется до эстимации (оценки затрачиваемого времени) членами команды (аналитик-программист-тестировщик). Поэтому корректность оформления возложена только на самого PM, а для всех остальных членов команды оно всего лишь информативное.
* Due Date. Дата, к которой задача должна быть исполнена, напрямую зависит от планов (Status, Structure, Fix Versions). Заполнение поля производит планировщик бэклога, информация важна исполнителям (в Assignee выбирается только программист, у которого не всегда есть право публикации) и проверяющему исполнение (в Conquest Software Solutions не оформляются отдельные задачи для тестирования и публикации каждого импрува, не переназначаются Assignee, поскольку фактический объём работ тестировщиков никак не учитывается).
* TO-DO. Чек-лист для типа задачи Task. Необязательное к заполнению поле используется в основном для чек-листов выпуска билда, когда мелкие шаги задачи должны выполнять разные сотрудники (QA, DevOps, ..). Полноценность оформления желательно контролировать руководящему составу.
Как много времени и сил нужно на проверку? Если эффективно распределить обязанности, то не более 20-30 секунд на каждую задачу. Если всю проверку делать один раз в день/неделю, то "набитый глаз" позволяет ускорять процесс.
Позднее аккумулированный объём знаний ускоряет принятие решений сотрудниками техподдержки при определении причн проблем от пользователей, дальнейшая разработка новинок сразу учитывает имеющиеся нюансы. А в случае большой текучки кадров не приходится искать виновных в недооформленности, поскольку тонкости учтены заранее.
Ещё одно преимущество в проверке новых задач всей командой – можно сократить количество собраний о проделанной и планируемой работе. Ознакомление каждого члена команды о направлениях развития продуктов через новые задачи упрощает понимание целей разработки. Получается, что все в курсе всех дел всегда.
Проверку новооформленных задач можно разделить на ступени: достаточность обязательных полей, необходимость данных во вспомогательных полях, лингвистическая грамотность. Не обязательно, а даже желательно, разделить степени ответственности за оформление на разных сотрудников – от тех.писателя до заказчика.
Рассмотрим поля в Jira, заполняемые в команде Conquest Software Solutions при создании задач.
* Project Name. Корректность выбора продукта может проверять любой член команды, знающий все разрабатываемые продукты команды, чтобы идентичная задача была выполнена во всех глобальных и интеграционных модулях. Если вовремя не оформить задачу на все связанные продукты, то на доработку может потребоваться в несколько раз больше времени, нежели программист продумает один алгоритм для всех продуктов в едином скрипте.
* Issue Type. У тестировщиков постоянная дилема – баг или фича. От типа задачи зависят тексты заголовка и описания: для бага заголовок пишется в утвердительном наклонении (Проблема есть там-то при таких-то условиях), для новшества – в повелительном (Сделать что-то где-то по другому, новому). В зависимости от правильно выбранного типа задачи можно автоматизировать создание текста в поле Description. Проверка корректности поля Issue Type неразделима с проверкой полей Summary, Description. От типа задачи зависит список бэклога спринта: планирование новой версии в Conquest Software Solutions с помощью эдона Structure зависит только от объёма разработок, Project Manager при выполнении обязанностей scrum-master не включает ни старые, ни новые баги в план выпуска, эстимация фиксов багов не проводится и для публикации фикс-билда. В первую очередь тип задачи должен проверять на корректность Project Manager или Product Lead.
* Summary. Текст заголовка задачи надо проверять лингвисту, тем более, что его содержимое зависит от типа задачи, а чаще заменяет даже полное описание (Description). Текст должен быть в повелительном наклонении для предложений об усовершенствовании или новинок (Сделать что-то где-то иначе), и в утвердительном – для багов (Проблема такая-то есть там-то при таких-то условиях). Удобно создавать Summary беря за подсказку два правила "Что-Где-Когда" (в одном предложении вся суть) и "краткость – сестра таланта" (текст не должен быть более 5-7 слов и без знаков препинания). Единовременно человек запоминает не более 7 символов. Хорошим тоном у публицистов считается однозначность восприятия заголовка при отсутствии знаков препинания.
* Components. Список модулей, в которых проявляется баг или нужны дополнения, лучше других проверит сотрудник, кто проверяет и Project Name. Программисту дешевле составить сразу один алгоритм на все модули, нежели дорабатывать их после возврата задачи. Тестировщику тоже дешевле составить комплексный тест-план, зная полный список мест для интеграционной задачи.
* Affect Versions. Точное соответствие версии продукта, где был выявлен баг, а также наличие бага в текущей разрабатываемой версии сокращает время программисту для поиска причин ошибки или истории её появления. При составлении Release Notes по импрувам точный номер билда, отличный от текущего опубликованного, показывает временность предложения. Для техподдержки и QA точный номер билда, в котором импрува не было, сокращает время поиска билда, работавшего благополучно, без регрессии.
* Priority. Blocker-Critical-Major-Minor-Trivial. Каждая команда определяет свой список приоритетов. О смысловой нагрузке лучше договориться заранее, так как руководитель или заказчик понимают даже слово Blocker/Fatal по разному: кто-то блокером/фаталом считает лишь ту проблему, при которой продукт не запускается, а кому-то достаточно грамматической опечатки. Сочетание с Business Value и Issue Type проверяется старшим по продукту.
* Business Value. Пользовательское числовое поле, аналогично Severity. Со значениями обязательно договориться внутри команды. Старая BTS имела простую систему – от 0 до 99, новая была усложнена Project Manager: наивысший 10 может быть только у Blocker, Critical и в случае "пятиминутки" (см. "Дорогие trivial-ы" ) у Trivial; 11 разрешено давать Critial или Major, 12 как минимальное только для Major, Minor могут быть со значениями 13, 14, 15, и т.д.; Trivial в большинстве должны быть 15 и более. Логичнее и проще, конечно, основываться на обычных баллах от 0 до 100 или от 1 до 10(5). Но если выбрана сложная зависимость от Priority, то проверка на корректность оформления обязательна, и лучше от имени старшего программиста или заказчика.
* Environments. Не для всех задач нужны особые условия, но если их не упомянуть (продублировать) в собственном поле, то при кодировании и проверке тестировщиком будет перерасход времени. На этапе оформления задачи системное окружение лучше проверять разработчикам или системным аналитикам.
* Labels. Система пользовательских лейбл упрощает фильтрацию задач в Jira. Наличие или отсутствие особых лейбл при оформлении может быть тесно связано со значениями полей Affect Versions, Fix Versions, Priority, Business Value, Issue Type. Композицию этих полей следует модерировать в несколько стадий. Примеры лейбл:
actual (отмечаются задачи во время процесса актуализации после выпуска очередной версии, не может быть у новооформленной),
internal (задача с такой отметкой не входит в Release Notes, имеет невысокий приоритет проверки, содержимое нужно только для внутреннего использования командой),
fix_in_component (отметка об особенности правки, влияющей на множество иных модулей и продуктов, требует полного перечисления модулей/продуктов/скриптов с исправленным компонентом для полноценных интеграционных тестов),
fix_in_official (фикс должен войти в текущую опубликованную версию, лейбла помогает фильтровать задачи перед выпуском фикс-билда, фикс и тестирование проводятся в первую очередь, обязательно наличие последнего опубликованного билда в Affect Versions),
fix_in_previous (фикс должен войти в предыдущую опубликованную и до сих пор поддерживаемую версию, лейбла помогает фильтровать задачи перед выпуском фикс-билда, фикс и тестирование проводятся в первую очередь, обязательно наличие предыдущей версии в Affect Versions),
fix_in_rc (фикс должен войти в ближайшую публикуемую версию, лейбла помогает фильтровать задачи перед выпуском новой версии, фикс и тестирование проводятся в первую очередь, обязательно наличие планируемой версии в Fix Versions для импрувов),
non_actual (отмечаются задачи во время процесса актуализации после выпуска очередной версии, не может быть у новооформленной, признак для автозакрытия программистом или старшим по продукту),
rare (редкие задачи могут иметь только Minor или Trivial приоритет и Business Value не выше 15, фикс и тестирование в таком же низком приоритете, обязательно упоминание условий редкости в Description и Environments),
regression (проблемы, как следствие нововведений, должны исправляться в первую очередь, не может иметь Affect Versions равным опубликованным билдам без исходного импрува, обязательно наличие линков с исходным импрувом),
temporary (не может быть у новооформленной задачи, пометка нужна для отсеивания из Release Notes, промежуток между Affect Versions и Fix Versions не должен перекрывать опубликованные билды),
waiting_for_feedback (некоторые задачи невозможно полноценно оформить без подтверждения заказчика или какого-то специалиста, наличие лейблы оправдывает незапланированный Status).
* Status. Баги планирует оформитель задачи, импрувы – только скрам-мастер и добавляет их в Structure. Любой может проверить корректность оформления совокупности полей Status-Issue Type-Fix Versions-Structure и сообщить о проблемах оформителю или PM.
* Bug_Hunter. Пользовательское поле в помощь к Reporter и Creator. Не всякого пользователя продукта можно добавить в список для выбора в поле Reporter, поэтому строковое Bug_Hunter помогает отсеить задачи конечных пользователей. За оформление поля отвечает сотрудник тех.поддержки, если поле не пустое, то в Description или Comments указывается способ связи с клиентом или его контакты.
* Assignee. Столь удобное автозаполнение по продукту или компоненту не всегда получается актуальным. В одной задаче можно обозначить несколько модулей, а связка с ответственным сделается по одному из модулей в алфавитном порядке. Назначенность задания надо перепроверять старшему программисту или руководителю команды.
* Fix Versions. Трёхзначный номер версии (без билда, только [Major-Minor-Release]) оформляется для импрувов, входящих в бэклог выпуска. Новооформленные баги должны быть с пустым значением. Актуальность поля лежит в ответственности QA.
* Resolution. У новооформленной задачи через клонирование может получиться некорректное значение, сбивающее с толку руководство и исполнителя. Сменить его можно во время перехода статусов.
* Description. Один из самых важных параметров задачи необходимо проверять в несколько этапов. Для ускорения работы и унификации текстов в Conquest Software Solutions были настроены два шаблона Баг и Импрув с точным использованием заголовков, стилей и фонтов, межстрочных интервалов. Для срабатывания (автовставка текста в поле Description) шаблонов необходимо создавать задачу в два этапа: сначала выбрать Product, Issue Type, Components, напечатать что-нибудь в поле Summary, создать задачу в Jira, при этом якобы пустое поле Description автоматически будет оформлено шаблоном в зависимости от выбранного типа задачи:
шаблон для типа BUG:
Introduction: [Enter text of issue history. Optionally.] User wrote: {quote} [Enter text from end-user. Optionally.] {quote} (OSD=[Enter OSD message number. Optionally.]) Steps to reproduce: [List steps of actions. Mandatory.] Actual result: [Describe actual, detailed result of actions in product. Mandatory.] Expected result: [Describe the detailed expected result of actions in product. Mandatory.] Notes: [Explain additional information. Optionally.] |
Introduction: [Enter text of issue history. Optionally.] User wrote: {quote} [Enter text from end-user. Optionally.] {quote} (OSD=[Enter OSD message number. Optionally.]) Resolutions: [Describe the detailed expected result. Mandatory.] Notes: [Explain additional information. Optionally.] |
При проверке на соответствие стандарту Project Manager отказывал в планировании импрувов, если не хватало пустой строки между абзацами или заголовок не был bold, либо банально удалял задачу и передавал оформление "дубликата" иному сотруднику без пояснения несовпадений с шаблоном и не принимая во внимание возможность смены типа задачи после её создания. Ещё один неудобный момент использования шаблонов заключается в автоматическом перевыборе Assignee в момент применения шаблона, но при этом в истории задачи логгируются изменения от имени автора шаблона.
Кроме соответствия стандарту, текст обязательно проверять тех.писателю или хорошему лингвисту, чтоб исключить последующие отвлекания оформителя и задержки разработки. Для удобства проверок необходимо договориться с командой о создании глоссария, словаря спец.слов и сокращений.
На полноценность текста влияют многие поля: Product (задача может быть склонирована для нескольких продуктов), Issue Type (шаблон зависит от типа задачи), Summary (не должно быть логического противоречия в кратком и подробном описаниях), Affect Versions (в примечаниях указываются отличия версий), Attachments (наличие и соответствие имён упомянутых прикреплений), Components (нет необходимости дублировать модули в полном описании, но есть смысл перечислить затрагиваемые скрипты в комментариях для облегчения составления плана фикса и проверки), Environments (особые настройки желательно перечислять в блоке Notes), Labels (некоторые из лейбл требуют детализации), Bug_Hunter (если в поле есть ID конечного пользователя, то строка про номер OSD не может быть пустой в описании; к сожалению, поиск в текстах Jira подразумевает своё определённое совпадение символов, поэтому фильтр по задачам от юзеров сложный).
* Attachments. Большинство задач невозможно описать только словами, поэтому для интерфейсных модулей обязательно наличие хотя бы одного снимка экрана с местом правки или прототипом новшества. Видеоролик бага часто заменяет множество описаний. Копии писем пользователей удобнее иметь в архивированном виде. В задаче от конечного пользователя должны быть оригинальные прикрепления из юзерского отчёта, чтобы у исполнителя не было причин отвлекать оформителя.
* Comments. Для новооформленной задачи комментарии не нужны, но проверяющий может указать имя оформителя или иного члена команды через символ "@" для более быстрого реагирования на замечания к описанию.
* Links. "Проверка одной задачи порождает как минимум две новые". У любого бага существует задача-импрув, породившая его. Даже отчёт от конечного пользователя не был бы создан, если бы не появилось что-то новое в продукте. Связь бага с породившим его импрувом – 50% помощи программисту для исправления. TestSession в режиме исполнения и функция клонирования линкуют автоматически. Список линков может быть расширен Jira-пользовательскими настройками, например, "Устаревшая задача + Отменяющая задача".
* TestSession. При подключенном плагине Capture в Jira появляется возможность более подробно описать и выполнить проверку фикса. Оформлением тест-сессии занимается тест-лид, расписывает тест-план и назначает тестировщика-исполнителя. Тест-сессия создаётся только для сложных задач, подразумевающих комплексное тестирование. Полноценность тест-плана проверяет Team Lead.
* Structure. По необъяснимому и упрямому желанию Project Manager в компании Conquest Software Solutions в Structure добавляются задачи только типов Improvement и New Feature. Каждая задача включается в бэклог при оформлении, а не при планировании ближайшей версии продукта. В бэклог задача добавляется до эстимации (оценки затрачиваемого времени) членами команды (аналитик-программист-тестировщик). Поэтому корректность оформления возложена только на самого PM, а для всех остальных членов команды оно всего лишь информативное.
* Due Date. Дата, к которой задача должна быть исполнена, напрямую зависит от планов (Status, Structure, Fix Versions). Заполнение поля производит планировщик бэклога, информация важна исполнителям (в Assignee выбирается только программист, у которого не всегда есть право публикации) и проверяющему исполнение (в Conquest Software Solutions не оформляются отдельные задачи для тестирования и публикации каждого импрува, не переназначаются Assignee, поскольку фактический объём работ тестировщиков никак не учитывается).
* TO-DO. Чек-лист для типа задачи Task. Необязательное к заполнению поле используется в основном для чек-листов выпуска билда, когда мелкие шаги задачи должны выполнять разные сотрудники (QA, DevOps, ..). Полноценность оформления желательно контролировать руководящему составу.
Why "issue review"?
Основная причина необходимости проверки новых задач в том, чтобы сократить время на последующую разработку – отвлекать оформителя от текущих дел более накладно в момент разработки, нежели по горячим следам в день оформления.Как много времени и сил нужно на проверку? Если эффективно распределить обязанности, то не более 20-30 секунд на каждую задачу. Если всю проверку делать один раз в день/неделю, то "набитый глаз" позволяет ускорять процесс.
Позднее аккумулированный объём знаний ускоряет принятие решений сотрудниками техподдержки при определении причн проблем от пользователей, дальнейшая разработка новинок сразу учитывает имеющиеся нюансы. А в случае большой текучки кадров не приходится искать виновных в недооформленности, поскольку тонкости учтены заранее.
| Наименование поля | Project Manager, Заказчик | Team Lead | Лингвист | Член команды |
|---|---|---|---|---|
| Affect Versions | 1-2 сек | |||
| Assignee | 3-5 сек | |||
| Attachments | 1-2 сек | |||
| Bug_Hunter | 1-2 сек | |||
| Business Value | 3-5 сек | |||
| Comments | 1-2 сек | |||
| Components | 3-5 сек | |||
| Description | 2 мин | 10 сек | ||
| Due Date | 1-2 сек | |||
| Environments | 3-5 сек | |||
| Fix Versions | 3-5 сек | |||
| Issue Type | 1-2 сек | |||
| Labels | 1-2 сек | 1-2 сек | ||
| Links | 3-5 сек | |||
| Priority | 1-2 сек | |||
| Project Name | 1-2 сек | |||
| Resolution | 1-2 сек | |||
| Status | 3-5 сек | |||
| Structure | 3-5 сек | |||
| Summary | 3-5 сек | |||
| TestSession | 0 сек - 1 мин | 3-5 сек | ||
| TO-DO | 0 сек - 1 мин | 3-5 сек | ||
| ИТОГО: | 14-24 сек | 7 сек - 2 мин 12 сек | 2 мин 3-5 сек | 30-56 сек |
Ещё одно преимущество в проверке новых задач всей командой – можно сократить количество собраний о проделанной и планируемой работе. Ознакомление каждого члена команды о направлениях развития продуктов через новые задачи упрощает понимание целей разработки. Получается, что все в курсе всех дел всегда.
при проверке поля Description стоит помнить о http://analyst.by/news/kak-izbezhat-dvusmyislennosti-v-trebovaniyah
ОтветитьУдалитькратко о вышеописанном - http://cmsplugin.ru/page/bug-tracking
Статья "Тестирование требований. Особенности"(http://quality-lab.ru/testing-requirements/) от Александра Филиппова ещё раз отвечает на вопрос "Зачем проверять описание до начала работ?"