"Новые" методологии

Quote:

Originally Posted by Bobkov

... то оба они будут очень заинтересованы в том, чтобы требования к результату были заранее поточнее определены и утверждены. Тут и возникает потребность в документах целеполагающего характера.

Вопрос в том возможно ли такое на первоначальном этапе.
Общие документы целеполагающего характера никто не отрицает в методологиях. А вот подробные...

В тех проектах которых доводилось участвовать то что предполагалось изначально порой очень сильно расходилось с действительностью на конечном этапе. Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости. В итоге рождение подробных ТЗ на первоначальном этапе, приводило к тому что в ходе показов пользователям приходилось перерабатывать все достаточно серъезно вплоть "проще было бы сделать с нуля"

[gl00mie]

Quote:

Originally Posted by Bobkov

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

Очень тонко подмечено

Quote:

Originally Posted by Bobkov

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

В переводе на русский, если сотрудник заинтересован в результате, то он документирует работу по проекту ("получите, распишитесь"), а если в самом процессе безотносительно результата, то концентрируется на удовлетворении хотелок пользователей ("чего изволите?")

Quote:

Originally Posted by axm2013

В тех проектах которых доводилось участвовать то что предполагалось изначально порой очень сильно расходилось с действительностью на конечном этапе. Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости.

В переводе на русский: консультанты не разбирались в бизнесе заказчика.

[Ivanhoe]

Quote:

Originally Posted by axm2013

Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости. В итоге рождение подробных ТЗ на первоначальном этапе, приводило к тому что в ходе показов пользователям приходилось перерабатывать все достаточно серъезно вплоть "проще было бы сделать с нуля"

А вот это уже вопрос к методологии. Если вы возлагаете ответственность на ключевых - их нужно сначала обучить системе, подходам к проектированию, той же методологии - на этих проектах была такая задача выполнена?

Показы, я так понимаю, после реализации. Опять же вопрос к методологии. Кто мешает, сдавая ТЗ, показывать живую систему, при необходимости даже с на коленке выполненными доработками? Это очень сложно делать если вы пишите космос - ну так не надо тогда Акс внедрять. Если же нормально пользователи видят систему после того, когда все сделано или даже на обучении - это неправильная методология внедрения Акс.

Quote:

Originally Posted by Ivanhoe

А вот это уже вопрос к методологии. Если вы возлагаете ответственность на ключевых - их нужно сначала обучить системе, подходам к проектированию, той же методологии - на этих проектах была такая задача выполнена?

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

Quote:

Originally Posted by Ivanhoe

Опять же вопрос к методологии. Кто мешает, сдавая ТЗ, показывать живую систему, при необходимости даже с на коленке выполненными доработками?

Ровно так и делали и выяснялось порой что не учтены определенные ньюансы серъезно влияющие на дальнейших ход всей разработки.

Quote:

Originally Posted by Ivanhoe

Если же нормально пользователи видят систему после того, когда все сделано или даже на обучении - это неправильная методология внедрения Акс.

В итоге приходим к тому что по факту имеем необходимость частого общения с пользователями, на что и нацелена agile методология

[pitersky]

Тут ещё надо иметь в виду, что зачастую требование пользователя звучит как "сделайте как в Экселе/1С/итд"(с) Т.е. требуемая функциональность имеется, но выглядит иначе. А у пользователя срабатывает инстинкт "выглядит не так, значит не то". Ведь в принципе главбуху должно быть всё равно, как выглядит план счетов - главное, чтобы он был.

[Ivanhoe]

А классика отвергает общение с пользователями? Я вот очень плохо отношусь, когда команда не сидит у клиента и не общается с пользователями. Исключения делаем на очень удаленных проектах, и то периодичность присутствия все равно ритмична на всех стадиях, даже разработки. Ну и современные средства общения - наше все.

Quote:

Originally Posted by Ivanhoe

А классика отвергает общение с пользователями?

Скажем так: на этом не заостряется внимание + нет общих подходов с правами и обязанностями пользователей системы на разных этапах (т.е. никаких свиней и куриц к примеру).

[belugin]

Quote:

Originally Posted by Ivanhoe

А классика отвергает общение с пользователями?

Водопад скорее - "Мы сделаем то-то за год и миллион долларов, если что-то в процессе меняется, давайте дополнительно денег и времени"

Agile скорее "Мы за месяц решим вам наиболее важную проблему а дальше посмотрим что будет самое важное"

Типа изменения - по-умолчанию

[AlexeyS]

Quote:

Originally Posted by pitersky

Тут ещё надо иметь в виду, что зачастую требование пользователя звучит как "сделайте как в Экселе/1С/итд"(с) Т.е. требуемая функциональность имеется, но выглядит иначе. А у пользователя срабатывает инстинкт "выглядит не так, значит не то". Ведь в принципе главбуху должно быть всё равно, как выглядит план счетов - главное, чтобы он был.

Это вопрос формы и содержания.
Привычная форма помогает быстрее понять содержание, именно поэтому у большинства важных типов документов существует регламентированная форма с отступами, шрифтами и прочим.

Купите клавиатуру с нестандартной раскладкой и попечатайте вслепую,
ведь в принципе вам должно быть все равно как выглядит клавиатура - главное, что все буквы и цифры есть

[pitersky]

Quote:

Originally Posted by AlexeyS

Купите клавиатуру с нестандартной раскладкой и попечатайте вслепую,
ведь в принципе вам должно быть все равно как выглядит клавиатура - главное, что все буквы и цифры есть

это понятно, что при переходе с абака или арифмометра на калькулятор я некоторое время буду считать медленнее, чем раньше. ну и что? всё равно такой переход оправдан в более-менее длинной перспективе

"Кто не освоит аgile сегодня, тем придется в текущих бизнес-процессах быть лузерами завтра"
Греф
http://www.vedomosti.ru/finance/arti...ormi-sberbanka

PS кстати мысли Грефа довольно сильно определяют саму архитектуру решения (явно спер их откуда то).
Собственно все сводится к кучке отдельных независимых сервисов. В чем то перекликается с идеями принятыми в Гугле (один человек один сервис) судя по книжке о тестировании там.

Только при таком решении обеспечивается быстрое тестирование. В ДАХ 12 есть как понимаю какие то подвижки в этом направлении тоже. Надеюсь будет продолжение и в 7 ке.

[George Nordic]

Подкину-ка еще на вентилятор - как раз статью написал.

Постараюсь в данной прадигме объяснить разницу между методологиями внедрения PMBOK и новомодным Agile.

Сразу скажу - я не против и того и того. Да хоть PrinceII - мне все равно. Больше методологий хороших и разных.Нет "хороших" и "плохих" методологий, каждая хороша для решения определенного класса задач или типа проектов. И настоящий РП должен уметь их комбинировать: например, PMBOK на этапе комплексной оценки проекта и глобального руководства проектом, и Scrum - для реализации конкретной функциональности покрытия As is-to be GAP.

И когда я слышу "только хордкор, только PMBOK"!! или "В жопу документацию, рефакторинг рулит, Аджайл - наше все!!" - мне становится страшновато. Да, я понимаю что PMBOK - очень перегружен рядом процедур по каждой фазе проекта, куча процедур и документов. И, действительно, зачастую подготовка проектной документации занимает очень много ресурсов, которые так необходимы на самом внедрении. Да, я понимаю Agile это тоже серьезная методология, а не "раз-раз и в продакшен". Но когда мне заявляют, что только он годится для настройки ERP, мне хочется привести следующую аналогию, когда Вам нужна электрика в новую квартиру:

PMBOK
- Анализ и дизайн:
Покажите план квартиры. А что вам нужно? А где будет спальня? А тумбочки будут? А какие? А розетки там какие? Как не нужны, а как вы будете телефон заряжать? А где телевизор? А какие кабели класть? Или лучше канал сделать? А домашний кинотеатр будет? А колонки сзади? А почему бы сразу аккустические провода в стены не убрать? Это что - кухня? А какая кухня будет, вы уже заказали? что значит потом - необходимо сначала заказать кухню, чтобы сделать розетки на высоте столешницы, и вывести силовые кабели под варочную панель, духовой шкаф и микроволновку. И так далее.
- Разработка и Тестирование:
Чертим схему, понимаем нагрузку, выбираем толщину кабелей и пакетники, не забываем УЗО, рисуем распределительный шкаф. Согласуем с заказчиком, объясняем что розетки двигать нельзя, подписываем у него. Сдаем схему на экспертизу, получаем разрешение и документы. Говорим заказчику сколько розеток и выключателей понадобится.
- Внедрение:
Нагоняем рабочих, они штробят стены и сверлят углубления под подрозетники. Приводим электриков, они монтируют разводку, точки и шкаф. Проверяем. Проветриваем дым, исправляем, проверяем еще раз.
- Сдача в эксплуатацию и Сопровождение:
Проверка вместе с заказчиком. Ответы на безумные вопросы в стиле "ой, мы другую спальню купили, а можно вот эти розетки передвинуть", апеллируя к подписанному заказчиком плану. Возможно, все-таки двигая розетки, но по двойному тарифу.

Agile
Так, братва, берем кучу проводов, розетки и лампочки. Будем сверлить там, куда укажет заказчик.

С Уважением,
Георгий

[macklakov]

Quote:

Originally Posted by George Nordic

"В жопу документацию, рефакторинг рулит, Аджайл - наше все!!" - мне становится страшновато.

Старая песня о главном. Зачастую используется псевдо-agile, с целью не писать документации. В то время как раельно agile не исключает документации, просто она пишется зандим числом. Т.е. решение и дизайн задокументированы, но нет документации по забракованным прототипам и промежуточным итерациям. И если клиент за эту документацию готов платить.
В общем случае, сопровождающая документация крайне рекомендуется. Но если это разовая поделка, то документация это просто дополнительные издержки.

Quote:

Originally Posted by George Nordic

Agile
Так, братва, берем кучу проводов, розетки и лампочки. Будем сверлить там, куда укажет заказчик.

Нет, Agile это: "Так ребята, наш клиент хочет освещение и розетки. Вот контакт клиента, вот контакт его жены, у них узнаете детали. Что делать вы лучше меня знаете. Если какие сложности, обращайтесь ко мне."
Это другой момент в agile, про который все норовят забыть. Agile это само-организующаяся команда. А это подразумевает что она состоит из высококлассных честолюбивых профессионалов. Это способ развязать руки звездным и дорогим экспертам, которые лучше менеджера знают что и как надо делать.
Если уж аналогии проводить, то члены agile команды это больше не электрики, а дизайнеры интерьера. Они не боятся эксперементировать и предлагать решения, о которых клиент и не догадывался. Есть десятки способов поставить свет. Можно сосредоточиться на энерго-сбережении, можно сделать рабочий свет, можно "сделать красиво", можно изменяющийся под настроение или погоду. А можно светом подчеркнуть статус клиента. К примеру стелаж с наградами или семейными реликвиями.
Т.е. типовой сценарий специалиста в agile это прототипирование. С помощь временных источников света создать приглушенный свет в гостинной и подсветить какой-то предмет в углу или на стене. И спросить клиента, как тому эффект. Тут же переместить в другое место и сравнить. И когда клиент проникнется и скажет:"вот оно!", тогда уже заниматься собственно прокладкой электрики. Если клиент захочет. В музеях и на выставках, к примеру, так и оставляют временные, переносные источники света. Просто провода с прохода убирают и все.

[Sancho]

+
agile может себе позволить специалист уровня архитектора, а никак не программиста.

[belugin]

По поводу того, кому подходит и что надо освоить можно погуглить "Agile Maturity model" или залипнуть на вот эту схему