|
07.10.2015, 11:12 | #1 |
Модератор
|
Так, стоять. axm2013, Вы правы. Коллеги - оппоненты axm2013, вы тоже правы
Дело в том, что вы разные вещи подразумеваете, вот из-за этого и произошло недопонимание. Итак, начнем с азов. Что такое методология внедрения? Я привык считать, что Методология Внедрения - это набор методов, рекомендаций, шаблонов документов и практик ведения проектной деятельности с целью достижения целей проекта с оговоренным качеством, призванных снизить проектные риски, в том числе риски выхода за бюджетные и временные рамки проекта, и оптимизировать полезное использование (утилизацию) ресурсов. Это, я считаю, отличное определение, если мы говорим о внедрении сложного проекта. Но есть и другое определение методологи, например: Гибкая методология разработки Цитата:
Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля[1]. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.
Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с их управлением комбинированым (либеральным и демократическим) методом. Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки. Надеюсь, я распутал текущую путаницу С Уважением, Георгий |
|
12.10.2015, 09:28 | #2 |
Гость
|
Цитата:
ЗЫ касательно гибкой методологии. Из общения в свое время с кликвьюшниками вынес представление что они ее как раз и используют в полной мере в силу крайней привязанности к клиенту и гибкости системы. Последний раз редактировалось axm2013; 12.10.2015 в 09:41. |
|
12.10.2015, 13:31 | #3 |
Модератор
|
Цитата:
Да, зачастую внедрение Qlik идет именно по Agile - методологии, потому что в начале проекта нет целей: точные цели выстраиваются именно во время внедрения проекта. Т.е. на пилотном проекте клиент понимает, что "все плохо", и стартует проект по Qlik на небольшое кол-во пользователей, с целью определения ключевых показателей и метрик. В результате этого проекта: - Выявляются ключевые показатели деятельности [по подразделениям, отделам, направлениям и отвественным] - Детализируются метрики, по которым идет оценка деятельности бизнеса - Формируются критерии к данным, их форматам, периодичности их обновления При этом у нас на дату старта проекта нет ни формализованных целей, ни функционального объема проекта. Фактически, хотя это и проект, по аналогии с Dynamics AX это - всего лишь проведение предпроектного обследования, на основании которого мы сможем сформировать требования к проекту. С одним большим плюсом - результатами данного небольшого проекта уже можно вовсю пользоваться, решая те или иные управленческие задачи. Для небольших компаний или на уровне отделов данного проекта вполне достаточно. Но вышеописанные проекты обычно небольшие, при их проведении не разрабатывается необходимая проектная документация и инструкции. Да, внедрение свехбыстрое и результативное, но если мы говорим про большое проект или масштабирование результатов данного пилотного проекта, то тут уже применяется "классическая" методология, базируясь на потребностях, выявленных в ходе подобного внедрения. И там уже все "по-взрослому". Запустить проект на 100+ пользователях, не сформировав целей и требовании к результатам проекта не решится ни одна уважающая себя консалтиногвая компания, так как отсутствие подобных документов увеличивает проектные риски. Цитата:
В основном все фигурируют следующим списком: Задание на изменение / Техническое Задание Акт приемки Инструкция пользователя Для большого проекта этого, увы, недостаточно. Особенно если мы не про BI-систему говорим, которая должна быть динамической и быстро меняться, а про ERP / учетную систему, которая должна работать "как положено", хотя бы на этапе сдачи в ОПЭ. Хотя, конечно, если она сможет динамически меняться в соотвествии с изменчивыми требованиями бизнеса - это огромный плюс. В этом мне DAX очень-очень нравится своей сбалансированностью. Так что если Вы знаете более подробный список проектных документов до данным Rapid-методологиям, буду признателен. С Уважением, Георгий. |
|
12.10.2015, 14:14 | #4 |
Аманд
|
Знаешь, всё больше убеждаюсь, что сбалансированность закончилась на AX2009
|
|
12.10.2015, 14:38 | #5 |
Гость
|
Цитата:
А вот подробности уточняют порой уже в ходе работ с непосредственным клиентом Цитата:
http://habrahabr.ru/company/unicloud/blog/167059/ |
|
12.10.2015, 14:58 | #6 |
Модератор
|
Цитата:
- "А почему этого нет? Вы же обещали!" - "А где мы вам это обещали?" Я пока не вижу, как это проблема (еще с десяток подобных) решаются в Rapid Implementation методологиях, какими проектными документами регламентируются эти и подобные вопросы. В принципе, пока я сидел на внутреннем проекте, смысл использования огромного числа проектных документов мне был непонятен и казался вреден - "зачем тратить время на бумагомарание, когда можно в это время решать задачи и писать код"?? Смысл я постиг позже. Как-нибудь подготовлю рассказ о рисках и список проектных документов. С Уважением, Георгий |
|
12.10.2015, 16:02 | #7 |
Гость
|
Цитата:
Цитата:
Цитата:
Вопрос в том как этого достичь и при этом чтобы заказчик был доволен и не ушел для перехода на R3 к другой команде к примеру. Для этого с ним надо общаться узнавать что он хочет и тп. Одна из методологий этого к примеру agile. Она ака устав в армии или ПДД написана кровью и must have у любого консультанта на уровне понимания. |
|
|
|