Вино скейлится до водочки

мы у себя практически такое внедрили.

Техпис имеет доступ до списка задач в спринте и начинает их документировать до того, как за них возьмется разработчик

у нас есть "практика"  смены парадигмы во время разработки (т.е. они реально могут передумать) .. поэтому в документацию идет задача, которая всеми проверена, одобрена и есть в "ночной сборке"

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

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

> у нас хороший процесс разработки, ибо релиз фризится за 2 недели до даты релиза обычно

ну вот от такого много кто отказывается =)

Есть масса причин не называть такое хорошим процессом.

с таким подходом проблема: техписа начинают ждать для релиза

как-то со временем они все равно оставляют месяц на тестирование. и в принципе, опозданий техписов еще не было )

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

У нас еженедельные демо, причем показывают не только UI, но и говорят бэкендеры, девопсы, qa. А так конечно таски, эпики, чаты, пощелкать продукт. Ну и выпученные глаза тоже случаются :)

Вот дааа)))

любопытно, какие, например, причины могут быть, чтобы назвать такой процесс неудачным?

На скрам плохо ложится?

в каком плане? вот не могу ни одной причины придумать, почему это плохо 😅
хотя я не спец по аджайлу-скраму, у нас разработка по 2 недельным спринтам, и все укладываются обычно

Не, я сам не знаю, думал, может кто знает и мне расскажет

@maxlapshin ?

Современная тенденция - сокращать цикл деплоя до упора.

Хочется поменять функциональность - взяли, поменяли.

Если от кодирования до выкатки минимум 2 недели,  то программистов тяжело вовлечь такой процесс и отслеживание реакции клиентов на такое.

Плюс вот этот двухнедельный запрет на мерж фич зачастую является проявлением того, что просто ссыкотно мержить код за день до релиза.

А стремно почему? Потому что нет доверия своему процессу валидации качества софта.

Так двунедельные спринты несовместимы с двухнедельным тестированием :)

Мы вот не откладываем :)

У нас релиз всегда каждую секунду готов и мастер постоянно пригоден к релизу.

Для этого и документация должна быть в такой же готовности

Ну тем более тогда нет проблемы

> документация _должна_

но не всегда получается