Comments 5
Как верно замечено, любая классическая схема, на самом деле, вполне допускает откат на любой из этапов в любой момент времени — просто в этой схеме такой откат обходится дороже, потому что слишком велики издержки на составление новой структуры работ, нового плана и прочие формальности, которые требуются при таком управлении.
Равно как и любая аджайл схема допускает, на самом деле, любой уровень формальности и бюрократии — лишь бы он бы комфортен для всех участников.
Поэтому, как мне кажется, белое поле на графике — это просто зона очень больших затрат. Вряд ли там скрывается какая-нибудь серебряная пуля.
Равно как и любая аджайл схема допускает, на самом деле, любой уровень формальности и бюрократии — лишь бы он бы комфортен для всех участников.
Поэтому, как мне кажется, белое поле на графике — это просто зона очень больших затрат. Вряд ли там скрывается какая-нибудь серебряная пуля.
+1
На правах шутки: первая мысль о сложных проектах где постоянные изменения — «надо продать аутстафф» :)
Изначально отталкиваться от ЖЦ в различиях не совсем корректно на мой взгляд. Есть такая штука, как динамическое управление в управлении проектами, то есть когда с одной стороны есть план, но он управляется в том числе и внешними событиями (рисками, изменениями). И это не аджайл.
Почему вообще классика в ИТ применяется? Она применяется в основном там, где есть ключевые для проекта активности, которые нельзя осуществить итерационно, или итерации очень затратные-большие. Это например, когда помимо софта нужно еще сделать железо, или когда нельзя развертывать конечный результат в боевой среде до посинения (есть наверняка и другие случаи). Там ценность проектирования вырастает в разы. Там где можно делать проект так же, как программировать — написал-запустил-посмотрел-написал-запустил-посмотрел, там аджайл подходит.
Поэтому в «белой зоне» коктейль такого рода: прототип-конечный дизайн-разработка-бета-альфа-релиз. То есть не туда-сюда как в аджайле не воспрещается, и не s-кривая от 0 до 100% по времени для готовности продукта, а ступеньки: изготовили, подумали-поисследовали, изготовили переделанную версию, и так по циклу. Если говорить в терминологии объединения, то есть это спланированный наперед аджайл из водопадов разного рода (разработка и маркетинг как минимум), управляемый динамически; по сути, программа, и работает там программный менеджмент, такой, какой он например описан рекомендациями PMI по управлению программами. Очень хороший документ, рекомендую ознакомиться.
Изначально отталкиваться от ЖЦ в различиях не совсем корректно на мой взгляд. Есть такая штука, как динамическое управление в управлении проектами, то есть когда с одной стороны есть план, но он управляется в том числе и внешними событиями (рисками, изменениями). И это не аджайл.
Диаграмма из книги, пример управления кораблем
Почему вообще классика в ИТ применяется? Она применяется в основном там, где есть ключевые для проекта активности, которые нельзя осуществить итерационно, или итерации очень затратные-большие. Это например, когда помимо софта нужно еще сделать железо, или когда нельзя развертывать конечный результат в боевой среде до посинения (есть наверняка и другие случаи). Там ценность проектирования вырастает в разы. Там где можно делать проект так же, как программировать — написал-запустил-посмотрел-написал-запустил-посмотрел, там аджайл подходит.
Поэтому в «белой зоне» коктейль такого рода: прототип-конечный дизайн-разработка-бета-альфа-релиз. То есть не туда-сюда как в аджайле не воспрещается, и не s-кривая от 0 до 100% по времени для готовности продукта, а ступеньки: изготовили, подумали-поисследовали, изготовили переделанную версию, и так по циклу. Если говорить в терминологии объединения, то есть это спланированный наперед аджайл из водопадов разного рода (разработка и маркетинг как минимум), управляемый динамически; по сути, программа, и работает там программный менеджмент, такой, какой он например описан рекомендациями PMI по управлению программами. Очень хороший документ, рекомендую ознакомиться.
0
Всё уже придумано до Вас.
Не надо пытаться натянуть сову узкой предметной области (программирования) на глобус всех на свете сложных задач. Там другие подходы, в которых агил — только очень примитивный частный случай.
Не надо пытаться натянуть сову узкой предметной области (программирования) на глобус всех на свете сложных задач. Там другие подходы, в которых агил — только очень примитивный частный случай.
0
Sign up to leave a comment.
Возможно ли Великое Объединение в теории управления проектами? Часть 1