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

Содержание:

ВВЕДЕНИЕ

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

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

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

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

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 подходит не для всех команд и организаций ещё и потому, что предлагаемый процесс может не подойти для разработки конкретного продукта – например промышленного станка или постройки здания.

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

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

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

«Работа» – самое точное определение осуществляемых в ходе достижения проектных целей процедур в силу максимальной близости к задачному контексту проектной деятельности. Работу и задачу легче всего грамотно декомпозировать (разбить) на составляющие операции и подзадачи.

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

В словаре ИСР указываются:

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

ИСР формируется на основе ряда правил, два из которых являются ключевыми:

1. Правило 100%. Специальное правило самопроверки обязывает собирать в структуру все создаваемые продукты, результаты работ, операций вне зависимости от источника их производства: внутреннего или внешнего. Это правило применяется ко всем элементам создаваемой иерархии. Ответственное за создание структуры проекта лицо обязано каждый раз после завершения списка раздела задавать вопрос: «Все ли мы учли, что могли забыть?». На практике это представляет собой весьма дискомфортную процедуру. Поэтому практически сразу с момента начала работы над структурой PM следует привлекать экспертов. Именно здесь начинается детальное планирование и нужны те, кто досконально разбирается в отдельных процессах.
2. Правило взаимоисключения элементов. Каждый раз разбивая результат на детализированные элементы, нужно применять ясный критерий, при этом отслеживать, чтобы полученные объекты не смешивались на одном уровне и не дублировались на разных «веточках» иерархии. Под «веточками» далее будем понимать выделенные иерархические разделы, имеющие дальнейшее разбиение вниз. В иерархии не допустимы два или более элемента с идентичным содержанием. Эта ошибка может привести к дублированию операций и конфликтам.

Основные ориентиры (условия) при создании структуры работ следующие:

1. Для каждого элемента структуры формулируется измеримый результат.
2. Каждый результат вышестоящего элемента носит агрегированный характер, т.е. является итогом результатов «дочерних» элементов декомпозиции.
3. Пакеты и отдельные операции должны быть уникальными.
4. Структура должна быть полной, но не избыточной.
5. Элементы структуры верхних уровней должны быть совместимы с организационной структурой проекта.
6. Размер элементов нижнего уровня должен быть достаточным для эффективного управления, но не избыточным для их контроля.

Мы можем представить ИСР как разбиение проекта по фазам, этапам или процессам проекта. Пример разбития ИСР по этапам проекта расположен на рисунке 6.

Рисунок 6 Пример разбития ИСР по этапам проекта

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

Вывод по главе «управление проектами: сущность, способы и методы»:

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

ГЛАВА 2.ПОСТРОЕНИЕ ИЕРАРХИЧЕСКОЙ СТРУКТУРЫ РАБОТЫ НА ПРИМЕРЕ ПРОЕКТА

2.1. Характеристика проекта

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

При использовании метода PERT мы должны построить 3 сетевые модели для трёх разных сроков:

1. Оптимистический;
2. Наиболее вероятный;
3. Пессимистический.

Наш проект носит название «SteAndri», в честь основателей проекта.

Цель проекта: создать SPA приложения для управление по SCRUM методу.

Результаты: результаты нашего проекта - это готовое приложения для управления проектами по методологии SCRUM.

Работы проекта:

1. Появление идеи;
2. Анализ рынка;
3. Создание концепции;
4. Разработка бизнес модели;
5. Выбор технологий для проекта;
6. Набор людей для проекта;
7. Продумывание Ux/Ui пользователя;
8. Создание дизайна сайта;
9. Создание Frontend части приложения;
10. Создание Backend части приложения;
11. Модульное тестирование;
12. Регрессивное тестирование;
13. Выбор хостинга для приложения;
14. Деплой приложения;
15. Заказ рекламы.

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

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

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

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

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

Продумывание Ux (User experience) пользователя: на этом этапе продумываем типичное поведение пользователя в приложении.

Создание Ui (User Interface) сайта: на этом этапе мы придумываем как будет выглядеть интерфейс нашего приложения, какие будут анимации, какие будут цвета и т.д.

Набор людей для проекта: на этом этапе мы занимаемся подбором людей для нашего утверждённого набора технологий на проекте.

Создание Frontend части приложения: на этом этапе программист, который отвечает за создание пользовательского интерфейса получает макеты от дизайнера и начинает воплощать в жизнь то что нарисовал и придумал дизайнер.

Создание Backend части приложения: на этом этапе программист начинает создавать базу данных (БД), он решает, что в ней будет хранится, каким образом информация будет попадать в БД, какие проверки будут перед тем как информация попадёт в БД, каким образом будет получение информации из БД и т д.

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

Регрессивное тестирование: на этом этапе тестировщик или программист занимается написанием регрессивных тестов, которые предназначены для проверки работы приложения при смене API (Application Programming Interface интерфейс программирования приложений, позволяющий сервисам взаимодействовать, получать доступ и обмениваться данными)

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

Деплой: на этом этапе программист занимается развертыванием приложения на новой машине/или на той же самой, но новой его версии. То есть, деплой это процесс (так или иначе организованный) перевода кода вашего проекта в рабочее состояние на конкретной машине.

Заказ рекламы: на этом этапе заказывается реклама на тематических платформах с возможной будущей аудиторией нашего приложения.

Теперь укажем сроки проекта, а затем распишем его бюджет

1. Сроки (65дней):
   1. 10 дней на прединвестиционный этап.
   2. 15 дней на этап разработки.
   3. 25 дней на этап реализации.
   4. 15 дней на этап завершения.
2. Бюджет
   1. 2500 рублей.
3. Участники
   1. Ефремов Степан (дизайнер).
   2. Ефремов Степан (frontend разработчик).
   3. Ефремов Степан (тестировщик).
   4. Цыганок Андрей (backend разработчик).
   5. Цыганок Андрей (тестировщик).
4. Заинтересованный стороны.
   1. Обычные пользователи приложения.
   2. Компании.
5. Критерии успешности
   1. Уложиться в установленные сроки.
   2. Уложиться в установленный бюджет.
6. Требования к проекту
   1. Frontend часть сайта написана с использованием React [1], Redux [2], Formik [3], TypeScript [3].
   2. Git [7] для контроля версий кода проекта.
   3. Backend часть написана с использованием Expressjs [4].
   4. База данных создана с использованием PostgreSQL [5].

Вывод по «главе характеристика проекта»: в этой главе мы ознакомились объектом исследования, его свойствами и требованиями и т.д.

ГЛАВА 2.2 Построение иерархической структуры работ проекта, сетевых моделей, календарного плана

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

Рисунок 7. Иерархическая структура работ «SteAndri».

После построения иерархической структуры работ, нам требуется построить сетевые модели вида «Работа-Дуга» с учётом 3 вариантов времени и «Работа-Вершины» с учётом наиболее вероятного времени для оценки времени работ и проекта в целом, во время построения сетевой модели мы будем обосновывать последовательность работ, опираясь на иерархическую структуру работ.

На рисунке 11 изображена сетевая модель вида «Работ-Дуга» с учетом оптимистической оценки времени реализации проекта.

Рисунок 8. Сетевой модели вида «Работ-Дуга» с учётом оптимистичного времени.

Продолжение рисунка 8.

Продолжение рисунка 8.

Теперь рассмотрим сетевую модель вида «Работ-Дуга» с учётом наиболее вероятного времени на рисунке 12.

Рисунок 9. Сетевой модели вида «Работ-Дуга» с учётом наиболее вероятного времени.

Продолжение рисунка 9.

Продолжение рисунка 9.

Так же нужно построить сетевую модель вида «Работ -Вершина» с учётом наиболее вероятного времени, модель находится на рисунке 13.

Рисунок 10. Сетевой модель вида «Работа-Вершина» с учетом наиболее вероятного времени.

Продолжение рисунка 10.

Продолжение рисунка 10.

Продолжение рисунка 10.

Осталось рассмотреть последнее время, на рисунке 14 изображён сетевая модель вида «Работ-Дуга» с учётом пессимистичного времени.

Рисунок 11. Сетевой модели вида «Работ-Дуга» с учётом пессимистичного времени.

Продолжение рисунка 11.

Продолжение рисунка 11.

На рисунке 15 представлен календарный план проекта, построенный на основе сетевой модели вида «Работ-Вершина» с учётом наиболее вероятного времени.

Рисунок 12. Календарный план проекта «SteAndri».

Продолжение рисунка 12.

Продолжение рисунка 12.

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

В этой главе мы построили иерархическую структуру работ, сетевые модели вида «Работа Дуга», «Работа Вершина» для объекта исследования. Так как у нас инновационный проекта, мы используем метод PERT для разработки расписания проекта, построили сетевую модель вида «Работа-Дуга» по трем видам оценок, для разного времени, сетевую модель «Вершина» для наиболее вероятного времени и «календарный план» построенный на основании сетевой модели «Вершина».

Вывод по главе «построение иерархической структуры работы» на примере проекта: на этом этапе мы подробно разобрали выбранный объект исследования, описали устав проекта, его участников, разработали расписание проекта и т.д.

ЗАКЛЮЧЕНИЕ

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

• разделение по фазам;
• разделение по этапам;
• разделение по процессам.

После ознакомления с теоретической частью мы начали описание объекта исследования, для подробного разбора проекта мы привели фрагмент устава проекта и кратко описали требования к нему. Объектом исследования является приложения под названием «SteAndri», главной целью приложения является облегчение управления проектом по методу SCRUM.

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

Так как у нас 3 разных варианта времени, мы построили различные варианты сетевой модели вида «Работа-Дуга», 1 сетевую модель вида «Работа-Вершина» с учётом наиболее вероятного времени проекта и календарный план на основе построенной сетевой модели «Вершина».

Задачи работы были достигнуты.

Так же мы решили перечень следующих задач:

1. Разбор понятия проект и управление проектом.
2. Разбор существующих методов управления проектами.
3. Разбор понятия ИСР.
4. Разбор правил построения ИСР.
5. Построение ИСР основываясь на фазы проекта
6. Построение сетевой модели вида «Работа-Дуга» с учётом оптимистичного времени.
7. Построение сетевой модели вида «Работа-Дуга» с учётом наиболее вероятного времени.
8. Построение сетевой модели вида «Работа-Дуга» с учётом пессимистичного времени.
9. Построение сетевой модели вида «Работа-Вершина» с учётом наиболее вероятного времени.
10. Построение календарного плана.

СПИСОК ИСПОЛЬЗОВАННОЙ ЛИТЕРАТУРЫ

1. Руководство к Своду знаний по управлению проектами (Руководство PMBOK) – 6 издание [Электронный ресурс] Режим доступа: https://www.livelib.ru/book/2735/readpart-rukovodstvo-k-svodu-znanij-po-upravleniyu-proektami-rukovodstvo-pmbok/~2.
2. Официальная документация Expressjs [Электронный ресурс] Режим доступа: https://expressjs.com/
3. Официальная документация Formik [Электронный ресурс] Режим доступа: https://jaredpalmer.com/formik/docs/overview
4. Официальная документация Git [Электронный ресурс] Режим доступа: https://git-scm.com/
5. Официальная документация PostgreSQL [Электронный ресурс] Режим доступа: https://postgrespro.ru/docs/postgresql
6. Официальная документация Project-manager-news [Электронный ресурс] Режим доступа: https://www.pmservices.ru/project-management-news/top-7-metodov-upravleniya-proektami-agile-scrum-kanban-prince2-i-drugie/
7. Официальная документация React [Электронный ресурс] Режим доступа: https://ru.reactjs.org/docs/getting-started.html
8. Официальная документация Redux [Электронный ресурс] Режим доступа: https://redux.js.org/introduction/getting-started/
9. Официальная документация TypeScript [Электронный ресурс] Режим доступа: https://www.typescriptlang.org/docs/home.html
10. Scrum. Революционный метод управления проектами / Джефф Сазерленд ; пер. с англ. М. Гескиной — М.: Манн, Иванов и Фербер, 2016. ISBN 978-5-00057-722-6

Глоссарий

Транспиляция – процесс преобразование кода написанный на одном языке программирование на другой язык программирования.

Кодовая база – весь код написанный в проекте.

ИСР – иерархическая структура работ.

React – javascript библиотека для реализации сложных пользовательских интерфейсов.

Redux – библиотека для управления состояния пользовательских интерфейсов.

Formik – библиотека написанная на React js, для облегчения работы с пользовательскими формами.

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

Git – система контроля версий для кодовой базы.

Nodejs – платформа для исполнения javascript кода вне браузера.

Expressjs – библиотека написанная на Nodejs для облегчённого создания обработки запрос с фронтент части приложения.

PostgreSQL – реляционная система управления базы данных.