Некий Unit of Work - как определить его границы и размер?
Релиз - эпик - история - задача - в чем разница между ними с точки зрения управления процессом?
- Кажется, что UnitOfWork должен определяться исходя из целей управления и принципов работы команды разработки, и не должен быть сильно привязан к объему и формату бизнес-требований. Если цель управления - это повышение эффективности работы системы в целом, то получается, что цель транзитивна по отношению к цели системы в целом. Значит, нужно смотреть на внешние проектные роли, т.е. на роли “заказчиков системы”. Я считаю, что к ним, наряду с бизнесом (хочет получить прибыль, оказывая услуги) и клиентами (хотят решать свои проблемы с помощью услуги) в полной мере относятся все участники команды разработки (хотят интересно и комфортно работать). Получается, что ценность можно доставлять для любой из этих групп, и это будет считаться частичным достижением целей системы.
- Еще кажется, что размер каждой единицы работы должен быть минимальным, насколько это возможно. Тем не менее, снизу он должен быть чем-то ограничен, т.к. изменение одного символа в коде явно не тянет на единицу работы. То есть, скорее всего, можно сформулировать какие-то критерии достаточности.
Пример
Бизнес-требование (новая функциональность): на главной странице веб-приложения должна появиться новая кнопка, доступная для 2 из 10 категорий клиентов. Нажатие на эту кнопку должно вызывать две последовательные операции на бэкенде: расчет по сложному, еще не реализованному алгоритму, и отправку данных в стороннюю систему, интеграция с которой еще не проводилась. После этого в новый блок в интерфейсе нужно вывести результаты расчета.
Вопрос: какие единицы работы можно “нарезать” из этого требования? На основании каких критериев разделять уровни этих единиц работы?
Как с этим могут быть связаны pull- и push- системы?
Что такое операционный менеджмент