|
25.08.2015, 14:51 | #1 |
Гость
|
ЗЫ кстати
http://smart-talks.org/event/smart-talks-22/ "Построение приложения при помощи TDD. Часть 1. (Level 300) Попробуем построить приложение используя TDD. Часть первая – вводная и постановочная. Пример будет основан на реально работающем приложении." Если что к smart-talks отношения не имею |
|
26.08.2015, 14:23 | #2 |
Administrator
|
На правах модератора хочу заметить, что дискуссия имеет склонность превратиться в выяснение отношений между участниками axm2013 и R.Safianov, ибо начинается переход на личности.
Хотелось бы недопустить выяснение отношений в столь замечательно поднятой тебе про тестирование функционала. Спасибо.
__________________
Возможно сделать все. Вопрос времени |
|
|
За это сообщение автора поблагодарили: R.Safianov (2). |
27.08.2015, 10:04 | #3 |
Участник
|
axm2013, повторюсь, у вас очень специфическое понимание рынка Dynamics AX, в России в частности. С учетом вашего слива с опытом не вижу смысла что-то с вами обсуждать далее. Удачи на проектах.
__________________
Ivanhoe as is.. |
|
27.08.2015, 10:22 | #4 |
Гость
|
Цитата:
Цитата:
По проектам со значительным участием: Вам самому не смешно? Порядка 20 проектов со значительным участием для консультанта означает от и до.. Вы 20 лет в аксапте? Хм... Подтвержденных знаний по Ax 2012 близко к нулю: ни одного сданного экзамена. По 2009 - как понимаю за три года осилили ровно один. По ПМ ству тоже успехов в изучении чего либо не заметно. В Корусе точно есть обучение? 2sukhanchik Ну и как вам переход на личности? Ровно поэтому и не привожу полную биографию. PS Ну раз Нургалиев разрешил... Да и вам не хворать. А то судя по Munz-у в некоторых консалтах чтят "традиции" времен Дикси. Последний раз редактировалось axm2013; 27.08.2015 в 11:58. |
|
|
За это сообщение автора поблагодарили: macklakov (-10), Yoil (-2), gl00mie (-1), Atar (-1), AxaptaUser (-1), R.Safianov (-1), rudi (-1). |
07.09.2015, 10:57 | #5 |
Участник
|
Как же хорошо, когда есть тот, кто оплатит подобные изыскания и аппробирование различных "методологий". Кстати, это знание не бывает лишним и может дать сильное преимущество на собеседовании, даже перед более сильным в профессиональном плане специалистом. Потому что обычный проект - это "давай-давай-давай", когда срочно надо реализовать заявленный или неучтенный функционал или допилить работающий под требования пользователей. А если время есть - то изучайте, и Scum / Adgile, и Pince 2, или COBIT, не говоря уже про PMBOK. Будет чем очаровать потенциального работодателя.
|
|
07.09.2015, 12:33 | #6 |
Гость
|
Да в том то и дело что при всех этих срочно и прочем получается по факту не быстрее и не качественнее (как то видел как разработчиков заставляли работать по 14 часов: итоговый результат не сильно отличался от того что они бы сделали за 8 часов, хотя вид у них был еще тот). Может что то надо менять в консерватории?
|
|
16.09.2015, 12:54 | #7 |
Талантливый разгвоздяй
|
axm2013, вы рассуждаете как теоретик. Вам дай лобзик, так вы кинетесь им баобабы срубать... А если кто-то попытается вас переубедить, то ответы будут в стиле "сам дурак, я уже десять баобабов срубил лобзиком и этот срублю, если вы не будете мешать".
Последний раз редактировалось sukhanchik; 16.09.2015 в 12:59. |
|
|
За это сообщение автора поблагодарили: Михаил Андреев (2), sukhanchik (2), gl00mie (2). |
16.09.2015, 13:48 | #8 |
Гость
|
Не совсем: agile-подобное видел. Это интереснее и по ощущениям эффективно.
Не так. Лобзиком зачастую сейчас работают те же консалты. Вместо топора. Знания и понимания методологий разработки ПО дальше теории (и это в лучшем! случае) нет. Почему уже отписывался выше (консультанты в большинстве своем, слабо знакомы с подобными вещами и соответственно ПМ-ы тоже). В общем то идет все пока к сожалению уровень гильдий средневековья, не выше. Промышленная революция данный край увы не затронула. Цитата:
Почитайте ради интереса How Google Tests Software (успел прочесть несколько страниц) где довольно интересно о качестве и прочем: Если сравнивать с крупными консалтами где мне доводилось бывать на экскурсиях: небо и земля по уровню развития, причем даже без шансов. И самое плохое что нет даже намека на стремление сделать лучше хоть что-то Последний раз редактировалось axm2013; 16.09.2015 в 14:00. |
|
|
За это сообщение автора поблагодарили: Kabardian (0). |
25.09.2015, 09:52 | #9 |
Гость
|
|
|
07.10.2015, 11:12 | #10 |
Модератор
|
Так, стоять. axm2013, Вы правы. Коллеги - оппоненты axm2013, вы тоже правы
Дело в том, что вы разные вещи подразумеваете, вот из-за этого и произошло недопонимание. Итак, начнем с азов. Что такое методология внедрения? Я привык считать, что Методология Внедрения - это набор методов, рекомендаций, шаблонов документов и практик ведения проектной деятельности с целью достижения целей проекта с оговоренным качеством, призванных снизить проектные риски, в том числе риски выхода за бюджетные и временные рамки проекта, и оптимизировать полезное использование (утилизацию) ресурсов. Это, я считаю, отличное определение, если мы говорим о внедрении сложного проекта. Но есть и другое определение методологи, например: Гибкая методология разработки Цитата:
Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля[1]. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.
Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с их управлением комбинированым (либеральным и демократическим) методом. Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки. Надеюсь, я распутал текущую путаницу С Уважением, Георгий |
|
12.10.2015, 09:28 | #11 |
Гость
|
Цитата:
ЗЫ касательно гибкой методологии. Из общения в свое время с кликвьюшниками вынес представление что они ее как раз и используют в полной мере в силу крайней привязанности к клиенту и гибкости системы. Последний раз редактировалось axm2013; 12.10.2015 в 09:41. |
|
12.10.2015, 13:31 | #12 |
Модератор
|
Цитата:
Да, зачастую внедрение Qlik идет именно по Agile - методологии, потому что в начале проекта нет целей: точные цели выстраиваются именно во время внедрения проекта. Т.е. на пилотном проекте клиент понимает, что "все плохо", и стартует проект по Qlik на небольшое кол-во пользователей, с целью определения ключевых показателей и метрик. В результате этого проекта: - Выявляются ключевые показатели деятельности [по подразделениям, отделам, направлениям и отвественным] - Детализируются метрики, по которым идет оценка деятельности бизнеса - Формируются критерии к данным, их форматам, периодичности их обновления При этом у нас на дату старта проекта нет ни формализованных целей, ни функционального объема проекта. Фактически, хотя это и проект, по аналогии с Dynamics AX это - всего лишь проведение предпроектного обследования, на основании которого мы сможем сформировать требования к проекту. С одним большим плюсом - результатами данного небольшого проекта уже можно вовсю пользоваться, решая те или иные управленческие задачи. Для небольших компаний или на уровне отделов данного проекта вполне достаточно. Но вышеописанные проекты обычно небольшие, при их проведении не разрабатывается необходимая проектная документация и инструкции. Да, внедрение свехбыстрое и результативное, но если мы говорим про большое проект или масштабирование результатов данного пилотного проекта, то тут уже применяется "классическая" методология, базируясь на потребностях, выявленных в ходе подобного внедрения. И там уже все "по-взрослому". Запустить проект на 100+ пользователях, не сформировав целей и требовании к результатам проекта не решится ни одна уважающая себя консалтиногвая компания, так как отсутствие подобных документов увеличивает проектные риски. Цитата:
В основном все фигурируют следующим списком: Задание на изменение / Техническое Задание Акт приемки Инструкция пользователя Для большого проекта этого, увы, недостаточно. Особенно если мы не про BI-систему говорим, которая должна быть динамической и быстро меняться, а про ERP / учетную систему, которая должна работать "как положено", хотя бы на этапе сдачи в ОПЭ. Хотя, конечно, если она сможет динамически меняться в соотвествии с изменчивыми требованиями бизнеса - это огромный плюс. В этом мне DAX очень-очень нравится своей сбалансированностью. Так что если Вы знаете более подробный список проектных документов до данным Rapid-методологиям, буду признателен. С Уважением, Георгий. |
|
12.10.2015, 14:14 | #13 |
Аманд
|
Знаешь, всё больше убеждаюсь, что сбалансированность закончилась на AX2009
|
|
12.10.2015, 14:38 | #14 |
Гость
|
Цитата:
А вот подробности уточняют порой уже в ходе работ с непосредственным клиентом Цитата:
http://habrahabr.ru/company/unicloud/blog/167059/ |
|
12.10.2015, 14:58 | #15 |
Модератор
|
Цитата:
- "А почему этого нет? Вы же обещали!" - "А где мы вам это обещали?" Я пока не вижу, как это проблема (еще с десяток подобных) решаются в Rapid Implementation методологиях, какими проектными документами регламентируются эти и подобные вопросы. В принципе, пока я сидел на внутреннем проекте, смысл использования огромного числа проектных документов мне был непонятен и казался вреден - "зачем тратить время на бумагомарание, когда можно в это время решать задачи и писать код"?? Смысл я постиг позже. Как-нибудь подготовлю рассказ о рисках и список проектных документов. С Уважением, Георгий |
|
12.10.2015, 16:22 | #16 |
Модератор
|
Но, увы, она не отвечает на простой вопрос: "в каком документе фиксируются цели проекта".
Так же она не отвечает на вопросы: "в каком документе фиксируются критерии достижения целей проекта", "что явяется критерием достижения вехи проекта", "документы, необходимые при сдаче вехи проекта" и "процесс сдачи вехи проекта" (закрывающие документы). Поверьте, меня эти вопросы вообще не беспокоили - вехи какие-то. А потом я стал разрабатывать КП, и зачастую оплата Заказчиком Исполнителю происходит именно по вехам проекта А вот это засталяет задуматься и смотреть на методологии на только как "как можно быстро что-то реализовать" и но "процесс, как безболезненно это сделать и прикрыть тылы". Так вот, пока у RIM - очень плохо со вторым вопросом. А у "классических" - наоборот, зачастую сильно перегружена часть, отвественная за точное фиксирование предполагаемого результата и процесса его сдачи заказчику - неудивительно, PMBOK писан кровью ПМов ну и туда зафигачили множество документов на каждый чих, а какие правильно использовать - "поймете с опытом, для этого как раз и нужны РП". Со временем и RIM подтянутся до подобного уровня. Но пока, повторяю, на мой взгляд им еще далеко. Однако, если Вы знаете ссылку на подобные документы для RIM - скиньте, я удивлюсь. С Уважением, Георгий |
|
13.10.2015, 11:43 | #17 |
Гость
|
Цитата:
Отмечу, что: Методология — это система принципов, а также совокупность идей, понятий, методов, способов и средств, определяющих стиль разработки программного обеспечения. Не меньше но и не больше. Документация процесса отдается на конкретной реализации методологии и в общем то это логично при желании сократить количество документации, создаваемой на проекте. Пожелания же к документации смотрите в чем то типа такого http://www.agilemodeling.com/essays/...Specifications |
|
|
За это сообщение автора поблагодарили: George Nordic (5). |
14.10.2015, 10:02 | #18 |
Модератор
|
Цитата:
Сообщение от George Nordic
Методология Внедрения - это набор методов, рекомендаций, шаблонов документов и практик ведения проектной деятельности с целью достижения целей проекта с оговоренным качеством, призванных снизить проектные риски, в том числе риски выхода за бюджетные и временные рамки проекта, и оптимизировать полезное использование (утилизацию) ресурсов.
Цитата:
В принципе, как я и говорил, мне всегда была ближе точка зрения "зачем все эти методологии, документацию всякую писать - это пустая трата времени - пахать надо". Однако она резко изменилась после работы в консалтинге, а не на внутреннем проекте У каждого подхода есть минусы и плюсы. В Rapid Implementation Methodology (RIM) - это быстрое достижение целей проекта, и это очень ценно когда цели не ясны или могут меняться. Поэтому для BI-проектов они очень хорошо подходят. В целом, считаю мы пришли к консенсусу, а дальнешее развитие перейдет в тему "а нужна ли [правильная] методология", которая уже обсуждалась. Вкратце, народ понимает важность использования методологии и документирования, но в целом неодобрительно к ней относится, т.к. это съедает очень много времени, сил и ресурсов, и, разумеется, удорожает проект. Вопрос, кто будет за это платить - открытый, клиенту тоже не особо хочется тратить деньги на бумажки, призванные защитить в первую очередь партнера, вместо того чтобы за эти деньги получить результат. Так что в целом пока отношение как к "необходимому злу". Да, как и обещал, накидаю в отдельной теме список документов, вдруг кому пригодится. С Уважением, Георгий |
|
14.10.2015, 20:00 | #19 |
Участник
|
Цитата:
В общих чертах, это выглядит так: - Если сотрудник сидит на окладе или подрядчик на таймшитах, то они оба будут заинтересованы в том чтобы поменьше писать документов, а побольше удовлетворять пользователей. - А если сотруднику обещана большая премия за результат или подрядчик привлечен на фикс-прайс, то оба они будут очень заинтересованы в том, чтобы требования к результату были заранее поточнее определены и утверждены. Тут и возникает потребность в документах целеполагающего характера. |
|
|
За это сообщение автора поблагодарили: macklakov (2). |
15.10.2015, 09:31 | #20 |
Гость
|
Цитата:
Общие документы целеполагающего характера никто не отрицает в методологиях. А вот подробные... В тех проектах которых доводилось участвовать то что предполагалось изначально порой очень сильно расходилось с действительностью на конечном этапе. Причин масса: зачастую пользователи ака ключевые пользователи слабо представляют работу Dynamics Ax а в свою очередь консультанты слабо представляют бизнес процессы и их тонкости. В итоге рождение подробных ТЗ на первоначальном этапе, приводило к тому что в ходе показов пользователям приходилось перерабатывать все достаточно серъезно вплоть "проще было бы сделать с нуля" |
|
|
|