Руководство проектами в области разработки по - Arganabio.ru - инструкции по эксплуатации и многое другое

Добавил:

Koboku1

По своей натуре перфекционист. Поэтому люблю все аккуратно оформлять и упорядочивать, складывать по полочкам. Вот, не пропадать же добру, нажитому за четыре кропотливых семестра. Тут я выложил все мои ответы, курсовые, отчеты и некоторые ДЗ. Они могут вам помочь для получения зачета или сдачи экзамена. Если чего-то не нашли в папочках, то попытайте удачу в разделе НЕОТСОРТИРОВАННОЕ на моей страничке, там все 4 семестра разложены по папкам. ГРУППА КТ-43-15. Годы обучения 2015-2019. Коллекция будет пополняться. Что ж, удачки :З

Опубликованный материал нарушает ваши авторские права? Сообщите нам.

Вуз:

Предмет:

Файл:

Скачиваний:

Добавлен:

15.09.2017

Размер:

293.25 Кб

Скачать

Руководство программным проектом

Руководство
программным проектом
— первый слой процесса конструирования
ПО. Термин «слой» подчеркивает, что
руководство определяет сущность процесса
разработки от его начала до конца.
Принцип руководства иллюстрирует рис.
2.1.Рис.
2.1. Руководство
в процессе конструирования ПО

Для
проведения успешного проекта нужно
понять объем предстоящих работ, возможный
риск, требуемые ресурсы, предстоящие
задачи, прокладываемые вехи, необходимые
усилия (стоимость), план работ, которому
желательно следовать. Руководство
программным проектом обеспечивает
такое понимание. Оно начинается перед
технической работой, продолжается по
мере развития ПО от идеи к реальности
и достигает наивысшего уровня к концу
работ

Начало
проектаПеред
планированием проекта следует:установить
цели и проблемную область проекта;
обсудить
альтернативные решения;
выявить
технические и управленческие ограничения.

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

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

Анализ
риска

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

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

Трассировка
и контрольКаждая
задача, помеченная в плане, отслеживается
руководителем проекта. При отставании
в решении задачи применяются утилиты
повторного планирования. С помощью
утилит определяется влияние этого
отставания на промежуточную веху и
общее время конструирования. Под вехой
понимается временная метка, к которой
привязано подведение промежуточных
итогов.В
результате повторного планирования:1)
могут быть перераспределены ресурсы;
2)
могут быть реорганизованы задачи;
3)
могут быть пересмотрены выходные
обязательства

Источник

Авторы
Резюме
Рецензия
Файлы
Ключевые слова
Литература

Кочеткова Л.И.

1

Сенкевич Л.Б.

1 ФГБОУ ВО «Тюменский индустриальный университет»

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

план управления проектом

программное обеспечение

IT-проект

жизненный цикл

моделирование

система

1. Гухман А.А. Введение в теорию подобия. – М.: Изд-во ЛКИ, 2010. – 296 с.

2. Ньютон Р. Управление проектами от А до Я. – М.: Альпина Паблишер, 2013. – 192 c.

3. Определение целей, результатов и продуктов проекта [Электронный ресурс]. – Режим доступа: http://pm-way.com/materials/material/show/157 (дата обращения 20.05.2017).

4. Романова М.В. Управление проектами: учебное пособие. – М.: ИНФРА-М, 2010. – 253 с.

5. Руководство к Своду знаний по управлению проектами (Руководство PMBOK). – 4-е изд. – М.: Олимп-Бизнес, 2010. – 496 с.

6. Солдатов В.П. Управление программными проектами. – М.: Бином-Пресс, 2010. – 382 c.

7. Эрик Синк. Бизнес для программистов. – СПб.: Питер, 2008. – 256 с.

8. Яворский В.В., Сергеева А.О., Пошанов Р.Т. Подготовка специалистов в сфере информационных технологий // Международный журнал экспериментального образования. – 2015. – № 11–4. – С. 554–556.

Сфера разработки программного обеспечения (ПО) – одна из самых активно развивающихся в настоящее время. В области разработки программного обеспечения на данный момент задействовано около 19 миллионов инженеров.

Результативное и успешное управление проектами разработки программного обеспечения обусловлено качеством и эффективной организацией работ в условиях ограничения стоимости и времени.

Согласно открытым данным исследований группы Standish Group в 2016 г., из 50 тысяч изученных программных проектов по всему миру, по причине неэффективного управления 19 % оказались провальными, 52 % спорными, что потребовало дополнительных вложений финансов и затрат времени и только 29 % проектов оказались успешными. По данным этого же исследования, бюджет проектов превышается на 179 %, а затраченное время на 202 % превышает изначально рассчитанное. Наряду с этим, реализуется в среднем всего 68 % объявленной в спецификации функциональности. Результаты исследования графически показаны на рис. 1.

Рис. 1. Диаграмма результатов данных исследований Standish Group

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

Существующие системы управления ресурсами рассчитаны на контролирование проектами на стадии их реализации и применяются изначально для разрешения таких необходимых задач, как [5]:

– представление общих норм проекта;

– представление логической организации работ, многоуровневого описания проекта;

– установление объединенного организационного состава исполнителей, имеющихся средств и перечня материалов;

– подготовка плана проекта, представленного в виде перечисления совокупности работ, связанных без учета ограниченности средств;

– регулирование плана проекта с учетом ограниченности средств;

– установление кризисного плана и запаса времени исполнения работ проекта;

– установление требований к проекту в финансировании, ресурсах и техническом обеспечении;

– подготовка плана разделения во времени загрузки восстановляемых ресурсов;

– оценка вероятности рисков и проектирование расписания с учетом рисков;

– извлечение, подборка и обобщение работ по срокам, средствам, видам и т.д.;

– введение фактических показателей состояния решения поставленных задач, объемов выполненных работ и применения средств;

– оценка несоответствия в порядке выполнения работ от поставленного плана и прогнозирование основных норм проекта в будущем;

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

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

Выбор необходимой системы управления обуславливается такими критериями, как [6]:

– объемом и затруднительностью проекта (объем работ, средств, времени, календарей);

– необходимый объем организованных порядков работ;

– обязательность объединенной работы над проектами и потенциал обмена информацией через Internet;

– потребность ввода и вывода данных из других систем и баз данных;

– потребность исполнения расчетов по формулам, заданным пользователем;

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

– простота овладения и практичность графического интерфейса;

– наиболее допустимая цена программы;

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

– единые правила компании по реализации специальных программных средств.

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

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

На первых стадиях управления проектом разработки программного обеспечения необходимо описать цели и рамки проекта, а также взаимосвязь данного проекта с другими, если такие существуют. Указываются запросы заказчика, на удовлетворение которых направлен проект, а также описание целей проекта, программного продукта, который должен быть разработан, чтобы достичь целей проекта. Также указывается, каким образом данный проект будет интегрироваться с другими проектами или процессами [7]. На этом этапе указывается выбранная модель жизненного цикла проекта, перечисляются все важные фазы проекта, их взаимосвязи, зависимости и последовательность выполнения. Проекты по разработке программного обеспечения обычно используют 2 модели: водопадная и инкрементная модели.

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

Фаза «Разработка требований» включает сбор требований заказчика и их формализацию. Требования – основа для всего проекта.

На фазе «Проектирование» проектная команда разрабатывает документы дизайнов в соответствии с требованиями.

На фазе «Разработка» проектная команда производит продукт в соответствии с документами дизайнов.

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

После стадии «Верификация» проект переходит в фазу «Ввод в эксплуатацию». На данной фазе продукт должен быть развернут для эксплуатации и быть принят заказчиком [8].

Инкрементная модель используется для проектов с недостаточными требованиями заказчика – требования определяются итеративно в течение всего процесса разработки продукта. Проект имеет следующую последовательность фаз, представленных на рис. 3.

Инкрементальная модель применима на проектах с плохо определёнными или не до конца определенными требованиями. Разработка производится итерациями (2–4-недельными циклами). Требования на итерацию оговариваются с заказчиком до старта итерации. Итерация планируется в соответствии с объёмом требований на итерацию, и каждая итерация включает проектирование, разработку и верификацию. Результаты первой итерации используются для уточнения требований на следующую итерацию. Итерации продолжаются, пока не достигнуты цели проекта, определенные в документе требований. Последняя версия построения продукта проходит полную проверку перед вводом в эксплуатацию [4].

Рис. 2. Последовательность фаз в водопадной модели

Рис. 3. Последовательность фаз в инкрементной модели

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

В качестве наиболее надежного и совершенного на практике аппарата аналогового моделирования предлагается применить теорию подобия [1].

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

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

– создание одной (первой) версии программного продукта группой разработчиков;

– создание аналогичной системы другой группой разработчиков;

– создание показательного прототипа системы.

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

Для использования аналогового моделирования программных проектов требуется установить:

– процессы, которые будут входить в класс;

– процессы, которые будут входить в группы (определить множество условий, определяющее подобие процессов реализации программных проектов) [1].

Параметры проекта и продукта определяют класс реализации проекта, соответственно:

– методом разработки (быстрая разработка, разработка по водопадной, спиральной, инкрементной, открытой и т.д. модели);

– типом разрабатываемого продукта (система обработки транзакций, система поддержки принятия решений, среда разработки, офисное приложение, учетное приложение и т.д.) [2].

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

Процессы реализации программных проектов при детальном сравнении с физическими процессами и явлениями имеют следующие сходные признаки:

– необходимый временной характер (программный продукт и физическое явление происходят во времени, причем внутри конечного, определенного промежут-ка времени);

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

– вероятность установления системы в завершающей стадии, в которой процесс реализуется не на знании ее предыстории, а на знании исходного состояния (для физических процессов – универсальные соотношения выражаются в общем виде в дифференциальной форме; для программных проектов, как правило, предыстория системы отсутствует) [1].

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

– существует функциональная зависимость между входными и выходными данными системы;

– входные и выходные данные системы установлены на одном и том же множестве моментов времени;

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

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

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

– хранение общей информации о проекте: цели, задачи, заказчик, ключевые сроки;

– формирование календарного плана этапов проекта с указанием сроков начала и окончания каждого этапа, критериев приемки каждого этапа и ответственных;

– распределение ролей в проекте между сотрудниками фирмы-разработчика;

– формирование плана взаимодействия исполнителей и заказчиков в рамках IT-проекта;

– хранение данных о процедурах эскалации и приемки проекта;

– формирование планов оценки проекта, мониторинга и контроля, управления рисками;

– формирование технических планов проекта;

– формирование планов по поддержке программного продукта;

– контроль сроков выполнения задач;

– обеспечение возможности корректировки сроков и исполнителей по различным этапам проекта в случае незапланированной ситуации;

– формирование итогового плана управления проектом.

Библиографическая ссылка

Кочеткова Л.И., Сенкевич Л.Б. СТРУКТУРА ПЛАНА УПРАВЛЕНИЯ ПРОЕКТОМ В ОБЛАСТИ РАЗРАБОТКИ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ // Современные наукоемкие технологии. – 2017. – № 6.
– С. 62-66;

URL: https://top-technologies.ru/ru/article/view?id=36699 (дата обращения: 25.04.2023).

Предлагаем вашему вниманию журналы, издающиеся в издательстве «Академия Естествознания»

(Высокий импакт-фактор РИНЦ, тематика журналов охватывает все научные направления)

Источник

Время на прочтение
5 мин

Количество просмотров 91K

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

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

Жизненный цикл разработки IT-продукта

Ниже описаны этапы цикла, начиная с момента, когда заказчик сформулировал свои идеи исполнителю.

Планирование

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

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

После того, как UX/UI проектирование выполнено, можно составить точный план, как будет идти разработка, и какая функциональность будет в продукте.

Дизайн

После планирования наступает черед UX/UI дизайнеров — специалистов, которые проектируют пользовательские интерфейсы. Дизайнеры занимаются изучением поведения пользователей и выстраиванием понятного человеку интерфейса. Визуальный вид продукта — также результат работы дизайнеров.

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

Разработка

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

Итерации в Agile называются спринтами, и в один спринт входят работы по всем направлениям: планирование, дизайн, разработка, тестирование.

Тестирование

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

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

Поддержка

Готовый продукт может нуждаться в дополнительной поддержке, будь то дополнительные вопросы по поводу работы продукта от клиентов, или необходимость внести изменения в уже заложенные функции, — специалисты службы поддержки всегда готовы прийти на помощь.
Большинство проектов по разработке проходят все этапы вышеописанного жизненного цикла.
Для примера мы подробнее рассмотрим процесс разработки продукта на текущем проекте компании.

Этап 1: Идея

Заказчик — печатная компания из штатов. По всему миру эта индустрия переживает не лучшие времена, но в США печатные компании остаются на плаву благодаря инновационным технологиям. Печатная компания обратилась к нам с просьбой разработать приложение для дополненной реальности — Augmented Reality, AR.

Почтовая служба США, рассылающая печатные отчеты о сделках, предоставляет скидки тем партнерским компаниям, которые уменьшают потребление бумаги за счет технологий. Наш клиент стал одной из таких компаний.

Этап 2: Контакт

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

Этап 3: Планирование

Заказчик описал основную функциональность продукта перед тем, как обратиться к нам. Команда разработчиков должна была изучить идею проекта и собрать все необходимые требования, выявить узкие места, и всё задокументировать. Подробности проекта и технические детали уточняли внутри каждого спринта.

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

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

Комментарий менеджера проекта Александра:
«Я отвечаю за непрерывный ход проекта. Я выбрал Scrum-методологию, чтобы быстро реагировать на запросы заказчика и рынка. Scrum помогает нам развивать продукт, учитывать потребности пользователей в каждом релизе продукта, и использовать в разработке самые современные технологии».

Этап 4: Дизайн

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

Этап 5: Разработка и тестирование

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

На первом этапе разработки команда состояла из:

Менеджера проектов, который также выполнял задачи бизнес-аналитика;
UX/UI дизайнера;
команды разработчиков.

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

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

Менеджер проектов;
Бизнес-аналитик с более широким кругом задач, чем были у менеджера до этого;
UX/UI дизайнер;
разработчики;
руководитель команды разработчиков (Team Lead);
Системный архитектор, разработавший структуру продукта;
Специалист по тестированию;
DevOps — связующее звено между разработкой и эксплуатацией, работал с сетью и развертыванием продукта.

Руководитель команды разработчиков Игорь внес свои нововведения:
«В этом проекте я отвечаю за выполнение задач проекта, провожу рецензию кода, планирую спринты (итерации в разработке), ввожу новые задачи. Я предложил проводить юнит-тесты с помощью GitFlow и создавать код при помощи AWS Lambda. Я также ввожу в курс дела новых членов команды, отвечаю за их адаптацию”.

Присоединение Team Lead было важным решением, так как он помог скоординировать разработку версий приложения под iOS и Android и веб-версию так, чтобы все двигалось в одном направлении.

Бизнес-аналитик Флор рассказывает:
“Благодаря организации проекта, моя работа была предельно ясной и эффективной. Я обрабатывал запросы клиентов и в понятном и технически точном виде передавал их команде разработчиков. Я работал в тандеме с UX/UI дизайнером, а наш проект менеджер был ответственным за переговоры, что дало мне возможность сфокусироваться на моих основных задачах»,

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

Этап 6: Поддержка

Поддержка обычно осуществляется на 3 уровнях:

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

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

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

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

Источник

Особенности управления проектами в области разработки программного обеспечения

КУРСОВАЯ РАБОТА

Особенности управления
проектами в области разработки программного обеспечения

Введение

управление программный
проектный

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

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

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

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

Проектный подход к управлению уже доказал свою эффективность
на практике и применяется ведущими мировыми компаниями, его успешно используют
IBM, Motorola, Boeing, Intel и множество других.

1.
Теория управления программными проектами

.1
История и основные понятия

Программное обеспечение (далее ПО) появился в 1958 году
благодаря трудам статистика Джона Тьюкей.

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

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

Процесс разработки ПО — совокупность процессов,
обеспечивающих создание и развитие программного обеспечения.

Модель процесса разработки ПО — формализованное представление
процесса разработки ПО. Часто при описании процессов вместо слова модель
употребляется термин методология, что приводит к неоправданному расширению
данного понятия.

Согласно SWEBOK 2004, программная инженерия включает в себя
10 основных и 7 дополнительных областей знаний, на которых базируются процессы
разработки ПО. К основным областям знаний относятся следующие области:

. Software requirements — программные требования.

. Software design — дизайн (архитектура).

. Software construction — конструирование программного
обеспечения.

. Software testing — тестирование.

. Software maintenance — эксплуатация (поддержка)
программного обеспечения.

6. Software configuration management — конфигурационное управление.

. Software engineering management — управление в программной инженерии.

. Software engineering process — процессы программной инженерии.

. Software engineering tools and methods — инструменты и методы.

10. Software quality — качество программного обеспечения.

Дополнительные области знаний включают в себя:

. Computer engineering — разработка компьютеров.

. Computer science — информатика.

. Management — общий менеджмент.

. Mathematics — математика.

. Project management — управление проектами.

. Quality management — управление качеством.

. Systems engineering — системное проектирование.

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

.2
Эволюция подходов к управлению программными проектами

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

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

«Водопад» или каскадная модель. Жесткое управление с обратной
связью. Расчет опорной траектории (план проекта), измерение отклонений,
коррекция и возврат на опорную траекторию. Лучше, но не эффективно.

«Гибкое управление». Расчет опорной траектории, измерение
отклонений, расчет новой попадающей траектории и коррекция для выхода на нее.
«Планы — ничто, планирование — все» (Эйзенхауэр, Дуайт Дэвид)

«Метод частых поставок». Самонаведение. Расчет опорной
траектории, измерение отклонений, уточнение цели, расчет новой попадающей
траектории и коррекция для выхода на нее.

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

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

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

Известно, что производительность разных программистов может
отличаться в десятки раз. Утверждаю, что производительность одного и того же
программиста может так же отличаться в десятки раз. Заставьте лучшего в мире
бегуна бегать в мешке, и он покажет в 10 раз худший результат. Заставьте
лучшего программиста заниматься «сизифовым трудом»: плодить документацию
(которую, как правило, никто не читает) в угоду «Методологии» (именно с большой
буквы ‘М’), — и его производительность снизится в 10 раз.

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

.3
Оценка успешности проекта разработки программного обеспечения

Стив Макконнелл в своеих работах приводит тест программного
проекта на выживание. Это перечень из 33-х пунктов. Руководитель программного
проекта должен его периодически использовать для внутреннего аудита своих процессов.

Чтобы программный проект стал успешным, необходимо:

— Четко ставить цели.

— Определять способ достижения целей.

— Контролировать и управлять реализацией.

— Анализировать угрозы и противодействовать
им.

— Создавать команду.

. Ставим цели

.1. Концепция определяет ясные недвусмысленные цели.

.2. Все члены команды считают концепцию реалистичной.

.3. У проекта имеется обоснование экономической
эффективности.

.4. Разработан прототип пользовательского интерфейса.

.5. Разработана спецификация целевых функций программного
продукта.

.6. С конечными пользователями продукта налажена
двухсторонняя связь

. Определяем способ достижения целей

.1. Имеется детальный письменный план разработки продукта.

.2. В список задач проекта включены «второстепенные» задачи
(управление конфигурациями, конвертация данных, интеграция с другими
системами).

.3. После каждой фазы проекта обновляется расписание и
бюджет.

.4. Архитектура и проектные решения документированы.

.5. Имеется план обеспечения качества, определяющий
тестирование и рецензирование.

.6. Определен план многоэтапной поставки продукта.

.7. В плане учтены обучение, выходные, отпуска, больничные.

.8. План проекта и расписание одобрен всеми участниками
команды.

.1. У проекта есть куратор. Это такой топ-менеджер
исполняющей компании, который лично заинтересован в успехе данного проекта.

.2. У проекта есть менеджер, причем только один!

.3. В плане проекта определены «бинарные» контрольные точки.

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

.5. Между руководством и разработчиками установлены
доверительные отношения.

.6. Установлена процедура управления изменениями в проекте.

.7. Определены лица, ответственные за решение о принятии
изменений в проекте.

.8. План, расписание и статусная информация по проекту
доступна каждому участнику.

.9. Код системы проходит автоматическое рецензирование.

.10. Применяется система управления дефектами.

. Анализируем угрозы

.1. Имеется список рисков проекта. Осуществляется его
регулярный анализ и обновление.

.2. Руководитель проекта отслеживает возникновение новых
рисков.

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

. Работаем над созданием команды

.1. Опыт команды достаточен для выполнения проекта.

.2. У команды достаточная компетенция в прикладной области.

.3. В проекте имеется технический лидер.

.4. Численность персонала достаточна.

.5. У команды имеется достаточная сплоченность.

.6. Все участники привержены проекту.

Оценка и интерпретация теста

Оценка: сумма баллов, каждый пункт оценивается от 0 до 3:

— 0 — даже не слышали об этом;

— 1 — слышали, но пока не применяем;

— 2 — применяется частично;

— 3 — применяется в полной мере.

Поправочные коэффициенты:

— для малых проектов (до 5 человек) — 1.5;

— для средних (от 5 до 20 человек) — 1.25.

Результат:

— <40 — завершение проекта сомнительно.

— 40-59 — средний результат. В ходе проекта
следует ожидать серьезные проблемы.

— 60-79 — хороший результат. Проект, скорее
всего, будет успешным.

— 80-89 — отличный результат. Вероятность
успеха высока.

— >90 — великолепный результат. 100%
шансов на успех.

1.4
Критерии успешности проекта

Задача проекта — достижение конкретной бизнес-цели, при
соблюдении ограничений «железного треугольника» (Рисунок 2). Это означает, что
ни один из углов треугольника не может быть изменен без оказания влияния на
другие.

Например, чтобы уменьшить время, потребуется увеличить
стоимость и / или сократить содержание.

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

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

Согласно текущей редакции стандарта PMBOK, проект считается
успешным, если удовлетворены все требования заказчика и участников проекта.
Поэтому у проекта разработки ПО сегодня не три, а четыре фактора успеха:

. Выполнен в соответствие со спецификациями.

. Выполнен в срок.

. Выполнен в пределах бюджета.

. Каждый участник команды уходил с работы в 18:00 с чувством
успеха.

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

Эффективность это отношение полученного результата к
произведенным затратам. Нельзя рассматривать эффективность, исходя только из
результативности: чем больше ты производишь, чем больше делаешь, тем выше твоя
эффективность.

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

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

Современное предприятие обязано относиться к своим работникам
так же, как к своим лучшим клиентам. Главный капитал современной компании — это
знания.

Большая часть этих знаний неотъемлема от их носителя —
человека. Те предприятия, которые этого не поняли, не выживут потому, что не
смогут быть эффективными. Сегодня эффективное предприятие — это сервис.

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

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

.1
Особенности организации проектной команды

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

Роли и ответственности участников типового проекта разработки
ПО можно условно разделить на пять групп:

. Анализ. Извлечение, документирование и сопровождение
требований к продукту.

. Производство. Проектирование и разработка ПО.

. Тестирование. Тестирование ПО.

. Обеспечение. Производство дополнительных продуктов и услуг.

Группа анализа включает в себя следующие роли:

— Бизнес-аналитик. Построение модели
предметной области (онтологии).

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

— Системный аналитик. Отвечает за перевод
требований к продукту в функциональные требования к ПО.

— Специалист по требованиям.
Документирование и сопровождение требований к продукту.

— Менеджер продукта (функциональный
заказчик). Представляет в проекте интересы пользователей продукта.

Группа управления состоит из следующих ролей:

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

Куратор проекта. Оценка планов и исполнения проекта.
Выделение ресурсов.

— Системный архитектор. Разработка
технической концепции системы. Принятие ключевых проектных решений относительно
внутреннего устройства программной системы и её технических интерфейсов.

— Руководитель группы тестирования.
Определение целей и стратегии тестирования, управление тестированием.

— Ответственный за управление изменениями,
конфигурациями, за сборку и поставку программного продукта.

В производственную группу входят:

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

— Проектировщик базы данных.

— Проектировщик интерфейса пользователя.

— Разработчик. Проектирование, реализация и
отладка отдельных модулей системы.

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

Группа тестирования в проекте состоит из следующих ролей:

— Проектировщик тестов. Разработка тестовых
сценариев.

— Разработчик автоматизированных тестов.

— Тестировщик. Тестирование продукта. Анализ
и документирование результатов.

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

— Технический писатель.

— Переводчик.

— Дизайнер графического интерфейса.

— Разработчик учебных курсов, тренер.

— Участник рецензирования.

— Продажи и маркетинг.

— Системный администратор.

— Технолог.

— Специалист по инструментальным средствам.

— Другие.

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

Некоторые роли всегда должен исполнять только один человек.
Например, Руководитель проекта, Системный архитектор. Один человек может
исполнять несколько ролей. Возможны следующие совмещения ролей:

— Руководитель проекта + системный аналитик
(+ системный архитектор)

— Системный архитектор + разработчик

— Системный аналитик + проектировщик тестов
(+ технический писатель)

— Системный аналитик + проектировщик
интерфейса пользователя

— Ответственный за управление конфигурациями
+ ответственный за сборку и поставку (+ разработчик)

Крайне нежелательно совмещать следующие роли:

— Разработчик + руководитель проекта

— Разработчик + системный аналитик.

— Разработчик + проектировщик интерфейсов
пользователя.

— Разработчик + тестировщик

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

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

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

Из профессиональных программистов получаются отличные
тестировщики. Лучшая команда тестирования, которую я встречал, была в Luxoft.
Это были маститые программисты из одного академического НИИ с опытом 20-30 лет.

Они не осваивали новые программистские технологии, но
исключительно эффективно ломали то, что было сделано на их основе. Однако,
совмещать одновременно роли программиста и тестировщика — плохая практика.
Хороший программист убежден, что он пишет программы правильно и ему
психологически тяжело допустить, что где-то в его коде может быть ошибка.

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

В модели Scrum рекомендуются ежедневные совещания по
состоянию работ — «Stand Up Meeting», но мне кажется, что это применимо,
скорее, для небольших рабочих групп от 3 до 5 разработчиков. Хотя в критические
периоды проекта, приходилось проводить и ежедневные совещания.

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

2.2
Жизненный цикл проекта. Фазы и продукты

Ранее уже отмечалось, что каждый программный продукт имеет
свой жизненный цикл, в который проект разработки очередного релиза входит как
одна из фаз. Аналогично, каждый проект разработки ПО имеет свой собственный
жизненный цикл, который состоит из четырех фаз (Рисунок 3).

Жизненный цикл и основные продукты программного проекта

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

И, наконец, на фазе завершения мы должны подтвердить, что мы
разработали именно тот продукт, который задумали в концепции проекта, а также
провести приемо-сдаточные испытания (ПСИ) продукта на предмет соответствия его
свойств, определенным ранее требованиям.

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

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

Распределение ресурсов по фазам проекта

Проект часто начинается с идеи, которая появляется у одного
человека.

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

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

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

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

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

2.3
Особенности управления приоритетами проектов

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

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

Эта информация заносится в Устав проекта и, если он
одобряется, проект официально авторизуется.

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

В российской практике данный документ чаще называется
Концепция проекта.

Концепция (от лат. conceptio — понимание, система),
определённый способ понимания, трактовки какого-либо предмета, явления,
процесса, основная точка зрения на предмет и др., руководящая идея для их
систематического освещения.

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

Приоритет любого проекта должен определяться на основе оценки
трех его характеристик:

— Финансовая ценность.

— Стратегическая ценность.

— Уровень рисков.

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

Высокая. Ожидаемая окупаемость до 1 года. Ожидаемые доходы от
проекта не менее чем в 1.5 раз превышают расходы. Все допущения при проведении
этих оценок четко обоснованны.

Выше среднего. Ожидаемая окупаемость проекта от 1 года до 3
лет. Ожидаемые доходы от проекта не менее чем в 1.3 раза превышают расходы.
Большинство допущений при проведении этих оценок имеют под собой определенные
основания.

Средняя. Проект позволяет улучшить эффективность производства
в Компании и потенциально может снизить расходы компании не менее чем на 30%.
Проект может иметь информационную ценность или помочь лучше контролировать
бизнес.

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

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

Шкала оценки стратегической ценности проекта может иметь
следующий вид:

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

Выше среднего. Создает временные конкурентные преимущества.
Выполнение обязательств перед многими важными клиентами. Конкурентное
преимущество может быть удержано в течение 1 года.

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

Низкая. Стратегическое воздействие отсутствует или
незначительно. Влияние на клиентов несущественно. Конкуренты могут легко
повторить результаты проекта.

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

Примерная шкала оценки уровня рисков проекта может иметь
следующий вид:

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

Средний. Цели проекта определены более-менее четко. Хорошее
понимание требований к системе. Масштаб и рамки проекта заданы достаточно
хорошо. Ресурсы требуемой квалификации доступны в основном. Системы создаются
на новой, но стабильной технологической платформе.

Выше среднего. Цели проекта недостаточно четки. Задачи
системы или бизнес-приложения поняты недостаточно полно. Понимание масштаба и
рамок проекта недостаточно. Ресурсы требуемой квалификации сильно ограничены.
Системы создаются на новой технологической платформе, сомнения в рыночной
стабильности платформы.

Высокий. Цели проекта нечетки. Основные функциональные
компоненты системы не определены. Масштаб и рамки проекта непонятны. Ресурсы
требуемой квалификации практически отсутствуют. Системы создаются на новой
технологической платформе, в отношении которой крайне мало ясности. Технологии
имеют неподтвержденную стабильность.

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

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

2.4
Особенности рисков программных проектов и способы реагирования

В мировой практике выделяют пять основных причин неудачного
исполнения проекта:

— Требования заказчика отсутствуют / не
полны / подвержены частым изменениям.

— Отсутствие необходимых ресурсов и опыта.

— Отсутствие рабочего взаимодействия с
заказчиком.

— Неполнота планирования. «Забытые работы».

— Ошибки в оценках трудоемкостей и сроков
работ.

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

К часто упускаемым требованиям можно отнести:

— Функциональные

o Программы установки,
настройки, конфигурации.

o Миграция данных.

o Интерфейсы с внешними
системами.

o Справочная система.

— Общесистемные

o Производительность.

o Надежность.

o Открытость.

o Масштабируемость.

o Безопасность.

o Кросплатформенность.

o Эргономичность.

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

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

— Переоценка проекта каждый раз, когда
требования добавляются / изменяются (уклонение).

— Итерационная разработка. Контракт с
компенсацией затрат на основе «Time & Materials» (передача риска
Заказчику).

— Учет в оценках трудоемкости и сроков
возможности роста требований, например, на 50% (резервирование риска).

Для большинства программных продуктов применим принцип
Парето: 80% ценности продукта заключены лишь в 20% требований к нему.

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

— Привлечь экспертов-консультантов на
начальных этапах.

— Учитывать в оценках трудоемкости издержки
на обучение сотрудников.

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

— Учесть в оценках «время разгона» для новых
сотрудников.

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

— Постоянное взаимодействие.

— Согласование пользовательских интерфейсов
и разработка прототипа продукта.

— Периодические поставки тестовых версий
конечным пользователям для их оценки.

При планировании работ по проекту часто «забывают»:

— Обучение.

— Координация работ.

— Управление конфигурациями.

— Разработка и поддержка скриптов
автосборки.

— Разработка автотестов.

— Создание тестовых данных.

— Обработка запросов на изменения.

И еще. Не стоит надеяться, что участники проекта будут каждую
неделю по 40 часов работать именно над вашим проектом. Есть множество причин,
по которым они не смогут работать по проекту 100% своего времени. К списку
наиболее распространенных причин этого относятся:

— Сопровождение действующих систем.

— Повышение квалификации.

— Участие в подготовке технико-коммерческих
предложений.

— Участие в презентациях.

— Административная работа.

— Отпуска, праздники, больничные.

Рекомендация, планировать, что разработчики, которые
назначены в проект на 100% будут реально работать над ваши ми задачами в
среднем от 24 до 32 часов в неделю.

Заключение

Не существует единственного правильного процесса разработки
ПО.

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

Чтобы программный проект стал успешным, необходимо:

. Четко ставить цели.

. Определять способ достижения целей.

. Контролировать и управлять реализацией.

. Анализировать угрозы и противодействовать им.

. Создавать команду.

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

Участников типового проекта разработки ПО можно условно
разделить на пять групп ролей:

. Анализ. Извлечение, документирование и сопровождение
требований к продукту.

. Управление. Определение и управление производственными
процессами.

. Производство. Проектирование и разработка ПО.

. Тестирование. Тестирование ПО.

. Обеспечение. Производство дополнительных продуктов и услуг.

У программного проекта имеется четыре фактора, которые
определяют его успешность:

. Выполнен в соответствие со спецификациями.

. Выполнен в срок.

. Выполнен в пределах бюджета.

. Каждый участник команды уходил с работы в 18:00 с чувством
успеха.

Литература

1. Арчибальд Р. Управление
высокотехнологичными программами и проектами. М.: ДМК-Пресс.2002.

2. Грей К, Ларсен Э. Управление проектами.
Пер. с англ. — М.: «Дело и Сервис».2003.

. Дитхелм Г. Управление проектами. В 2 т.:
Пер. с нем. — СПб.: Издательский дом «Бизнес — пресса», 2003.-258 с.

. Кофанов Ю.Н. Теоретические основы
конструирования, технологии и надежности радиоэлектронных средств. — М.: Радио
и связь, 1991.-360 с.

. ЛитвакБ.Г. Экспертная информация. Методы
получения и анализа. — М.: Радио и связь, 1982.

. Руководство к Своду знаний по управлению
проектами. Третье издание (Руководство PMBOK)/. Американский национальный
стандарт ANSI/PMI 99-001-2004.

. Топка В.В. Вероятностное моделирование в
управлении проектами. — М., 1995 (Препринт / Институт проблем управления).

. Управление проектами. Основы
профессиональных знаний. Национальные требования к компетенции специалистов. —
М.: Изд-во «Консалтинговое Агентство «КУБС Групп — Кооперация, Бизнес-Сервис»,
2001.

. Управление проектами: Основы
профессиональных знаний. Национальные требования к компетентности специалистов.
М.: Изд-во «Консалтинговое Агенство «КУБС Групп — Кооперация, Бизнес — Сервис»,
2001-265 с.

. Щедровицкий Г.П. Организация.
Руководство. Управление. (Оргуправленческое мышление: идеология, методология,
технология. Курс лекций / из архива Г.П. Щедровицкого. Т.4). М.: «Путь», 2000 —
384 с.

Источник

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

Создание программного обеспечения
Управление проектами программного обеспечения

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

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

Программный проект

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

Необходимость управления программным проектом

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

Изображение выше показывает тройные ограничения для программных проектов. Это важная часть организации программного обеспечения для предоставления качественного продукта, сохранения затрат в рамках бюджета клиента и выполнения проекта в соответствии с графиком. Существует несколько факторов, как внутренних, так и внешних, которые могут повлиять на этот треугольник тройного ограничения. Любой из трех факторов может серьезно повлиять на два других.

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

Менеджер программных проектов

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

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

Давайте посмотрим, какие обязанности несет руководитель проекта –

Управление людьми

Выступать в качестве руководителя проекта
Связь с заинтересованными сторонами
Управление человеческими ресурсами
Настройка иерархии отчетов и т. Д.

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

Определение и настройка масштаба проекта
Управление деятельностью по управлению проектами
Мониторинг прогресса и производительности
Анализ рисков на каждом этапе
Сделайте необходимый шаг, чтобы избежать или выйти из проблем
Выступать в качестве представителя проекта

Деятельность по управлению программным обеспечением

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

Планирование проекта
Управление областью
Оценка проекта

Планирование проекта

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

Управление областью

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

Во время управления содержанием проекта необходимо:

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

Оценка проекта

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

Оценка проекта может включать в себя следующее:

Оценка размера программного обеспечения
Размер программного обеспечения может быть оценен либо в единицах KLOC (Kilo Line of Code), либо путем расчета количества функциональных точек в программном обеспечении. Строки кода зависят от практики кодирования, а функциональные точки различаются в зависимости от требований пользователя или программного обеспечения.
Оценка усилий
Менеджеры оценивают усилия с точки зрения потребности в персонале и человеко-часов, необходимых для производства программного обеспечения. Для оценки усилий должен быть известен размер программного обеспечения. Это может быть получено из опыта менеджеров, исторические данные организации или размер программного обеспечения могут быть преобразованы в усилия с использованием некоторых стандартных формул.
Оценка времени
Как только размер и усилия оценены, можно оценить время, необходимое для производства программного обеспечения. Требуемые усилия подразделяются на подкатегории в соответствии со спецификациями требований и взаимозависимостью различных компонентов программного обеспечения. Задачи программного обеспечения подразделяются на более мелкие задачи, действия или события с помощью Work Breakthrough Structure (WBS). Задачи запланированы на ежедневной основе или в календарных месяцах.

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

Размер программного обеспечения
Качество программного обеспечения
аппаратные средства
Дополнительное программное обеспечение или инструменты, лицензии и т. Д.
Квалифицированный персонал с конкретными навыками
Путешествие участвует
связь
Обучение и поддержка

Размер программного обеспечения может быть оценен либо в единицах KLOC (Kilo Line of Code), либо путем расчета количества функциональных точек в программном обеспечении. Строки кода зависят от практики кодирования, а функциональные точки различаются в зависимости от требований пользователя или программного обеспечения.

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

Как только размер и усилия оценены, можно оценить время, необходимое для производства программного обеспечения. Требуемые усилия подразделяются на подкатегории в соответствии со спецификациями требований и взаимозависимостью различных компонентов программного обеспечения. Задачи программного обеспечения подразделяются на более мелкие задачи, действия или события с помощью Work Breakthrough Structure (WBS). Задачи запланированы на ежедневной основе или в календарных месяцах.

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

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

Методы оценки проекта

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

Менеджер проекта может оценить перечисленные факторы, используя два широко признанных метода –

Техника Разложения

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

Есть две основные модели –

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

Методика эмпирической оценки

Этот метод использует эмпирически полученные формулы для оценки. Эти формулы основаны на LOC или FP.

Модель Putnam
Эта модель сделана Лоуренсом Х. Путнэмом, который основан на распределении частот Нордена (кривая Рэлея). Модель Putnam отображает время и усилия, необходимые с размером программного обеспечения.
COCOMO
COCOMO расшифровывается как COnstructive COst MOdel, разработанная Barry W. Boehm. Он делит программный продукт на три категории программного обеспечения: органическое, полуотдельное и встроенное.

Эта модель сделана Лоуренсом Х. Путнэмом, который основан на распределении частот Нордена (кривая Рэлея). Модель Putnam отображает время и усилия, необходимые с размером программного обеспечения.

COCOMO расшифровывается как COnstructive COst MOdel, разработанная Barry W. Boehm. Он делит программный продукт на три категории программного обеспечения: органическое, полуотдельное и встроенное.

Планирование проекта

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

Для составления расписания проекта необходимо:

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

Управление ресурсами

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

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

Управление ресурсами включает в себя –

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

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

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

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

Процесс управления рисками

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

Идентификация – запишите все возможные риски, которые могут возникнуть в проекте.
Категоризировать – классифицировать известные риски по высокой, средней и низкой интенсивности риска в соответствии с их возможным влиянием на проект.
Управлять – анализировать вероятность возникновения рисков на разных этапах. Составьте план, чтобы избежать или столкнуться с рисками. Попытайтесь минимизировать их побочные эффекты.
Монитор – внимательно отслеживать потенциальные риски и их ранние симптомы. Также следите за последствиями шагов, предпринятых для смягчения или предотвращения их.

Выполнение проекта и мониторинг

На этом этапе задачи, описанные в планах проекта, выполняются в соответствии с их графиками.

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

Эти меры включают в себя –

Мониторинг активности – все действия, запланированные в рамках какой-либо задачи, можно отслеживать на ежедневной основе. Когда все действия в задании завершены, оно считается выполненным.
Отчеты о состоянии. Отчеты содержат сведения о состоянии работ и задач, выполненных в течение определенного периода времени, обычно за неделю. Статус может быть помечен как завершенный, ожидающий или незавершенный и т. Д.
Контрольный список этапов – Каждый проект разделен на несколько этапов, на которых выполняются основные задачи (этапы) на основе этапов SDLC. Этот контрольный список этапов составляется раз в несколько недель и содержит информацию о состоянии этапов.

Управление коммуникациями проекта

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

Общение может быть устным или письменным. Процесс управления связью может иметь следующие этапы:

Планирование – этот этап включает в себя определение всех заинтересованных сторон в проекте и способ общения между ними. Он также учитывает необходимость каких-либо дополнительных средств связи.
Обмен – После определения различных аспектов планирования, менеджер сосредотачивается на том, чтобы делиться правильной информацией с правильным человеком в правильное время. Это позволяет каждому участнику проекта быть в курсе прогресса и статуса проекта.
Обратная связь – Руководители проектов используют различные меры и механизм обратной связи и создают отчеты о состоянии и эффективности. Этот механизм гарантирует, что вклад от различных заинтересованных сторон поступает к руководителю проекта в качестве обратной связи.
Закрытие – В конце каждого важного события, в конце фазы SDLC или в конце самого проекта, официально объявляется административное закрытие, чтобы обновить всех заинтересованных лиц, отправив электронное письмо, распространив бумажную копию документа или другим способом эффективного общения.

После закрытия команда переходит к следующему этапу или проекту.

Управление конфигурацией

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

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

Как правило, после того, как SRS будет завершен, вероятность внесения изменений со стороны пользователя будет меньше. Если они происходят, изменения рассматриваются только с предварительного одобрения высшего руководства, поскольку существует вероятность перерасхода средств и времени.

базисный

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

Управление конфигурацией – это дисциплина администрирования организации, которая заботится о возникновении любых изменений (процесс, требования, технологические, стратегические и т. Д.) После определения фазы. CM следит за любыми изменениями в программном обеспечении.

Смени управление

Контроль изменений – это функция управления конфигурацией, которая гарантирует, что все изменения, внесенные в программную систему, согласованы и выполнены в соответствии с организационными правилами и положениями.

Изменение конфигурации продукта проходит через следующие шаги –

Идентификация – запрос на изменение поступает из внутреннего или внешнего источника. Когда запрос на изменение идентифицирован формально, он надлежащим образом документируется.
Валидация – проверяется действительность запроса на изменение и подтверждается процедура его обработки.
Анализ – Влияние запроса на изменение анализируется с точки зрения графика, стоимости и необходимых усилий. Общее влияние предполагаемого изменения на систему анализируется.
Контроль. Если предполагаемое изменение затрагивает слишком много объектов в системе или является неизбежным, обязательно получить одобрение вышестоящих органов, прежде чем изменение будет включено в систему. Решено, стоит ли вносить изменения или нет. Если это не так, запрос на изменение отклоняется формально.
Выполнение – если на предыдущем этапе было решено выполнить запрос на изменение, на этом этапе предпринимаются соответствующие действия для выполнения изменения, при необходимости выполняется тщательный пересмотр.
Запрос на закрытие – изменение проверяется для правильной реализации и объединения с остальной системой. Это новое внесенное изменение в программное обеспечение задокументировано надлежащим образом, и запрос официально закрыт.

Идентификация – запрос на изменение поступает из внутреннего или внешнего источника. Когда запрос на изменение идентифицирован формально, он надлежащим образом документируется.

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

Анализ – Влияние запроса на изменение анализируется с точки зрения графика, стоимости и необходимых усилий. Общее влияние предполагаемого изменения на систему анализируется.

Контроль. Если предполагаемое изменение затрагивает слишком много объектов в системе или является неизбежным, обязательно получить одобрение вышестоящих органов, прежде чем изменение будет включено в систему. Решено, стоит ли вносить изменения или нет. Если это не так, запрос на изменение отклоняется формально.

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

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

Инструменты управления проектами

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

Доступны инструменты, которые помогают эффективно управлять проектами. Некоторые описаны –

Диаграмма Ганта

Диаграммы Ганта были разработаны Генри Ганттом (1917). Он представляет график проекта относительно периодов времени. Это горизонтальная гистограмма с столбцами, представляющими действия и время, запланированное для действий проекта.

Диаграмма PERT

Диаграмма PERT (Program Evaluation & Review Technique) – это инструмент, который изображает проект в виде сетевой диаграммы. Он способен графически представлять основные события проекта как параллельно, так и последовательно. События, которые происходят одно за другим, показывают зависимость более позднего события от предыдущего.

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

Гистограмма ресурса

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

Анализ критического пути

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

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

Источник

Топ методов управления проектами при разработке софта: Waterfall, Agile, Scrum, Kanban и другие

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

Управление проектом было слишком неповоротливым, а отклонение от четкого плана грозило крушением рабочего процесса в целом.

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

Процесс разработки в Waterfall выглядит как поток процессов от этапа к этапу с четкими требованиями и условиями. Пока не завершен один этап — нет перехода к другому.

В 1990-х годах на смену неповоротливым методам пришло семейство гибких

Конечно, мы говорим об Agile (agile software development, от англ. agile — проворный) методах разработки программного обеспечения. Новый подход к методологии управления проектами ворвался в IT и позже перешел в производство, инженерию, разработку искусственного интеллекта и т.д.

Первыми гибкими методами были: RAD (с ориентиром на качество при минимальном бюджете и ограниченном сроке), XP (экстремальное программирование с коллективным владением кодом), SCRUM (где каждый участник команды несет ответственность за результат), Kanban (визуализация этапов разработки на доске) и другие.

Четыре Agile-идеи, которые важно знать:

Люди в команде и взаимодействие между ними важнее процессов
Взаимодействие с заказчиком важнее согласования условий договора
Работающий продукт на первом месте. Документация — второстепенна
Готовность быстро реагировать на изменения важнее заранее утвержденного плана

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

Таблица сравнения

Agile	Waterfall
Гибкость рабочих процессов и внесение изменений при первой необходимости	Каскадная модель разработки с жесткой последовательностью процессов
Готовый продукт важнее документации	Документация важнее готового продукта
Личная ответственность каждого участника команды за результат	Ответственность за результат в целом на команде
Взаимодействие с заказчиком в процессе разработки	Заказчик не привлекается к рабочему процессу.
Максимальное вовлечение владельца продукта в рабочий процесс	Владелец продукта минимально задействован в рабочем процессе
Рабочий процесс разбивается на короткие спринты. Обычно от 1 недели до 1 месяца	Каждый рабочий процесс — отдельная фаза, которая длится до тех пор, пока не проходит этап тестирования и одобрения

Пример управления проектами по Канбан

Есть задача: снять обучающее видео для клиента. Для съемки обучающего ролика будет создан ряд однотипных задач: «Написание сценария», «Съемка», «Черновой монтаж», «Пост-обработка». Каждая из задач на Канбан доске будет отдельной колонкой.

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

Канбан или Скрам? Какая система управления проектами нужна

Выше мы описали плюсы и минусы этих двух гибких методов, но еще один интересный нюанс:

Scrum на старте работы над новым продуктом даст больше контроля и управляемости

Если Kanban — это максимальная гибкость, то Scrum — больше о контроле и управляемости. Когда процесс отлажен и все понятно — приходит на помощь Канбан. Он идеален для работы с однотипными задачами.

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

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

Как выбрать инструмент управления проектами?

Правильный выбор таск-менеджера — половина успеха. Как только вы определились с методом управления проектами и выбрали таск-менеджер, важно перевести работу над проектами и задачами в выбранную систему. С чем сталкиваются руководители при переходе к проектному менеджменту?

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

Кто-то воспринимает работу в таск-менеджере — как дополнительный контроль и недоверие. Здесь важно объяснить всей команде, что таймер, например, это необходимость, а не контроль или недоверие. Таймер — это как дополнительный инструмент для улучшения эффективности работы, прозрачности процесса и результата для клиента. Кстати, таймер — это еще и возможность обосновать необходимость в оплате труда сверх нормы (если для выполнения задачи понадобилось больше времени, чем заложили в задачу изначально).

6 признаков того, что таск-менеджер выбран правильно:

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

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

FAQ

Какие бывают методы управления проектами?

Каскадная (водопадная) и гибкая (итерационная) — две основные на сегодняшний день методологии управления проектами, включающие в себя набор методов. Каскадная: PERT, метод критического пути и освоенного объема, а также некоторые другие.
Итерационная («Agile Umbrella»): Scrum, Kanban, Feature Driven Development, XP (Extreme Programming), Lean, Six Sigma, PRINCE2. Ключевые принципы гибкой методологии Agile: участники проекта и коммуникация между ними приоритетнее процессов; эффективное взаимодействие с заказчиком приоритетнее, чем согласование условий договора; главное — работающий продукт, документы второстепенны; готовность к оперативному реагированию на произошедшие изменения важнее первоначального плана.

Что такое управление проектами?

Управление проектом (проектный менеджмент, Project Management) — совокупность действий, направленных на согласование участников проекта, процессов, инструментов и навыков для достижения поставленных перед проектом целей и запланированных результатов, в соответствии с выдвигаемыми требованиями.
Грамотное управление проектами помогает повысить процент успеха, прозрачность и наглядность, оптимизировать коммуникацию, и способствует оптимальному распределению имеющихся ресурсов (люди, время, финансы).

Как управлять проектами?

Наиболее эффективный и востребованный способ управления проектами — использование специфических инструментов контроля и управления. В большинстве случаев, эти инструменты представлены профильным программным обеспечением, где все необходимые функции объединены в удобном и наглядном интерфейсе. Современный рынок ПО предлагает обширный ассортимент подобных сервисов, каждый из которых обладает своими отличительными особенностями. Пользующиеся в настоящее время популярностью сервисы используют такие инструменты, как диаграмма Ганта, канбан доски и многие другие.

Каким проектам лучше всего подходит гибридная методология?

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

Для чего нужно управление проектами?

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

Что должен делать менеджер проекта?

Менеджер проекта (рroject-manager) — специалист, в круг обязанностей которого входит управление проектом, что включает в себя: создание технического задания проекта, создание проектной группы, настройка процесса работы над проектом, налаживание коммуникации между командой и заказчиком, устранение преград для участников проектной команды, контроль за соблюдением сроков, качества выполнения проекта и выделенного бюджета и ведение отчетности.

Что такое методология управления ИТ проектом?

Это свод правил и принципов, которых придерживаются в течение процесса работы. В сфере IT наиболее часто используется гибкая методология Agile и каскадная Waterfall. Выбор оптимальной стратегии определяется масштабами проекта, спецификой его задания, объемом выделенного времени и бюджетом.

Источник

Что такое управление проектами

Содержание

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

Оптимизируйте маркетинг и увеличивайте продажи вместе с Calltouch

Узнать подробнее

Что такое проект и его управление

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

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

Чем отличается проектное управление от традиционного менеджмента

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

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

Зачем нужно управление проектами

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

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

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

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

Технология
речевой аналитики
Calltouch Predict

Автотегирование звонков
Текстовая расшифровка записей разговоров

Узнать подробнее

Стандарты управления проектами

Это рекомендации и советы, на которые нужно ориентироваться при организации работы. Какие стандарты бывают:

Общественные. Разрабатывают и применяют в обществах специалистов.
Корпоративные. Разрабатывают и используют в рамках одной компании.
Частные. Создают специально для определенных проектов.

Есть международные стандарты управления проектами – правила организации работы в разных странах. Один из самых известных стандартов – PMBOK (A Guide to the Project Management Body of Knowledge). Это руководство по управлению проектами, где есть вся терминология и базовые принципы. Его применяют в более 160 странах мира.

Роли в проекте

Роль в проекте – это набор функций и полномочий для разделения обязанностей между членами команды. Стандарт PMBOK выделяет следующие роли:

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

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

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

Состав идеальной команды зависит от специфики и целей проекта: можно привлекать дополнительных специалистов или наоборот, исключать лишних.

Кто такой руководитель проекта

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

Требования к проект-менеджеру

Какие компетенции понадобятся руководителю проектов в работе:

Знания в области управления проектами, включая стратегическое мышление, умение прогнозировать и планировать.
Опыт. Чем больше у проект-менеджера кейсов, тем лучше он понимает как распоряжаться бюджетом, решать разные проблемы, взаимодействовать с командой.
Техническая подготовленность. Эффективный проект-менеджер – это не просто управленец, а компетентный специалист. Он может грамотно настроить все процессы, потому что разбирается в специфике проекта: IT-сфере, строительстве, архитектуре или других областях.
Умение работать с людьми. Способность сформировать и отладить работу внутри команды – половина успеха проекта.
Личностные качества: ответственность, коммуникабельность, аналитический склад ума, стрессоустойчивость, многозадачность и оптимизм.

Преимущества проектного метода управления и его недостатки

Плюсы проектного управления:

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

Минусы формата:

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

Основные этапы управления проектом

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

Инициирование проекта

На этой стадии определяют суть и цели проекта, выбирают руководителя, рассчитывают предварительный бюджет и ресурсы. Инициация – первичное содержание проекта, которое уточняют и дополняют в процессе. Чем крупнее проект, тем тщательнее прорабатывается этот этап.

Планирование проекта

Теперь нужно определить, как именно будет выполняться проект:

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

Планирование – это не только создание плана на старте, но и способность подготовиться к будущим проблемам, правкам и изменениям требований.

Исполнение проекта

Следующий шаг – запуск операций по плану. Здесь важно качественно выстроить работу внутри коллектива: всех познакомить, четко объяснить функции и задачи, продумать мотивацию для сотрудников.

Мониторинг и контроль проекта

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

Контролировать работу легче с помощью автоматизированных систем: CRM и других сервисов. Например, сквозная аналитика от Calltouch поможет проанализировать эффективность интернет-рекламы. Система объединяет данные со всех площадок в одном окне. С помощью наглядных отчетов можно сделать выводы об эффективности, оптимизировать затраты и выстроить полноценную воронку продаж.

Сквозная аналитика Calltouch

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

Узнать подробнее

Закрытие проекта

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

Подходы к управлению жизненным циклом проекта

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

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

Какую выбрать методологию

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

Waterfall

Эту модель еще называют каскадной или водопадной. Главный принцип метода – последовательное и четкое соблюдение всех этапов по заранее продуманному плану. Например, этапы разработки IT-продукта по методологии Waterfall:

аналитика;
проектирование;
разработка;
тестирование;
эксплуатация и поддержка.

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

Agile

В отличие от Waterfall, Agile – целый набор гибких методик. Его главная ценность – это качество продукта, поэтому agile-команды постоянно поддерживают контакт с заказчиком и готовы к любым изменениям и доработкам. Обычно методология используется в IT-сфере при работе небольших групп сотрудников, занятых творческой работой.

Scrum

Scrum – это часть методологии Agile. Здесь тоже в приоритете результат и удовлетворение запросов заказчика, поэтому его максимально вовлекают в процесс. Работа состоит из коротких периодов – спринтов. В рамках спринта создается часть продукта, которую тестируют демонстрируют клиенту. По обратной связи от клиента команда улучшает эффективность.

Kanban

«Kanban» переводится как «доска объявлений». Это тоже часть Agile-философии, включающая ее базовые принципы. Методологию используют для равномерного распределения обязанностей между сотрудниками, чтобы не перегрузить команду.

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

Инструменты для управления проектами

Чтобы руководителю было проще выстраивать и контролировать процессы, разработчики создают специальные сервисы и ПО, которые автоматизируют часть работы. Самые популярные:

Битрикс24 – российский сервис для управления бизнесом: поддерживает работу с Kanban, диаграммой Ганта, обеспечивает продвинутую фильтрацию в задачах.
Jira – это система отслеживания ошибок в программном коде. При этом множество компаний использует ее инструментарий для управления проектами. Подходит для работы по Scrum и Kanban.
Asana – это приложение для управления командными проектами. Есть система удобных тегов, можно анализировать эффективность и управлять несколькими проектами в рамках одной команды.

Заключение

Проектный менеджмент – это один из самых прогрессивных методов управления в компании. Его применяют для решения задач в любой сфере: бизнесе, общественной деятельности или госуправлении. Проектный подход позволяет заранее обозначить важные цели и максимально эффективно использовать бюджет и другие ресурсы. Однако сама по себе система не решит проблем. Чтобы выстроить управление в соответствии со спецификой и задачами конкретного бизнеса нужен грамотный менеджер.

Предложения от наших партнеров

Источник

В последние годы в перечне вакансий все чаще можно увидеть загадочное словосочетание «менеджер проекта» или «руководитель проекта» (международный термин: project manager — РМ). Что же стоит за этими словами? Почти каждый руководитель или специалист может с уверенностью сказать, что по долгу службы управляет теми или иными проектами, исполняя при этом роль менеджера проекта. На современном рынке труда есть также специалисты, для которых управление проектами — профессия. Такой менеджер может быть как штатным сотрудником компании, так и внешним управляющим, берущимся за реализацию перспективных начинаний, гарантией успеха которых служит его репутация в профессиональном сообществе. В чем же специфика работы РМ?

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

Из этих различий и вытекают плюсы и минусы профессионального руководства проектами.

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

Что же это такое, УПРАВЛЕНИЕ ПРОЕКТОМ?

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

Элементы проекта.

1. Цель проекта. Измеряемый конечный результат (выход, продукция), определяемый в терминах затрат, качества и времени реализации (чего? Сколько? И когда?).

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

3. Уникальность. Проект – это разовое начинание, которое не будет повторяться. Даже «повторяющиеся» проекты, например, по строительству одного предприятия по той же проектной документации, значительно отличаются друг от друга использующимися ресурсами и средой реализации.

4. Ограниченность во времени. Проект имеет начало и конец. Для его реализации необходима временная концентрация ресурсов. Со временем ресурсы могут быть перепрофилированы на другие цели.

5. Жизненный цикл. По мере реализации проекта изменяется потребность в тех или иных ресурсах. Это изменение идет в определенной предсказуемой последовательности.

С точки зрения планирования и контроля проект целесообразно разбивать на этапы:

Этап 1. Среда проекта, влияющие на проект внутренние и внешние факторы.

Этап 2. Формулирование проекта – постановка целей, задач и выработка стратегии реализации проекта.

Этап 3. Планирование проекта – система мероприятий по реализации проекта.

Этап 4. Техническое исполнение – непосредственное техническое выполнение пунктов плана проекта (набора мероприятий).

Этап 5. Управление проектом – контроль за выполнением проекта в соответствии с планом.

Формулирование проекта.

В основе лежат 3 элемента:

• Цели проекта – чего достигнет проект в своей конечной точке,

• Задачи проекта – спектр работ и операций (мероприятий) пот проекту,

• Стратегия – каким путем руководители проекта приведут его к цели (способ достижения цели).

Иерархия целей.

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

Ясность цели. Хорошая цель – это ясная цель, измеримая, предпочтительно количественно. Для уяснения цели проект полезно разбить на 3 составляющие:

1) цель – преодолеть кризис, предотвратить спад производства, обеспечить запланированный объемы выпуска продукции;

2) конечный результат – представить отчет о причинах снижения производственных показателей и рекомендуемых мерах по исправлению положения дел;

3) критерий успеха – отчет должен быть готов к 30 июня, рекомендации должны предусматривать объем выпуска на уровне не ниже 70 тонн в год, а стоимость плана мероприятий (рекомендаций) не должна превышать 100 тыс. долл.

Цели управления проектом.

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

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

Качество – результат должен соответствовать цели, работать так, как задумано.

Спецификация проекта.

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

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

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

Внешние изменения возникают в результате решения покупателя изменить спецификацию. Например, при изменении международного стандарта, покупатель самолета решает заменить все навигационное оборудование.

Стратегия проекта.

Стратегия проекта – это способ достижения целей и показателей проекта.

Пример: 2 вида стратегии Олимпиады в Сочи: 1) все объекты строить в самом Сочи, 2) сделать Сочи только титульной столицей.

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

Этапы могут быть следующими:

• Этап спецификации – учет требований потребителей, составление спецификаций системы.

• Этап разработки – определение структуры системы и составление спецификаций подсистем.

• Этап реализации – разработка модулей.

• Этап тестирования модулей – каждый модуль тестируется отдельно.

• Этап поставки – передача системы покупателю.

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

1. Согласование общей концепции с клиентом;

2. Подготовка и согласование сценария;

3. Съемка рекламного ролика;

4. Демонстрация клиенту первого варианта;

5. Окончательная съемка ролика, согласованного с клиентом.

Выявление отношений и зависимостей.

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

Выявление ограничений.

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

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

Ограничение по времени – главный приоритет – завершение проекта точно в срок. После использования накопленных ресурсов привлекаются дополнительные «пороговые» ресурсы.

КВАДРАТ ДЕКАРТА

БУДЕТ
Что будет, если это не произойдет?	Что будет, если это произойдет?
НЕ ПРОИЗОЙДЕТ	ПРОИЗОЙДЕТ
Чего не будет, если это не произойдет?	Чего не будет, если это произойдет?
НЕ БУДЕТ

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

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

Управление проектами.docx

Андрей Сооляттэ. Управление проектами в компании. Методология, технологии, практика..docx

Источник

Руководство программным проектом

Библиографическая ссылка

Жизненный цикл разработки IT-продукта

Этап 1: Идея

Этап 2: Контакт

Этап 3: Планирование

Этап 4: Дизайн

Этап 5: Разработка и тестирование

Этап 6: Поддержка

Особенности управления проектами в области разработки программного обеспечения

Введение

1. Теория управления программными проектами

.1 История и основные понятия

.2 Эволюция подходов к управлению программными проектами

.3 Оценка успешности проекта разработки программного обеспечения

1.4 Критерии успешности проекта

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

.1 Особенности организации проектной команды

2.2 Жизненный цикл проекта. Фазы и продукты

2.3 Особенности управления приоритетами проектов

2.4 Особенности рисков программных проектов и способы реагирования

Заключение

Литература

Программный проект

Необходимость управления программным проектом

Менеджер программных проектов

Управление людьми

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

Деятельность по управлению программным обеспечением

Планирование проекта

Управление областью

Оценка проекта

Методы оценки проекта

Техника Разложения

Методика эмпирической оценки

Планирование проекта

Управление ресурсами

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

Процесс управления рисками

Выполнение проекта и мониторинг

Управление коммуникациями проекта

Управление конфигурацией

базисный

Смени управление

Инструменты управления проектами

Диаграмма Ганта

Диаграмма PERT

Гистограмма ресурса

Анализ критического пути

В 1990-х годах на смену неповоротливым методам пришло семейство гибких

Четыре Agile-идеи, которые важно знать:

Популярные системы управления проектами в Agile

Scrum

Для кого подходит Scrum?

+ Плюсы

— Минусы

Пример управления проектами по методу Scrum

Контроль скорости завершения спринтов — важный элемент Scrum

Kanban

+ Плюсы

Гибкость Канбана — лучшее, что можно придумать для ведения проектов с частыми изменениями исходных данных или постоянным потоком новых задач.

— Минусы

Пример управления проектами по Канбан

Канбан или Скрам? Какая система управления проектами нужна

Как выбрать инструмент управления проектами?

6 признаков того, что таск-менеджер выбран правильно:

FAQ

Какие бывают методы управления проектами?

Что такое управление проектами?

Как управлять проектами?

Каким проектам лучше всего подходит гибридная методология?

Для чего нужно управление проектами?

Что должен делать менеджер проекта?

Что такое методология управления ИТ проектом?

Что такое управление проектами

Что такое проект и его управление

Чем отличается проектное управление от традиционного менеджмента

Зачем нужно управление проектами

Стандарты управления проектами

Роли в проекте

1.
Теория управления программными проектами

.1
История и основные понятия

.2
Эволюция подходов к управлению программными проектами

.3
Оценка успешности проекта разработки программного обеспечения

1.4
Критерии успешности проекта

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

.1
Особенности организации проектной команды

2.2
Жизненный цикл проекта. Фазы и продукты

2.3
Особенности управления приоритетами проектов

2.4
Особенности рисков программных проектов и способы реагирования