ПОЗНАВАТЕЛЬНОЕ

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

Отёска стен и прирубка косяков - Когда на доме не достаёт окон и дверей, красивое высокое крыльцо ещё только в воображении, приходится подниматься с улицы в дом по трапу.

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

Принципы Agile от создателей методологии

1 2 34

1. Наивысшим приоритетом для нас является удовлетворение потребностей заказчика, благодаря регулярной и ранней поставке ценного программного обеспечения.

2. Изменение требований приветствуется, даже на поздних стадиях разработки.

3. Agile-процессы позволяют использовать изменения для обеспечения заказчику конкурентного преимущества.

4. Работающий продукт следует выпускать как можно чаще, с периодичностью от пары недель до пары месяцев.

5. На протяжении всего проекта разработчики и представители бизнеса должны ежедневно работать вместе.

6. Над проектом должны работать мотивированные профессионалы. Чтобы работа была сделана, создайте условия, обеспечьте поддержку и полностью доверьтесь им.

7. Непосредственное общение является наиболее практичным и эффективным способом обмена информацией как с самой командой, так и внутри команды.

8. Работающий продукт — основной показатель прогресса.

9. Инвесторы, разработчики и пользователи должны иметь возможность поддерживать постоянный ритм бесконечно. Agile помогает наладить такой устойчивый процесс разработки.

10. Постоянное внимание к техническому совершенству и качеству проектирования повышает гибкость проекта.

11. Простота — искусство минимизации лишней работы — крайне необходима.

12. Самые лучшие требования, архитектурные и технические решения рождаются у самоорганизующихся команд.

13. Команда должна систематически анализировать возможные способы улучшения эффективности и соответственно корректировать стиль своей работы. [4]

В компании используются три разновидности гибки методологий: Scrum, Kanban, AUP.

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

В классическом Scrum существует 3 базовых роли:

Product owner является связующим звеном между командой разработки и заказчиком. Задача PO — максимальное увеличение ценности разрабатываемого продукта и работы команды. Одним из основных инструментов PO является Product Backlog. Product Backlog содержит необходимые для выполнения рабочие задачи, отсортированные в порядке приоритета (срочности).

Scrum master является «служащим лидером». Задача Scrum Master — помочь команде максимизировать ее эффективность посредством устранения препятствий, помощи, обучения и мотивации команды, помощи PO.

Команда разработки (Development team, DT) состоит из специалистов, производящих непосредственную работу над производимым продуктом. DT должны обладать следующими качествами и характеристиками:

® Быть самоорганизующейся. Никто не может указывать команде каким преобразовать Product Backlog в работающий продукт;

® Быть многофункциональной, обладать всеми необходимыми навыками для выпуска работающего продукта;

® За выполняемую работу отвечает вся команда, а не индивидуальные члены команды;

Рекомендуемый размер команды — 7 (плюс-минус 2) человека. Согласно идеологам Scrum, команды большего размера требуют слишком больших ресурсов на коммуникации, в то время как команды меньшего размера повышают риски (за счет возможного отсутствия требуемых навыков) и уменьшают размер работы, который команда может выполнить в единицу времени. [2]

Основой Scrum является Sprint, в течении которого выполняется работа над продуктом. По окончанию Sprint дола быть получена новая рабочая версия продукта. Sprint всегда ограничен по времени (1-4 недели) и имеет одинаковую продолжительность на протяжении все жизни продукта.

Перед началом каждого Sprint производится Sprint Planning, на котором производится оценка содержимого Product Backlog и формирование Sprint Backlog, который содержит задачи (Story, Bugs, Tasks), которые должны быть выполнены в текущем спринте. Каждый спринт должен иметь цель, которая является мотивирующим фактором и достигается с помощью выполнения задач из Sprint Backlog. По окончанию Sprint'а производятся Sprint Review и Sprint Retrospective, задача которых оценить эффективность (производительность) команды в прошедшем Sprint'е, спрогнозировать ожидаемую эффективность в следующем спринте, выявлении имеющихся проблем, оценки вероятности завершения всех необходимых работ по продукту и другое.

Agile Unified Process (AUP) – упрощенная версия IBM Rational Unified Process, созданная Скоттом Амблером и состоящая из семи методов:

1. Моделирование используется для понимания бизнес-требования и предметной области.

2. Реализация – это преобразование модели в исполняемый код с модульными тестами.

3. Тестирование – способ поиска дефектов и верификации системы на предмет соответствия требованиям.

4. Размещение – доставка готовой системы пользователям.

5. Управление конфигурациями – управление доступом и версиями артефактов проекта.

6. Управление проектом – непосредственные активности, связанные с ходом проекта: управление и координация людей, управление рисками, управление финансами и так далее.

7. Среда – совокупность процессов, инструментов, стандартов и правил.

Agile Kanban - самая «не директивная методология». Внедрять и использовать Kanban хорошо после Scrum. Kanban - это высоко адаптивный инструмент, который требует от команды, решившей использовать его, соответствующего уровня самоорганизации и дисциплины.

Принципы методологии:

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

2. Ограничение количества незавершенной работы (WIP, Work In Progress)

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

3. Оптимизация процесса. Необходимо отслеживать среднее время задачи и уменьшать его (например, с использованием Value Stream Mapping).

Среднее время реализации задачи (lead time) – метрика, показывающая,

насколько быстро задача проходит весь поток.

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

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

1) Гибкая методология состоит в абсолютной концентрации на достижении цели, которую поставил заказчик перед командой проекта. Стратегические цели компании в рамках методологии Agile не являются приоритетными.

2) Данная методология не учитывает условия внешней среды организации.

3) Управление рисками проектов с использованием Agile не принимает в рассмотрение риски, не относящиеся непосредственно к разработке продукта.

Методологии, рассчитанные на управление проектами различных направлений деятельности, уделяют большее внимание внешним рискам компании. Наиболее полной является методология Project Management Body of Knowledge (PMBOK) - Стандарт управления проектом от Project Management Institute (PMI).

Следующая подзадача включала в себя «Изучение рисков ИТ-сферы, оказывающих влияние на работу компании»,

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

Управление проектами – практическая область менеджмента, применение которой дает возможность четко определить цели и результаты проекта, дать им количественные характеристики, временные, стоимостные и качественные параметры проекта, создать четкий план проекта, выделить, оценить риски и предотвратить возможные негативные последствия во время реализации проекта.

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

• техническая сложность в связи с взаимодействием множества разнородных подсистем, имеющих свои локальные задачи и цели функционирования;

• отсутствие полных аналогов, ограничивающее возможность использования каких-либо типовых проектных решений, высокая доля вновь разрабатываемого ПО;

• функционирование приложений на различных устройствах разных поколений;

• большое количество локальных объектов внедрения, территориально распределенная и неоднородная среда функционирования (СУБД, операционные системы, аппаратные платформы);

• взаимодействующие системы различных организаций с различными форматами обмена информацией;

• различные формы организации и управления проектом:

• проекты с участием собственных разработчиков и сторонних компаний на контрактной основе;

• большое количество участников проекта как со стороны заказчиков, так и со стороны разработчиков;

• значительная временная протяженность проекта, обусловленная масштабами организации-заказчика, различной степенью готовности отдельных ее подразделений к внедрению ПО и нестабильностью финансирования проекта;

• высокие требования со стороны заказчика к уровню технологической зрелости организаций-разработчиков (наличие сертификации в соответствии с международными и отечественными стандартами). [1]

В работе «Вальсируя с медведями», пособие по управлению рисками в ИТ-проектах, выделены 5 наиболее распространенных рисков, из-за которых происходит большинство расхождений между планом и реальным ходом проекта:

1. внутренние изъяны календарного планирования;

2. изменение требований;

3. текучесть кадров;

4. нарушение спецификаций;

5. низкая производительность. [7]

Наиболее распространенный риск - «Изъяны календарного планирования». Он появляется из-за изъянов процесса планирования бюджета времени и средств. Ошибки календарного планирования состоят в неправильной оценке размеров продукта, который предстоит создать: могут быть упущены какие-либо работы, переоценка размера работ, оказавшаяся в плане, редко оказывается достаточной, чтобы компенсировать недооценку. Оценки календарного планирования основаны всего лишь на требованиях заказчика и чаще всего расходятся с итоговым сроком выполнения проекта. Когда календарное планирование строится без учета размера продукта, весьма вероятен перерасход времени на 50-80%.

Риск «Изменение требований» возникает в связи с тем, что область деятельности заказчика не остается статичной за время создания программного обеспечения. Она будет изменяться со скоростью, диктуемой рынком и собственными темпами технологического развития, а, следовательно, меняются и желания заказчика относительно проекта. С точки зрения проекта, эти изменения всегда являются раздуванием требований. Даже удаление того, что уже создано — своего рода раздувание, поскольку требует дополнительной работы.

Следующим риском является «Текучесть кадров».

Оценка текучести кадров основана на следующих данных:

• средний процент текучести технического персонала в компании;

• оценка общих потерь времени при найме для каждой замены;

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

Четвертый риск «Нарушение спецификаций» дискретный, если он реализуется, то это почти всегда губительно для проекта. Нарушение спецификаций относится к краху процесса переговоров по установлению требований, которые идут в начале проекта.

Распространенной попыткой «решения» проблемы является оттягивание решения, маскировка и утаивание проблемы с помощью двоякой трактовки спецификации.

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

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

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

Следующим риском является «Низкая производительность».

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

Примерами стратегических рисков являются:

• Приход иностранных конкурентов;

• Падение рентабельности отрасли;

• Старение применяемых технологий;

• Изменение отраслевого законодательства;

• Отсутствие персонала требуемой квалификации.

Основные финансовые риски:

• Валютные – изменение курса;

• Кредитные – просроченные дебиторские задолженности;

• Налоговые претензии – изменение налогового законодательства;

• «Ножницы цен» - финансовые потери в случае роста цен на потребляемые ресурсы.

Операционные риски:

• Неэффективные маркетинговые компании;

• Рост неликвидов;

• Избыточная численность персонала;

• Уход топ-менеджеров.

Риски опасностей:

• Пожар;

• Отключение электроэнергии;

• Потеря данных;

• Рост непредвиденных затрат;

• Крупное хищение;

• Недружественное поглощение.

«Изучение и анализ особенностей управления рисками проектов в компании ООО «Сенла» - подзадача, для выполнения которой были изучены примеры Реестров рисков.

Условно риски компании ООО «Сенла» можно разделить на три группы:

1) Внепроектные риски ООО «Сенла»;

2) Риски проектов типа Fixed-price;

3) Риски проектов типа Time-and-material.

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

Риски проектов типа Fixed-price более управляемы, так как по ним составлен Реестр рисков, предоставляемый Заказчику. Данный реестр не отражает риски для компании, направлен на интересы заказчика. Недостатками такого управления рисками являются недостатки собственно методологии Agile.

Риски проектов типа Time-and-material изменяются с течением процесса разработки, они не регистрируются в Реестре рисков вплоть до окончательного завершения проекта.

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

«Выявление возможностей повышения эффективности риск-менеджмента» происходит с помощью дополнения используемой методологии шагами из стандарта PMBoK.

На основе недостатков используемых методологий и наиболее полной методологии PMBoK может быть создано собственное решение для ООО «Сенла» по управлению рисками.

Оно состоит в создании БД трех типов рисковых ситуаций и в составлении стандарта, где описаны основные этапы управления тремя разновидностями рисков.

Для использования решения необходимо «Определение основных этапов внедрения предложенного решения»:

Внедрение состоит в следующих этапах:

1) Создание базы данных рисков с указанием причин возникновения, вероятности риска, частоты возникновения, решений, триггеров;

2) Включение в БД ранее встречающихся рисков, типичных рисков ИТ-сферы;

3) Назначение ответственных за группы рисков из топ-менеджмента компании для отслеживания возникновения риска из списка внепроектных рисков.

4) Включение отслеживания рисков из БД по типу проекта в обязанности проектного менеджера.

5) Запись возникающих рисков в БД – новая обязанность проектного менеджера.

6) Детальное описание этапов управления рисками в соответствии с методологией PMBoK применительно к ООО «Сенла».

7) Объединение этапов управления рисками из методологии PMBoK и уникальных шагов по управлению рисками в единый стандарт по управлению рисками для ООО «Сенла».

Таким образом, данные семь этапов позволяют оптимизировать управление рисками в ООО «Сенла» за счет использования:

® стандарта PMBoK, где описаны основные этапы управления проектами;

® методологии Agile для управления собственно процессом производства ПО;

® литературных источников и опыта других компаний для наполнения БД рисков;

® собственного опыта компании в аналогичных проектах;

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

ЗАКЛЮЧЕНИЕ

В процессе прохождения практики мной были выполнена задача, поставленная руководителем, состоящая из семи различных подзадач.

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

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

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

Теоретические знания, полученные в ходе преддипломной практики, используются в дипломном проекте. Дополнительно, анализ полученных данных был использован для написания статей в научных сборниках:

® Молодежный сборник научных статей «Научные стремления». Выпуск 16.

Название статьи: "Управление проектами с учетом рисков"

® Сборник научной конференции студентов и аспирантов «Новые математические методы и компьютерные технологии в проектировании, производстве и научных исследованиях»

Название статьи: "Особенности риск-менеджмента в ИТ-сфере"

Таким образом, основная задача и подзадачи выполнены в полном объеме в соответствии с требованиями руководителя практики.

1 2 34