СФ
«Документационный эджайл»
Size: a a a
2019 June 24
ЕД
Он менее эффективен в краткосрочной перспективе. После первого же сэкономленного часа на то, чтобы разобраться в своей же поделке через пару месяцев / через полгода он эффективен, благодарен и мотивирован
ЕД
Проверено многократно
ЕД
Особенно, когда CTO просит через пару месяцев пояснить в деталях, как работает решение каждой команды и дать описание архитектуры
ЕД
После этого тимлиды тех команд, кто не послушал бабушку вовремя, выстраиваются в очередь со словами "Научи нас, пожалуйста"
IL
«Документационный эджайл»
Один из основополагающих принципов agile - "хорошо работающая фича в документации не нуждается", однако, если очень хочется, то процесс написания документации может быть жёстко привязан к инкрементам. Например, спринт не считается успешным, если дока к фиче не написана.
IL
Простите, вру, "Работающий продукт важнее исчерпывающей документации». Это не совсем то)))
A
Простите, вру, "Работающий продукт важнее исчерпывающей документации». Это не совсем то)))
Вот именно так манифест гласит))
S
Один из основополагающих принципов agile - "хорошо работающая фича в документации не нуждается", однако, если очень хочется, то процесс написания документации может быть жёстко привязан к инкрементам. Например, спринт не считается успешным, если дока к фиче не написана.
Если цель разработать продукт, а не сделать его возможным для эффектиного использования и возможности поддерживать его развитие.
Аджайл - это маркетинг, что бы дать возможность консультантам зарабатывать деньги на его внедрении
Аджайл - это маркетинг, что бы дать возможность консультантам зарабатывать деньги на его внедрении
NV
Простите, вру, "Работающий продукт важнее исчерпывающей документации». Это не совсем то)))
Это совсем не то. ))
Д
Простите, вру, "Работающий продукт важнее исчерпывающей документации». Это не совсем то)))
Простите, я думала, этот пункт про документацию требований, а не конечную документацию пользователя. Разве нет?
A
Простите, я думала, этот пункт про документацию требований, а не конечную документацию пользователя. Разве нет?
Это про конечную
NV
Таки очень сомневаюсь.
IL
Это про конечную
Не конкретно про конечную, все-таки. Речь о том, что затраченное время на спецификации, документацию для пользователй, тз и прочее, прочее, не всегда на пользу продукту, если есть цель быстро выпуститься и, например, проверить гипотезу
NV
Не конкретно про конечную, все-таки. Речь о том, что затраченное время на спецификации, документацию для пользователй, тз и прочее, прочее, не всегда на пользу продукту, если есть цель быстро выпуститься и, например, проверить гипотезу
Всё что угодно может быть не на пользу продукту.
NV
Вон у нас в Plesk есть отличная история про то, как можно за год разработки сделать целый новый интерфейс, который будет не на пользу продукту.
NV
Это было где-то в начале 2010х.
NV
ИСЧЕРПЫВАЮЩАЯ документация слишком дорога и недостижима. Она живёт в той же стране фантазий, где и код без багов, 100% покрытия тестами и 100% аптайма.
A
Не конкретно про конечную, все-таки. Речь о том, что затраченное время на спецификации, документацию для пользователй, тз и прочее, прочее, не всегда на пользу продукту, если есть цель быстро выпуститься и, например, проверить гипотезу
Over comprehensive documentation.
То есть проверить гипотезу можно с минимальным набором документации по архитектуре решения и требованиям. Конечной докой зонами можно вообще пренебречь
То есть проверить гипотезу можно с минимальным набором документации по архитектуре решения и требованиям. Конечной докой зонами можно вообще пренебречь
A
Здесь*