Руководители Работ — различия между версиями

Материал из Брацка Правки
Перейти к: навигация, поиск
м (Gary переименовал страницу Руководители Работ в Руководители Проектов без оставления перенаправления)
(→‎Термины)
 
(не показано 18 промежуточных версий 3 участников)
Строка 3: Строка 3:
  
 
==Материалы==
 
==Материалы==
−
Предшественник этого ''Лектио'' -- [[Воплощаемости Задумок]].
+
Предшественник этого ''Лектио'' -- [[Реализуемости Задумок]].
  
 
===Иллюстрации===
 
===Иллюстрации===
Строка 9: Строка 9:
 
</gallery>
 
</gallery>
  
−
===Текст===
+
===Текст (HTML)===
−
:<p><strong>Руководители Проектов</strong></p><p>
+
:<p><strong>Руководители Работ</strong></p><p>Руководитель разработки -- это лицо, которое отвечает за разработку нового продукта. Руководители имеют разные роли на различных стадиях разработок.</p><ol type="a"><li>Руководитель определяется в конце стадии инициирования, когда необходимость в разработке прояснена. До начала планирования, руководитель устанавливает контакт с кураторами продукта и разработки, после чего договаривается с ними о формате дальнейшей работы,</li><li><p>Руководитель играет ключевую роль, первую скрипку, в планировании разработки. В плановых разработках разработка планов ведётся до утверждения контрольных уровней, в оперативно-гибких -- до разработки приоритетного перечня пользовательских историй. В оперативно-периодических разработках планирование может быть сведено к минимуму.</p><p>На этом этапе руководитель может привлечь бизнес-аналитиков для сбора требований и системных инженеров для разработки системного решения. Для нулевого прогона могут быть привлечены специалисты по оценке.</p></li><li>На стадии работ по разработке конечного продукта, руководители привлекают разработчиков. При плановых разработках, руководители командуют разработчиками напрямую, чтобы разработать утвержденные продукты в соответствии с оговоренными бюджетами и запланированному графику. При оперативно-гибких разработках, руководители не командуют разработчиками напрямую, но отвечают за количество и качество тех разработчиков, которые выделены на разработку. В оперативно-периодических и оперативно-нарастающих разработках, общее правило может быть сформулировано так: если разработчики квалифицированы и могут сами определять фронт своих работ, им лучше дать самостоятельность. Если разработчикам нужен начальник, то в его качестве выступает руководитель разработки.</li><li>Если разработка доходит до стадии сворачивания, то, кроме руководителя, этой работой никто больше не командует.</li></ol><p>Если персонал разработки составляет менее 5-9 человек и график не сжат, руководитель редко выполняет выделенную роль. Один из разработчиков или кто-то другой может выступать в качестве руководителя разработки в дополнение к другим обязанностям.</p><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><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p>
 
  
 
===Варианты===
 
===Варианты===
−
:
+
:руководитель сам является инициатором всех процессов разработок; руководитель инициирует процессы разработок; руководитель является ответственным лицом; кто-то из разработчиков может смело заменять руководителя. 
  
 
:Следующее лектио -- '''[[Кураторы Разработок]]'''
 
:Следующее лектио -- '''[[Кураторы Разработок]]'''
  
 
===Термины===
 
===Термины===
−
:[[WBS]], [[Объем Проекта]], [[Области Решения]], [[Критерии Приемки]], [[Бэклог Продукта]]
+
:[[Руководитель]], [[Объём работ]], [[Разработка]], [[Плановый способ]], [[Оперативно-гибкий способ]]
  
 
==Экзамен==
 
==Экзамен==

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

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


Материалы

Предшественник этого Лектио -- Реализуемости Задумок.

Иллюстрации

Текст (HTML)

Руководители Работ

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

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

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

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

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

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

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

Варианты

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

Термины

Руководитель, Объём работ, Разработка, Плановый способ, Оперативно-гибкий способ

Экзамен

Определения

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

Чтобы создать Объем Проекта для планирования вашей работы, вам необходимо описание будущего.________________
Источник — «https://pravka.bskol.com/w1/index.php?title=Руководители_Работ&oldid=27217»