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

Все жалобы пользователей должны где-то храниться, быть приоритезированы, удобно отслеживаться, и, более того, должны быть вовремя обработаны. Но не всегда есть возможность выделить достаточно ресурсов на разработку и поддержание подобной системы, ведь всегда найдется задача в бэклоге с более высоким приоритетом. Ниже я расскажу, как мы достаточно эффективно и быстро решили эту задачу в Uxcel используя JIRA REST API.

Для чего нам Report a problem?

Добавим немного контекста для чего мы предоставляем функционал жалоб и что нам нужно?
Uxcel веб-сервис для обучения UI/UX в игровой форме. Обучающим элементом у нас является Практика в большинстве случаев это 2 изображения, где одно верное, а другое нет. Что позволяет натренировать глаз находить недочеты даже в визуально идентичных элементах. Каждая практика помимо изображений имеет подсказку (hint наводку на верный ответ) и описание (description) с теорией, касающейся данной задачи.

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

Чтобы не изобретать велосипед со своими бордами, тикетами и backlog-ом, а также чтобы хранить все задачи команд в одной системе и даже в общих спринтах, было решено для этих целей использовать JIRA + REST API.

Организация тикетов в JIRA

Для каждой практики у которой есть хотя бы 1 жалоба создается BUG в JIRA в выделенном эпике Practices Reports. А сами жалобы хранятся в виде комментариев к соответствующим багам-практикам. В дополнение к этому, для разных видов практик добавляется Label (в нашем случае такие как: Course, Gym, UEye). Общая логика представлена на схеме ниже:

Таким образом, контент-команда выбирает наиболее приоритетные практики (в виде багов) для исправления в каждом спринте.

А теперь давайте взглянем на технические подробности реализации.

Интеграция с JIRA REST API

Первым делом нужно создать API token в JIRA, чтобы получить доступ к JIRA API. Для использования на продакшене рекомендую создать отдельного пользователя от имени которого и будут создаваться тикеты, иначе придется отбиваться от постоянных уведомлений, в то время как для отдельного пользователя их проще сразу все отключить.

Получение API токена:

• Логинимся в https://id.atlassian.com/manage/api-tokens
• Создаем API token

• Задаем имя токена -> нажимаем Create

Готово. Сохраняем куда-нибудь созданный токен, терять его нельзя.

Теперь можно выполнять API запросы к JIRA. В каждый запрос передается заголовок, содержащий емейл (пользователя для которого был создан токен) и сам токен их передаем посредством реализации HTTP basic authentication.

Пример кода (весь код на TypeScript для NodeJS):

private generateAuthHeader(): string {    // конвертируем строку email:apiToken в Base64    const basicAuthValue = Buffer.from(`${this.jiraEmail}:${this.jiraApiToken}`).toString('base64');     return `Basic ${basicAuthValue}`;}

Примечание: для хранения ключей и паролей мы используем AWS Secrets Manager. Прямо в коде такие данные хранить не безопасно. Больше информации тут.

Создание бага через API

Осталось совсем немного подготовки. Для того чтобы создать баг, нам нужно знать его Issue ID в JIRA. Один из способов его узнать вызвать GET запрос на получение информации обо всех типах:

GET https://{id}.atlassian.net/rest/api/3/issuetype 

Поскольку это разовая операция, то чтобы не писать код можно воспользоваться Postman:

Во вкладке Authorization выбираем Type: Basic Auth, вводим email и api token.

В ответе нас интересует эта часть:

{    "self": "https://{id}.atlassian.net/rest/api/3/issuetype/10004",    "id": "10001",    "description": "A problem or error.",    "iconUrl": "https://${id}.atlassian.net/secure/viewavatar?size=medium&avatarId=10303&avatarType=issuetype",    "name": "Bug",    "untranslatedName": "Bug",    "subtask": false,    "avatarId": 10303}

После того как узнали Issue Id типа BUG (10001) нам нужно узнать Project Id, к которому баг будет принадлежать. Похожим образом можем получить список всех проектов и найти id нужного.

Для этого делаем GET запрос на

GET https://{id}.atlassian.net/rest/api/3/project/search

И последний подготовительный шаг: как я выше упоминал, мы храним баги в отдельном эпике (Jira Epic). Его id знать не обязательно, достаточно скопировать его Key (расположен перед названием эпика, либо в адресной строке, например UX-1).

Все готово к созданию первого бага через API.

Я использовал npm пакет Got для создания HTTP запросов для NodeJS.

await got.post({    url: `${this.jiraApiHost}/issue`, // jiraApiHost = https://{id}.atlassian.net/rest/api/3    headers: {        Authorization: authorization, // созданный Basic Auth Header в методе generateAuthHeader        'Content-Type': 'application/json'    },    responseType: 'json',    json: {        update: {},        fields: {            issuetype: { id: this.jiraBugTypeId }, // полученный id типа BUG (пример - 10001)            project: { id: this.jiraPracticeReportProjectId }, // id проекта (пример - 10005)            parent: { key: this.jiraPracticeReportEpicKey }, // ключ Epic (пример - UX-1)            summary: practiceTicketName, // имя практики формата -  [practiceId] practiceName (#reports)            labels: [practice.label]        }    }});

API Reference

Баг создан. Далее рассмотрим остальные методы необходимые для настройки полного цикла обработки жалоб и ведения их в JIRA, такие как: Поиск, Обновление статуса, Обновление информации, Добавление комментария к багу.

Поиск бага через API

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

Пример кода:

// формируем JQL запрос, ищем по типу BUG в эпике где хранятся жалобы по id практики (которое есть в названии каждого бага)const jql = `issuetype = Bug AND project = CNT AND parent = ${this.jiraEpicKey} AND text ~ "${practiceId}" order by created DESC`; const response = await got.get({    url: `${this.jiraApiHost}/search?jql=${jql}`,    headers: {        Authorization: authorization    },    responseType: 'json'});const practiceJiraTicket = response.body['issues'] && response.body['issues'][0];

API Reference

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

Обновление статуса бага через API

Чтобы обновить статус, воспользуемся Transitions. Но для этого нужно узнать Status ID для TODO / OPENED статуса (статус зависит от настроек JIRA).

Возвращаемся к Postman:

GET https://{id}.atlassian.net/rest/api/3/project/{projectIdOrKey}/statuses

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

Запрос на перевод бага в открытый статус:

await got.post({    url: `${this.jiraApiHost}/issue/${practiceJiraTicket.key}/transitions`, // где practiceJiraTicket - найденный объект бага    headers: {        Authorization: authorization,        'Content-Type': 'application/json'    },    responseType: 'json',    json: {        transition: {            id: this.jiraToDoStatusId // id статуса полученного выше (пример - 10006)        }    }});

API Reference

Следующий шаг после перевода найденного бага в открытое состояние обновление названия (а если нужно, то и описания либо приоритета).

Обновление названия бага через API

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

Код вызова API для обновления бага:

await got.put({    url: `${this.jiraApiHost}/issue/${practiceJiraTicket.key}`,    headers: {        Authorization: authorization,        'Content-Type': 'application/json'    },    responseType: 'json',    json: {        update: {            summary: [{ set: newPracticeTicketName }]        }    }});

API Reference

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

Добавление комментария через API

Каждая жалоба пользователя хранится в виде комментария к багу-практике.

Код создания комментария:

await got.post({    url: `${this.jiraApiHost}/issue/${practiceJiraTicket.key}/comment`,    headers: {        Authorization: authorization,        'Content-Type': 'application/json'    },    responseType: 'json',    json: comment // подробности о формировании объекта ниже});

API Reference

Объект comment формируется в виде Atlassian Document Format.
На сайте так же есть Builder, который значительно упрощает генерацию объекта: просто форматируем текст под свои нужды в редакторе при этом параллельно создается итоговый JSON объект.

Готово! Теперь можно принимать, хранить, обрабатывать, закидывать в спринты и удобно искать жалобы пользователей используя JIRA.

Как у нас выглядят жалобы в виде комментариев:

Итоговый вид нашего списка багов в JIRA (название содержит id, #N число жалоб, % верных ответов):

Дальше все зависит от вашей фантазии и требований. Например, можно:

• реализовать асинхронную обработку жалоб, чтобы пользователь не ждал пока пройдет вся цепочка запросов к JIRA (у нас реализовано средствами AWS SNS)
• добавить поле priority для багов и менять приоритет в зависимости от числа жалоб для более удобной фильтрации в борде
• дополнительно информировать модераторов в Slack при появлении новой жалобы со ссылкой на созданный баг (slack/webhook пакет очень прост в интеграции)
• настроить JIRA Webhooks, чтобы при закрытии бага автоматически рассылать уведомления всем пользователям, которые жаловались на практику с благодарностью за участие в улучшении продукта
• автоматически назначать баг на автора контента, на который поступила жалоба.

Всем спасибо за внимание! Надеюсь, статья была для вас полезной :)
С радостью отвечу на ваши вопросы!

Что такое Trello, и как оно работает?

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

P.S. если вы хоть раз открывали приложение trello листайте до основы работы.

Как начать работу

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

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

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

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

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

Основы работы

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

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

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

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

Интересная модель: когда я готовился к ЕГЭ, и у меня было большое количество вебинаров, которое нужно было посмотреть, я просто создавал чек-лист с вебинарами и в строчки вносил ссылки на эти видео, а затем отмечал по мере просмотра.

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

Как это сделать:

1. В правом верхнем углу доски нажимаем на кнопку меню.
2. Далее, в открывшемся меню мы видим раздел Улучшения.
3. Открываем этот раздел и вбиваем в поиск календарь, по-русски или по-английски в зависимости от версии приложения.
4. Видим карточку calendar и нажимаем добавить.
5. Готово, теперь на нашей доске есть календарь.

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

Четвертая штука это вложения, на них мы остановимся поподробнее. Для меня, человека, который из-за учебы работает с огромным количеством файлов, это одна из самых полезных функций карточки. В эти вложения можно очень просто добавлять картинки или файлы, перетащив их из папки на компьютере или телефоне на карточку (drag and drop).

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

Вот мои шаблоны, копируйте, пользуйтесь.

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

Шаблоны

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

P.S. я использую шаблон, который можно найти, вбив getting things done.

Синтаксис

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

В trello используется известный во всем мире способ синтаксиса markdown, и вот некоторые штуки, которые можно применять для оформления текста в карточке trello.

Заголовки

Если вам нужно выделять заголовки, ставим # (чем больше хэштегов перед заголовком, тем меньше будет шрифт заголовка).

Заголовок H1

Заголовок H2

Шрифты

Различные виды шрифтов (ставим служебные символы перед и после текста и при дальнейшем просмотре карточки шрифты будут различаться).

Курсив и Курсив
Жирный текст и Жирный текст
Жирный и курсивный текст

Выделение

Выделение части текста рамочкой другого оттенка, ставим (>) перед текстом и все красиво.

Очень глубокомысленная цитата. Пожалуйста, прочтите её внимательно.

Оскар Уайльд

Линии разделения

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

(***)
(___)

Зачеркнутый текст

Символ (~)
~~ зачеркнутый текст ~~
зачеркнутый текст

Как посчитать количество карточек?

Если на доске открыть меню и вбить в поиск карточек символ ($), то над каждым столбцом появится количество карточек в нем.

Заключение

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

Рамки исследования

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

Дж. Коплиен

• управление требованиями;
• формирование постановок задач для программистов, планирование реализации и контроль выполнения этих задач;
• подготовка проектной документации.

Проектные решения VS проектной документации?

Как всё прекрасно на бумаге,
Как легко следовать словам.
Как просто сделать так, что ты непогрешим.

Б. Гребенщиков

Описание слона не по ГОСТ

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

Фредерик Брукс

1. Перечень требований заказчика (которые будут реализованы в рамках проектного решения).
2. Список определений и сокращений.
3. Перечень нормативных документов, регламентирующих автоматизируемый процесс.
4. Описание порядка применения программного обеспечения (use case), которое может включать:
   
   описание автоматизируемого процесса (как правило, в формате BPMN не забывайте отмечать, как выполняется то или иное действие: автоматически, автоматизировано или вообще без компьютера) и предполагаемого результата;
   перечень ролей и их полномочий;
   определение необходимости ведения истории изменения объектов учета (необходимость хранения и последующего анализа предыдущих значений атрибутов объекта) пренебрежение данным пунктом может увеличить время разработки в разы;
   определение необходимости протоколирования действий пользователей (определение таких действий, связь с историей изменения объекта).
5. Описание доработки:
   
   описание новых классификаторов и требования по доработке имеющихся, определение порядка их сопровождения;
   описание пользовательского интерфейса (UI) и правил его отображения (в случае, если в рамках проектного решения определяются схемы процессов, все экранные формы должны быть связаны с действиями на этих схемах);
   описание печатных отчетов и правил (алгоритмов) их формирования.
6. Электронный обмен данными:
   
   описание форматов и регламента взаимодействия через API;
   описание форматов и регламента (последовательности) загрузки внешних данных в ручном режиме (в виде файлов);
   описание форматов и регламента (последовательности) выгрузки данных в ручном режиме в виде файлов.
   
   В качестве примеров проектного решения по электронному обмену данными может здорово пригодиться пакет стандартов, разработанный некоммерческим партнерством Стандарты некоммерческого обмена информацией (партнерство распалось в 2011 г., в настоящее время эти стандарты продолжает сопровождать компания 1С). Также могут помочь нормативно-эксплуатационные документы, размещенные на техническом портале Системы межведомственного электронного взаимодействия (СМЭВ).
7. Определение полномочий доступа:
   
   определение атомарных действий, по которым должно (может) производиться ограничение доступа, определение иерархии этих действий;
   определение перечня атрибутов объекта, по которым должно (может) производиться ограничение доступа.
8. Сценарий (синопсис) проведения тестирования, который включает последовательность выполнения и названия отдельных тестовых заданий, а также ожидаемый результат выполнения этих тестовых заданий. При наличии времени на проектирование в этот раздел могут включаться описание тестовых заданий (по шагам) и краткое описание тестовых данных. Именно в этом разделе должны находить отражение пользовательские истории (собранные и запротоколированные во время проведения информационных обследований), начальные условия выполнения программы, условия (ограничений) успешного завершения, альтернативные варианты завершения процесса. Сценарий проведения тестирования в обязательном порядке должен быть узнаваем со стороны заказчика.

Лучше один раз увидеть

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

Виллард Британ

1. Прототипирование пользовательских интерфейсов позволяет более точно определить сроки реализации функционала. Согласно статистике, точность экспертной оценки сроков программного проекта, выполненной на основе утвержденных макетов UI, в несколько раз выше, чем точность оценки на основе концептуальных требований технического задания.
   
   
   
   Источник: Стив Макконел. Сколько стоит программный проект. ISBN: 978-5-91180-090-1
2. Грамотный UX-дизайн позволяет обеспечить формирование проектной и эксплуатационной документации еще до завершения кодирования. Сразу после согласования проектного решения, параллельно с разработкой, становится возможным формировать руководство пользователя (замена макетов интерфейса на скриншоты осуществляется во время выполнения задач тестирования).
3. Фиксация макетов пользовательского интерфейса облегчает нахождение решения спорных вопросов при определении новизны требований. Если на согласованном макете UI не было поля, значит, его добавление это новое требование, выходящее за рамки согласованного проектного решения (следующий пример раскроет последствия добавления всего лишь одного поля на форму).
4. Иногда, форма внезапно может оказать существенное влияние на содержание. Описанный далее случай произошел на четвертой неделе активного UX-проектирования и регулярного обсуждения с заказчиком макетов пользовательского интерфейса одной из подсистем АСУ. Заказчик охотно шел на общение, были уже предварительно согласованы схемы основных процессов и более 80% экранных форм. Мало того, чтобы ускорить разработку была уже создана база данных и по отдельным задачам в полную силу работали программисты. На одном из рабочих совещаний вдруг заместитель начальника управления (для которого собственно и создавалась подсистема) спросил: А где у вас тут поле даты?. Как выяснилось, он имел в виду, что программа должна иметь возможность отразить состояние дел (или сформировать отчет) на любую произвольную дату, и это при том, что ведение истории изменений ранее не обсуждалось. Все представители заказчика подразумевали, что это было совершенно очевидно и не требовало дополнительных пояснений. В результате небольшое замечание увеличило время разработки подсистемы почти в два раза. Надо отметить, что макеты форм практически не изменились, просто на некоторых добавилось поле По состоянию на дату Х.

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

1. Все элементы управления формой должны располагаться в верхней части в форме панели инструментов при этом вероятность того, что пользователь потеряет их, сводится практически к нулю. При этом практика показала целесообразность отказа от строки иерархического меню в пользу ленточного интерфейса (ribbon).
2. Для всех списков, как правило, на ленте должны присутствовать четыре группы элементов управления:
3. При формировании статистических отчетов (в т.ч. и для вывода на печать) желательно не создавать специализированные формы для предварительной настройки этих отчетов. Сама списковая форма с ее возможностями выборки, сортировки и отображения объектов должна обеспечивать предварительную настройку требуемых отчетов. Другими словами по возможности отчеты должны формироваться на основе выбранных критериев при формировании списков.

В рамках описания карточки объекта при проектировании должны быть определены:

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

1. В случае, если в ходе разработки требуются изменения уже существующих интерфейсов, не стоит изобретать велосипед. Здесь лучше всего себя проявил Paint.NET (с помощью которого, кстати, подготовлены картинки к этой статье). Не имеет смысла заново перерисовывать формы, проще изменить готовый скриншот.
2. Если вы разрабатываете новый интерфейс пользователя, а ваш заказчик бумажная крыса, в таких случаях лучше всего себя зарекомендовал MS Visio со стандартным набором элементов управления. Не раз видел, как заказчик, который наотрез отказывался посмотреть разработанный интерактивный прототип, увлеченно обсуждал предлагаемые проектные решения, выполненные с использованием MS Visio, и рисовал очень интересные каракули на макетах, распечатанных на бумаге в цвете, выполненных в стиле привычного ему Windows.
3. Если вы разрабатываете новую подсистему, а ваш заказчик - продвинутый пользователь, то интерактивные прототипы вне конкуренции. При этом с наилучшей стороны показал себя подход, когда эти прототипы строятся на основании того же самого фреймворка, который используется для создания интерфейса пользователя. В случае одного из моих успешных проектов прототип программного обеспечения строился на основе инструментов DHTMLX. Вместо базы данных для имитации работоспособности использовались статичные XML-файлы, сформированные на основе примеров таблиц, которые предоставил заказчик. Представления (view), созданные аналитиками в ходе прототипирования, использовались как заготовки для работы программистов. За счет низкого порога вхождения по использованию данного фреймворка, трудозатраты аналитиков на создание прототипов пользовательского интерфейса были соизмеримы с трудозатратами, если бы те же макеты экранных форм создавались в MS Visio. Правда, при этом некоторые представители заказчика не понимали, что еще надо программировать после того, как им продемонстрировали рабочую программу.

Строительные леса и опалубка

Обычно люди очень много думают. Но беда в том, что они думают о проблемах, а не о решениях этих проблем.

Дэвид Аллен

• Анализ документов отчет по результатам анализа нормативных документов заказчика или проектной документации.
• Аналитический обзор отчет по результатам анализа путей решения возникшей проблемы (как правило, сравнительный анализ новых технологий или тенденций рынка).
• Информационное обследование отчет по результатам проведенного исследования существующих бизнес-процессов заказчика (формирование модели as is как есть).
• Системный анализ материалы, описывающие в терминах разработчиков способ реализации требований заказчика одного из вариантов использования программного обеспечения (use case). Этот же тип аналитической работы организуется в случае необходимости реинжиниринга legacy-кода.
• Анализ данных отчет по результатам исследования качества данных, загруженных в систему (выявление ошибок и противоречий).
• Учебные материалы материалы, подготовленные для проведения обучения сотрудников заказчика или членов проектной группы.

План для маэстро

Всё должно быть изложено так просто, как только возможно, но не проще.

Альберт Эйнштейн

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

Продолжение следует

Реорганизация таск-треккера

• Service to Portfolio (Demand and Selection) стадия раскурки, поиска, выбора сервиса, технологии.
• Request to Deploy (Plan and Design) обсуждение, планирование разработки, развития услуг, сервисов.
• Request to Deploy (Develop) разработка услуги, сервиса чего либо.
• Request to Deploy (Deploy) развертывание чего либо.
• Request to Deploy (Test) тестирование сервиса, услуги.
• Request to Fulfill этап эксплуатации разработанных сервисов, предоставление услуг.
• Detect to Correct (Correct) исправление, доработка внутренних сервисов и услуг.
• Detect to Correct (Monitor&Feedback) тоже самое, только + общение с клиентом.
  

Аналитика данных в R

# Открыто тасокthis_week_opened <- jira_changelog_data %>%         filter(issue_type != "Epic") %>%         filter(as.Date(issue_created) >= start_date) %>%         filter(as.Date(issue_created) <= end_date) %>%   select(key, issue_created) %>% unique() %>% nrow()# В работеthis_week_processed <- jira_worklog_data %>% filter(as.Date(started) >= start_date) %>%         filter(as.Date(started) <= end_date) %>%   select(key) %>% unique() %>% nrow()# Закрытоthis_week_closed <- jira_changelog_data %>%         filter(issue_type != "Epic") %>%         filter(as.Date(issue_resolutiondate) >= start_date) %>%         filter(as.Date(issue_resolutiondate) <= end_date) %>%  select(key, issue_created) %>% unique() %>% nrow()# Отправлено в холд / бэклог this_week_holded <- issue_history %>% filter(change_date >= start_date) %>%         filter(change_date <= end_date) %>%filter(toString == "Hold" | toString == "Backlog") %>%   select(key) %>% unique() %>% nrow()

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

В базовую поставку R включен основной набор пакетов, а всего по состоянию на 2019 год доступно более 15 316 пакетов.

Генерация отчета

Заключение

Поля

Ключевые слова

Функции

assignee was currentUser()AND fixVersion was inunreleasedVersions()AND created > startOfYear()

Функции ScriptRunner

issueFunction in epicsOf("worklogDate >= startOfWeek(-1) AND worklogDate <= endOfWeek(-1)")AND project in ("Видео.B2G")

issueFunction in epicsOf("worklogDate >= startOfYear()")AND issueFunction not in hasLinkType(Contract)AND project in ("Видео.B2G")

Все изменения в требованиях к новой фиче на одной странице

Подробнее...

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


На странице документа с новой функциональностью:
Добавляем макрос Multiexcerpt include. В нём указываем, какой блок из какой страницы нужно вставлять:


Готовая страница фичи в режиме редактирования выглядит примерно так:

Подробнее...

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



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

Трассировка требований

Подробнее...

На примере функционального модуля Карточка Персоны:

• Находим все функциональные модули, на которые может повлиять изменения требований к карточке Персоны
• Добавляем в них соответствующий тег (в нашем случае это #person)
• Добавляем макрос Результаты поиска на странице требований к карточке Персоны

В режиме редактирования это выглядит так:



А читатель видит так:

Версионирование требований по релизам

Комментирование

• Можно видеть комментарии и отвечать на них в режиме редактирования документа. Это очень удобно, когда надо вносить правки в требования по результатам ревью
• Нет проблем с параллельным комментированием (особенно если вы планируете переход с MS Word + Sharepoint: не нужно блокировать документ целиком), требования может рецензировать одновременно вся проектная команда
• Если комментарий оставляют на странице с фичей в блоке с Multi Excerpt, он автоматически появляется в исходном документе требований

• Нельзя использовать в связке с плагином Multi Excerpt
• Не видно комментариев в режиме редактирования документа
• Пропадают комментарии, если изменить текст, к которому они были привязаны

Создание диаграмм и мокапов

Базовые возможности

• Сравнение версий документов. Можно быстро понять, как менялась функциональность от релиза к релизу.
• Параллельное редактирование одного документа и автоматическое разрешение конфликтов. Ревью документа могут делать одновременно несколько человек и при этом не нужно ждать своей очереди, пока документ заблокирован на редактирование другим сотрудником (как было, когда мы использовали Sharepoint и требования хранились в виде Word-файлов).
• Шаблоны документов. Мы создали шаблоны по всем основным типам документов (функциональный модуль, фича, протокол совещания)
• Гибкие возможности разграничения доступа (вплоть до уровня страницы). Это удобно, например, для аутсорсных сотрудников, которым нельзя предоставлять доступ сразу ко всем требованиям
• Экспорт документов в различные форматы. Очень выручает в тех редких случаях, когда возникает необходимость передачи документов наружу.
• Интеграция с JIRA. Можно автоматически вставлять статус задач, сроки согласований и прочей информации из тикетов JIRA.

Переход с MS Word

Нумерация заголовков

Гиперссылка на раздел

Подробнее...

Добавляем макрос Anchor и указываем его имя (Вставить -> Другие макросы -> Anchor):



Так он выглядит в документе в режиме редактирования:



Затем вставляем ссылку на этот якорь в документе (Вставить -> Ссылка -> Дополнительно):

• Для создания ссылки на другой документ перед названием якоря указываем название документа, на который нужно сослаться, затем символ # и после него название якоря.
• Для создания ссылки на текущий документ перед названием якоря просто указываем символ #.

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

Цвет фона текста

<span style="background-color: rgb(202,225,255);">текст</span>

• Копирование и вставка из буфера обмена размеченного таким образом текста как правило ведет к потере разметки.
• Изменить разметку можно только в режиме редактирования исходного кода страницы.

1. Подготовка резервной копии(бэкапа).
2. Подготовка сервера. Установка программного обеспечения. Настройка.
3. Развертывание бэкапа из облака на сервере.

sudo chmod +x soft_install_c7.sh

sudo bash soft_install_c7.sh

sudo firewall-cmd --zone=public add-port=порт/tcp permanent

sudo firewall-cmd --zone=public --remove-port=порт/tcp --permanent

sudo firewall-cmd list-all или sudo iptables -L -n -v line-numbers

sudo firewall-cmd --reload

sudo service postgresql-11 restart 

Оптимизация удалённой работы

Наши открытия

Карта сотрудничества

Между регионами

Между дизайнерами и их коллегами

В рамках дизайнерского процесса

Перенос офлайн-процессов в онлайн

Сотрудничество между людьми разных профессий в Atlassian

Асинхронность в первую очередь в Dropbox

Концепция Apache NiFi кратко.

• Достать из жиры ворклог и историю изменений за неделю.
• Вывести базовую статистику за этот период и дать ответ на вопрос: чем же занималась команда?
• Отправить отчет боссу и коллегам.

Первые шаги. Забор данных из API

{"startAt": ${startAt}, "maxResults": ${maxResults}, "jql": "updated >= '2020/11/02'", "fields":["summary", "project", "issuetype", "timespent", "priority", "created", "resolutiondate",  "status", "customfield_10100", "aggregatetimespent", "timeoriginalestimate", "description", "assignee", "parent", "components"]}

Галопом по Европам. Выгрузка ворклога и др.

Заключительный этап. Генерация отчета и отправка по Email

Послесловие

Полезные ссылки

Историческое отступление

Старт проекта

Технологический стэк

По верхам ITIL стандарта

• Управление инцидентами (Incident management). Целью этого процесса является управление жизненным циклом всех инцидентов. Процесс направлен на быстрое решение запросов пользователя, которые непредвиденно начали мешать его работе.
• Управление проблемами (Problem management). Этот процесс помогает ИТ департаменту предотвратить инциденты и минимизировать влияние инцидентов, которые невозможно предотвратить или предвидеть.
• Запросы пользователей (Request fulfillment). Основной процесс службы поддержки выполнение запросов на обслуживание. Как правило, это помощь в решении базовых вопросов или незначительные изменения, например, рабочего места пользователя.
• Управление изменениями (Change management). Процесс контролирует все изменения, которые могут выполняться одновременно несколькими департаментами банка. Это могут быть доработки программного обеспечения, изменения инфраструктуры, внедрение новых инструментов.
• Управление конфигурациями (Configuration management). Этот процесс направлен на управление ИТ инфраструктурой и все что с ней связано. Хранение в едином месте информации по серверам, приложениями, доступам, лицензиями, рабочим местам и использование этих данных во всех остальных процессах помогает четко прослеживать изменения или инциденты. Мы использовали дополнительный плагин Insight Asset management, который красной нитью проходит через все продукты и позволяет работать с конфигурационными единицами на всех линиях поддержки.
• Управление знаниями (Knowledge management). Отвечает за управление информацией о системе в целом. Предоставляемые услуги для пользователей, имеющаяся инфраструктура, типовые инструкции для пользователей. Все это должно хранится в одном месте и быть доступно для клиентов службы поддержки. В этом кейсе мы использовали Confluence, как продукт для работы с базой знаний и местом для технической документации ИТ департамента.

Результат

1. Проведена ревизия бизнес-процессов для работы с запросами пользователя и внутри банка;
2. Получены прозрачные SLA, которые можно отслеживать и использовать для улучшения департаментов;
3. Разделены зоны ответственности на явные линии поддержки и снижена нагрузка на департамент в целом. Вместо того, чтобы обрабатывать каждую заявку по прямой цепочке нулевая-первая-вторая-третья линии, теперь часть заявок автоматически распределяется на нужные линии;
4. Ускорилось время реакции и время решения задач.