Comments 10
Проблема решается, когда в процесс разработки возвращается обязательная фаза - проектирование, которую вы называете, кхм... Discovery. Ну Ok. Результатом проектирования является набор документации, - формальные документы. Именно формализм позволяет потом организовать процесс реализации согласно имеющимся ресурсам. А по вашему мнению проблему решает бюрократия - методология управления, граничащая с религией и прочими мифами (обряды, ритуалы и прочее).
Соглашусь, что проблема целостности крупных цифровых продуктовых решений во многом решается большим вниманием к фазе проектирования, которой в водопаде уделялось слишком много внимания, а в Agile-методиках - ИМХО, слишком мало (по-хорошему, затраты на проектирование должны коррелировать со сложностью реализуемого решения). Однако, автор на это как раз и указывает (в качестве одной из мер по улучшению управляемости видением и реализацией решения). А описанная "бюрократия" - это и есть попытка формализации процесса, закрепления его остова. Формализация артефактов проектирования (фазы Discovery) в статье затронута вскользь, но как я понял, она подразумевается (хотя бы в виде упомянутого "концепта" решения).
Это общепринятые практики, которые нам помогли. Возможно, у вас другой подход к организации работы команд. Какой?
чем больше я читаю про UP (RUP), тем больше не понимаю, зачем изобрели аджайл. Нужна прозрачность - делай итерации меньше да и всё
Это самое главное при работе руководителя с командой на мой взгляд - пропускать окружающий рабочий хаос через себя и упорядочивать его для своей команды. Лайк👍👍
Ненавижу читать тексты на половину состоящие из иностранных терминов, определения которым в статье не приводится.
По сути вы изобрели планерки и 5тилетки заново. А так же научились дробить большие задачи на маленькие.
Пытался найти новизну в смысле текста, а получил полный негатив о походах работы в альфе.
Как оседлать хаос