|
Как по-умному вести документацию?
|
|||
---|---|---|---|
#18+
MyNiGooЯ считаю, что вести актуальное описание системы в монолитном документе необходимо . Версионирование такого документа - признак хорошего тона, но является делом вкуса. Всё верно, только не в монолитном документе, а в одном документе на один модуль. pmleправильнее - вести требования в базе, а документ генерировать при необходимости иначе замучаетесь на управлении изменениями . А вот для этого и нужны аналитики :) Весь смысл в том, что для каждого программного модуля - в идеале - есть единый набор документации: от спецификации требований до дизайн-спецификации. И каждый из этих документов подлежит обновлению при каждом изменении версии соответствующего компонента. Да, это дополнительные временные расходы, но это способствует культуре разработки. Отмечу, что чем проект сложнее организационно (распределённые команды, быстро растущий штат, интеграции со сторонними системами и т.д.), тем важнее следовать этой культуре разработки. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2012, 11:52 |
|
Как по-умному вести документацию?
|
|||
---|---|---|---|
#18+
InkelyadТак вики тоже страдает той проблемой, что в первой цитате озвучена. Ее же тоже в актуальном состоянии поддерживать надо. И текущее состояние вики - это и есть тот самый "монолит" под VC. Совершенно не обязательно. На пальцах, в Вики вполне могут лежать странички "старый модуль складского учёта", "проект нового модуля складского учёта" и "новый модуль складского учёта"; работать с ней при этом будет вполне удобно, но вот "монолитом" оно не будет ни в малейшей степени. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2012, 11:56 |
|
Как по-умному вести документацию?
|
|||
---|---|---|---|
#18+
DPH3Разных стратегий сочетания Jira и Confluence (эээ, т.е. issue-tracker и wiki-system, но линейка от Atlassian уже давно практически корпоративный стандарт) можно придумать дофига и они сильно зависят от процессов в конкретной компании. +1 До кучи: можно интегрировать Jira с VC. В том виде, в каком я это видел, было очень удобно: находишься в таске и с неё смотришь список всех коммитов по ней в SVN. Только при коммитах нужно не забывать указывать ID таски, но к этому можно быстро привыкнуть. ... |
|||
:
Нравится:
Не нравится:
|
|||
22.11.2012, 11:59 |
|
Как по-умному вести документацию?
|
|||
---|---|---|---|
#18+
InkelyadИ текущее состояние вики - это и есть тот самый "монолит" под VC. Только не в виде исходников документации + система контроля версий, а в виде базы данных + вики-движок. wiki мне тоже кажется вполне приемлемым решением. Главное, что я хочу отметить - история коммитов и/или база тасков (e.g. Jira) не может служить единственным или основным источником информации о функциональных требованиях к системе. Если о какой-то фиче создан таск в jira, будет большим заблуждением считать, что данное изменение задокументировано. Пара итераций, и про него уже никто не вспомнит, а поиск выдаст ещё 100500 записей на ту же тему. ... |
|||
:
Нравится:
Не нравится:
|
|||
23.11.2012, 12:45 |
|
Как по-умному вести документацию?
|
|||
---|---|---|---|
#18+
Задался сабжем топика. 1) Документация кода в стиле javadoc - обязательна. + периодически на код травить тулзы вроде doxygen 2) Документация бизнес логики в стиле: выделил сущность: остатки, выделил процессы, которые влияют на сущность: пополнение, списание. Нарисовал диаграмму влияния. И т.д. 3) Проектное управление Jira: Иерархия: 1п. Проект(ИТ) 1к. Клиент 1п.1 Склад 1к.1 Запрос на изменение от клиента (связь с конкретным ТЗ 1п.2) 1п.2 ТЗ (ссылка на всю исходную и сопутствующую документацию : вики, конфлуенс, что-угодно ссылка на диаграмму бизнес взаимодействия, другими словами, на что влияет данное ТЗ автоматически ревизии из репозитория) Разбить на подзадачи с тех заданием для каждого отдела: 1п.3 Интеграция ТЗ 1п.4 GUI ТЗ 1п.4 Логика ТЗ Вики: Разбить на категории: Категория: Проект Подкатегория: Склад Подкатегория: Сущности(или как так) Подкатегория: Остатки Где хранить диаграмму бизнес взаимодействия. ... |
|||
:
Нравится:
Не нравится:
|
|||
05.12.2012, 16:00 |
|
Как по-умному вести документацию?
|
|||
---|---|---|---|
#18+
ОзверинЗадался сабжем топика. 1) Документация кода в стиле javadoc - обязательна. + периодически на код травить тулзы вроде doxygen 2) Документация бизнес логики в стиле: выделил сущность: остатки, выделил процессы, которые влияют на сущность: пополнение, списание. Нарисовал диаграмму влияния. И т.д. 3) Проектное управление Jira: Иерархия: 1п. Проект(ИТ) 1к. Клиент 1п.1 Склад 1к.1 Запрос на изменение от клиента (связь с конкретным ТЗ 1п.2) 1п.2 ТЗ (ссылка на всю исходную и сопутствующую документацию : вики, конфлуенс, что-угодно ссылка на диаграмму бизнес взаимодействия, другими словами, на что влияет данное ТЗ автоматически ревизии из репозитория) Разбить на подзадачи с тех заданием для каждого отдела: 1п.3 Интеграция ТЗ 1п.4 GUI ТЗ 1п.4 Логика ТЗ Вики: Разбить на категории: Категория: Проект Подкатегория: Склад Подкатегория: Сущности(или как так) Подкатегория: Остатки Где хранить диаграмму бизнес взаимодействия. Озверин, сколько стоит такая технология? ... |
|||
:
Нравится:
Не нравится:
|
|||
08.12.2012, 21:32 |
|
|
start [/forum/topic.php?fid=33&msg=38066471&tid=1547758]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
28ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
others: | 284ms |
total: | 405ms |
0 / 0 |