Наверх

Итерационная методика VS каскадная при внедрении СЭД

Время чтения: 2 минуты
4
Итерационная методика VS каскадная при внедрении СЭД

Проектное управление, управление рисками - высококлассынй внедренец должен владеть набором методик. Новая методика Agile насколько она подходит для внедрения СЭД?

Итерационная методика внедрения имеет определенные преимущества перед классической, но как убедить заказчика ее использовать. Мне, как исполнителю, итерационная методика приятней. С ней более спокойно работается (меньше нервотрепка), результат более интересный и полезный заказчику (на мой взгляд), нет длинных приемок продукта и т.д.

Как это разумно обосновать заказчику, что именно такой подход даст лучшие результаты?

Совсем недавно старались одного заказчика убедить в полезности именно итерационной методики. Сработал следующий аргумент: в сравнении итерационного и классического подходов, при равной общей стоимости работ исполнителя, в итерационном случае больше времени вкладывается именно в разработку функционала. При сравнении детальных планов-графиков работ, в итерационном случае на функционал тратиться почти на 30% больше (соответственно и функционала должно быть больше).

Тут http://www.youtube.com/watch?v=lif3VxoBQyM (с 3:30)

Парень дает достаточно интересную аргументацию в пользу итерационного внедрения (правда там он говорит о разработке веб): быстрый и понятный результат, прозрачность действий, приоритеты, и честный рассказ про удачи и неудачи.

С другой стороны, на этом видео говорится, что при внедрении готового продукта более применим "каскад".

Предлагаю поделиться мнениями по аргументации в пользу итерационного либо классического внедрения.

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 4

Agile-методики при всей своей привлекательности часто не подходят для заказчика. Дело в том, что все государственные заказчики, ФГУПы, большинство коммерческих компаний реализуют проекты через конкурсы. А в конкурсе всегда фиксируется цена, функционал и сроки, что неприемлемо для Agile.

Сработал следующий аргумент: в сравнении итерационного и классического подходов, при равной общей стоимости работ исполнителя, в итерационном случае больше времени вкладывается именно в разработку функционала. При сравнении детальных планов-графиков работ, в итерационном случае на функционал тратиться почти на 30% больше (соответственно и функционала должно быть больше).

Честно говоря, слабо верится. Можете пояснить - из чего возникла такая разница?

Честно говоря, слабо верится. Можете пояснить - из чего возникла такая разница?

Да, на SEC(R) 2014 был интересный доклад от одного действительно интересного человека. Посмотреть видео и скачать презентацию можно здесь.

Докладчик говорил, что при использовании Agile накладные расходы получаются на 20-30% больше по сравнению с Waterfall. Не знаю, как при внедрении, но при разработке это близко к заявленной цифре (ревью, тестирование, разворачивание и т.д.). Я бы даже сказал, что издержки начинаются от 30%.
По мнению тог же докладчика, Agile - это вынужденная мера, которая помогает как-то справиться со следующими факторами:
- невысокая компетенция заказчика
- недостаточные доменные знания у исполнителя
- невысокая компетенция у исполнителя.
Если по мере развития отношений исполнителя и заказчика, а также "взросления" исполнителя значимость вышеперечисленных факторов снижается, по переход от Agile к Waterfall даст прирост эффективности в те же 20-30%.
Так что я поддерживаю Мишу, у меня тоже такие сомнения по поводу большей эффективности Agile при тех же затратах.

Жалко, что парень на видео самое интересное и не рассказал. К сожалению, рамочный договор - это не панацея.

Выше Александр правильно описал ситуацию с тендерами и конкурсами. Мало кто из коммерсантов сейчас готов работать по схеме с возмещением затрат, т.к. риски неудач практически полностью ложатся на него самого. А рисковать, тем более в кризисное время, никто не готов. Контракт с фиксированной ценной - единственный вариант передать максимум рисков на поставщика, что мы собственно и наблюдаем не только на рынке IT.

Другой вопрос, каким образом исполнитель распорядится имеющимся бюджетом. На мой взгляд итерационный подход освоения бюджета, необходимо применять у клиентов без четких ожиданий от системы. Признаками этого является размытое или обобщающее ТЗ, отсутствие явного бизнес-заказчика и отсутствие понимания у заказчика разницы проектного и процессного управления. При наличии одного из этих сигналов, вероятнее всего, каскад приведет у провалу, а итерации позволят по крайней мере сформировать четкие ожидания от системы.

Чтобы прокомментировать, или зарегистрируйтесь