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

http://dev.goshoom.net/en/2015/08/un...ax-what-is-it/

[Link]

Цитата:

Сообщение от Morpheus

Каких инструментов? Почему эти инструменты недоступны партнерам и клиентам?

Кто интересуется темой почитайте Testing best practices (White paper) [AX 2012]:

Цитата:

Test phase best practices
Unit testing
SDEs created new unit tests and modified existing unit tests while developing new features. The source code check-in process required a minimum level for the code coverage of the unit tests that the developer created. For X++ development, these tests were developed by using the SysTest framework in MorphX. For managed code, these tests were developed by using an internal test harness and/or MSTest. Tens of thousands of unit tests were run during Microsoft Dynamics AX 2012
development. The number of lines of code for unit testing was nearly the same as the number of lines of code for the product.
A subset of the unit tests was defined as check-in tests (CITs). These tests were run and required to pass as part of the gated check-in system that all SDEs used for any check-in to the source code repository. This prevented major regressions from being introduced into the code base.
Function testing
The first hands-on use of a feature by the SDETs came as part of the scorecard testing of the testable units. This testing is a lightweight form of acceptance test–driven development (ATDD). SDETs and SDEs work very closely in this phase of the project.
Subprocess, process, integration, and user acceptance testing
In addition to testing that was focused on features, the SDETs broadened their testing efforts to focus on key interfaces with other areas of the system. As described earlier, end-to-end scenarios were a key part of this testing effort.
In addition to the scripted E2E scenarios, the test team coordinated numerous “interactive test sessions” in the later phases of the release. The goal of each session was to bring together SDETs,
PMs, and SDEs to focus on a particular business cycle or a particular area of the product. These sessions were critical to driving completeness into the product.
To automate or not to automate?
Because of the scale of the product and the long-term support requirements for Microsoft Dynamics
AX, the development team made a heavy investment in automated regression tests during the Microsoft Dynamics AX 2012 development cycle. The unit tests were one part of this regression suite.
Additionally, many functional tests were automated. For these tests, the user interface of the product was the primary interaction point. The automated regression tests for features fell into one of three categories:
- Build verification tests (BVTs) – These tests verify the most basic functionality in the product and can be considered “smoke tests.” These tests were run as part of the gated check-in system for every SDE change. Tens of BVT test cases were executed thousands of times during the development cycle.
- Build acceptance tests (BATs) – These tests verify core functionality in each functional area of the product. As core features of the product were created, a new test case was created, or an existing test case was modified. These tests were run together with every nightly build. They also were frequently run before an SDE check-in to verify that no functional breaks resulted from the checkin. Hundreds of BAT test cases were executed for each run.
- Weekly tests – These tests made up the remainder of the automated test suite. As the name suggests, these tests were run one time per week for much of the release. As Microsoft Dynamics AX 2012 approached its release to customers, the tests were run much more frequently. Tens of thousands of weekly test cases were executed for each run. The team has several milestone and release goals for automation – for example:
- A targeted percentage of priority 1 test cases must be automated.
- A targeted percentage of all test cases must be automated.
- A targeted percentage of code coverage must be met for each area of the system.
Another category of regression testing is the verification of bug fixes. The workflow that is associated with a bug can be summarized as follows:
1. The bug can be created by anyone on the team and is mapped to a feature team in the bug tracking tool. The bug is in an Active state.
2. The bug is triaged by a cross-discipline team (PM, SDE, and SDET). The triage result is one of the following:
- Fix
- Don’t Fix – The bug is put into a Resolved state, and a resolution must be specified. The resolution options include By Design, Duplicate, External, Fixed, Not Repro, Postponed, and Won’t Fix.
- Vnext Candidate – The bug is put into a Resolved state, and a resolution must be specified.
The options are the same as the options for Don’t Fix.
3. If the triage result is Fix, it is assigned to an SDE, who makes the changes that are required to address the issue. Upon check-in to source code control, the bug is in a Resolved state, and the resolution is Fixed.
4. Regardless of the triage result, all bugs that are in the Resolved state are assigned to an SDET so that the resolution can be reviewed. If the resolution is Fixed, the SDET tests the fix to verify correctness. The SDET also acts as a customer advocate, and provides a “check and balance” in the system for other resolution types. For example, an SDET may “push back” on a bug that has a resolution of Postponed, by providing more details or a stronger argument for the triage team to consider.
5. If the SDET supports the resolution, the SDET puts the bug into a Closed state. The SDET gets input from the original bug author before closing the bug. As part of the closing process, the SDET reviews the existing test case collateral and decides whether test cases must be updated to ensure that the product does not regression in the future.
6. Any bugs that have a resolution of Postponed are reactivated in the next release.

Просматривая документ обратил внимание на книжку
How We Test Software at Microsoft
и методом поиска обнаружил что есть аналог, человек который уже свалил из Гугл в Микрософт
http://habrahabr.ru/post/210634/
и даже выпустил книжку
с похожим названием "How Google Tests Software" переведенную на русский "Как те­сти­ру­ют в Google" (которую можно даже поискать, например вместе с coollib)

Имхо занимательно.

PSИ чтобы два раза не ходить по Agile
http://msk15.agiledays.ru/

Тыкнув на понравившийся доклад в расписании можно просмотреть видео

И чуть позже будет

http://msk16.agiledays.ru/

[Удвой Покуров]

Как же хорошо, когда есть тот, кто оплатит подобные изыскания и аппробирование различных "методологий". Кстати, это знание не бывает лишним и может дать сильное преимущество на собеседовании, даже перед более сильным в профессиональном плане специалистом. Потому что обычный проект - это "давай-давай-давай", когда срочно надо реализовать заявленный или неучтенный функционал или допилить работающий под требования пользователей. А если время есть - то изучайте, и Scum / Adgile, и Pince 2, или COBIT, не говоря уже про PMBOK. Будет чем очаровать потенциального работодателя.

Цитата:

Сообщение от Удвой Покуров

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

Да в том то и дело что при всех этих срочно и прочем получается по факту не быстрее и не качественнее (как то видел как разработчиков заставляли работать по 14 часов: итоговый результат не сильно отличался от того что они бы сделали за 8 часов, хотя вид у них был еще тот). Может что то надо менять в консерватории?

[Kabardian]

axm2013, вы рассуждаете как теоретик. Вам дай лобзик, так вы кинетесь им баобабы срубать... А если кто-то попытается вас переубедить, то ответы будут в стиле "сам дурак, я уже десять баобабов срубил лобзиком и этот срублю, если вы не будете мешать".

Цитата:

Сообщение от Kabardian

axm2013, вы рассуждаете как теоретик.

Не совсем: agile-подобное видел. Это интереснее и по ощущениям эффективно.

Цитата:

Сообщение от Kabardian

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

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

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

Цитата:

Сообщение от Kabardian

А если кто-то попытается вас переубедить, то ответы будут в стиле "сам дурак, я уже десять баобабов срубил лобзиком и этот срублю, если вы не будете мешать".

Пока ровно наоборот: "мы тут десяток баобабов лобзиком срубили и дальше будем рубить, а чего добился ты лобзиком?"

Почитайте ради интереса How Google Tests Software (успел прочесть несколько страниц) где довольно интересно о качестве и прочем:

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

Анонсирована 2 часть по TDD
http://smart-talks.org/event/smart-talks-26/

украинских коллег

[George Nordic]

Так, стоять. axm2013, Вы правы. Коллеги - оппоненты axm2013, вы тоже правы
Дело в том, что вы разные вещи подразумеваете, вот из-за этого и произошло недопонимание.

Итак, начнем с азов. Что такое методология внедрения? Я привык считать, что Методология Внедрения - это набор методов, рекомендаций, шаблонов документов и практик ведения проектной деятельности с целью достижения целей проекта с оговоренным качеством, призванных снизить проектные риски, в том числе риски выхода за бюджетные и временные рамки проекта, и оптимизировать полезное использование (утилизацию) ресурсов.

Это, я считаю, отличное определение, если мы говорим о внедрении сложного проекта.

Но есть и другое определение методологи, например: Гибкая методология разработки

Цитата:

Гибкая методология разработки (англ. Agile software development, agile-методы) — серия подходов к разработке программного обеспечения, ориентированных на использование интерактивной разработки, динамическое формирование требований и обеспечение их реализации в результате постоянного взаимодействия внутри самоорганизующихся рабочих групп, состоящих из специалистов различного профиля[1]. Существует несколько методик, относящихся к классу гибких методологий разработки, в частности экстремальное программирование, DSDM, Scrum, FDD.
Применяется как эффективная практика организации труда небольших групп (которые делают однородную творческую работу) в объединении с их управлением комбинированым (либеральным и демократическим) методом. Большинство гибких методологий нацелены на минимизацию рисков путём сведения разработки к серии коротких циклов, называемых итерациями, которые обычно длятся две-три недели. Каждая итерация сама по себе выглядит как программный проект в миниатюре и включает все задачи, необходимые для выдачи мини-прироста по функциональности: планирование, анализ требований, проектирование, программирование, тестирование и документирование. Хотя отдельная итерация, как правило, недостаточна для выпуска новой версии продукта, подразумевается, что гибкий программный проект готов к выпуску в конце каждой итерации. По окончании каждой итерации команда выполняет переоценку приоритетов разработки.

То есть вы говорите про абсолютно разные вещи: axm2013 рассказывает, как классно модно написать модификацию, используя "новые методологии", а Вы думаете, что он говорит про весь проект!

Надеюсь, я распутал текущую путаницу

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

Цитата:

Сообщение от George Nordic

.. axm2013 рассказывает, как классно модно написать модификацию, используя "новые методологии", а Вы думаете, что он говорит про весь проект!
..

Все правильно думают так как имею ввиду именно проект либо его стадию (которая по мысли одного из консультантов при обсуждении по сути отдельный проект)
ЗЫ касательно гибкой методологии. Из общения в свое время с кликвьюшниками вынес представление что они ее как раз и используют в полной мере в силу крайней привязанности к клиенту и гибкости системы.

[George Nordic]

Цитата:

Сообщение от axm2013

ЗЫ касательно гибкой методологии. Из общения в свое время с кликвьюшниками вынес представление что они ее как раз и используют в полной мере в силу крайней привязанности к клиенту и гибкости системы.

Давайте сначала по второй части прокомментирую, а потом по первой спрошу

Да, зачастую внедрение Qlik идет именно по Agile - методологии, потому что в начале проекта нет целей: точные цели выстраиваются именно во время внедрения проекта. Т.е. на пилотном проекте клиент понимает, что "все плохо", и стартует проект по Qlik на небольшое кол-во пользователей, с целью определения ключевых показателей и метрик. В результате этого проекта:
- Выявляются ключевые показатели деятельности [по подразделениям, отделам, направлениям и отвественным]
- Детализируются метрики, по которым идет оценка деятельности бизнеса
- Формируются критерии к данным, их форматам, периодичности их обновления

При этом у нас на дату старта проекта нет ни формализованных целей, ни функционального объема проекта. Фактически, хотя это и проект, по аналогии с Dynamics AX это - всего лишь проведение предпроектного обследования, на основании которого мы сможем сформировать требования к проекту. С одним большим плюсом - результатами данного небольшого проекта уже можно вовсю пользоваться, решая те или иные управленческие задачи. Для небольших компаний или на уровне отделов данного проекта вполне достаточно. Но вышеописанные проекты обычно небольшие, при их проведении не разрабатывается необходимая проектная документация и инструкции. Да, внедрение свехбыстрое и результативное, но если мы говорим про большое проект или масштабирование результатов данного пилотного проекта, то тут уже применяется "классическая" методология, базируясь на потребностях, выявленных в ходе подобного внедрения. И там уже все "по-взрослому". Запустить проект на 100+ пользователях, не сформировав целей и требовании к результатам проекта не решится ни одна уважающая себя консалтиногвая компания, так как отсутствие подобных документов увеличивает проектные риски.

Цитата:

Сообщение от axm2013

Все правильно думают так как имею ввиду именно проект либо его стадию (которая по мысли одного из консультантов при обсуждении по сути отдельный проект)

Хм, я смотрел несколько методологий, и я не нашел требований к проектным документам, вот почему я считаю их не сильно применимым к большим проектам.

В основном все фигурируют следующим списком:
Задание на изменение / Техническое Задание
Акт приемки
Инструкция пользователя

Для большого проекта этого, увы, недостаточно. Особенно если мы не про BI-систему говорим, которая должна быть динамической и быстро меняться, а про ERP / учетную систему, которая должна работать "как положено", хотя бы на этапе сдачи в ОПЭ. Хотя, конечно, если она сможет динамически меняться в соотвествии с изменчивыми требованиями бизнеса - это огромный плюс. В этом мне DAX очень-очень нравится своей сбалансированностью.

Так что если Вы знаете более подробный список проектных документов до данным Rapid-методологиям, буду признателен.

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

[Vals]

Цитата:

Сообщение от George Nordic

В этом мне DAX очень-очень нравится своей сбалансированностью.

Знаешь, всё больше убеждаюсь, что сбалансированность закончилась на AX2009

Цитата:

Сообщение от George Nordic

Да, зачастую внедрение Qlik идет именно по Agile - методологии, потому что в начале проекта нет целей: точные цели выстраиваются именно во время внедрения проекта.

Это имхо конечно же не так. Какие то цели внедрения есть иначе продукт не купили.
А вот подробности уточняют порой уже в ходе работ с непосредственным клиентом

Цитата:

Сообщение от George Nordic

Хм, я смотрел несколько методологий, и я не нашел требований к проектным документам, вот почему я считаю их не сильно применимым к большим проектам.

Хм. Документы как раз есть (те же спринты к примеру содержат вполне себе лдостаточно информации). И проекты делающиеся по данной методолгоии масштабом бывают бОльше масштабом чем банальное внедрение DAX

http://habrahabr.ru/company/unicloud/blog/167059/

[George Nordic]

Цитата:

Сообщение от axm2013

Документы как раз есть (те же спринты к примеру содержат вполне себе лдостаточно информации). И проекты делающиеся по данной методолгоии масштабом бывают бОльше масштабом чем банальное внедрение DAX

Увы. Запустить простой процесс на 100 000 сотрудников - это не то же самое, что запустить ERP с кучей взаимосвязанных бизнес-процессов на 100 сотрудников. И тут очень сильные проектные риски. И самый сильный риск по результатам проекта это:
- "А почему этого нет? Вы же обещали!"
- "А где мы вам это обещали?"

Я пока не вижу, как это проблема (еще с десяток подобных) решаются в Rapid Implementation методологиях, какими проектными документами регламентируются эти и подобные вопросы.

В принципе, пока я сидел на внутреннем проекте, смысл использования огромного числа проектных документов мне был непонятен и казался вреден - "зачем тратить время на бумагомарание, когда можно в это время решать задачи и писать код"?? Смысл я постиг позже. Как-нибудь подготовлю рассказ о рисках и список проектных документов.

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

Цитата:

Сообщение от George Nordic

Увы. Запустить простой процесс на 100 000 сотрудников - это не то же самое, что запустить ERP с кучей взаимосвязанных бизнес-процессов на 100 сотрудников.

Вообще говоря запускают и не очень простые сервисы и больше чем на 100 000 человек. Систем разных и сложных очень много.

Цитата:

Сообщение от George Nordic

И тут очень сильные проектные риски. И самый сильный риск по результатам проекта это:
- "А почему этого нет? Вы же обещали!"
- "А где мы вам это обещали?"

Именно поэтому цели проекта таки есть.

Цитата:

Сообщение от George Nordic

Я пока не вижу, как это проблема (еще с десяток подобных) решаются в Rapid Implementation методологиях, какими проектными документами регламентируются эти и подобные вопросы.

Выписать общие идеи чего хотим не проблема +-.

Вопрос в том как этого достичь и при этом чтобы заказчик был доволен и не ушел для перехода на R3 к другой команде к примеру.

Для этого с ним надо общаться узнавать что он хочет и тп. Одна из методологий этого к примеру agile. Она ака устав в армии или ПДД написана кровью и must have у любого консультанта на уровне понимания.

[George Nordic]

Но, увы, она не отвечает на простой вопрос: "в каком документе фиксируются цели проекта".

Так же она не отвечает на вопросы: "в каком документе фиксируются критерии достижения целей проекта", "что явяется критерием достижения вехи проекта", "документы, необходимые при сдаче вехи проекта" и "процесс сдачи вехи проекта" (закрывающие документы). Поверьте, меня эти вопросы вообще не беспокоили - вехи какие-то. А потом я стал разрабатывать КП, и зачастую оплата Заказчиком Исполнителю происходит именно по вехам проекта

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

Однако, если Вы знаете ссылку на подобные документы для RIM - скиньте, я удивлюсь.

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

[Удвой Покуров]

Да какая нафиг документация может быть при экспресс-внедрении? На то оно и экспресс, что такими вещами не заморачиваются

Цитата:

Сообщение от George Nordic

Но, увы, она не отвечает на простой вопрос: "в каком документе фиксируются цели проекта".

В договоре с клиентом очевидно. Так же как внедряя клик вью вы и клиент очевидно знаете для чего внедряете.

Отмечу, что:
Методология — это система принципов, а также совокупность идей, понятий, методов, способов и средств, определяющих стиль разработки программного обеспечения. Не меньше но и не больше.

Документация процесса отдается на конкретной реализации методологии и в общем то это логично при желании сократить количество документации, создаваемой на проекте.

Пожелания же к документации смотрите в чем то типа такого
http://www.agilemodeling.com/essays/...Specifications

[George Nordic]

Цитата:

Сообщение от George Nordic

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

Цитата:

Сообщение от axm2013

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

Ну, в общем, у меня 100% попадние - мы немного по-разному относимся к определению базового понятия, отсюда и расхождения. Спасибо за ссылку, интересно.
В принципе, как я и говорил, мне всегда была ближе точка зрения "зачем все эти методологии, документацию всякую писать - это пустая трата времени - пахать надо". Однако она резко изменилась после работы в консалтинге, а не на внутреннем проекте

У каждого подхода есть минусы и плюсы. В Rapid Implementation Methodology (RIM) - это быстрое достижение целей проекта, и это очень ценно когда цели не ясны или могут меняться. Поэтому для BI-проектов они очень хорошо подходят.

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

Да, как и обещал, накидаю в отдельной теме список документов, вдруг кому пригодится.

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

[Bobkov]

Цитата:

Сообщение от George Nordic

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

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

В общих чертах, это выглядит так:

- Если сотрудник сидит на окладе или подрядчик на таймшитах, то они оба будут заинтересованы в том чтобы поменьше писать документов, а побольше удовлетворять пользователей.

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