Раздувания Планов — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
(Текст)
(Термины)
 
(не показано 26 промежуточных версий 3 участников)
Строка 1: Строка 1:
[[Раздувания Рамок]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Плановых Работ]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
+
[[Раздувания Планов]] (здесь и далее по тексту -- ''Лектио'') -- это часть урока [[Суть Контролей Планов]]. В [[Брацка Школа|Брацкой Школе]], уроки делятся на так называемые [[лектио]], каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару '''[[Выбор Профессии]]'''.
  
  
 
==Материалы==
 
==Материалы==
Предшественник этого ''Лектио'' -- [[Изменение Уровней]].
+
Предшественник этого ''Лектио'' -- [[Расчёты Планов]].
  
 
===Иллюстрации===
 
===Иллюстрации===
Строка 9: Строка 9:
 
</gallery>
 
</gallery>
  
===Текст===
+
===Текст (HTML)===
:<p><strong>Раздувания Рамок</strong></p><p>
+
:<p><strong>Раздувания Планов</strong></p><p>В проектах, заказчик и подрядчик вместе работают над продуктом. Важно, чтобы между ними установились деловые плодотворные отношения. В то же время, ответственности и интересы двух сторон могут отличаться.</p><p>Для демонстрации, давайте представим, что мы -- подрядчик и наняты сделать веб-сайт. Мы пообещали заказчику, что информационные страницы и онлайн-магазин будут готовы за неделю работы. Заказчик обещал предоставить тексты; заказчик заверил, что они готовы. Мы поставили разработчиков и платим деньги. Неделя прошла, а текстов нет. Заказчик решил их обновить и ответственность не была предусмотрена. За простой разработчиков заказчик также отказывается платить, так как об этом также договорённости не было.</p><p>Эта ситуация называется раздуванием сроков. Сроки сдачи сайта были оговорены, а сроки получения материалов -- нет.</p><p>Интересы заказчика и подрядчика часто различаются -- заказчик желает получить больше на свои деньги, в то время как подрядчик заинтересован завершить проект, как можно быстрее.</p><p>Неконтролируемое раздувание рамок проекта (scope creep) -- это увеличение объёма работ без оплаты. Продолжая пример, мы получили тексты в начале второй недели. Сайт сделан. Заказчик отказывается принять разработку из-за того, что:</p><ol type="a"><liонлайн-магазине недостаточное количество товаров.</li><li>Сайт не выскакивает на первой странице при использовании поисковых движков.</li><li>В текстах есть грамматические и логические ошибки.</li><li>Заказчик решил поменять что-то в текстах и пришлёт обновления скоро.</li><li>В тексты надо добавить фотографии и лучше организовать.</li></ol><p>Мы предлагаем заказчику доплатить за дополнительные работы, а заказчик отказывается, утверждая, что он считает эти работы основными. Цена за весь проект оговорена была, а объём работы мы не закрепили.</p><p>Реально? Абсолютно реально. Нет ничего плохого в том, что заказчику хочется больше работы. Задача подрядчика -- не делать эту работу бесплатно.</p><ol type="a"><li>В оперативных проектах, цена часто устанавливается за время работы, потому проблемы раздувания объёма работы нет. Больше работы -- больше денег для подрядчика.</li><li>В плановых проектах, когда контрольные планы утверждены, каждое их изменение должно сопровождаться новым одобрением планов.</li></ol><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, раздувание планов:</p>
 
 
 
 
<p>Выполнение проекта начинается после утверждения Бэклога Продукта. Это отставание выполняет роль объема продукта, и разработчики принимают решения о том, какую работу им следует выполнять, исходя из этого объема. По мере того как проект по Заданному Подходу развивается, объем продукта уточняется.</p> <p>Рассмотрим подробнее значение определения Бэклог Продукта — это перечень рабочих задач, расположенных в порядке важности, для команды разработчиков. Его составляют на основе дорожной карты и требований в ней. Наиболее важные задачи расположены в начале Бэклога Продукта, чтобы команда понимала, какую работу следует выполнить в первую очередь.</p>
 
 
 
Если разработка предсказуема, то следующий вопрос -- могут ли разработчики сами определять фронт своих работ или им нужет начальник.
 
 
 
 
 
В поисковых проектах этапы проекта всегда перекрываются. Предварительное планирование работы, которое называется Нулевой Спринт, устанавливает правила и приоритеты для проекта. Каждый день планирование открывается заново, чтобы учесть разработки предыдущего дня.
 
 
 
Владелец проекта несет ответственность за управление проектом. Чтобы направлять, контролировать и/или поддерживать персонал проекта, владелец может создать офис управления проектом, часто сокращенно ОУП.</p>
 
<p>В управлении проектами Гибкой Методологии ключевую роль играет руководитель проекта. Эти менеджеры концентрируются на разработке утвержденных продуктов в соответствии с утвержденными бюджетами и утвержденными графиками.</p>
 
<p>Менеджер проекта ведет Планирование проекта до утверждения базовых показателей, выполнение проекта до подтверждения результатов и закрытие проекта. На этапе планирования менеджер может нанять бизнес-аналитиков для сбора требований и системных инженеров для разработки системы, как Решения. Те разработчики, которые непосредственно создают результаты, нанимаются только на стадии Выполнения.</p>
 
<p>Если персонал проекта составляет менее 5-9 человек и график не сжат, менеджер редко выполняет выделенную роль. Один из разработчиков или кто-то другой может выступать в качестве менеджера проекта в дополнение к другим обязанностям.</p>
 
<pЖестком Подходе функции управления распределены между несколькими ролями. Например, разработчики определяют работу на основе требований решения, таких как пользовательские истории.
 
На этапе Планирования некий координатор, например, менеджер по работе с клиентами, работающий в ОУП, нанимает членов группы планирования в дополнение к владельцу продукта. Эта команда проводит Нулевой Спринт или аналогичные действия, предпринимаемые для создания Бэклога Продукта.</p>
 
<p>На исполнительный этап нанимается команда разработчиков. Помимо product owner-а(Владелец Продукта), в эту команду входят разработчики и, возможно, такие официальные лица, как Scrum Master. Разработчики обычно работают в итерациях и, как только разрабатываются новые инкременты и обнаруживаются новые данные, обсуждают будущий продукт и его доставку с Владельцем Продукта. Скрам-Мастера не занимаются рабочими продуктами и поставками; Вместо этого Скрам-Мастера следят за тем, чтобы разработка шла в соответствии с согласованными правилами.
 
В отличие от Управления проектами, администрирование разработки часто распределяется между двумя организациями, если две организации участвуют в одном проекте.</p>
 
<p>Заказчик Проекта определяет бизнес-потребность, которая является проблемой, которую необходимо решить, инициирует проект по созданию решения и предоставляет бюджет проекта.
 
Владелец Проекта, следовательно, нанимает кого-то, кто действует от имени клиента при утверждении Требований к решению, базовых планах проекта и / или оценке того, соответствует ли рабочий продукт критериям приемки.</p>
 
<p>В проектах Гибкой Методологии -- эта административная роль называется Спонсором Проекта. Базовые показатели не являются особенностью проектов с Жесткким Подходом, поэтому администрация концентрируется только на требованиях к продукту.</p>
 
<p>Владелец продукта - ключевая административная роль в Жестких Методологиях проекта. Этот человек концентрируется на представлении правильного продукта, описании этого продукта обычно с использованием пользовательских историй и расстановке приоритетов в отставании по продукту. Владельцы Продуктов не занимаются бюджетами, графиками, а также другими функциями управления, такими как найм и закупки. Область ответственности product owner-а - убедиться, что деньги покупателя тратятся на продукт, который покупатель ищет.
 
 
 
 
 
 
 
</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p>
 
  
 
===Варианты===
 
===Варианты===
:
+
:плохо, когда происходит неконтролируемо. / всегда плохо. / когда заказчик требует больше, чем платит. / никогда не зависит от подрядчика.
  
:Следующее лектио -- '''[[Что Есть Факторы]]'''
+
:Следующее лектио -- '''[[Изменения Одобрений]]'''
  
 
===Термины===
 
===Термины===
:[[Бюджет Проекта]], [[Активы Проекта]], [[Внешние Среды]], [[Внутренние Среды]], Проектная Среда, [[Затраты На Проект]], [[График Проекта]], [[Фактор Предприятия]], [[Рабочий Продукт]], [[Временные Шкалы Проекта]]
+
:[[Бюджет проекта]], [[Неконтролируемое раздувание рамок проекта]], [[Проект]].
  
 
==Экзамен==
 
==Экзамен==

Текущая версия на 18:24, 26 сентября 2022

Раздувания Планов (здесь и далее по тексту -- Лектио) -- это часть урока Суть Контролей Планов. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.


Материалы

Предшественник этого Лектио -- Расчёты Планов.

Иллюстрации

Текст (HTML)

Раздувания Планов

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

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

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

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

Неконтролируемое раздувание рамок проекта (scope creep) -- это увеличение объёма работ без оплаты. Продолжая пример, мы получили тексты в начале второй недели. Сайт сделан. Заказчик отказывается принять разработку из-за того, что:

  1. В онлайн-магазине недостаточное количество товаров.
  2. Сайт не выскакивает на первой странице при использовании поисковых движков.
  3. В текстах есть грамматические и логические ошибки.
  4. Заказчик решил поменять что-то в текстах и пришлёт обновления скоро.
  5. В тексты надо добавить фотографии и лучше организовать.

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

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

  1. В оперативных проектах, цена часто устанавливается за время работы, потому проблемы раздувания объёма работы нет. Больше работы -- больше денег для подрядчика.
  2. В плановых проектах, когда контрольные планы утверждены, каждое их изменение должно сопровождаться новым одобрением планов.

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

Варианты

плохо, когда происходит неконтролируемо. / всегда плохо. / когда заказчик требует больше, чем платит. / никогда не зависит от подрядчика.
Следующее лектио -- Изменения Одобрений

Термины

Бюджет проекта, Неконтролируемое раздувание рамок проекта, Проект.

Экзамен

Определения

Вопросы экзамена

Использование подвижного Подхода для разработки в Брацкой Школы лучше всего можно классифицировать как:

Актив проекта . Фактор предприятия . Проектная среда . Все остальные ответы по существу верны.