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