∙спиральная модель разрешает пользователям "увидеть" систему на ранних этапах, что обеспечивается посредством использования ускоренного прототипирования в жизненном цикле разработки ПО;
∙обеспечивается определение непреодолимых рисков без особых дополнительных затрат;
∙эта модель разрешает пользователям активно принимать участие при планировании, анализе рисков, разработке, а также при выполнении оценочных действий;
∙в модели предусмотрена возможность гибкого проектирования, поскольку в ней воплощены преимущества каскадной модели, и в тоже время, разрешены итерации по всем фазам этой же модели;
8 Методика планирования WBS. Особенности, сфера применения.
WBS – Work Breakdown Structure (иерархическая структура проекта), является частью PMBOK.
WBS
WBS является средством для разделения всех работ по проекту на управляемые, определяемые пакеты работ, позволяющие достичь уровень детализации предоставляемой информации, соответствующий потребностям руководства проекта в контроле. WBS позволяет определить работу по проекту с точки зрения жизненного цикла проекта.
WBS позволяет свести цели проекта к иерархии средств их достижения, или, что то же, получения результатов, предусмотренных проектом. WBS является так же инструментом, позволяющим руководителю проекта получить описание конечного результата (продукта, услуги) проекта и всех подпроектов, в результате которых будет достигнут запланированный результат. Далее WBS может разделяться (и результаты подразделяться) на части для специализации видов и объемов работ участников проекта, координации их действий и закрепления ответственности за объемами работ, вплоть до уровня, обеспечивающего управляемость и надлежащее администрирование проекта.
Применяют следующие виды WBS:
● Продуктовая, когда проект разбивается по элементам продукта проекта
● Функциональная: декомпозиция по функциональным областям менеджмента
● По этапам жизненного цикла проекта
9 Методика планирования Gantt. Особенности, сфера применения.
Диагра́мма Га́нтта - это популярный тип столбчатых диаграмм (гистограмм), который используется для иллюстрации плана, графика работ по какому-либо проекту. Является одним из методов планирования проектов. Используется в приложениях по управлению проектами.
- работа с параметром ее
длительности
- Веха, как результат работы или
группы работ
10 Методика планирования CPM и ее вариант PERT. Особенности, сфера применения.
Метод критического пути - инструмент планирования расписания и управления сроками проекта.
В основе метода лежит определение наиболее длительной последовательности задач от начала проекта до его окончания с учетом их взаимосвязи.
Задачи, лежащие на критическом пути (критические задачи), имеют нулевой резерв времени выполнения, и, в случае изменения их длительности, изменяются сроки всего проекта. В связи с этим, при выполнении проекта критические задачи требуют более тщательного контроля, в частности, своевременного выявления проблем и рисков, влияющих на сроки их выполнения и, следовательно, на сроки выполнения проекта в целом. В процессе выполнения проекта критический путь проекта может меняться, так как при изменении длительности задач некоторые из них могут оказаться на критическом пути.
Ключевая задача метода – определить критический путь, и установить на нем максимальный контроль выполнения задач.
Действия при построении CPM
- Определить индивидуальные задачи.
- Определить последовательность этих задач.
- Нарисовать диаграмму в виде сети взаимосвязанных задач.
- Оценить время каждой активности.
- Выделить критический путь (наибольшая цепочка действий в вашей сети)
- Мониторинг диаграммы по ходу проекта.
Образец CPM
1 путь: начало-A1-A3-A6-конец = 3+1+3 = 7 (критический путь)
2 путь: начало-A1-A4-конец = 3+2 = 5 (резерв 2)
3 путь: начало-A2-A5-конец = 4+2 = 6 (резерв 1)
Отличие PERT от CPM
Бывают случаи, когда точно определить длительность задачи сложно или невозможно (инновационный проект или проект с рисками). Для этих случаев лучше использовать PERT метод:
- он вероятностный (4 измерения времени - )
- он учитывает риски
Измерения времени PERT
Оптимистическое время (optimistic time) (O): минимальное возможное время для выполнения задачи, в предположении что все происходит лучше чем ожидается.
Пессимистическое время (pessimistic time) (P): максимально возможное время требующееся для выполнения задачи, в предположении что все происходит неправильно (исключая крупные катастрофы).
Наиболее вероятное время (most likely time) (M): оценка времени, требующегося для выполнения задачи, в предположении, что все происходит как обычно.
Ожидаемое время (expected time) (TE): лучшая оценка времени, требуемого для выполнения задачи, учитывая, что вещи не всегда происходят как обычно. (Ожидаемое среднее время выполнения задачи, если она будет повторяться многократно).
11 Методика планирования Agile-доска (варианты scrum и kanban). Особенности, сфера применения.
Гибкая методология создания проекта программного средства (например, ИС).
Привязана к основным положениям Agile методов разработки.
Agile — простая и симпатичная философия
Если вы думаете, что авторы Agile Manifesto написали сборник советов о работе над проектом, вы немного ошибаетесь. Манифест включает в себя 4 ценности, 12 принципов и 0 практик.
Начнем с ценностей, потому что именно они соль Agile:
Люди и взаимодействие важнее процессов и инструментов.
Работающий продукт важнее исчерпывающей документации.
Сотрудничество с заказчиком важнее согласования условий контракта.
Готовность к изменениям важнее следования первоначальному плану.
В этом виде Agile похож на религию прекраснодушных ИТ-эльфов. Авторы как будто не знают, что разработка ПО — это бессонные ночи авралов, скандалы между проектировщиками и кодерами, переносы релизов, нервы и прочие прелести реальной жизни.
К счастью, Agile — больше, чем набор из четырех заповедей. Авторы прописали в манифесте также 12 принципов методологии. Принципы тоже непохожи на руководство стартапера, но в них уже есть настоящее мясо.
Основополагающие принципы Agile-манифеста
1. Наивысшим приоритетом для нас является удовлетворение потребностей
заказчика, благодаря регулярной и ранней поставке ценного программного
обеспечения.
2. Изменение требований приветствуется, даже на поздних стадиях разработки.
Agile-процессы позволяют использовать изменения для обеспечения заказчику
конкурентного преимущества.
3. Работающий продукт следует выпускать как можно чаще, с периодичностью
от пары недель до пары месяцев.
4. На протяжении всего проекта разработчики и представители бизнеса должны
ежедневно работать вместе.
5. Над проектом должны работать мотивированные профессионалы. Чтобы
работа была сделана, создайте условия, обеспечьте поддержку и полностью
доверьтесь им.
6. Непосредственное общение является наиболее практичным и эффективным
способом обмена информацией как с самой командой, так и внутри команды.
7. Работающий продукт — основной показатель прогресса.
8. Инвесторы, разработчики и пользователи должны иметь возможность
поддерживать постоянный ритм бесконечно. Agile помогает наладить такой
устойчивый процесс разработки.
9. Постоянное внимание к техническому совершенству и качеству
проектирования повышает гибкость проекта.
10. Простота — искусство минимизации лишней работы — крайне необходима.
11. Самые лучшие требования, архитектурные и технические решения рождаются
у самоорганизующихся команд.
12. Команда должна систематически анализировать возможные способы
улучшения эффективности и соответственно корректировать
стиль своей работы.
Команды в Kanban и Scrum
Scrum и Kanban — это гибкие методологии создания продукта. По ним можно работать в любой отрасли, но особенно хорошо они подходят для ИТ. В основе обеих методологий лежат принципы Agile, работают небольшие автономные команды из 5—9 человек.В командах нет формального руководителя, и никто извне не диктует, как организовывать работу над продуктом.
Чистый Scrum — более директивная методология — больше предписаний. Kanban — демократичнее, поэтому его проще внедрить.
Kanban. Над задачей может работать несколько узкопрофильных команд. К примеру, сначала работают аналитики, потом дизайнеры рисуют прототип, а на третьем этапе включаются разработчики.
При этом универсальные команды не запрещены.
В Kanban внутри команды нет ролей.
Scrum. Над проектом работает одна универсальная команда. В ней столько разноплановых специалистов, сколько нужно для решения любой задачи проекта.
Поскольку команда самоорганизуется, у специалистов scrum-команды нет формальной компетенции. Когда необходимо, тестировщик помогает дизайнеру, а аналитик — разработчику.
В scrum-команде помимо собственно специалистов есть две роли.
Scrum-мастер — человек, который организует работу. Это не управленческая должность, и он не раздает указания. Его задачи:
1. вести собрания;
2. устранять препятствия в работе (если команде мешает перфоратор в соседнем офисе, мастер ищет выход);
3. замечать и вытаскивать на поверхность скрытые проблемы;
4. отвечать за соблюдение методологии;
5. следить за статусом задач.
В свободное от этих задач время скрам-мастер работает так же, как другие члены команды.
Владелец продукта — product owner — определяет ход проекта, он может представлять внешнего заказчика. Владелец знает все о рынке и целевой аудитории. Он ставит приоритеты задачам. Результат работы команда представляет владельцу продукта.
12 Методика планирования RACI. Особенности, сфера применения.
RACI matrix (RAM Responsibility Assignment Matrix) – график линейной ответственности. Показывает степень участия разных ролей в разных активностях процесса или проекта.
Выделяют множество альтернативных вариаций, из которых наиболее применимы RACI-VS и RASCI.
Матрица RACI
Матрица представляет собой таблицу, столбцами которой являются роли, а строками – деятельности процесса или проекта.
На пересечении столбца и строки устанавливается одна из следующих вариативных опций:
Responsible (на матрице отмечается буквой R) – ответственный непосредственно за выполнение работы
Accountable (A) – подотчетный, такую роль может занимать только один человек на одной задаче
Consulted (C) – один сотрудник или группа, с которыми проводятся консультации касательно задачи и мнения которых должно учитываться
Informed (I) – сотрудники, уведомляемые о выполнении конкретной задачи.
Вариации RACI
- В вариации RACI-VS добавляются еще две функции: Verifies (V) – один сотрудник или группа, проверяющие соответствие результата выполнения задачи согласованным заранее допустимым критериям, Signs off (S) – утверждает сдачу продукта заказчику (выполнения задачи). Данную роль можно совместить с подотчетной ролью.
- В вариации RASCI добавляется роль Supportive (S) – предоставляет дополнительные ресурсы для выполнения работы, такой как поддержка внедрения продукта, к примеру.
Пример RACI диаграммы
Анализ результатов по осям
По функциональным ролям:
Много «А» — правильно ли распределены обязанности? Есть ли в наличии «узкие места»?
Много «R» — не много ли мы ответственности повесили на одну роль?
Отсутствие пустых ячеек в таблице – действительно ли эта роль должна быть вовлечена в такое количество задач?
По выполняемым активностям:
Более одного «А» — только одна роль должна быть подотчетной
Отсутствие «А» — необходимо найти подотчетного
Более одного «R» или отсутствие такового – кто-то должен быть ответственный, однако нам не нужно, чтобы ответственность была широко распределена – есть риск того, что задача не будет выполнена
Много «С» — стоит ли нам консультироваться с многими ролями и будет ли это эффективно?
Отсутствие «С» и «I» — правильно ли у нас установлены коммуникации?
Дата: 2018-12-28, просмотров: 341.
