Size: a a a

DocOps-сообщество

2018 August 15

NV

Nick Volynkin in DocOps-сообщество
И работу по актуализации тоже можно оценить
источник

D

Daria in DocOps-сообщество
Nick Volynkin
Понимание сложно формализовать и измерить
+
источник

ИЦ

Игорь Цупко in DocOps-сообщество
Спасибо!
источник

NV

Nick Volynkin in DocOps-сообщество
А вот «держать в голове» не знаю, как измерить
источник

D

Daria in DocOps-сообщество
Nick Volynkin
А вот «держать в голове» не знаю, как измерить
Что вообще значит «держать в голове»?
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
Товарищи, подскажите, кто как трассировку требований реализует?

Историей в wiki-движках вроде Confluence — сплошная боль, не понимаю как нормально изменения стейджить, да потом плоский список не могу разобрать

Выкручиваюсь .md и git'ом, вижу ветки + сообщения коммитов нормально объясняют, чем обусловлена пачка изменений; тем не менее, кажется каким-то костылём на изоленте

У кого есть хороший опыт с трассировкой без привлечения убойных инструментов, вроде IBM'овских?
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
А, ещё git annotate позволяет прям по строчкам разобрать, что откуда взялось

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

NV

Nick Volynkin in DocOps-сообщество
Vadim Smelyanskiy
А, ещё git annotate позволяет прям по строчкам разобрать, что откуда взялось

Очень хочу чего-то такого, но в более юзер-френдли пакете, чтоб коллегам можно было внедрить без боли
git blame?
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
источник

ИЦ

Игорь Цупко in DocOps-сообщество
гит блейм не очень решает вопрос трассировки
источник

ИЦ

Игорь Цупко in DocOps-сообщество
это сложный орг. вопрос, как мне кажется
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
Это да, но организационно хотя бы понятно как подступиться

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

Я пока только гитом решил так, чтобы не биться головой об стол, но не может же это быть лучшим решением?
источник

ИЦ

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

VS

Vadim Smelyanskiy in DocOps-сообщество
Из опыта: в сообщении к коммиту можно записать, кто по матрице решений это принёс/одобрил, на каком созвоне/встрече и т.д.

Потом выкапывать протоколы собраний дело 5 минут
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
В протоколе главное общую задачу собрания пометить и на месте вести обсуждение, что будет задето
источник

VS

Vadim Smelyanskiy in DocOps-сообщество
Как минимум один раз ловил конфликт, когда две встречи тянули требования в разные стороны по цели и появлялись дыры; заодно объяснять на пальцах проще, почему это не работает)
источник

NV

Nick Volynkin in DocOps-сообщество
Мы как-то обсуждали эту тему в чате у Дмитрия Симонова.

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

SV

Ser V in DocOps-сообщество
Nick Volynkin
А вот «держать в голове» не знаю, как измерить
это как над проектом работает 15 разрабов, 8 аналитиков, 1 пм а ты должен держать все в голове, причем сразу и в полном объеме за весь проект :)
источник

SV

Ser V in DocOps-сообщество
Max Nikulin
мы bookstack используем
крутая штука, ставится в 1 клик буквально, надо будет поковырять на досуге ее
источник

ИЦ

Игорь Цупко in DocOps-сообщество
ещё бы хранила в гите, а не вот так - цены бы не было. и в ветки умела бы.
источник