Таск трекеры и система для хранения документации

[Yekaterina]

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

[EVGL]

Цитата:

Сообщение от Yekaterina

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

Azure DevOps и ничего более: масса преимуществ и не известны недостатки.

[Yekaterina]

Цитата:

Сообщение от EVGL

Azure DevOps и ничего более: масса преимуществ и не известны недостатки.

Меня как то смущает, что это Майкрософт, и документация на Sharepoint - не самая удобная вещь. И мне не нужен контроль версий системы, мне нужен контроль задач с момента поступления проблемы от пользователя/бизнеса до ее решения и внедрения на prod. И пользовательская документация/проектная документация. Вот версии документации вести было бы интересно, но не кода.

[EVGL]

Цитата:

Сообщение от Yekaterina

Меня как то смущает, что это Майкрософт, и документация на Sharepoint - не самая удобная вещь. И мне не нужен контроль версий системы, мне нужен контроль задач с момента поступления проблемы от пользователя/бизнеса до ее решения и внедрения на prod. И пользовательская документация/проектная документация. Вот версии документации вести было бы интересно, но не кода.

С огромным трудом понимаю логику. Если сама система - от Microsoft (что можно предлоложить по тематике форума), и это не смущает, то почему вас смущает Microsoft для хранения документации по ней? Документация на Sharepoint для DevOps не нужна, можно просто загружать файлы. Однако для работы всех с одной копией документа как раз подходит может быть не самая удобная Sharepoint (я все свои спецификации так храню и оставляю Hyperlink в DevOps).

[Yekaterina]

Цитата:

Сообщение от EVGL

С огромным трудом понимаю логику. Если сама система - от Microsoft (что можно предлоложить по тематике форума), и это не смущает, то почему вас смущает Microsoft для хранения документации по ней? Документация на Sharepoint для DevOps не нужна, можно просто загружать файлы. Однако для работы всех с одной копией документа как раз подходит может быть не самая удобная Sharepoint (я все свои спецификации так храню и оставляю Hyperlink в DevOps).

Как может не смущать Аксапта? Просто это работа Но зачем добровольно себе лишний геморрой устраивать?

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

[EVGL]

Цитата:

Сообщение от Yekaterina

Sharepoint это же просто интерфейс к папочкам обычным, там ничего нет.

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

[sukhanchik]

DevOps ранее был известен, как VSTS (Visual Studio Team Server), а еще ранее - как TFS (Team Foundation Server).
Собственно, шикарная вещь для баг/таск трекера. Есть еще правда компании, которые используют JIRA для этого. Тоже вариант, но особенно для D365 DevOps гораздо удобнее. Очень приятно видеть в задаче, в рамках каких changeset-ов она была выполнена (это делается автоматически, когда разработчик указывает номер задачи при CheckIn своего changeset-а).
Непосредственно сами Word-файлы можно как приаттачивать туда, так и хранить их на Sharepoint-портале, а в DevOps хранить только ссылки на них, как правильно сказал EVGL.

[Yekaterina]

Цитата:

Сообщение от sukhanchik

DevOps ранее был известен, как VSTS (Visual Studio Team Server), а еще ранее - как TFS (Team Foundation Server).
Собственно, шикарная вещь для баг/таск трекера. Есть еще правда компании, которые используют JIRA для этого. Тоже вариант, но особенно для D365 DevOps гораздо удобнее. Очень приятно видеть в задаче, в рамках каких changeset-ов она была выполнена (это делается автоматически, когда разработчик указывает номер задачи при CheckIn своего changeset-а).
Непосредственно сами Word-файлы можно как приаттачивать туда, так и хранить их на Sharepoint-портале, а в DevOps хранить только ссылки на них, как правильно сказал EVGL.

у нас 2012я.
что такое changeset?

[sukhanchik]

Цитата:

Сообщение от Yekaterina

у нас 2012я.
что такое changeset?

Применительно к D365 - это набор объектов, которые разработчик закончил править и отдает в систему контроля версий. Просто в 2012 все несколько не так - не хранится абсолютно весь код в системе в текстовых файлах; с отчетами в студии не все так просто в плане контроля версий. В общем - не совсем еще бесшовно все красиво работает. Но это не мешает использовать TFS / VSTS / DevOps в качестве такс-трекера, а Sharepoint в качестве хранилища документов с возможностью многопользовательского доступа и версионности самих документов

[trud]

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

[EVGL]

Цитата:

Сообщение от trud

JIRA вне конкуренции из того что пробовал. Удобное редактирование, редактор правил и переходов статусов.
Azure DevOps использовал на нескольких проектах, показалась неудобной.

У меня строго обратное впечатление: Jira медленнее, неудобнее, интерфейс перегружен.

The beauty is in the eye of the beholder.

[trud]

Цитата:

Сообщение от EVGL

Jira медленнее, неудобнее, интерфейс перегружен.

А что там неудобного? ну т.е. JIRA это единственная система которую я видел, где обсуждение по задаче шло в трекере(ну еще GitHub не на АХ проектах). Во всех остальных проектах - это какой-то несвязанный чат или почта. Плюс редактор переходов статусов. Он кстати вообще есть в Azure DevOps? что я видел - при смене статуса - просто выпадающий список со всеми статусами и ручное назначение ответственного
Хотя особо я не разбирался, допускаю что можно как-то все настроить

[EVGL]

Мы все задачи обсуждаем в DevOps. Статусы и переходы настраивать можно.
https://docs.microsoft.com/en-us/azu...w=azure-devops

[Raven Melancholic]

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

[Yekaterina]

JIRA - ерунда, конечно, для проектов внедрения. Можно использовать, но концов не найдешь потом. Ну или долго и нудно настраивать.. Задачи не решает.

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

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

[belugin]

Цитата:

Сообщение от Yekaterina

MS Teams - не видела там задач, может не помню уже.

Насколько я знаю, там нет задач, они есть в MS Planner , который интегрируется с тимс.

Впрочем, Azure Dev Ops тоже интегрируется с тимс.

[pitersky]

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

Цитата:

Сообщение от Yekaterina

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

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

[belugin]

Цитата:

Сообщение от pitersky

в любом случае рано или поздно сведётся к дебаггингу.

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

Конечно, без кода зачастую не обойтись, связка commit -> pr -> workitem в Azure Dev Ops очень сильно помогает при использовании функции annotate (aka blame - когда для каждой строчки выводится последний изменивший ее комит).

Внутренняя документация часто ведется инкрементно - на изменение а не на текущее состояние. Это затрудняет ответ на вопрос "почему сейчас так" - в таких случаях проще через код (blame -> переход на коммит и изменением -> переход на привязанный workitem).

[Yekaterina]

Цитата:

Сообщение от belugin

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

.

Да, и если лежат в одном месте ТЗ и юзер мануалы. Еще практиковала такую вещь - рассылать пользователям письма what's new in AX с подробным описанием новых функций. Вот контекстный поиск по этим имейлам - самое полезное было)) Но у нас не было хорошего хранилища документации, так как у нас была Jira, то есть к вложениям доступа хорошего не было.

[vmoskalenko]

Однозначно DevOps (VSTS/TFS).
Все находится в одном месте. И документы и задачи и код и билд сервера и релизы и код деплоймент. Прозрачность и прослеживаемость во всем.

Меня часто пытаются совратить на Jira, но все тоже самое можно сделать в DevOps.