Презентация на тему Классификация логистических проектов. (Модуль 2. Лекция 2.1)

координации по приоритетам

остатков средств производства на предприятиях и в системе материально-технического

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

под которым понимается минимальная, постоянная величина запаса (затрат), необходимая

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

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

год установлен в сумме 2 млрд. р. При этом, на наценки

приходится 100 млн. р., а на транспортные расходы – 50 млн. р. В расчете норматива по товарным запасам учитывается оборот по себестоимости в сумме 1,850 млрд. р. (2000–100–50). При этом среднедневной оборот составит 5,139 млн. р. (1850:360)1.

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

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

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

(непосредственно перед поставкой товаров)  - максимальный остаток товаров (непосредственно после

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

основании плановых норм и нормативов исходя из заданий по

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

могут учитываться с помощью компонентов количества, стоимости, времени и

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

капитала = Количество х Стоимость х Время


Затраты на связанный

капитал =
= Количество х Стоимость х Время х Процент на связанный капитал

вперёд) — замысел, идея, образ, воплощённые в форму описания, обоснования,

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

стандартом
ANSI РМВоК — область деятельности, в ходе которой определяются

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

Project Management Body of Knowledge («PMBoK»)
Свод знаний по управлению проектами PMBoK (Project Management Body of Knowledge)
представляет собой сумму профессиональных знаний по управлению проектами.
Руководство PMBOK фиксирует части Свода знаний по управлению проектами, которая
обычно считается хорошей практикой. PMI использует этот документ в качестве
основного справочного материала для своих программ по профессиональному
развитию. Является Американским национальным стандартом.

PMI: Институт по Управлению Проектами — англ. Project Management Institute

3

сочетание науки и искусства, которые используются в профессиональных сферах

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

P2M
P2M — «A Guidebook of Project and Program Management for Enterprise Innovation» — стандарт по управлению проектами, базирующийся на опыте Японии с 1999 года, который позволил визуализировать проекты с большей добавленной стоимостью и инновационные программы.
P2M — это система знаний, представленная в форме «Руководства по управлению инновационными проектами и программами предприятий».
Первая редакция P2M была опубликована в ноябре 2001 года Японской ассоциацией развития инжиниринга (ENAA), сейчас P2M поддерживается Ассоциацией проектных менеджеров Японии (PMAJ).
P2M сконцентрировал уроки японских компаний с 1980 года, сформировав методологию управления ценностью и выздоровления компаний за последнее десятилетие с 1990 года, как новое направление развития.

структуризации работ и сетевого планирования, разработанные в конце 50-х

годов XX века в США.

Классическая форма Тройственной Ограниченности

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

The Project Management Triangle

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

ограничения определены как содержание проекта, время и стоимость. Они также относятся к Треугольнику Управления проектами, где каждая его сторона представляет ограничение. Изменение одной стороны треугольника влияет на другие стороны. Дальнейшее уточнение ограничений выделило из содержания качество и действие, превратив качество в четвертое ограничение.

ограниченности: финансы, время и человеческие ресурсы. При необходимости сократить

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

числе цепей поставок)

Определение проблемы и планирование проекта.
Сбор и анализ

данных.
Окончательный план реализации (создание рабочей группы).

классических представлений
Прямая цепь поставок состоит из фокусной (центральной) компании

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








Рис. 1.1. Прямая цепь поставок

Поставщик
I уровня

Фокусная
Компания

Потребитель
I уровня

включает дополнительно поставщиков и потребителей второго уровня.














Рис. 1.2. Расширенная

цепь поставок

Поставщик
I уровня

Фокусная
Компания

Потребитель
I уровня

Поставщик
II уровня

Потребитель
II уровня

всех ее контрагентов слева (вплоть до поставщиков исходного сырья

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

Поставщик
I уровня

Фокусная
Компания

Потребитель
I уровня

Поставщик
II уровня

Логистические посредники

Потребитель
II уровня

Рис. 1.3. Обобщенный вид максимальной цепи поставок

Начальный поставщик

Конечный потребитель

Информационные и финансовые посредники

второго уровня
Поставщики и потребители третьего уровня
Начальный поставщик и конечный

потребитель

Рис.1.3. Сетевая структура цепи поставок

Поставщики третьего уровня

Потребители третьего уровня

Начальные поставщики

Конечные потребители

второго уровня
Управляемые связи
Отслеживаемые связи
Рис.1.4. Типы связей между участниками цепи

поставок

Поставщики третьего уровня

Потребители третьего уровня

Начальные поставщики

Конечные потребители

Неуправляемые связи

Связи с объектами, не входящими в цепь поставок

1

2

управления связями между фокусной компанией и поставщиками первого уровня

Поставщик

второго уровня

график
Функциональная стратегия
Бизнес-стратегия
Логистическая стратегия
Планы использования мощностей
Обобщенные

планы

Краткосрочные графики

Рис. 1.6. Подход к планированию цепи поставок

Стратегические решения высшего уровня

Стратегические логистические решения

Тактические логистические решения

Операционные логистические решения

роли заказчика, исполнителя (и иногда инвестора или спонсора). Такие

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

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

с конфликтами целей, приоритетов, сроков, назначений, ресурсов и отчетности

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

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

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

Последовательность процедур управления проектом:
• Определение среды проекта.
• Формулирование проекта.
• Планирование проекта.
• Техническое выполнение проекта (за исключением планирования и контроля).
• Контроль над выполнением проекта.

процессы PMI описаны в стандарте PMBOK:
• Определение требований к проекту
• Постановка

чётких и достижимых целей
• Балансирование конкурирующих требований по качеству, возможностям, времени и стоимости
• Адаптация спецификаций, планов и подходов для нужд и проблем различных заинтересованных лиц (стейкхолдеров)

Процедуры управления проектами по методологии MSF
Microsoft Solutions Framework (MSF) разработан корпорацией Microsoft как методология ведения IT-проектов. MSF представляет каждую фазу проекта как:
• Выработка концепции (Envisioning)
• Планирование (Planning)
• Разработка (Developing)
• Стабилизация (Stabilizing)
• Внедрение (Deploying)
План управления проектом
План управления является основным документом, с которого должен начинаться любой проект. План корректируется в течение всего проекта.

проекта (IP).
• Планирование проекта (PL).
• Управление проектом (DP).
• Контроль стадий (CS).
• Контроль границ

стадий (SB).
• Управление производством продукта (MP).
• Завершение проекта (CP).

Прочие процедуры (управление командой, контрактами и тп) вынесены «за рамки» методологии и называются инструментарием менеджера проекта. Кроме того, методология рассматривает «компоненты», которые состоят из Бизнес плана (Business Case), организации, планирования, управления рисками, управления качеством, управление конфигурацией, контроля и управления изменениями.

Quality management systems — Guidelines for quality management in

projects
Национальные стандарты управления проектами:
• ГОСТ Р 54869—2011 «Проектный менеджмент. Требования к управлению проектом» (Россия)
• ГОСТ Р 54870—2011 «Проектный менеджмент. Требования к управлению портфелем проектов» (Россия)
• ГОСТ Р 54871—2011 «Проектный менеджмент. Требования к управлению программой» (Россия)
• NASA Project Management (США)
• BSI BS 6079 (Великобритания)
• APM Body of Knowledge (Великобритания)
• OSCEng (Великобритания)
• DIN 69901 (Германия)
• V-Modell (Германия)
• VZPM (Швейцария)
• AFITEP (Франция)
• Hermes method (Швейцария)
• ANCSPM (Австралия)
• CAN/CSA-ISO 10006-98 (Канада)
• P2M (Япония)
• C-PMBOK (Китай)
• South African NQF4 (ЮАР)
• CEPM (Индия)
• PROMAT (Южная Корея)

от типа проекта:
• Предположение о неограниченности ресурсов, критичен только срок

выполнения и качество. Используется метод PERT, метод критического пути

PERT

Program (Project) Evaluation and Review Technique (сокращенно PERT) — техника оценки и анализа программ (проектов), которая используется при управлении проектами. PERT — это способ анализа задач, необходимых для выполнения проекта. В особенности, анализа времени, которое требуется для выполнения каждой отдельной задачи, а также определение минимального необходимого времени для выполнения всего проекта.

на бумаге и составления графиков больших и сложных проектов.

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

Самой популярной частью PERT является Метод критического пути, опирающийся на построение сетевого графика (сетевой диаграммы PERT).

фирмой «Буз, Ален и Гамильтон[en]» совместно с корпорацией «Локхид»

по заказу Подразделения специальных проектов ВМС США в составе Министерства Обороны США для проекта создания ракетной системы «Поларис» (Polaris). Проект «Поларис» был ответом на кризис, наступивший после запуска Советским Союзом первого космического спутника.

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

10 до 50) и шестью деятельностями (от A до F).

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

В основе метода лежит определение

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

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

как модель "Водопад") — модель процесса разработки программного обеспечения,

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

Содержание модели
В 1970 году в своей статье У. У. Ройс (W. W. Royce) описал в виде концепции то, что сейчас принято называть «каскадная модель», и обсуждал недостатки этой модели. Там же он показал как эта модель может быть доработана до итеративной модели.
В оригинальной каскадной модели Ройса, следующие фазы шли в таком порядке:
1. Определение требований
2. Проектирование
3. Конструирование (также «реализация» либо «кодирование»)
4. Воплощение
5. Тестирование и отладка (также «верификация»)
6. Инсталляция
7. Поддержка

разработки к другой происходит только после полного и успешного

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

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

модель» довольно часто критикуют за недостаточную гибкость и объявление

самоцелью формальное управление проектом в ущерб срокам, стоимости и качеству. Тем не менее, при управлении большими проектами формализация часто являлась очень большой ценностью, так как могла кардинально снизить многие риски проекта и сделать его более прозрачным.
Поэтому даже в PMBOK 3-ей версии формально была закреплена только методика «каскадной модели» и не были предложены альтернативные варианты, известные как итеративное ведение проектов.
Начиная с PMBOK 4-ой версии удалось достичь компромисса между методологами, приверженными формальному и поступательному управлению проектом, с методологами, делающими ставку на гибкие итеративные методы. Таким образом, начиная с 2009 года, формально Институтом управления проектами (PMI) предлагается как стандарт гибридный вариант методологии управления проектами, сочетающий в себе как плюсы от методики «Водопада», так и достижения итеративных методологов.

разработке программного обеспечения — это выполнение работ параллельно с

непрерывным анализом полученных результатов и корректировкой предыдущих этапов работы. Проект при этом подходе в каждой фазе развития проходит повторяющийся цикл PDCA:
Планирование — Реализация — Проверка — Оценка
(англ. plan-do-check-act cycle).

стадиях проекта, что ведет к минимизации затрат на их

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

понятием диаграммы Ганта является «Веха» — метка значимого момента

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

применения диаграммы. Тем не менее, в настоящее время диаграмма

Ганта является стандартом де-факто в теории и практике управления проектами, по крайней мере, для отображения Структуры перечня работ по проекту

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

Недостатки

Сдвиг вехи приводит к сдвигу всего проекта. Поэтому диаграмма Ганта не является, строго говоря, графиком работ.
И это один из основных её недостатков.

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

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

История
Первоначально метод был разработан в 1989 году Central Computer and Telecommunications Agency (CCTA) в Великобритании как стандарт для руководства проектами в сфере информационных технологий. В настоящее время широко используется и является «de facto» стандартом для руководства проектами в Великобритании.

управлению проектами, т. е. представляет собой метод для управления

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

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

информационных потоков.

board), перед которым регулярно отчитывается менеджер. Состоит из 3х

человек — Заказчика, Главного пользователя и Главного специалиста. Совет проекта ответственен за принятие стратегических решений. Менеджер проекта обязан отслеживать возможные проблемы и предлагать совету альтернативные решения. Совет решает — какой путь лучше.
• служба project assurance (аналог проектного офиса), цель которой предоставлять независимое мнение о проекте с точки зрения тех же трех групп людей — заказчиков, пользователей и специалистов (в предметной области). Служба готовит три отчета —
o business report (отчет о финансовом состоянии проекта и выгодности проекта в целом),
o user report (насколько хорошо выполняются требования пользователей),
o technical report (насколько хорош проект в технологическом плане — туда ли он движется).
• Есть служба административной поддержки (администраторы проектов и т. п.), ответственная за проведение встреч, доведение нужной информации до всех ее адресатов, сохранение проектной информации и т. п. В случае маленьких проектов это делает менеджер проекта.

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

разработки программного обеспечения. Scrum чётко делает акцент на качественном контроле процесса разработки. Кроме управления проектами по разработке ПО Scrum может также использоваться в работе команд поддержки программного обеспечения (software support teams), или как подход управления разработкой и сопровождением программ: Scrum of Scrums.

Историческая справка









Схватка (Scrum) в регби между Newport и London Welsh в 1904
].

в статье The New Product Development Game (Гарвардский Деловой

Обзор, январь-февраль 1986). Они отметили, что проекты, над которыми работают небольшие команды из специалистов различного профиля, обычно систематически производят лучшие результаты, и объяснили это как «подход регби».
В 1991 году ДеГрейс и Шталь в книге «Нечестивые проблемы, праведные решения» ссылались на этот подход, как на Scrum (толкотня; схватка вокруг мяча (в регби)), спортивный термин, приведённый в статье Такэути и Нонакой. Кен Швабер в начале 1990-х использовал подход, который привел Scrum в его компанию. Впервые метод Scrum был представлен на общее обозрение задокументированным, чётко сформированным и описанным совместно Швабером и Джефом Сазерлендом на OOPSLA’96 (англ.) в Остине. Швабер и Сазерленд на протяжении следующих лет работали вместе, чтобы обработать и описать весь их опыт и лучшие практические образцы для индустрии в одно целое, в ту методологию, что известна сегодня как Scrum. Швабер объединил усилия с Майком Бидлом в 2001 году, чтобы детально описать метод в книге «Agile Software Development with SCRUM».

строится процесс разработки, позволяющий в жёстко фиксированные и небольшие

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

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

Длительность одного спринта от 2 до 4 недель. В отдельных случаях, к примеру согласно Scrum стандарту Nokia, длительность спринта должна быть не более 6 недель. Тем не менее, считается, что чем короче спринт, тем более гибким является процесс разработки, релизы выходят чаще, быстрее поступают отзывы от потребителя, меньше времени тратится на работу в неправильном направлении. С другой стороны, при более длительных спринтах команда имеет больше времени на решение возникших в процессе проблем, а владелец проекта уменьшает издержки на совещания, демонстрации продукта и т. п. Разные команды подбирают длину спринта согласно специфике своей работы, составу команд и требований, часто методом проб и ошибок.

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

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

Диаграмма сгорания задач (Burndown chart)

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

есть определённые роли, разбитые на 2 группы «свиней» и

«кур». Эти названия были использованы из-за шутки.
Свинья идёт по дороге. Курица смотрит на неё и говорит: «А давай откроем ресторан!» Свинья смотрит на курицу и отвечает: «Хорошая идея, и как ты хочешь его назвать?» Курица думает и говорит: «Почему бы не назвать „Яичница с беконом“?». «Так не пойдёт, — отвечает свинья, — ведь тогда мне придётся полностью посвятить себя проекту, а ты будешь вовлечена только частично».
Свиньи создают продукт, тогда как куры заинтересованы, но не настолько — ведь им всё равно, будет ли проект удачным или нет, на них это мало отразится. Требования, пожелания, идеи и влияние кур принимаются во внимание, но им не разрешают непосредственно включаться в ход скрам-проекта.

итерации Спринта.
• Из резерва проекта выбираются задачи, обязательства по выполнению

которых за спринт принимает на себя команда;
• На основе выбранных задач создается резерв спринта. Каждая задача оценивается в идеальных человеко-часах;
• Решение задачи не должно занимать более 12 часов или одного дня. При необходимости задача разбивается на подзадачи;
• Обсуждается и определяется, каким образом будет реализован этот объём работ;
• Продолжительность совещания ограничена сверху 4-8 часами в зависимости от продолжительности итерации, опыта команды и т. п.
o (первая часть совещания) Участвует владелец проекта и скрам команда: выбирают задачи из резерва продукта;
o (вторая часть совещания) Участвует только команда: обсуждают технические детали реализации, наполняют резерв спринта.

Ежедневное совещание (Daily Scrum meeting)
• начинается точно вовремя;
• все могут наблюдать, но только «свиньи» говорят;
• длится не более 15 минут;
• проводится в одном и том же месте в течение спринта

англ. Scrum poker) — техника оценки, основанная на достижении

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

Описание процесса оценки
Подготовка

Для проведения покера планирования необходимо подготовить список обсуждаемых функций и несколько колод пронумерованных карт. Список функций либо пользовательские истории описывают разрабатываемое программное обеспечение. Карты в колодах должны быть пронумерованы. Обычно колода содержит карты, содержащие числа Фибоначчи, включая ноль: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; другие разновидности колод могут использовать аналогичные последовательности.

продаже колод содержит следующую последовательность: 0, ½, 1, 2,

3, 5, 8, 13, 20, 40, 100 и иногда знак вопроса («?»), означающий неуверенность, и чашку кофе, означающую требование перерыва. Некоторыми организациями используются обычные игровые карты, включающие туз, 2, 3, 5, 8 и короля. Король буквально означает: «Данный пункт слишком большой или его слишком сложно оценить». Выбрасывание короля завершает обсуждение пункта в текущем круге (англ. sprint).
По желанию, может использоваться таймер, чтобы устанавливать лимит времени одного круга.

карт. Все колоды идентичны друг другу.
Обсуждение проводится следующим образом.
• Ведущий

(Moderator), не участвующий в обсуждении, ведёт собрание.
• Менеджер проекта (Product Manager) представляет краткие обзоры каждого из пунктов. Команда может задавать вопросы и вести обсуждение предложений и рисков. Итог обсуждения записывается менеджером проекта.
• Участники выбирают по одной карте и кладут их рубашкой вверх, показывая таким образом, что выбор сделан. Числовые достоинства карт могут использоваться по-разному: они могут означать количество дней, наиболее подходящие дни или относительные единицы сложности (англ. story points). Защиты от эффекта привязки.
• Каждый участник называет свою карту и переворачивает её.
• Участникам с высокими и низкими оценками даётся возможность высказаться и обосновать свою оценку.
• Процесс обсуждения продолжается до тех пор, пока не будет достигнут консенсус. Голос участника, который, скорее всего, будет владеть разработкой, имеет больший вес в «голосовании на основе консенсуса».
• Таймер используется для обеспечения структурированности обсуждения; ведущий или менеджер проекта может в любое время перезапустить таймер, по истечении времени все обсуждения должны быть прекращены, затем начинается новый круг покера.
Выступления участников повторяются вновь и вновь.

по разработке программного обеспечения. Эта техника минимизирует эффект привязки

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

Исследование K. Молёккен-Эствольда (норв. K. Moløkken-Østvold) и Н. Хаугена (норв. N.C. Haugen) показало, что оценки, полученные с помощью покера планирования, были менее оптимистичными и более точными, чем оценки, полученные с помощью простого сложения отдельных оценок аналогичных задач.

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

или эффект привязки (от англ. anchoring and adjustment heuristic)

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

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

за пять секунд оценить произведение:
8 × 7 × 6

× 5 × 4 × 3 × 2 × 1
и
1 × 2 × 3 × 4 × 5 × 6 × 7 × 8
При правильном ответе 40320 медиана результатов в первой группе была 2250, а во второй — 512, что говорит о том, что коррекции оценки, полученной произведением первых чисел, оказалось явно недостаточно

Использование эффекта якоря
Эффект якоря известен управляющим многих магазинов, которые увеличивают продажи за счёт
• указания цены нескольких штук изделия (даже если нет объёмной скидки),
• указания ограничения (в одни руки только N штук),
• или даже просто упоминанием некоторого числа (купите 18 «сникерсов»).
Благотворительные организации также используют этот эффект при рассылке писем с предложениями внести пожертвования. Средние пожертвования получателей писем с бо́льшей суммой, приведенной в качестве примера, будут выше (даже при одинаковых текстах писем)[4]

образом оценивается в разных методиках. Группы оценок успешности:
• Ориентированные на

контракт, например традиционные методологии, в том числе PMBOK: «Проект успешен, если выполнен согласно утвержденным критериям: объему, сроку, качеству». То есть проект успешен, если исполнен и закрыт договор между Заказчиком и Исполнителем. При этом оценка успешности единая как для заказчика так и для исполнителя.
• Ориентированные на заказчика, например гибкие методологии SCRUM, частично управление программами, направленное на длительное взаимодействие, а не на один проект/контракт: «Проект успешен, если заказчик удовлетворен». Здесь делается акцент на продолжение сотрудничества Исполнителя с Заказчиком в рамках последующих проектов и иного взаимодействия, либо проект можно рассматривать как программу из нескольких небольших проектов. Оценка успешности рассматривается в основном с точки зрения заказчика.
• Сбалансированные, например PRINCE2: «Проект успешен при сбалансированности по крайней мере по трем категориям — бизнеса, ориентации на пользователя и технологической зрелости». Здесь делается акцент на финансовой успешности проекта, удовлетворенности пользователей и развитии (косвенная польза для самого исполнителя).