JIRA: границы проекта

[alan008]

Это в свою очередь создает все предпосылки для роста эффективности проектных групп на основе применения механизмов BPM

Ёшкин кот, сколько же водищи. Тут не часть 1 надо писать, а TL;DR.

[aimfirst]

Если для Вас тут слишком много «водищи», вероятно у вас есть несколько вопросов на которые вы надеялись получить ответ? Или у вас успешно и давно применяется BPM?
Welcome, добавьте «мяса»)

[evgenis]

Приветствую! @aimfirst, уточните, пожалуйста, как в описанном вами процессе проходят стадии анализа (описание аналитиками что надо сделать) и кодревью?

[aimfirst]

Все стадии подробно описаны в статье https://habr.com/ru/company/lanit/blog/486754/ . Стадии анализа подробно детализированы в статье https://habr.com/ru/company/lanit/blog/515452/
Кодревью формируется как подзадача к задаче типа разработка и выполняется после того как аналитик примет доработанный функционал (перед заливкой ветки разработки в develop - https://habr.com/ru/company/lanit/blog/515452/ ). Если нужны дополнительные уточнения - пишите - попробую ответить.

[evgenis]

Т.е. проверкой реализованного у вас заняты аналитики, а не тестировщики? Почему так? И почему код-ревью идёт после проверки реализации? Не потребуется ли проводить повторное тестирование если код не пройдёт код-ревью?

[aimfirst]

Именно так - первичную проверку реализованного нового функционала осуществляет аналитик, который отвечает за реализацию требования. Тестировщики отвечают за реализацию регрессионного тестирования (проверку ранее реализованного и принятого функционала). Код-ревью идет после проверки реализации, поскольку, как правило, новый функционал всегда допиливается после проверки аналитиком (не только потому, что ошибки, а и потому, что могут быть незначительно уточнены требования). Повторное тестирование проводится всегда - при выпуске версии для заказчика (тут могут быть привлечены и тестировщики).