Комментарии по теме

«Об одной те­хно­ло­гии работы с длинными текстами в SAP BW, BI-IP»
Илья Муковоз:
Более красивое решение: SAP BW - BusinessDocumentService (BDS).
«Рестарт SAP ERP и влияние на SAP BW»
Олег Точенюк:
Да я прочитал, я вообще интересуюсь, вы где-то такое видели с копированием продуктивных мандантов (классическое заблуждение, не знаю кого) и ... если видели, то добавить мандант нужно было на этапе...

База знаний

Вы можете подписаться на эту колонки этого автора, если авторизируетесь или зарегистрируетесь

Практики экстремального программирования при внедрении BW/BI проектов

27 марта 2014, 12:19

Метафора (Metaphor)

Метафора системы (system metaphor). Хорошая метафора системы означает простоту и единый стиль именования объектов системы. Единый стандарт именования объектов системы определяется при помощи метафоры или набора метафор, которые принимаются как требования, понятные любому новому члену команды.

Стандарты кодирования (Coding Standards)

Стандарты кодирования (coding conventions). Стандарты разработки нужны для обеспечения других практик: коллективного владения кодом, парного программирования. Без единого стандарта выполнять эти практики как минимум сложнее, а в реальности вообще невозможно: группа будет работать в режиме постоянной нехватки времени. Детальные стандарты не требуются, необходимо стандартизировать только важные вещи. Стандарты разработки складываются из требований по именованию объектов SAP BW/BI, требований по реализации типовых задач, требований по организации потоков данных внутри системы (примером такого стандарта на верхнем уровне может служить LSA архитектура). Если стандарт разработки будет отсутствовать, то процесс контроля качества реализации может оказаться бесконечно итерационным.

Игра в планирование (Planning Game )

Планирование процесса (planning game). Практика планирования основывается на итерационном подходе который определяет конечные задачи понятные разработчикам с четкими критериями их выполнения и оценками трудоемкости (оценку делает сам разработчик). Вся команда, раз в неделю, собирается вместе, принимается коллективное решение о том, какие свойства системы будут реализованы в ближайшей итерации (итерация может длиться от одной до нескольких недель). В практике ХР предполагается что программисты реализуют только те функции, которые необходимы для возможностей, выбранных на данной итерации Заказчиком. В реалиях внедрения BW/BI проектов взаимодействие и участие Заказчика на этапах разработки, как правило, минимально, но  возможность Заказчику самому определять приоритеты реализации функционала и задач проекта под чутким управлением ожиданий силами РП помогает делать реализацию более гибкой и востребованной.

Заказчик в команде разработки (On-site Customer)

Постоянное участие заказчика (on-site customer). Представитель заказчика в период работы над системой находится в команде разработчиков, причем требования к квалификации этого человека или команды весьма высоки. Если заказчик не согласился предоставить персонал уровня экспертов, то проект попадает в группу наиболее высокого риска. Необходимо постоянное наличие обратной связи с заказчиком (feed-back).

Парное программирование (Pair Programming)

Парное программирование (pair programming) — одна из самых известных XP-практик. Все консультанты должны работать в парах: один пишет код, настраивает BW-объекты, другой смотрит. Человеческий фактор в данном случае играет определяющую роль: пара или работает или нет, третьего не дано. Из этой практики вытекает потребность размещения проектной команды в одном месте. Наибольший эффект достигается и наглядно виден при обучении стажеров: скорость «вливания» нулевого сотрудника не превышает 3-х месяцев, после чего вчерашний стажер может самостоятельно выполнять задачи в системе.

Простота проектирования (Simple Design)

Простая архитектура (simple design). Любое свойство системы должно быть реализовано как можно проще. Разработчики в XP-команде работают под девизом: «Ничего лишнего!». Принимается первое наипростейшее работающее решение, реализуется необходимый уровень функциональности на данный момент. Тем самым экономится время. В каждый момент времени разрабатываемая система может пройти все тесты и поддерживает все взаимосвязи, определяемые разработчиками, не имеет дубликатов и содержит минимально возможное количество объектов системы. Это правило кратко можно выразить так: «Каждую мысль формулируй один и только один раз». Данный принцип требует наличия высокой самодисциплины и жестких стандартов разработки системы.

Тестирование (Testing)

Тестирование (testing). Одна их самых труднореализуемых практик при внедрении SAP BW/BI. Причина в банальной неготовности консультантов, методологов и РП перестроить мышление и начать думать наперед. Экстремальный подход заключается в том, что до разработки какого-либо функционала прорабатывается система тестирования ожидаемого результата, т.е. тесты прорабатываются до написания кода и создания объектов в системе. Каждый блок реализуемого функционала, каждый DSO, каждый Инфо-куб, трансформация и т.д. обязаны иметь Unit test — тест данного объекта; таким образом, в XP осуществляется regression testing (регрессионное тестирование, «неухудшение качества» при добавлении или изменении функциональности). Заранее подготовленные и проработанные тесты позволяют принять верное решение в вопросе, во что обойдется сдача системы с заранее известным дефектом, и позволяет сравнить это с ценой задержки на его устранение.

40-часовая рабочая неделя (40-hour Work Week)

40-часовая рабочая неделя. Консультант не должен работать более 8 часов в день. Необходимость сверхурочной работы (overtime) — это четкий индикатор проблемы на данном конкретном направлении; к тому же Заказчик не платит за сверхурочную работу в XP. Даже отдельные случаи сверхурочных работ, повторяющиеся слишком часто, служат признаком серьезных проблем, которые требуют безотлагательного решения. Поиск причин сверхурочной работы и их скорейшее устранение  — одно из основных правил.

Повторное кодирование (Refactoring)

Переработка системы (refactoring). Архитектура системы постоянно эволюционирует. Текущий проект трансформируется, при этом гарантируется правильное выполнение всех тестов. Экстремальное программирование исходит из того, что переделать часть системы всегда можно, причем без особых затрат. Рефакторинг — это оптимизация существующей реализации в сторону упрощения. При реализации каждого нового свойства системы консультант должен подумать над тем, можно ли упростить существующую реализацию, упростить код и как это поможет реализовать новое свойство или требование к системе. Рефакторинг не должен совмещаться с дизайном.

 

Следующие практики слабо применимы на проектах SAP BW/BI т.к. частично уже покрываются функционалом SAP и не требуют отдельного рассмотрения:

  • Коллективное владение кодом (collective code ownership).
  • Небольшие релизы (Small Release)
  • Постоянная интеграция (Continuous Integration)

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

Функциональная область : Бизнес аналитика / BI, Управление проектами / Project management

Ключевые слова : BI/BW, SAP NetWeaver BW

Ролевое назначение : Руководитель / Manager

Комментарии:

ВЛАДИСЛАВ МИЛЯЕВ (Рейтинг: 397) 15:45, 05 сентября 2014

Илья, добрый день!
Подскажите, какими средствами можно тестировать правила формул в трансформациях BW, а также подпрограммы завершения?
17:41, 22 сентября 2014

Илья Муковоз (Рейтинг: 5422)

Конечными тестами: т.е. сначала делается расчет "на бумаге" согласно которому при прогоне теста должен получаться известный заранее результат. Если результат в какой-то момент становится другим, значит в систему внесены изменения повлиявшие на логику ее работы. Применительно к BW, я бы использовал Q систему для этих целей - регулярный прогон небольшого шаблонного набора данных до конечного отчета с эталонными значениями для сравнения результата.