Журнал о системах электронного документооборота (СЭД)
Внедрение электронного документооборота

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

  4 комментариев Добавить в закладки

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

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

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

 

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

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

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

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

Ещё материалы автора
Похожие записи
Комментарии (4)
Александр Сидоренков 14 мая 2015 г. 15:08  

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

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

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

Сергей Бушмелев 15 мая 2015 г. 08:41  
Честно говоря, слабо верится. Можете пояснить - из чего возникла такая разница?

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

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

 

Айрат Сибгатуллин 15 мая 2015 г. 08:55  

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

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

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

Сейчас обсуждают
Исхаков Роберт 10 февраля 2017 г. 16:33  
Сергей Бушмелев 10 февраля 2017 г. 13:45  
Вадим Майшев 10 февраля 2017 г. 13:39  
Сергей Бушмелев 10 февраля 2017 г. 13:27  
Исхаков Роберт 10 февраля 2017 г. 11:28  
Больше комментариев