Файл: Разработка и построение ИСР проекта. Структурная декомпозиция работ.pdf

ВВЕДЕНИЕ

Актуальность темы исследования. Значимость иерархической структуры работ (ИСР) возрастает с ростом масштаба задач разрабатываемых проектов. Являясь одним из ключевых факторов успеха проекта, иерархическая структура работ служит основой для:

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

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

Задачи проекта:

1. Создание необходимых инструментов для управления SCRUM методом
2. Облегчение управления по SCRUM методу

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

Объектом исследования является приложение для управления проектами по гибкому методу SСRUM.

Во время написания курсовой работы использовались следующие методы исследования:

• анализ и синтез;
• сравнение;
• индукция;
• дедукция.

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

Наш проект это SPA(Single Page Application) приложение главной целью, которой является ускорение и облегчение управления по SCRUM методологии.

Наш проект является инновационным, так как прямых конкурентов мы не имеем. Из-за того что проект является инновационным мы вынуждены использовать при построении сетевых моделей метод PERT с учётом 3 вариантов оценки затраченного времени

ГЛАВА 1. УПРАВЛЕНИЕ ПРОЕКТАМИ СУЩНОСТЬ, СПОСОБЫ И МЕТОДЫ.

1.1. Сущность и методы управления проектами

Проект – это комплекс взаимосвязанных мероприятий, направленный на достижение поставленной цели и имеющие свои ограничения [9].

Управление проектами – это

На данный момент существуют множество методов и методик управления проектом, но мы рассмотрим основные методы управления проектом и подробно разберём несколько из них:

1. Классический проектный менеджмент наиболее очевидный способ сделать свой проект более управляемым – это разбить процесс его исполнения на последовательные этапы. Именно на такой линейной структуре базируется традиционное проектное управление. В этом смысле оно напоминает компьютерную игру – нельзя перейти на следующий уровень, не завершив предыдущий [8]. Схема рабочего процесса классического проектного менеджмента приведена на рисунке 1.

Рисунок 1.Рабочий процесс классического проектного менеджмента.

1. Agile - это семейство гибких итеративно-инкрементальных методов к управлению проектами и продуктами. Согласно данному подходу, проект разбивается не на последовательные фазы, а на маленькие подпроекты, которые затем «собираются» в готовый продукт. Схема работы приведена на рисунке 2.

Рисунок 2. Рабочий процесс Agiel управления.

Сам по себе Agile – не метод управления проектами. Это скорее набор идей и принципов того, как нужно реализовывать проекты. Уже на основе этих принципов и лучших практик были разработаны отдельные гибкие методы или, как их иногда называют, фреймворки (frameworks): SCRUM, Kanban, Crystal, и многие другие. Эти методы могут достаточно сильно отличаться друг от друга, но они следуют одним и тем же принципам.

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

1. В Lean работа разбивается на небольшие пакеты поставки, которые реализуются отдельно и независимо. Но в Lean для разработки каждого пакета поставки существует поток операций с этапами, подобными тем, которые были созданы для проекта Аполлон. Как и в классическом проектном менеджменте, это могут быть этапы планирования, разработки, производства, тестирования и поставки – или любые другие необходимые для качественной реализации проектов этапы. Схема работы приведена на рисунке 3.

Рисунок 3. Рабочий процесс Lean управления.

Как и Agile, Lean это скорее концепция, образ мышления, нежели нечто высеченное в камне. Используя идеи Lean можно самостоятельно создать систему, удовлетворяющую вашим требованиям в управлении проектами.

1. Рассмотрим более подробно метод PRINCE2. НАСА – не единственная государственная организация, которая внесла вклад в развитие проектного управления. Британское Правительство давно оценило эффективность проектного управления, и в 1989 году была создана британская методология PRINCE2. Название произошло от акронима «PRojects IN Controlled Environments version 2», что переводится как «Проекты в контролируемой среде версия 2». В отличие от гибких методов, PRINCE2 не использует итеративный подход к проекту. Если сравнивать PRINCE2 с другими продуктами, то его можно сравнить с гибридом классического подхода к проектному управлению и концентрации на качестве из 6 сигм. Схема работы приведена на рисунке 4.

Рисунок 4. Рабочий процесс PRINCE2 управления.

1. SCRUM - гибкий фреймворк, созданный в 1986 году, считается самым структурированным из семейства Agile. Созданный в 1986 году, он сочетает в себе элементы классического процесса и идеи гибкого подхода к управлению проектами. В итоге получилось очень сбалансированное сочетание гибкости и структурированности управления [10].

Рассмотрим более подробно метод SCRUM. Следуя заветам Agile, SCRUM разбивает проект на части, которые сразу могут быть использованы Заказчиком для получения ценности, называемые заделами продуктов (product backlog). И несмотря на то, что «задел продукта» — достаточно верный перевод и используется в профессиональной литературе, в российской практике чаще всего используется просто «беклог». Затем эти части приоретизируются Владельцем продукта – представителем Заказчика в команде. Самые важные «кусочки» первыми отбираются для выполнения в Спринте – так называются итерации в SCRUM, длящиеся от 2 до 4 недель. В конце Спринта Заказчику представляется рабочий инкремент продукта – те самые важные «кусочки», которые уже можно использовать. Например, сайт с частью функционала или программа, которая уже работает, пусть и частично. После этого команда проекта приступает к следующему Спринту. Длительность у Спринта фиксированная, но команда выбирает её самостоятельно в начале проекта, исходя из проекта и собственной производительности. Схема рабочего процесса приведена на рисунке 5.

Рисунок 5 Рабочий процесс SCRUM управления.

Чтобы удостовериться в том, что проект отвечает требованиям Заказчика, которые имеют свойство изменяться со временем, перед началом каждого Спринта происходит переоценка ещё не выполненного содержания проекта и внесение в него изменений. В этом процессе участвуют все – команда проекта, SCRUM Мастер (SCRUM Master, лидер команды проекта) и Владелец продукта. И ответственность за этот процесс лежит на всех.

Как уже говорилось, Владелец продукта является представителем Заказчика в проекте, или олицетворяет всех клиентов будущего проекта, в случае если Заказчика нет. Для этого он должен досконально знать их потребности и образ мышления, а также разбираться в продукте и технологии его изготовления. SCRUM Мастер призван помочь участникам проекта лучше понять и принять ценности, принципы и нормы практики SCRUM. Он лидер и посредник между внешним миром и командой. Его задача — следить, чтобы никто не мешал команде самостоятельно и комфортно работать над поставленными задачами. Команда же отвечает за то, чтобы в конце спринта все необходимые задачи были сделаны, а поставки – выполнены.

Основная структура процессов SCRUM вращается вокруг 5 основных встреч: упорядочивания беклога, планирования Спринта, ежедневных летучек, подведения итогов Спринта и ретроспективы Спринта.

«Встреча по упорядочиванию беклога» - эта встреча аналогична фазе планирования в классическом проектном управлении, и проводится в первый день каждого Спринта. На ней рассматривается – что уже было сделано по проекту в целом, что ещё осталось сделать и принимается решение о том, что же делать дальше. Владелец продукта определяет, какие задачи на данном этапе являются наиболее приоритетными. Данный процесс определяет эффективность Спринта, ведь именно от него зависит, какую ценность получит Заказчик по итогам Спринта.

«Планирование Спринта» - после того, как Владелец продукта определил приоритеты, команда совместно решает, что же конкретно они будут делать во время грядущей итерации, как достигнуть поставленной на предыдущей встрече цели. Команды могут применять различные инструменты планирования и оценки на данном этапе, лишь бы они не противоречили принципам и логике SCRUM. Планирование Спринта проводится в самом начале итерации, после Встречи по упорядочиванию продукта.

«Ежедневные летучки» - каждый день спринта, в идеале, в одно и то же время, члены команды тратят 15 минут на то, чтобы поделиться информацией о статусе задач и состоянии проекта. На ней не происходит обсуждений проблем или принятия решений – если после встречи возникают вопросы и конфликты, SCRUM Мастер и вовлечённые участники обсуждают их отдельно. Летучка же нужна для обмена информации и поддержания всех членов команды в курсе состояния проекта.

«Подведение итогов Спринта» - это обследование и адаптация создаваемого продукта. Команда представляет результаты деятельности всем заинтересованным лицам. Основная задача – убедиться, что продукт этапа соответствует ожиданиям участников и согласуется с целями проекта.

«Ретроспектива Спринта» - этот процесс проводится сразу после «Подведения итогов» спринта и до планирования следующего спринта. На нём команда выясняет, насколько чётко и слаженно проходил процесс реализации этапа. Обследованию подвергаются возникшие проблемы в работе, методологии и взаимодействии. Именно этот этап позволяет команде провести рефлексию и следующий Спринт провести эффективнее.

SCRUM был разработан для проектов, в которых необходимы «быстрые победы» в сочетании с толерантностью к изменениям. Кроме того, этот фреймворк подходит для ситуаций, когда не все члены команды имеют достаточный опыт в той сфере, в которой реализуется проект – постоянные коммуникации между членами командами позволяют недостаток опыта или квалификации одних сотрудников за счёт информации и помощи от коллег.

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

В ходе каждой итерации, разработчики добавляют и тестируют новые функции сайта и убирают те, которыми не пользовались клиенты. По словам команды Netflix, основное преимущество SCRUM в том, что он позволяет «быстро ошибаться». Вместо того, чтобы долго и с большими затратами готовить крупный релиз, поставки раз в две недели по Scrum имеют небольшой размер. Их легко отслеживать и, если что-то идёт не так, быстро исправлять.

SCRUM очень требователен к команде проекта. Она должна быть небольшой (5-9 человек) и кроссфункциональной – то есть члены команды должны обладать более чем одной компетенцией, необходимой для реализации проекта. Например разработчик ПО должен обладать познаниями в тестировании и бизнес-аналитике. Делается это для того, чтобы часть команды не «простаивала» на разных этапах проекта, а также для того, чтобы сотрудники могли помогать и подменять друг друга.

Кроме того, члены команды должны быть «командными игроками», активно брать на себя ответственность и уметь самоорганизовываться. Подобрать такую зрелую команду очень непросто!

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