В рейтинге участвует:

групп:

каналов:

Виртуальный сервер на SSD - недорого!

Аренда выделенных и виртуальных серверов (VDS/VPS), хостинг, аренда IP-адресов, администрирование, круглосуточная поддержка

qwarta.ru подробнее

Резервное копирование с проверкой на вирусы!!!

Удобный сервис создания резервных копий на любой сервер сети интернет. Отслеживайте изменения, проверяйте на вирусы. Надежно защитите свой бизнес!

go.backupland.com

Выбираете сервер? Любая конфигурация на заказ!

Аренда физических серверов любых конфигураций под любые запросы - 1С бухгалтерия, игровые сервера, нагруженные проекты, интернет-магазины!

qwarta.ru подробнее

Size: a a a

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

544 membersпожаловаться на группу
2019 January 25

A

Antonio in DocOps-сообщество
Мы не выкатываем доки, пока не убедимся, что описаны основные моменты ее работы и настройки. Потому, как если целевая аудитория не до конца понимает, как пользоваться фичей, то это недоработка писателя. После релиза доки, мы обычно дописываем только какие-то corner cases, но, функциональность фичи всегда должна быть подробно описана
источник
19:22пожаловаться#1
2019 January 26

ML

Maksim Lapshin in DocOps-сообщество
Я сейчас начал пытаться потихоньку внедрять doc first подход, когда прежде чем взяться за кодирование, программист с техписом пишут будущую документацию на сайт
источник
19:26пожаловаться#2

ML

Maksim Lapshin in DocOps-сообщество
это отличается от ТЗ, потому что ТЗ нужен для того, что бы формализовать _что прогать_, а дока описывает, как поменяется жизнь юзера после этой фичи
источник
19:27пожаловаться#3

ML

Maksim Lapshin in DocOps-сообщество
внезапно это помогает не делать фигни
источник
19:27пожаловаться#4

SB

Sergey Bronnikov in DocOps-сообщество
Maksim Lapshin
внезапно это помогает не делать фигни
А много времени на такое занятие уходит у разработчиков? И не проще ли помимо ТЗ писать стори/сценарии использования и убеждаться разработчик с ними ознакомился?
источник
19:41пожаловаться#5

ML

Maksim Lapshin in DocOps-сообщество
Sergey Bronnikov
А много времени на такое занятие уходит у разработчиков? И не проще ли помимо ТЗ писать стори/сценарии использования и убеждаться разработчик с ними ознакомился?
мы ТЗ вообще не пишем, у нас нет такой практики
источник
19:43пожаловаться#6

ML

Maksim Lapshin in DocOps-сообщество
времени уходит не очень много, но если много, то значит что задача сложная и всё равно такое надо делать. Т.е. если программист не знает, как потом пользоваться фичей, то как он её вообще может сделать =)
источник
19:44пожаловаться#7

ML

Maksim Lapshin in DocOps-сообщество
Понятно, что это касается тех, кто делает документируемые фичи. Дата сатанисты, которые пилят нейросетки от этого отстоят на два шага, но им нужно другое понимать: как это в принципе будет работать, так что их тоже беспокоит финальная документация
источник
19:45пожаловаться#8

SB

Sergey Bronnikov in DocOps-сообщество
А в какой форме происходит общение между заказчиками или сейлзам? Какая то постановка задачи для разработки должна же быть.
источник
19:46пожаловаться#9

SB

Sergey Bronnikov in DocOps-сообщество
Maksim Lapshin
времени уходит не очень много, но если много, то значит что задача сложная и всё равно такое надо делать. Т.е. если программист не знает, как потом пользоваться фичей, то как он её вообще может сделать =)
Согласен. Но на практике так делают и потом им фичу обратно  возвращают, потому что сделали не то что надо было.
источник
19:47пожаловаться#10

ML

Maksim Lapshin in DocOps-сообщество
Мы сами делаем свой продукт и стараемся не заниматься какой-либо существенной доработкой под кастомеров. Поддержка — да, но только в виде того кода, который потом много кому ещё пригодится
источник
19:48пожаловаться#11

NV

Nick Volynkin in DocOps-сообщество
Maksim Lapshin
Я сейчас начал пытаться потихоньку внедрять doc first подход, когда прежде чем взяться за кодирование, программист с техписом пишут будущую документацию на сайт
Звучит как отличная тема на knowledgeconf.ru! Результаты уже есть или подождем до 2020? :)
источник
20:12пожаловаться#12

НН

Нац Нац in DocOps-сообщество
Sergey Bronnikov
А много времени на такое занятие уходит у разработчиков? И не проще ли помимо ТЗ писать стори/сценарии использования и убеждаться разработчик с ними ознакомился?
О у меня был где-то перевод про document driven development, если надо
источник
20:30пожаловаться#13

НН

Нац Нац in DocOps-сообщество
Сорри, что так редко выходит какой-то ориджынал контент, совсем нет времени, но вот вам (довольно небрежный, если уж совсем на чистоту, но суть ясна) мой перевод статьи Тома Престона-Вернера, со-основателя GitHub, о важности написания README в самом начале разработки (чего-либо).

https://telegra.ph/Readme-Driven-Development-09-25
Telegraph
Readme Driven Development
Нац Нац
источник
20:30пожаловаться#14

EN

Ekaterina Noskova in DocOps-сообщество
Нац Нац
О у меня был где-то перевод про document driven development, если надо
А поделитесь
источник
20:39пожаловаться#15

НН

Нац Нац in DocOps-сообщество
Ekaterina Noskova
А поделитесь
Выше
источник
20:46пожаловаться#16

EN

Ekaterina Noskova in DocOps-сообщество
Нац Нац
Выше
Так это про readme driven development, а не про documentation driven development. Это же не одно и то же?
источник
20:54пожаловаться#17

ML

Maksim Lapshin in DocOps-сообщество
Nick Volynkin
Звучит как отличная тема на knowledgeconf.ru! Результаты уже есть или подождем до 2020? :)
Немного есть результаты
источник
20:59пожаловаться#18

EN

Ekaterina Noskova in DocOps-сообщество
https://medium.com/blacklane-engineering/documentation-driven-development-8b2ff119104f
Medium
Documentation driven development
Blacklane Engineering in Blacklane EngineeringJan 13, 2017 · 6 min read
источник
21:15пожаловаться#19

НН

Нац Нац in DocOps-сообщество
Ekaterina Noskova
Так это про readme driven development, а не про documentation driven development. Это же не одно и то же?
Я попутал, но суть, казалось, та же
источник
21:21пожаловаться#20