L
но видимо пока не до конца разобрался с тем, какие там есть возможности по генерации чего-то целого с меню итп
Size: a a a
2019 March 19
IN
а есть какие-то готовые наборы тем? просто я ни разу не фронтенд разработчик. Максимум, чего я касался, так это базовые html теги
IN
спасибо, посмотрю
L
а есть какие-то готовые наборы тем? просто я ни разу не фронтенд разработчик. Максимум, чего я касался, так это базовые html теги
выше ссылка, там примеры доков публичных на разных темах, можно гнаписать свою, мы используем sphinx_bootstrap
2019 March 20
KB
Всем добрый день. Мне интересно ваше мнение в разрезе темы документации проекта. Кто и как видит процесс? Является ли userstory с версионипованием, руководства администратора и руководства пользовател достаточной документацией.
NV
Всем добрый день. Мне интересно ваше мнение в разрезе темы документации проекта. Кто и как видит процесс? Является ли userstory с версионипованием, руководства администратора и руководства пользовател достаточной документацией.
Зависит от задачи )
KB
На мой взгляд если у вас есть проблема в виде отсутствия описания системы, нужно формировать рабочую группу для восполнения не достающие знаний в лице аналитика и разработчика. И в процесс встраивать обязательный пункт по обновлению документаций и историй.
KB
Ещё стоит не забывать работать лично с командой, так как просто дав задачу лиду, можно столкнуться с ситуации, что команда будет соботировать нововведение. Тут уже возникнет вопрос, вести ли переговоры с "терроримтами". И оценка рисков при смене членов команды.
KB
Зависит от задачи )
Это безусловно) к примеру предположим что у нас заказная разработка, и мы набрали agile команду, которая приняла решение работать двух недельными спринтами.
L
Это безусловно) к примеру предположим что у нас заказная разработка, и мы набрали agile команду, которая приняла решение работать двух недельными спринтами.
если заказная, а не продуктовая, то сеттинг версионированное руководство юзера и админа кажется не подходящий, думаю, к выпуску должен прилагаться какой-то квик старт с юз кейсами, если доработки, то релиз ноуты
L
На мой взгляд если у вас есть проблема в виде отсутствия описания системы, нужно формировать рабочую группу для восполнения не достающие знаний в лице аналитика и разработчика. И в процесс встраивать обязательный пункт по обновлению документаций и историй.
Да, это выглядит как правильный подход, но сначала стоит обсудить с командой, как и где им удобнее было бы следить за обновлением - доки рядом с кодом, докстринги, что-то еще, у нас обновление описаний проверяется на ревью, вроде пока это работает неплохо
2019 March 22
AG
Всем привет. Ребят есть не большой проект, для него надо написать документацию. И все это дело надо как-то грамматно прописать в договоре. Есть ли какие то стандарт или что-то подобное. Как все это правильно оформить?
AG
Бросьте плиз ссылочку где почитать что посмотреть
OY
Alex Gaj
Всем привет. Ребят есть не большой проект, для него надо написать документацию. И все это дело надо как-то грамматно прописать в договоре. Есть ли какие то стандарт или что-то подобное. Как все это правильно оформить?
здравый смысл, не?
L
Alex Gaj
Всем привет. Ребят есть не большой проект, для него надо написать документацию. И все это дело надо как-то грамматно прописать в договоре. Есть ли какие то стандарт или что-то подобное. Как все это правильно оформить?
Ну да, common sense, описать, какие артефакты должны быть на выходе (руководство такое-то и такое-то, быстрый старт, справочник по API) и какая в нем должна быть структура на основе требований
AG
Да, это все понятно. Но может кто сталкивался с подобным и где-то есть инфа как это прописать более формально))
KS
Alex Gaj
Да, это все понятно. Но может кто сталкивался с подобным и где-то есть инфа как это прописать более формально))
А вы что хотите в договоре то прописать?)Как работает ваш функционал, который вы передаёте третьему лицу?
AG
Нет, договор для разработчика. И в нем должно быть прописано какая должна быть документация и в каком виде.
KS
Alex Gaj
Нет, договор для разработчика. И в нем должно быть прописано какая должна быть документация и в каком виде.
Тогда так и пишите, что разработчик, по завершении работ, обязан предоставить техническое описание методов АПИ, методов класса и т.д . Описание должно быть выполнено в виде файла README.md и должно находиться в корне проекта и выложено в репозиторий, где находится проект
KS
Как то так