Спасибо за видео, успел частично посмотреть. Инструкции дорого стоят, особенно, когда пишет разработчик. Есть другой кейс: При анализе задачи можно указать (в Jira) описание разработки (как работало по старому, как по новому, какие особенности). Такую техническую часть удобно на планерках "защищать", а потом поддерживать сопровождению. Параллельно указывается суть логики функционала, откуда пользователь может получить полезную для себя информацию.
Александр, привет! Спасибо за комментарий. Я как-нибудь расскажу на конскружке про описание (постановку) задач (не task) в виде канвасов, с целеполаганием и прочими атрибутами хорошего производственного цикла. Можно все таки уточнить, почему с вашей точки зрения инструкции дорого стоят? и почему дороже если их делает разработчик?
@@plastinin идеальная инструкция - это описание как должно работать. А что не работает по инструкции - баг (или фича). Писать должны ключевые пользователи, которые отвечают за конкретный бизнес-процесс компании - они же авторы задач (внутренние заказчики). У нас в компании по каждому документу есть черновик-инструкция, на основе которого делают ТЗ, выделяя желтым что менять. В процессе анализа, разработки или тестирования выявляются доп.требования. Актуализировать инструкцию под требования новой ТЗ и доп.требования - двойная, тройная работа. Если еще писать будет разработчик (он же исполнитель) - начнет дергать методологов, аналитиков - тоже двойная, тройная работа.
@@plastinin будет интересно посмотреть про постановку задач. Особенно, как большие задачи нарезаются на более мелкие по разработчикам. И как попадаете по срокам (часам) на задачу. А сонаркуб используете? Есть видео на эту тему? Писать правильный код ради написания правильного кода ИЛИ уменьшать риски появления багов с помощью сонара =)
Спасибо за отличное видео по Ванессе
Привет, Алексей, спасибо за фидбек
Спасибо за видео, успел частично посмотреть.
Инструкции дорого стоят, особенно, когда пишет разработчик. Есть другой кейс:
При анализе задачи можно указать (в Jira) описание разработки (как работало по старому, как по новому, какие особенности).
Такую техническую часть удобно на планерках "защищать", а потом поддерживать сопровождению.
Параллельно указывается суть логики функционала, откуда пользователь может получить полезную для себя информацию.
Александр, привет! Спасибо за комментарий. Я как-нибудь расскажу на конскружке про описание (постановку) задач (не task) в виде канвасов, с целеполаганием и прочими атрибутами хорошего производственного цикла. Можно все таки уточнить, почему с вашей точки зрения инструкции дорого стоят? и почему дороже если их делает разработчик?
@@plastinin идеальная инструкция - это описание как должно работать. А что не работает по инструкции - баг (или фича). Писать должны ключевые пользователи, которые отвечают за конкретный бизнес-процесс компании - они же авторы задач (внутренние заказчики).
У нас в компании по каждому документу есть черновик-инструкция, на основе которого делают ТЗ, выделяя желтым что менять. В процессе анализа, разработки или тестирования выявляются доп.требования.
Актуализировать инструкцию под требования новой ТЗ и доп.требования - двойная, тройная работа.
Если еще писать будет разработчик (он же исполнитель) - начнет дергать методологов, аналитиков - тоже двойная, тройная работа.
@@plastinin будет интересно посмотреть про постановку задач. Особенно, как большие задачи нарезаются на более мелкие по разработчикам. И как попадаете по срокам (часам) на задачу. А сонаркуб используете? Есть видео на эту тему? Писать правильный код ради написания правильного кода ИЛИ уменьшать риски появления багов с помощью сонара =)
Колонки таблицы проще удалять через редактор таблицы Геркин
Сложно воспринимается диктор. По возможности, перед публикацией почистите видео от кашля. Портит впечатление от подачи.
Благодарю за обратную связь, мотаем, мотаем на ус.