Шпаргалка: WBS как средство управления
С помощью WBS поддерживается эффективное управление проектом по стадиям жизненного цикла. Это обеспечивается за счет:
разделения результатов на составные части (таким образом, гарантируется, что график проекта соответствует утвержденному объему работ и что все необходимые результаты проекта запланированы); поддержки планирования и назначения ответственных исполнителей; осуществления контроля состояния распределения ресурсов, оценки стоимости, расходов и выполнения; декомпозиции на простые компоненты, обеспечивая один из основных методов управления комплексными проектами. помощи в определении требований к ресурсам (т.е. квалификации, характеристик и т.д.).
WBS при формировании организационной структуры С помощью WBS можно связать определенный объем работ с элементом организационной структуры, субподрядчиками или отдельными исполнителями. Как только работы и область ответственности определяются, отдельные исполнители (включая субподрядчиков) назначаются ответственными за выполнение определенных элементов WBS в рамках назначенных бюджетов и определенных сроков выполнения.
Гибкая методология Scrum — это набор принципов, на которых строится процесс разработки, позволяющий в жёстко фиксированные небольшие промежутки времени (спринты от 2 до 4 недель) предоставлять конечному пользователю работающее ПО с новыми возможностями, для которых определён наибольший приоритет. Возможности ПО к реализации в очередном спринте определяются в начале спринта на этапе планирования и не могут изменяться на всём его протяжении. При этом строго фиксированная небольшая длительность спринта придаёт процессу разработки предсказуемость и гибкость.
РОЛИ ScrumMaster — тот, кто ведёт Scrum митинги и следит, чтобы при этом соблюдались все принципы Scrum (роль не предполагает ничего кроме корректного ведения самого Scrum-а. Владелец Продукта (Product Owner)— человек, который представляет интересы конечных пользователей и других заинтересованных в продукте сторон; и кросс-функциональная. Руководитель проекта скорее относится к Product Owner и не должен являться ScrumMaster).
Команда (Scrum Team),состоящая как из разработчиков, так и из тестировщиков, архитекторов, аналитиков и т. д. (при этом размер команды в идеале составляет 7±2 человека). Команда является единственным полностью вовлечённым участником разработки, и отвечает за результат как единое целое. Никто кроме команды не может вмешиваться в процесс разработки на протяжении спринта.
Скрам процессы На протяжении каждого спринта создаётся функциональный рост программного обеспечения. Набор возможностей, которые реализуются в каждом спринте, происходят из этапа, называемого product backlog(документация запросов на выполнение работ), обладающего наивысшим приоритетом по уровню требований к работе, который должен быть выполнен. Запросы на выполнение работ (backlog items), определенных на протяжении совета по планированию спринта (sprint planning meeting), перемещаются в этап спринта. На протяжении этого собрания Владелец Продукта информирует о заданиях, которые должны быть выполнены. Тогда Команда определяет, сколько из желаемого они могут выполнить, чтобы завершить необходимые части на протяжении следующего спринта. Во время спринта команда выполняет определенный фиксированный список заданий (т. н. sprint backlog). На протяжении этого периода никто не имеет права менять список требований к работе, что следует понимать как заморозку требований (requirements) во время спринта.
Product backlog (бэклог) Это документ, содержащий список требований к функциональности, которые упорядочены по степени важности. Product backlog представляет собой список того, что должно бытьреализовано. Элементы этого списка называются «историями» (user story) или элементами backlog’a (backlog items). Product backlog открыт для редактирования для всех участников Scrum-процесса.
Product backlog (Обязательные поля) ID — уникальный идентификатор, порядковый номер, применяемый для идентификации историй в случае их переименования.
Название (Name)— краткое описание истории. Оно должно быть однозначным, чтобы и разработчики, и product owner могли понять, о чем идёт речь и отличить одну историю от другой.
Важность (Importance)— степень важности данной истории, по мнению product owner’a. Обычно представляет собой натуральное число, иногда для этой цели используются числа Фибоначчи. Чем больше значение, тем выше приоритет.
Предварительная оценка (initial estimate) — начальная оценка объёма работ, необходимого для реализации истории по сравнению с другими историями. Измеряется в story point’ах. Приблизительно соответствует числу «идеальных человеко-часов».
Как продемонстрировать (how to demo) — краткое пояснение того, как завершённая задача будет продемонстрирована в конце спринта. Данное поле может представлять собой код автоматизированного теста для приёмо-сдаточного испытания.
Дополнительные поля Категория (track).Например, «панель управления» или «оптимизация». При помощи этого поля product owner может легко выбрать все пункты категории «оптимизация» и установить им низкий приоритет. Компоненты (components)— указывает, какие компоненты (например, база данных, сервер, клиент) будут затронуты при реализации истории. Данное поле состоит из группы checkbox’ов, которые отмечаются, если соответствующие компоненты требуют изменений.Инициатор запроса (requestor).Product owner может захотеть хранить информацию о всех заказчиках, заинтересованных в данной задаче. Это нужно для того, чтобы держать их в курсе дела о ходе выполнения работ.
ID в системе учёта дефектов (bug tracking ID)— если вы используете отдельную систему для учёта дефектов (например. Jira), тогда в описании истории полезно хранить ссылки на все дефекты, которые к ней относятся.
Sprint backlog Содержит функциональность, выбранную Product Owner из Product Backlog. Все функции разбиты по задачам, каждая из которых оценивается командой. Каждый день команда оценивает объем работы, который нужно проделать для завершения задач.
Планирование спринта (Planning Meeting) Происходит в начале итерации. Выбирается объём работ, обязательства по выполнению которой за спринт принимает на себя команда Обсуждается и определяется, каким образом будет реализован этот объём работ Каждая запись в Product Backlog, принятая к реализации, разбивается на подзадачи, которые оцениваются в идеальных человеко-часах Ограничено сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.
Покер планирования (англ. Planning Poker, а также англ. Scrum poker) — техника оценки, основанная на достижении договорённости, главным образом используемая для оценки сложности предстоящей работы или относительного объёма решаемых задач при разработке программного обеспечения. Ведущий озвучивает задачу (новая опция в программном продукте). Участники обсуждают задачу, задавая ведущему и друг другу вопросы. После этого всем дается время на обсуждение.По сигналу ведущего игроки кладут карту со своей оценкой рубашкой вверх – так, чтобы ее не видели другие. После этого звучит команда «Вскрываемся!» и команда видит результаты оценок друг друга.
Участники, оценившие задачу по верхней и нижней границе должны объяснить свое решение другим участникам.Обсудив предложения игроков, команда запускает еще один раунд оценки. Цель покера– спустя несколько раундов свести оценку всех участников команды к единой цифре (или близкой к ней).
Демонстрация (Demo Meeting Происходит в конце итерации (спринта). Команда демонстрирует инкремент функциональности продукта всем заинтересованным лицам.
Привлекается максимальное количество зрителей.Все члены команды участвуют в демонстрации (один человек на демонстрацию или каждый показывает, что сделал за спринт).
Ограничена 4-мя часами в зависимости от продолжительности итерации и инкремента продукта.
РетроспективаВсе члены команды рассказывают своё отношение к ходу прошедшего спринта. Отвечают на два основных вопроса: Что было сделано хорошо в прошедшем спринте? Что надо улучшить или не допускать в следующем?
Выполняют улучшение процесса разработки (решают вопросы и фиксируют удачные решения).Ограничена 1—3-мя часами.
Сетевой график отражает операции проекта, которые необходимо выполнить, логическую последовательность и взаимозависимость этих операций и время начала и окончания самой продолжительной цепочки операций — критический путь. раскрывает внутренние связи проекта и служит основой для календарного планирования работ и использования оборудования. дает возможность оценить периоды времени, в течение которых выполнение операций может начинаться и заканчиваться, а также время допустимой задержки их выполнения.Сетевой график позволяет определить, какие операции являются «критическими ПостроениеСетевой график строится при помощи прямоугольников (блоков) и стрелок.Блок обозначает операцию и стрелка показывает подчиненность операций и направленность хода выполнения проекта.
Работа–представляет собой трудовой процесс, требующий затрат времени и ресурсов. Работу изображают простой стрелкой. Продолжительность проставляется цифровым значением над стрелкой. К работе относится и процесс ожидания – это пассивный процесс, который не требует затрат ресурсов, но требует затрат времени (например, сушка). На графике пассивная работа изображается пунктирной стрелкой.
Событиеобозначает момент завершения одной или нескольких предшествующих работ. Оно не может быть выражено во времени. В сетевом графике событие обозначается кружком, внутри которого ставится порядковый номер.
Путь– это любая последовательность взаимосвязанных событий и работ на сетевом графике. В сетевом графике следует различать несколько видов путей:полный путь, т. е. путь от исходного до завершающего события; предшествующий путь, т. е. путь от исходного события до данного; последующий путь, т. е. путь от данного события до завершающего.Продолжительность любого пути равна сумме продолжительностей составляющих его работ.Путь, имеющий наибольшую продолжительность, называется критическим путем, а работы, лежащие на этом пути, называются критическими работами.
Развертка сетевых графиков Операция представляет одну или несколько задач, требующих определенных затрат времени.
Наборы работ используются для разработки детального сетевого графика для руководителей первого уровня (см. уровень 3 „Планы“).Подробные графики двух проектов для руководителей отделов (уровень 2) могут быть объединены в более агрегированную форму и, далее, могут быть сведены к самому общему виду, необходимому для руководителя проекта, высшего руководства и клиента.Этот верхний уровень обычно представлен в виде графика Ганта и называется планом контрольных точек. Достоверность информации на каждом уровне зависит от точности определения набора работ и операций.Первое, что нужно сделать для разработки сетевого графика проекта, определить набор работ.