Русский
Русский
English
Статистика
Реклама

Confluence

Практики работы с требованиями

24.03.2021 12:04:07 | Автор: admin
image

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

Последние 3 года я работаю системным аналитиком в группе компаний InfoWatch и в этой статье я хочу поделиться с вами практиками работы с требованиями, которые мы используем. Компания занимается разработкой Enterprise-продуктов для снижения рисков информационной безопасности, защиты и анализа корпоративных данных. К таким продуктам выдвигаются высокие требования, касающиеся их надёжности, производительности, отказоустойчивости, а так же требования для сертификации. В силу особенностей рынка информационной безопасности наши решения не являются облачными, а устанавливаются on-site у клиента. Поэтому мы работаем в режиме выпуска больших релизов несколько раз в год. Чтобы прийти к назначенной цели и сократить сроки релиза, мы работаем по принципам, заложенным в методологии Agile. Для старта разработки мы не готовим абсолютно детальные системные требования, а начинаем с высокоуровневого описания самых важных аспектов новой функциональности. То есть, принимаем решения, которые больше всего влияют на объем и сложность доработок и дают команде разработки необходимую информацию для старта работ по проектированию архитектуры и написанию кода (для небольших фич). Затем, по ходу разработки, постепенно детализируем требования и доводим их до уровня детализации, достаточного для написания подробных тест-кейсов. Такой подход позволяет не тратить много времени на старт работ и снизить риски того, что требования придется значительно перерабатывать, если выявятся какие-то новые технические ограничения.

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

Требования к разрабатываемому продукту основная зона ответственности системного аналитика. Практики, описанные ниже, направлены на упрощение работы с требованиями и, как следствие, на упрощение процесса разработки продукта:

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

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


image

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

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

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

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

Оповещение об изменениях в требованиях


image

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

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

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

  • реализация может не соответствовать требованиям;
  • ожидаемый результат тестирования может не соответствовать требованиям и реализации;
  • документация может не соответствовать реализации.

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

Скриншот 1
image

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

Скриншот 2
image

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

Ревью новых требований


image

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

Для этого мы так же доработали issue-tracker, добавили отдельный тип задачи Ревью, которая запускается ответственным аналитиком по каждой фиче на всех руководителей команд. Руководители самостоятельно или, делегируя своим подчиненным, делают вычитку требований, задают вопросы или вносят уточнения через комментарии и согласовывают внесенные изменения.

Скриншот 3
image

Митинги/собрания/статусы


image

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

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

Обсуждение/решение открытых вопросов


image

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

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

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

Протоколирование обсуждений


image

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

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

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

Валидация нового функционала


image

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

Презентация нового функционала


image

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

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

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

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

Автор: Венера Аббясова AbbyasovaVenera

* Все картинки для статьи взяты из открытого доступа в сети Интернет.
Подробнее..

Как мы используем Confluence для разработки требований к продукту

17.02.2021 14:23:34 | Автор: admin


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

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


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



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

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



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



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

Технически это реализовано с помощью плагина Multi Excerpt, который позволяет вставлять части одного документа в разные документы.

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


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


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


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



Делается это с помощью стандартных макросов Отчёт о свойствах страницы и Свойства страницы.

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



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



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


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

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



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

Для этого мы используем стандартную функциональность меток в Confluence и макрос Результаты поиска.

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



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



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



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


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



Так выглядит в жизни переключение между версиями релизов:



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


Для работы с комментариями мы используем плагин Talk.



Его плюсы:

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

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

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

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

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


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

Как оказалось, в Confluence есть множество плагинов для работы с разного рода графическими объектами (диаграммы, схемы, мокапы и пр). Balsamiq Wireframes for Confluence и Draw.io Diagrams for Confluence позволяют редактировать графические объекты, не выходя из Confluence. На данный момент эти плагины почти полностью покрывают наши потребности.
image

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


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

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

Переход с MS Word


Есть несколько неочевидных вещей, с которыми почти сразу сталкиваешься после перехода с Word на Confluence.

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


Чтобы добавить автоматическую нумерацию заголовков, нужно обрамить текст макросом Numbering headings.



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


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

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



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



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

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



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

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


Сделать нестандартное визуальное оформление текста, в частности выделить фон текста
заливкой, можно с помощью Markdown-разметки (Вставить -> Разметка, Markdown).



Используйте этот код
Для заливки мы используем такой код:
<span style="background-color: rgb(202,225,255);">текст</span>

Подставьте RGB-код нужного вам цвета.

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

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

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

На этом всё. Задавайте вопросы в комментариях!

P.S. Статья основана на базе доклада Лайфхаки Confluence для разработки требований на конференции Analyst Days, видео версию этого доклада можно посмотреть по этой ссылке.

Автор статьи: Ильшат Габдуллин g1r
Подробнее..

Навыки команды Как я настраивал матрицу компетенций

27.11.2020 12:11:35 | Автор: admin

Почему в Confluence?


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


Первое, что пришло на ум, это сделать таблицу, где в строчках сотрудники, а в колонках навыки/продукты. Встал вопрос, где вести такую таблицу?
  • Excel сложно организовать совместное редактирование
  • Google Docs не рекомендован к использованию в компании.

Подсказку сделать в Confluence я нашел в докладе Алексея Трошина (ФИНАМ) Знания и компетенции в команде: найти, увидеть, прокачать. Кому больше нравится читать держите конспект доклада от Светланы Новиковой.

Шаг 1. Обычная таблица


В начале я сделал обычную таблицу, где в строчках навыки, в колонках сотрудники. На тот момент в команде было 10 человек и с полсотни навыков, сгруппированных по тринадцати темам.
Начальный список навыков мы c командой придумали во время ретро. Таблица выглядела относительно компактно. И все с удовольствием пошли заполнять. Заполнять необходимо было количеством звездочек. Тут же возник вопрос? А сколько звездочек ставить? Нужны критерии.
Мы для себя выбрали такие (одна пять звезд):
  1. Давно изучал и давно не применял на практике
  2. Прослушал курс/изучал самостоятельно, практики было мало
  3. Практик, регулярно применяю на практике
  4. Эксперт, знаю тонкости, готов делится лайфхаками с коллегами
  5. Гуру, готов выступать на внешних конференциях




После этого все довольно оперативно смогли заполнить информацию по себе.


Итоги после первого шага:


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

Шаг 2. Сводная таблица


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

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


Для примера на картинке выше две группы навыков: Computer languages и Management.

Далее добавил метку (Label) на страницу Шаблон профиля специалиста. Например, skills.


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

Теперь магия сводная таблица по свойствам страниц.


Добавил макрос Вертикальное меню, внутри него макрос Элемент вертикального меню, внутри него макрос Отчет по свойствам страницы.

У элемента вертикального списка задал название. Оно может быть любым и может не совпадать с названием свойства страницы.
А вот с макросом Отчет по свойствам страницы немного сложнее.
Во-первых, надо указать метку ту, что навесили на Шаблон профиля специалиста. Например, skills. Это позволило мне отобрать только нужные страницы.
Во-вторых, стоит ограничить список пространств, в которых будут искаться страницы. Например, текущим.
В-третьих, важно указать Свойство страницы, ведь, как мы помним [из предыдущего], в шаблоне сотрудника у нас много свойств, каждое из которых соответствует одной группе навыков. В данном случае computer language.
Наконец, лучше задать название первой колонке в сводной таблице. Я назвал её Сотрудник


Повторил для следующей группы навыков. Добавил Элемент вертикального меню и внутри него Отчет по свойствам страницы.
Теперь давайте посмотрим, что у меня получилось?


Итоги после второго шага:


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

Шаг 3. Продвинутый шаблон


Предупреждение: Для этого улучшения потребуются права администратора пространства.

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


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


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


Второе tooltip. Этот макрос позволил мне сделать всплывающее описание к навыку и будет полезен для просмотра информации на сводной таблице.


В итоге мой шаблон выглядит вот так:

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

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


В результате появляется кнопка<img

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


Я использую эту возможность для формирования отдельных сводных отчетов по мини-командам. Как вы помните, когда я пришел, нас было десять, на первой итерации изменений уже 15, сейчас нас более двадцати, и мы приняли решение делиться на четыре мини-команды.
В нашем случае это команды:
  • DEV внутренняя автоматизация
  • CI/CD развитие и эксплуатация таких продуктов как Artifactory, Gitlab, Jenkins и т.д.
  • k8s развитие kubernetes
  • TESTZONE автоматизация пересоздания тестовых зон

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

Итоги после третьего шага:


Время: На разработку и тестирование нового шаблона у меня ушло две недели. Основное время на уточнение формулировок критериев для каждого навыка.
Выхлоп: Оценка уровня навыка стала более точной. Есть возможность сравнивать с целевым специалистом и планировать обучение.

ЗАКЛЮЧЕНИЕ


Вот какие задачи решает матрица компетенций у нас:
  • Во-первых, bus factor. Очень не хочется оказаться в ситуации, когда о том, как работает продукт, знает только один человек, и он уходит. Это полезно и для планирования, и для согласования отпусков.
  • В-вторых, нужно планировать платное обучение. Заранее принять и согласовать решение о том, кого, когда и на какие курсы отправить.
  • Во-третьих, самообучение. Есть как внутренние курсы, так и множество открытых ресурсов. Главное определить, какой навык нужно прокачивать и создать на это задачу.
  • И, наконец, мы нашли еще одно применение профиля целевого сотрудника: с его помощью мы решаем вопрос подбора персонала. Можем четко объяснить HR, кого мы ищем.

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

Мистер X или стоит ли небольшой команде рассмотреть XWiki как возможную замену Confluence?

07.02.2021 02:13:24 | Автор: admin

Если я всё правильно понимаю, в феврале 2021 года Atlasian прекратил продажу серверной версии Confluence.

On February 2, 2021 Pacific Time (PT), the following changes will go into effect:

- End of new server license sales:You can no longer purchase or request a quote for a new server product.

- Updates to server prices:We will implementnew prices for server renewals and upgrades.

Получается, что отныне для серверной версии нельзя получить новые лицензии, в том числе пробные. И вроде бы ничего страшного, есть бесплатные облачные версии для команд размером до 10 человек. Также можно получить лицензию на версию Data Center. Но что делать, если оба эти варианта не приемлемы?

Требования

Поскольку в моём случае, требования к пространству для документации были не очень высокие, а команда не превышала 25 человек, было принято решение посмотреть в сторону бесплатных альтернатив. После изучения примерно 20 Wiki систем (и не только) наиболее интересной заменой для Confluence мне показалась Xwiki.

В этой статье я кратко рассмотрю способность XWiki заменить для нас базовый функционал Confluence.

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

В нашем случае по факту нужен был весьма скромный набор требований:

  • бесплатность (или низкая стоимость);

  • возможность установки на свой сервер;

  • русификация;

  • удобное редактирование контента (WYSIWYG или Mardown);

  • шаблоны страниц;

  • повторное использования контента;

  • настройки внешнего вида;

  • история версий;

  • аннотации или комментарии к тексту;

  • управление доступом к страницам для пользователей и групп;

  • возможность со временем установить расширения если понадобится.

По факту данный набор требований могут удовлетворить разные решения для документирования. Но судя по порталу Xwiki, она позиционируется именно, как opensource альтернатива Confluence. Поэтому выбор пал именно на неё. Кстати почетное второе место в списке заняла BlueSpice MediaWiki, но мне показалось, что там в бесплатной версии количество доступных расширений меньше.

Установка

На текущий момент для загрузки доступны две версии Xwiki:

  • Stable - включает более новый функционал, но менее стабильна. Цикл обновления примерно раз в месяц.

  • LTS - по сути прошлогодняя версия, для которой регулярно выпускаются важные исправления и багфиксы.

Для каждой из версий доступны разные способы установки: WAR Package, Docker, или установка из репозитория (Debian / Ubuntu). Xwiki можно установить и в Windows, но я пробовал только установку в Linux Mint. Главное при установке тщательно следовать инструкциям (установка из репозитория / Docker).

При установке с помощью образа Docker рекомендую установить DemoFlavor, чтобы быстро познакомится с наиболее распространенными приемами использования Xwiki, все ненужные расширения, потом можно будет спокойно удалить.

Удовлетворение потребностей

Пробежимся по вышеуказанному списку требований:

Бесплатность и возможность установки на свой сервер

Xwiki - opensource проект. Установка на свой сервер доступна абсолютно бесплатно. Есть коммерческая версия в облаке, но это для нас. Также есть платные плагины, например улучшенный форум, но острой потребности в них пока нет.

Русификация и редактор

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

У Xwiki есть свой стандарт разметки, чем-то напоминающий MediaWiki, при желании можно подключить Markdown, можно писать в чистом HTML, но в принципе TinyMCEв качестве визуального редактора весьма удобен.

Шаблоны страниц, повторное использования контента

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

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

Настройки внешнего вида

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

История версий, аннотации или комментарии к тексту

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

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

Управление доступом и установка расширений

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

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

Есть встроенный инструмент для создания собственных мини-приложений на базе Xwiki.

В принципе никто не запрещает самостоятельно разработать расширение, но для этого нужно знать Java.

Больше чем ожидали

Есть еще множество занятного функционала который нам пока не нужен:

  • интеграция с OpenOffice (LibreOffice);

  • форум и инструмент для учета идей;

  • календари, собрания, учет задач;

  • блоги и голосования;

  • создание нескольких Wiki (видимо аналог пространств в Confluence)

Думаю со временем, что-то из этого может оказаться востребованным.

Заключение

Xwiki не смотря на некоторую медлительность, за счет своего функционала и его потенциальной расширяемости показалась, мне в долгосрочной перспективе более удобным решением чем GitLab Wiki, DocuWiki, DjangoWiki и другие вики движки, а также другие решения имеющие функционал для документирования (например, Onlyoffice или Youtrack).

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

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

Эта публикация получилась достаточно поверхностной, но последняя статья на Хабре по запросу Xwiki была почти 5 лет назад, поэтому я решил что все же стоит "сверить часы" и опубликовать свой взгляд на актуальную версию.

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

Подробнее..

Все на панель! или несколько полезных приемов настройки панелей Xwiki

11.04.2021 14:15:43 | Автор: admin

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

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

В первой статье мы погорим о простых вещах, которые не отнимут у нас много времени, а именно:

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

Весь материал статьи я проверял в версиях Xwiki 12.10.5 и 13.2 с установленной Demo Flavor. Также в статье подразумевается, что вы обладаете правами администратора.

Оглавление страницы в боковой панели

В админ-панели переходим в раздел Настройки интерфейса -> Мастер панелей и внизу страницы находим ссылку "Перейти к панелям". Ну или просто введите в адресную строку
{ваш домен с Xwiki}/bin/view/Panels/
В разделе "Создать новую панель"
Введите название панели (например, SideTOC}
и нажмите кнопку "Создать"
Тип панели оставьте - "View"
Описание - на ваше усмотрение.
В поле Содержимое введите код:

{{velocity}}{{context document="$services.model.serialize($doc.documentReference)" transformationContext="document"}}#set ($hasHeaders = [])#set ($mydoc = $doc.getDocument())#foreach ($block in $mydoc.getXDOM().getBlocks('class:HeaderBlock', 'DESCENDANT')) #set ($discard = $hasHeaders.add($block))#end#if($hasHeaders.size()>0) #panelheader('Table of Contents') {{box cssClass="sidetoc"}}{{toc/}}{{/box}}#end{{/context}}{{/velocity}}

Поясню для тех, кто только начал знакомство с данной Вики.

В Xwiki для автоматизации используется различные средства автоматизации и одно из них Appache Velocity. В данном случае весь код между тегами {{velocity}} {{/velocity}} будет обрабатываться как код на данном языке шаблонов.

В макросе {{context}} мы указываем контекст для которого будет выполнятся наш код.
В нашем случае это контекст основного содержимого страницы. Таким образом, наш скрипт будет думать, что он не внутри сквозной боковой панели, а внутри блока с текстом статьи. Это необходимо для того, чтобы получить заголовки из которых формируется оглавление.
блок
#if($hasHeaders.size()>0)
#panelheader('Table of Contents')
#panelheader('Table of Contents') {{box cssClass="sidetoc"}}{{toc/}}{{/box}}
#end

Выводит нам заголовок для панели и сами ссылки на разделы статьи, только в том случае если на странице есть заголовки из которых можно собрать оглавление.
Макрос {{toc/}} - непосредственно создает оглавление. Мы обрамим его в макрос
{{box cssClass="sidetoc"}}, чтобы иметь возможность удобной стилизации блока. Но об этом немного позже.

Теперь необходимо вставить нашу панель в верстку страницы.
Я решил разместить блок слева.
Чтобы сделать также в админ-панели перейдите на страницу Мастер панелей -> вкладка "Список панелей" и просто перетащите панель с названием SideTOC на панель слева (справа).
Если перетаскивание не сработает, вы можете добавить панель в ручную
На вкладке "Макет страницы" в поле "ПАНЕЛИ СЛЕВА" (или справа) добавив "Panels.SideTOC".
например, Panels.Applications,Panels.Navigation,Panels.SideTOC

Не забудьте нажать кнопку "Сохранить".
Выглядеть будет примерно так:

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

Но прежде убедимся, что у нас включен расширенный режим редактора.
Перейдите на страницу вашего профиля. Нажмите кнопку "Редактировать"
В разделе "Настройки" найдите пункт "Тип пользователя" и выберите значение : "Продвинутый" (Advanced). Теперь нам точно будет доступен редакторов объектов.

Откройте страницу созданной ранее панели, вы можете найти её на странице списка панелей или просто перейдя по адресу {домен}/bin/view/Panels/SideTOC.
Теперь у кнопки "Редактировать" доступен список с дополнительными вариантами.
Выберите пункт "Объекты".

В поле "Новый объект" выберите StyleSheetExtension и нажмите кнопку "Добавить"

Xwiki очень функциональна и позволяет поменять css стили практически для любого элемента. В данном случае мы поменяем стиль класса siidetoc, который был указан в макросе {box}.
Введите любое название например sidetoc, а затем CSS код:

.sidetoc {  border:0px;  margin:0px;  padding:0px;  width:100%;}.sidetoc ul {  padding-left:2px;  list-style-type:disc;  font-size:1em;  padding:0px;  margin-left:0px;}.sidetoc li {  padding-left: 0px;  margin-left:5px;  list-style-type:disc;}

В поле "Использовать это расширение" обязательно выберите "В этой вики" ,

Не забудьте сохранить страницу.
Проверяем нашу главную.
Теперь панель выглядит немного по другому:

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

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

Cвоя панель навигации справа / слева

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

Сейчас информация о нашей любимой пицце отображается в разделе "Навигация".

Мы хотим убрать эти страницы из раздела "Навигация" и перенести в свою собственную панель.
Для начала уберем ссылки на пиццу из стандартной панели навигации.
В админ-панели откройте раздел "Настройки интерфейса" - > "Панель навигации".
Перетащите раздел "Моя любимая пицца" в раздел "Исключенные страницы".

Теперь перейдите в соседний раздел "Меню" и нажмите кнопку "Добавить новую запись".
Введите название панели, например, PizzaMenu.
Удаляем заглушку. Если у вас WYSIWIG редактор нажмите кнопку "Источник" и вставьте следующий код:

{{documentTree root="document:xwiki:Моя любимая пицца.WebHome" compact="true"/}}

Ну или вы можете просто вставить макрос "Дерево страниц" и добиться также настроек.

В поле "root" первая половина значения - document:xwiki: - это особенность структуры адресов Xwiki, Вы со временем разберетесь в тонкостях, а вот вторую часть: "Моя любимая пицца.WebHome", можно легко узнать перейдя на страницу "Моя любимая пицца.WebHome" и открыв внизу вкладку "Информация".

В поле "МЕСТО ОТОБРАЖЕНИЯ МЕНЮ" выберите - "Внутри левой панели".
В поле "ОБЛАСТЬ ВИДИМОСТИ МЕНЮ" выберите - "Current Wiki".
Не забудьте сохранить.

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

Перейдите на страницу Админ-панель -> Мастер панелей.
И добавить в левую панель строку: Menu.PizzaMenu.WebHome

Например, вот так:

Сохраняем и наслаждаемся меню (откройте главную страницу чтобы проверить).

Осталось немного навести марафет.

Давайте заменим заголовок панели.
Перейдите на страницу меню. Через админ-панель или просто по адресу:{домен}/bin/view/Menu/PizzaMenu/

Аналогично прошлому разделу откройте редактор объектов.
Разверните "UIExtensionClass" и в тег {{menu}} добавьте: id="PizzaMenu".
Замените значение в "#panelheader("PizzaMenu"), на то что вам больше по душе. Например так:

Если хотите можете аналогично примеру с оглавлением подредактировать CSS стиль блока (именно для этого мы и добавили id="PizzaMenu").
Создайте объект для настройки стилей и введите:

#PizzaMenu ul.jstree-children{  padding-left:0px !important;}

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

Добавляем свои советы в панель подсказок

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

Для этого надо в любом месте создать страницу.
Я создам пустую страницу Tips в разделе Xwiki чтобы она не "мозолила" глаза.

Откройте редактор объектов и добавьте объект расширения интерфейса.

В поле "Extension Point ID" вставьте: "org.xwiki.platform.help.tipsPanel".
В поле "Extension ID" введите любое название, например, "grammarHelp".
В поле "Extension Scope" выберите "Current Wiki".
В поле "Extension Parameters" введите:

tip = Чтобы воспользоваться исправлением опечатки нажмите Ctrl+ПКМ

Аналогичным образом создайте на странице еще одно расширение. См. скриншот.

Остается только сохранить изменения и дождаться появления советов.

Если честно я хотел добавить еще примеров, но статья итак получилась объемной.
Впереди у нас интеграция с Figma, GitLab, Swagger и кастомные DocumentThree!
Постараюсь не затягивать со следующим материалом.

Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru