Здравствуйте, Alex EXO, Вы писали:

AE>Здравствуйте, Gaperton, Вы писали:
G>>Вы описываете реальную жизненную ситуацию. В которой новые бизнес-процессы должны быть зафиксированы на бумаге, и пройти серию проверок. Этого глупо не делать. Это в данном случае есть работа аналитиков и консультантов.

AE>+1 согласен
AE>Но при этом не забываем, что пока эти БП таки пока остаются "сферическим конем в вакууме". Даже после всех проверок.

Ну допустим. Хотя можно довольно неплохо выверить их и на бумаге, выловив процентов 80 проблем, а то и больше.

G>> Никаких agile в такой ситуации, категорически.

AE>agile работает несколько на другом уровне — нарезке на минимально осмысленные изменения. Включаяя и изменеия БП и поддерживающую разработку. "Опасные шаги" нужно сделать как можно мельче. А уж как это назвать — второй вопрос.

Предположим. Мне казалось, что agile относится только к разработке? Не могли бы вы сказать конкретно и по возможности математически точно — каким именно образом это реализует agile?

G>> Именно будет завершенным именно НИР. И одним из результатов НИР будет проект ТЗ и пожтапный план внедрения.

AE>Да. Почти так.
AE>Этап 1. Описание БП. На _весь_ комплект взаимосвязанных БП.
AE>Этап 2. Поэтапный план внедрения.

AE>а вот дальше цикл:
AE>3.1 ТЗ этапа
AE>3.2 разработка блока ИС поддерживающего функционал этапа
AE>3.3 тестипрование
AE>3.4 _опа_! "Внимание прыгаем". Изменеие БП в организации, запуск блока ИС
AE>3.5 опытная эксплуатация — нестабильный этап(кошмар и аврал, выворачивание всего блока на изнанку)
AE>3.6 опытная эксплуатация — стабилизация, документирование итогового функционала, написание "журнала различий" (какие требования менялись и почему — понадобится на шаге 3.1 следующих этапов)
AE>3.7 рефакторинг блока (причесывание того кода, который аврально менялся на этапе 3.5) под непрерывным тестированием.
AE>3.8 "рефакторинг" общего описания комплекта БП (с шага 1)

AE>Самым дорогим для всех здесь является шаг 3.5
AE>И полностью исключить его обычно не удается. Лучше всего работает сокращение всего "цикла 3.*"

Ай-ай. Проватерфолили вы, Алекс, одину ватерфольную проверку, которая вам сильно облегчила бы жизнь. Легковесные прототипы гуя для исполнителей, которые идут между началом разработки и завершением работ по постановке ТЗ. Как раз посерединке. Служат они для верификации того, как вы переносите бизнес-процессы в ТЗ (реализуете их), и для вылова остатков ошибок в самих БП. И тогда не будет "_ОПА_" на 3.4, будет маленькое "опаньки". Да, хорошо, если вы используете РАД-тул, который позволит вам не выкинуть эти прототипы. Это вполне возможно.

Это раз. Два. Я бы поправил ваш план, он на мой взгляд не очень хорош. И главной целью первого этапа поставил скорейшее выделение функицональных блоков, которые можно пускать независимо и/или последовательно, а также зависимостей между ними и их приоритетов. Результат первого этапа — общая грубая схема (декомпозиция) БП + поэтапный план дальнейших работ (в том числе и по уточнению БП). После чего, половину работ вашего этапа 1 (по детальному уточнению и верификации БП, включая изготовление легковесных прототипов ГУЯ) я бы перенес в рамки Этапа 2, и вел бы их также последовательно по функцинальным блокам, с конвейерным наложением друг на друга. То есть, полномасштабная разработка стартует по закрытию фазы с легкими прототипами, после чего группа "аналитиков" берет следующий функциональный блок.

Три. То что я вам сейчас сказал в "раз" и "два" — это ватерфол, мать его, построенный по всем ватерфольным канонам. И он — ацки хорош и разумен. Am I wrong?!

G>> Кстати, для большой организации практически всегда можно запускать автоматизацию потапно. Без исключений. Вы неправы, Алекс, утверждая, что надо реализовать обязательно полную функциональность. Просто этапы надо бить не по отделам и филиалам, а по "функциональным блокам".

AE>Да. Именно так.
AE>Но только такой "функциональный блок" — это не макет. На него сразу падает полная нагрузка (в смысле числа пользователей и информационного потока).
Разумеется. Макет — это макет гуя, я про них написал выше.

G>>В описываемом вами случае внедрение КИС является частью более крупной работы по реорганизации БП, и общую работу надо строить не по канонам разработки софта. Вот и весь фокус. Софт — это необходимый, но далеко не главный этап.

AE>Только софт тоже нужно разрабатывать. И вот получающаяся в итоге разработка софта ("проектция" "общей работы" на плоскость разработки софта) очень сильно напоминает agile.

По мне — так самый что не на есть ватерфол, даже не в профиль. Разумеется, после добавления процедур контроля качества, отсутствующие у вас — у вас при вашем плане ошибки в БП и их реализации в постановке на поздний этап пролезают, а им правильнее выставить еще один барьер.