В разработке софта аббревиатура «CR» теперь имеет два значения:
- недавно в некоторых местах стала использоваться для обозначения «Code Review»;
- изначально же «CR» — это именно «Change Request».
Причём занятно, что «CR» означает «code review» в том случае, если в компании не оперируют такими вещами как «change request» в процессах. И почти всегда это компании так и не осилившие погрузиться в #
Agile. Потому и не оперируют сущностью в том виде и тем образом, в каком оно существует в Agile Methodology, а придумывают какую-то свою абстракцию.
Для примера, о какой сложности идёт речь —
https://www.gregerwikstrand.com/agile-change-requests/Т.е. сложно представить компанию, действительно работающую по Agile и при этом чурающуюся использовать «change request».
Сперва «change request» был напрямую про деньги, т. к. многие заказчики — натуральные жмоты. Извечно пытающиеся кроить бюджет до такого состояния, при котором вероятность маломальски успешного завершения проекта начинает сводиться к вероятности встретить динозавры у входа в метро. Такому заказчику многое безразлично, т. к. для него любой проект выглядит как для той девушки из анекдота, мол 50% на 50% — либо встречу, либо нет — либо получится, либо нет. Управление рисками, страхование рисков, горизонты планирование оказываются слишком сложными вещами для очень многих заказчиков.
И вот, ради своего выживания команды разработки и стали полагаться на дополнительное финансирование, изначально подписываясь под проектами с чрезвычайно скудными бюджетами. Прекрасно осознавая, что любой заказчик рано или поздно хочет часть требований на проекте изменить или пересмотреть. Если уж не большую часть, то уж какую-то часть поменять точно захочет, такова реальность. Именно в этот момент заказчику и приходится серьёзно раскошелиться или же пустить по ветру аванс и/или время, которые потрачены на уже выполненные работ над проектом.
Таким образом «change request» и стал означать что кому-то предстоит нести финансовые расходы. А какой же именно из двух сторон, заказчику или подрядчику/интегратору/разработчику — это стало зависеть от умения вести переговоры. Например, удастся ли «что-то не то» в софте признать багой разработчиков или же неоднозначностью в описании требований (уже согласованных и утверждённых ранее заказчиком).
Например, большинство авторов библиотек и компонентов имеющим платный вариант (модель Freemium) никогда не принимают баг-репортов от пользователей бесплатных версий/редакций. Поскольку в подавляющем большинстве случаев это является завуалированным «change request» на изменение функциональности (в соответствии с видениями/представлениями/чаяниями конкретного пользователя). А оформляя его в виде баг-репорта люди пытаются избежать необходимости оплачивать работу над «change request».
Это уже ощутимо позднее масса компаний стала играть в Agile-разработку и стало немного сложнее — появилось аж два разных типа/вида «запросов на изменения» :) И для многих это оказалось непреодолимой сложностью в выстраивании процессов и взаимодействия с внешними или внутренним заказчиком.
#
softwaredevelopment #
software #
softwaredev #
agile #
lang_ru
