CC BY
64
УДК 681.321.3, 339.138 Петров Б.М.
ОАО «МНИИ «Агат»
УПРАВЛЕНИЕ ИНТЕРНЕТ - ПРОЕКТАМИ ПРИ СОЗДАНИИ ИНФОРМАЦИОННОГО ПОРТАЛА ДИСТАНЦИОННОГО ОБУЧЕНИЯ
НА КУРСАХ ПО НАДЕЖНОСТИ
Работа посвящена проблеме разработки и управлению интернет-проектами при создании информационного портала дистанционного обучения на курсах повышения квалификации специалистов по надежности и живучести технических и программных средств. Особенностью информационного портала дистанционного обучения является новое распределение интернет - ресурсов с использованием новых ролевых специалистов: менеджеров по интернет - проектам, руководителей интернет - проектов, менеджеров портала для повышения эффективности управления интернет-проектами.
Рассмотрим основные виды интернет-проектов, которые целесообразно использовать при создании информационного портала дистанционного обучения. Классификация интернет-проектов, которые целесообразно использовать при создании информационного портала дистанционного обучения на курсах повышения квалификации специалистов: сайт - визитка, промо - сайт, интернет - представительство, корпоративный портал, новостной портал, интернет - сервис, социальные сети, блоги, форумы, в которых должны быть бизнес-модели (способы монетизации) интернет-проектов, прямые продажи через портал (интернет - магазин), продажа рекламы на портале (баннеры, директ - реклама, и др.) . Онлайн -сервисы - предоставление виртуальных услуг (государственные, коммерческие и др.). Привлечение клиентов (бэк-офис сайты).
Рассмотрим особенности работы ролевых специалистов, которых целесообразно использовать «в команде» при создании информационного портала дистанционного обучения на курсах повышения квалификации специалистов. Эти особенности требуют от руководителей интернет-проектов разработки новых основных бизнес - моделей, методологии, рабочих процессов в Рунете.
В обязанности руководителя интернет-проекта обычно входит: решение комплекса задач по созданию, поддержке, продвижению и развитию проекта во Всемирной сети, разработка стратегии развития, концепции и структуры портала интернет - проекта, подготовка контента, оптимизация и поисковое продвижение портала интернет-проекта, анализ статистики посещаемости.
Руководитель интернет-проекта осуществляет постановку и контроль выполнения технических заданий, координирует действия команды специалистов, следит за соблюдением бюджета проекта, в его компетенцию также входит планирование, проведение и изучение результатов рекламных и маркетинговых кампаний.
Проектный менеджер в софтверных компаниях - это человек, управляющий всеми технологическими процессами производства, интернет - ресурсами и поставки программного обеспечения для решения прикладных задач в рамках интернет - проекта.
Менеджеры портала для повышения эффективности управления интернет - проектами должны быть уверенными пользователями ПК, иметь базовые знания по HTML, CSS, XML, JS, AJAX, Flash технологиям, иметь знания основ интернет-маркетинга, интернет-рекламы, иметь знания и опыт участия в создании, развитии или поддержке интернет - проектов, иметь опыт работы администратором портала интернет -проекта, seo-оптимизатором, интернет-маркетологом, менеджером интернет - проекта (scrum-master, project manager, product manager»). В его функции входит составление полного технического задания интернет - проекта, в котором проектное управление - обязательный элемент команды разработки.
Типичные функциональные обязанности менеджера портала: решение комплекса задач по созданию,
поддержке, продвижению и развитию интернет - проекта, разработка стратегии развития интернет -проекта, разработка концепции и структуры портала, постановка и контроль выполнения технических заданий, подготовка контента для информационного и графического наполнения портала, оптимизация и поисковое продвижение портала, анализ статистики посещаемости портала, планирование, проведение и анализ результатов рекламных и маркетинговых кампаний, внедрение новых сервисов и проектов, планирование и контроль сроков исполнения и бюджета интернет-проекта, координация действий команды специалистов.
Стэйкхолдеры - все лица (физические или юридические), имеющие интерес в данном интернет - проекте, работа со стэйкхолдерами - важнейшая часть проекта.
Наша задача оценить и обеспечить эффективность интернет-проекта и разработать план мероприятий для обеспечения выполнения заданных функций, а главное повысить производительность выполняемых работ при реализации идей проекта и сопровождение портала интернет-проекта.
В перспективе облачные технологии интернет - проектов все чаще используются при создании информационных порталов дистанционного обучения на курсах повышения квалификации специалистов по всему миру, так в США дистанционное обучение используется более чем в 60%, а в Западной Европе более чем в 40 %, а в РФ менее 15%, и этот разрыв должен быть уменьшен, чтобы значительно увеличить производительность умственного труда преподавателей РФ.
Вероятность успешной разработки и управление интернет-проектами Руип при создании информационного портала дистанционного обучения на курсах повышения квалификации специалистов по надежности технических и программных средств многоядерных нанопроцессорных систем определяется Руип = Рпсп(В) х Рмс(С), где Рпсп(В) - условная вероятность безотказной работы программных средств портала, Рмс(С) -безусловная вероятность успешной работы при создании информационного портала дистанционного обучения маркетинговой стратегии.
Интенсивность безуспешной разработки и управление интернет-проектами Хуип (t) из-за ошибок, представляющих облачные технологии определяется по формуле:
Х.УИП (t) = Xnc(t) Х КТПІ Х КПКІ Х KynSP Х КСЛ Х КЯП + X.MC(t) х квд, ну, лр, ок х КОЦ, ПО, КП, ЦЗ х кпк, цр х КОС, КС
х Кнп, пд, ркХ Кнр, пс, ир, воХ Ксс,
где Xnc(t) - базовая интенсивность ошибок программных средств портала;
Хмс (t) - базовая интенсивность несоответствий маркетинговой стратегии организаций, представляющих облачные технологии;
Ктпі - коэффициент, учитывающий влияние i-й технологии программирования на процесс разработки и отладки ПС;
Кпкі - коэффициент, учитывающий влияние наличия проверочного кода на i-м уровне (внутри метода, библиотеки классов, консольного приложения) на процесс разработки и отладки ПС;
Kynsp - коэффициент, учитывающий влияние управления большим множеством узлов SharePoint на серверной и клиентской части, с учетом особенностей различных шаблонов, списков, библиотек для хранения информации, электронных досок обсуждений, вики-узлов и блогов в ПС;
Ксл - коэффициент, учитывающий влияние сложности ПС, разрабатываемого для клиентских, серверных приложений на процесс разработки, отладки и версии обновления ПС;
Кяп - коэффициент, учитывающий различие в сложности проектирования ПС, выполненных на языках программирования (Кяп(С)=1,0; Кяп (С++)=0,7; Кяп (С#)=0,3); Кяп(^#)=0,1; Кяп (Ора )=0,04), где Ора - облачный язык программирования, это опенсорная платформа для быстрого создания защищенных и масштабируемых веб- и облачных приложений и сервисов, который включает все средства для создания клиентской части и серверной логики со средой времени выполнения и взаимодействия с базами данных;
Квд, ну, лр, ок - коэффициент, учитывающий анализ маркетинговой ситуации на рынке работы организации, выбор вида деятельности (ВД), набор и сложность основных видов ИТ-услуг (НУ) для завоевания лидерства на рынке (ЛР), разработку маркетинговой стратегии по конкуренции в основной категории (ОК) услуг;
Коц, по, кп, цз - коэффициент, учитывающий определение целей (ОЦ) и задач маркетинга, возможностей организации, выбор партнеров организации (ПО), определение основного ключевого конкурентного преимущества (КП) и эффективное информирование о нем, разработку итоговой ценностной значимости (ЦЗ) для удовлетворения потребностей клиентов облачных ИТ-услуг;
Кпк, цр - коэффициент, учитывающий анализ шкалы предпочтений клиентов (ПК) ИТ-услуг и динамику изменений потребностей во времени, определение целевого рынка (ЦР) клиентов, доли рынка и его перспектив в развитии ИТ-услуг;
Кос, кс - коэффициент, учитывающий эффективность обратной связи (ОС) от клиентов, разработку коммуникационной стратегии (КС) взаимоотношений организации с клиентами целевого рынка;
Кнп, пд, рк - коэффициент, учитывающий анализ стратегии ценообразования и нормы прибыльности (НП), анализ реальных потоков поступления доходов (ПД) в организацию с учетом рекламной компании (РК) организации и оценки ее эффективности;
Кнр, пс, ир, во - коэффициент, учитывающий - необходимые ресурсы (НР) для успешного функционирования при: выходе на рынок, создания, представления клиентам ценностных предложений, поддержки связи с потребительскими сегментами, получения прибыли. Оценка ресурсов м.б.: по чистой приведенной стоимости (ПС), по индексу рентабельности (ИР), по учетному коэффициенту и времени окупаемости (ВО).
Иерархия коэффициентов влияния особенностей стратегии маркетинга организации, сервисы которые обеспечивают высокоэкономичную информационную облачную инфраструктуру, проводится с учетом:
- доступности сервисов через Web-браузер любой фирмы с использованием открытых стандартов или через специальный интерфейс прикладного программирования для доступа к Web-сервисам;
- доступности сервисов облачной инфраструктуры по требованию, т. е. сервисы представляются только тогда, когда вам это требуется;
- использования высокоэкономичной информационной облачной инфраструктуры, которая не требует никаких дополнительных затрат в инфраструктуру или дополнительной настройки, т. е. дополнительных капиталовложений;
- использования высокоэкономичной облачной инфраструктуры, которая оплачивает только те сервисы, с которыми работают клиенты;
- использования высокоэкономичной облачной инфраструктуры, которая оплачивает только то фактическое время, в течение которого эта облачная инфраструктура используется клиентами;
- использования высокоэкономичной облачной инфраструктуры, при которой нет необходимости строить сеть и покупать сервисы и получать какие-то дополнительные технические знания.
УДК 681.321.3, 339.138 Петров Б.М.
ОАО «МНИИ «Агат»
ИСПОЛЬЗОВАНИЕ ДЛЯ ДИСТАНЦИОННОГО ОБУЧЕНИЯ НА КУРСАХ ПОВЫШЕНИЯ КВАЛИФИКАЦИИ ТЕХНОЛОГИЙ «GOTOWEBINAR», «CLICKMEETING» И «GOTOMEETING»
Работа посвящена проблеме использования для краткосрочного дистанционного открытого обучения (ДОО) на курсах повышения квалификации специалистов по надежности и живучести технических и программных средств технологий «GoToWebinar» (вебинаров), «ClickMeeting» и «GoToMeeting», которые позволяют проводить успешное управление информационного портала, а главное повысить производительность выполняемых работ при реализации идей проекта и сопровождение портала интернет-проекта.
Рассмотрим особенности краткосрочного ДОО на курсах повышения квалификации специалистов, которые необходимо учитывать при планировании рабочих процессов, так плюсами ДОО являются:
- обучение в ДОО в индивидуальном темпе по скорости изучения материалов устанавливается самим студентом в зависимости от его личных обстоятельств и желаний, но должны быть получены средние характеристики рабочих процессов;
- свобода и гибкость обучения, так как студент может выбрать любой курс, а также самостоятельно рассчитать время и продолжительность занятий с учетом наших рекомендаций;
- доступность обучения для любого слушателя независимо от его географического и временного положения ;
- при ДОО слушатель сразу получает комплект учебных материалов в который входят: тексты лек-
ций, задачи, практикумы, задания для самостоятельной работы и тесты для контроля процесса обучения ;
- скорость общения - это эффективная обратная связь между преподавателем и слушателем, которая всегда должна контролироваться;
- технологичность образовательного процесса, которая должна быть обеспечена использованием новейших достижений информационных и телекоммуникационных технологий таких как: «GoToWebinar»,
«ClickMeeting» и «GoToMeeting»;
- социальное равноправие это независимость ДОО от места проживания, состояния здоровья, национальности и материального состояния слушателя, но должна быть разработана эффективная система скидок;
- ДОО чаще используется для получения дополнительного образования, когда есть уже основное образование, есть основа теории и практические навыки и шкала-лестница достижения типовых целей;
- творческое самовыражение в процессе усвоения знаний с учетом синхронного и асинхронного обучения ;
- постоянное обновление учебных материалов в реальном времени.
Есть минусы ДОО:
- отсутствие реального людского общения между преподавателем и студентом и нет эмоционального окрашивания обсуждаемых знаний;
- для ДОО необходима регулярная жесткая самодисциплина, мотивация, самосознательность студента, которая не всегда присутствует;
- нужна хорошая техническая оснащенность у студента, необходимый доступ к Интернету;
- отсутствие практических занятий и общения для закрепления теории;
- отсутствие регулярного контроля со стороны над обучающимися;
- должна быть жесткая отчетность, которая обеспечивает полное прохождение материала;
- обучающие электронные программы не всегда хорошо разработаны;
- в ДОО обучение ведется в письменной форме и мало в устной.
Рассмотрим особенности сопровождение информационного портала интернет-проекта для краткосрочного дистанционного открытого обучения на курсах повышения квалификации специалистов вначале для охвата русскоговорящей аудитории СНГ, а после и англо-франкоговорящей.
Технологии «GoToWebinar», «ClickMeeting» и «GoToMeeting» позволяют проводить обучение в реальном масштабе времени при обязательном (или необязательном) присутствии преподавателя и при работе студентов по записанным лекциям и практическим работам с контролем проведения занятий и проверкой записи курса лекций.
Одной из проблемой при проведении занятий является выбор времени проведения занятий из-за проблем со связью, с выбором провайдера есть проблемы даже при проведении занятий в подмосковье.
Перед началом проведения занятий представителем центра (информационного портала) пересылается слушателям логин и пароль для подключения к оборудованию, а также должна быть проведена проверка всех подключений для смешанных групп (очных и заочных) и договоренность о взаимодействии со слушателями при параллельном использовании технологий «GoToWebinar», «ClickMeeting» и «GoToMeeting» в зависимости от соотношения очных и заочных слушателей.
При вебинаре проводится совместная работа над документами в единой среде по модели «звезда», чтобы слушатели могли говорить при «мозговом штурме» не перебивая друг друга, или по модели «колесо» по которой слушатель общается каждый с каждым, т. е. коммутация видеопотоков в специализированном формате через кодеки. Регулярный контроль заданий, лабораторных и домашних работ.
Целесообразно иметь в аудитории несколько переносных микрофонов и колонок: у преподавателя и в разных концах аудитории для осуществления обратной связи между слушателями «GoToWebinar», «ClickMeeting» и «GoToMeeting». И должна быть, в отличие от вузовских занятий, передача видео самого преподавателя на большом экране.
После проведения курса обязательный сбор фитбэка (высказываний и обсуждений мнений слушателей о курсе с записью всех замечаний и рекомендаций). Особенно должна быть обсуждена процедура повторения курса и поддержка после окончанию курса, когда слушатели пишут в чате преподавателю вопросы, а преподаватель отвечает на заданные вопросы.
Следует отметить, что использование технологий «GoToWebinar», «ClickMeeting» и «GoToMeeting», для ДОО предполагает создание информационного портала, желательно на SherePoint с полным набором функций в шаблоне: вертикальной и горизонтальной навигацией, поиском, подкачкой и т.п., этот портал должен быть настроен (иметь сервисы) на технологии «GoToWebinar», «ClickMeeting» и «GoToMeeting».
Кроме того, эти технологии должны иметь следующие технические средства: он-лайн приложения,
специализированные порталы и общедоступные средства «peer-2-peer» коммутации (MS live messenger), в зависимости от используемой аудитории, а на занятиях нужно демонстрировать виртуальный рабочие столы, которые тормозят связь.
Конечно, хорошо иметь два вебинара: основной вебинар на который получена ссылка, второй вебинар для иллюстраций, а видео-камеры сильно отвлекает слушателей, хотя видео, который показывает преподавателя, хорошо обеспечивает эффект присутствия, повышает внимательность слушателя, но видео сильно перегружает, тормозит связь и сильно повышает требования к каналу.
Желательно использовать электронные интерактивные доски с хорошим разрешением, которые пока стоят очень дорого, но они позволяют все, что пишется транслировать сразу на экран, а там, где использовать доску не удобно, когда преподаватель загораживает доску, желательно использовать планшетники, но у планшетников есть проблемы с позиционированием перьев и это надо учитывать.
УДК 681.321.3, 339.138 Петров М.Б.
ОАО «МНИИ «Агат»
РАЗРАБОТКА ЭКСПЕРТНОЙ СИСТЕМЫ АНАЛИЗА ЖИВУЧЕСТИ СТЕНДА МОДЕЛИРОВАНИЯ НАНОПРОЦЕССОРНЫХ СИСТЕМ С УЧЕТОМ МОДЕЛЕЙ УПРАВЛЕНИЯ ИНТЕРНЕТ-ПРОЕКТАМИ
В работе рассматриваются основные особенности экспертной системы анализа живучести стенда моделирования нанопроцессорных систем (ЭСАЖСМНПС) с учетом различных моделей управления интернетпроектами. Известно, что отказы технических средств и несоответствия программных средств при проверке на функционирование и исследовании нанопроцессорных систем (НПС) могут привести к большим ошибкам и часто приводят к большим материальным потерям в эксплуатации. Поэтому возникла необходимость рассмотреть различные модели управления интернет-проектами при внедрении нового поколения стендов моделировании нанопроцессорных систем (СМ НПС) с учетом структуры, состава и новых элементов электрооборудования стенда в процессе эксплуатации.
Для нового поколения СМ НПС целесообразно рассмотреть основные международные стандарты:
- ISO (International Organization for Standardization - ISO 21500), USA - International;
- ANSI PMI (Project management Institute - PMBOK), USA;
- P2M (стандарт проектного управления), Japan;
- PRINCE2 (правительственный стандарт управления в Великобритании).
И основные методологии:
- Project+ (CompTIA), USA - International;
- MSF (Microsoft Solutions Framework), USA;
- SAP Buisiness 1 Implementing (SAP B1), USA;
- Waterfall, Agile-SCRUM, XP, RUP и др.
В соответствии с ISO 21500 (2012 г.) СМ НПС нового поколения является уникальным набором про-
цессов, состоящих из скоординированных и управляемых задач с начальной и конечной датами, предпринятых для проверки на функционирование и исследование НПС с целью достижения требований по надежности, заданных в техническом задании с одной стороны и повышения производительности выполняемых работ, с другой стороны.
Применение стандарта управление интернет - проектами по ISO управление проектами (project management) — в соответствии с определением международного стандарта ISO 21500, принятого правительствами США, странами Евросоюза и правительством России в сентябре 2012 года - применение методов, инструментов, техник и компетенций к СМ НПС нового поколения, позволяет совершенствовать процессы разработки и сопровождения на всех этапах жизненного цикла.
Применение стандарта управление интернет - проектами по ANSI PMI - в соответствии с определением национального стандарта ANSI PMBOK 4 - область деятельности, в ходе которой определяются и достигаются четкие цели проекта анализа СМ НПС нового поколения при балансировании между объемом работ, ресурсами (такими как деньги, материалы, энергия, временя функционирования, надежность и трудоемкость работ).
Следующим стандартом по управлению интернет - проектами является PRINCE2 - это Британский правительственный стандарт управления проектами, который полностью базируется на PMBOK и требует знания PMBOK, это как бы надстройка над стандартом PMI, описывающая только часть рабочих процессов управления СМ НПС нового поколения.
Рассмотрим основные модели (структуры) управления интернет - проектами СМ НПС: каскадная мо-
дель (waterfall - водопад), итеративная модель (IBM RUP - Rational Unified Process), спиральная модель SAP Business One (B1) Implementation), гибкая модель (agile - SCRUM - XP - KANBAN), Project+ CompTIA, применение которых зависит от сложности процессов функционирования СМ НПС нового поколения.
Если процессы функционирования СМ НПС не сложные и количество групп разработчиков небольшое, то для анализа и управления интернет - проектами можно не строить процесс, но риски возрастают. Если процессы функционирования СМ НПС сложные и количество групп разработчиков > 2-3, то для анализа и управления проектами необходимо строить процессы.
Когда проект объемный, планирование сложное с развитием веб -системы, то необходимо строить сложные рабочие процессы и считать вероятности успеха, так как увеличиваются риски, а сложность развивается по экспоненте. При этом разобраться и переписать по новой программную часть вебсистемы проекта очень сложно, а вносить изменения в нее невозможно, так как не все помнят, как все работает (даже заказчик), любое изменение рождает много новых ошибок, а тестировщик не знает, как все проверить. Любое изменение требует больших затрат на пересогласование, перепроектирование...
При построении процессов необходимо использовать требования, заданные в техническом задании к проекту, сформировать бриф и по функциональным требованиям выбирать методологию «процессного» управления, создать процесс, организовать анализ артефактов проекта и оценить риски. А главное при этом увеличиваются стоимость проекта и возрастают (затягиваются) сроки выполнения проекта.
1. Рассмотрим каскадную модель «waterfall - водопад» SAP Business One (B1) Implementation и ее организационные моменты в применении к СМ НПС нового поколения.
На первом этапе проводится инициация разработки проекта СМ НПС нового поколения. Поставка и установка внедряемого софта.
На втором этапе проводится анализ, проектирование основных задач и описание бизнес-процессов с определением бизнес-требований. Разработка и согласование технического задания. Согласование плана проекта.
На третьем этапе проводится реализация проекта. Установка систем и программных продуктов, настройка их в соответствии с техническим заданием. Программирование необходимого функционала. Тестирование системы. Определение планов обучения пользователей и запуска системы.
На четвертом этапе проводится завершение проекта. Обучение ключевых пользователей и системного администратора. Определение готовности системы к запуску в продуктивную эксплуатацию.
На пятом этапе проводится ввод в эксплуатацию. Внедрение программного решения и его запуск в продуктивную эксплуатацию. Ввод в эксплуатацию и перевода проекта в режим сопровождения. Проведение анализа результатов проекта и рассмотрение вариантов оптимизации.
2. Рассмотрим итеративная модель (IBM RUP - Rational Unified Process) и ее организационные моменты в применении к СМ НПС нового поколения.
Для итеративных процессов повторяем все фазы, но на каждом этапе улучшается обратная связь с заказчиком - и на каждом этапе (итерации) принимаются и решаются все самые приоритетные задачи и оцениваются риски, а затраты на проект и постоянное тестирование распределяются равномерно, а не в конце проекта. При эффективной загрузки команды, модель эффективно работает на сложных, больших проектах. Изменения требований - можно проводить RUP. При этом много ролей, которые сложно настроить, внедрить, для поддерки процесса.
3. Рассмотрим гибкую модель (agile - SCRUM - XP - KANBAN) и ее организационные моменты в применении к СМ НПС нового поколения.
Процессы и итерации управления в RUP итеративный Agile манифест - документ, зафиксировавший основные принципы управления проектами разработки ПО, отличные от традиционных (водопад, итеративный и др.) Agile - гибкий подход к процессам управления, то есть он не имеет жёсткой структуры, он основан на наборе философских принципов. В этом направлении было сформировано множество методов и подходов к разработке ПО. Сам манифест, когда люди и взаимодействие важнее (превыше) процессов и инструментов, а работающий продукт важнее исчерпывающей документации. Сотрудничество с заказчиком важнее согласования условий контракта, а готовность к изменениям - важнее следования первоначальному плану. То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева. Agile - очень гибкий подход в жизненном цикле применительно к СМ НПС нового поколения .
УДК 681.321.3, 339.138 Петров М.Б.
ОАО «МНИИ «Агат»
ПРИМЕНЕНИЕ КАСКАДНОЙ МОДЕЛЬ «WATERFALL» SAP BUSINESS ONE ПРИ УПРАВЛЕНИИ ЖИВУЧЕСТЬЮ СТЕНДА МОДЕЛИРОВАНИЯ НАНОПРОЦЕССОРНЫХ СИСТЕМ
В работе рассматриваются основные особенности экспертной системы анализа живучести стенда моделирования нанопроцессорных систем (ЭСАЖСМНПС) при применении каскадной модели «waterfall - водопад» SAP Business One (B1) Implementation для управления интернет-проектами.
В структуре команды разработки и сопровождения стенда моделирования нанопроцессорных систем (СМ НПС) должны быть основные роли: Stakeholders, Product owner, Team member, Team lead, Architecture owner, Agile mentor (coach), а идеология непрерывного тестирования Agile команды разработчиков должна обязательно использовать две основные практики тестирования: TDD - test driven development (разработка, управляемая тестированием), которая означает, что перед тем как писать код, разработчик СМ НПС пишет маленький тест, который подтвердит, что спрограммировано то, что нужно.
Automated unit test - маленькие тесты, которые запускаются сразу после написания любой функции СМ НПС, блока кода и др. в автоматическом режиме Continuous Integration and Deployment CI и CD -
практика непрерывной интеграции написанного кода в рабочий проект СМ НПС в целях тестирования с последующим непрерывным внедрением.
При построении рабочего процесса СМ НПС реализация и представление проекта на Iteration Review должна быть проведена демонстрация того, что команда сделала за контрольный период и сбор отзывов о результате работы. Iteration retrospective - встреча и обсуждение, на которой проводится анализ всех итерации по СМ НПС.
Основные Agile методологии (подходы): SCRUM - XP - Kanban - Crystal - Dynamic Systems Development Method (DSDM) - Feature-Driven Development (FDD). Японцы отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля (принцип построения команды в регби), обычно систематически производят лучшие результаты, и объяснили это как «подход регби». "Scrum" - схватка в регби. Скрам (Scrum) — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные и небольшие по времени итерации, предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет.
Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования СМ НПС и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки СМ НПС предсказуемость и гибкость.
Так Backlog (бэклог) применяется вместо многостраничного много раз изменяемого технического задания. Backlog - документ, который содержит список всех требований к проекту СМ НПС (видение заказчика проекта, список того, что должно быть реализовано в СМ НПС) . В бэклог сводят не мелкие задачи (нарисовать кнопочку), а бизнес-задачи (реализовать проверку НПС в заданном режиме функционирования с заданной эффективностью и надежностью). Agile - спринты, это спринты вместо этапов разработки, где спринт - короткий этап разработки, закрывающий какую-то часть проекта. Все функции СМ НПС разбиваются на задачи, задачи имеют оценки и приоритеты и времена выполнения по утвержденному руководством план-графику.
SCRUM - фишки Agile board, где скрам - доска в Яндексе. Роль - Product owner это главная обязанность - управлять списком требований - Product Backlog и расставлять приоритеты «Владелец» СМ НПС - менеджер проекта управляет "хотелками" клиента, пользователей, других менеджеров и защищает команду от дерганья со стороны «кур» из известного рассказа о ролях. Product backlog приоритизи-рованный список требований роль - Scrum master «судья», арбитр устраняет препятствия перед командой и следит, чтобы все следовали правилам Scrum. Управляет списком требований к СМ НПС, приоритетами - Product backlog. SCRUM роль - Development Team команда кроссфункциональна, которая предполагается тесное сотрудничество для реализации СМ НПС, при этом конкретных ответственных - нет, есть «команда».
Рассмотрим основные роли, принимающие участие в реализации проекта СМ НПС и основные этапы. Роль - Team member, такой роли на самом деле нет, это «безликий» участник проектной команды. Sprint planning meeting участники выбирают и оценивают задачи на Sprint для СМ НПС при этом присутствуют все члены команды разработчиков СМ НПС. Sprint planning meeting разработчики оценивают задачи СМ НПС, играя в Planning Pocker. Sprint backlog Sprint board это списки задач на Sprint.
На начальном этапе Daily standup meeting утром или вечером в течение не более 15 минут каждый член команды докладывает: что было сделано вчера и с каким результатом (плюсы и минусы), что будет сделано сегодня с оценкой вероятности успеха и оценкой эффективности работы, с какими проблемами он столкнулся и какие есть варианты решения этой проблемы. Проводится интенсивное обсуждение данной проблемы, предлагаются различные варианты ее решения, выбирается наиболее оптимальное решение этой проблемы.
На втором этапе Burndown chart Definition of Done (DoD) проводится анализ результатов, это условие готовности задачи - очень тонкий момент, как задача попадает в «готовые решения», при этом предполагается участие всех тестировщиков, проводящих тестирование каждого модуля и представителей заказчиков ответственность за разработку СМ НПС.
На третьем этапе Sprint review meeting приводится демонстрация результатов спринта представителю заказчика ответственного за разработку СМ НПС (клиенту), обсуждается Sprint retrospective, что вызвало проблемы в спринте что можно сделать лучше. При этом Velocity скорость работы команды измеряется для каждого завершенного спринта.
На четвертом этапе проводится прогноз сроков реализации СМ НПС, обсуждается оптимизация рабочих процессов СМ НПС, оценивается эффективность и производительность рабочих процессов СМ НПС.
В результате проведенных исследований принято решение о применении каскадной модели «waterfall - водопад» SAP Business One (B1) Implementation для управления интернет-проектами при разработке СМ НПС и использовать технологию SCRUM из-за ее прозрачности и ориентации на успешный конечный результат.
