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

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

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

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


Материалы

Предшественник этого Лектио -- Кураторы Продуктов.

Иллюстрации

Текст (HTML)

Роли Разработчиков

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

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

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

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

Компетенция и природа разработчиков играет роль при выборе способа разработки. "Компетенция" относится к способности функционировать самостоятельно. "Природа", как пример, участник оркестра или соло музыкант, относится к персональным качествам.

В плане ролей разработчиков, плановые и оперативно-гибкие разработки находятся на разных полюсах:

  1. В плановом способе, разработчики подчиняются руководителю разработки. Если разработчиков сравнить с музыкантами, плановые разработки будут оркестром. Каждый разработчик играет свою роль, имея точные ноты и слушаясь дирижёра.
  2. В оперативно-гибком способе, разработчики работают без формального начальства и без описания работы. Если их сравнить с музыкантами, оперативно-гибкие разработки будут джазовым ансамблем. Джазовые ноты описывают исключительно общую тему, а не всю композицию. Дирижёра нет и быть не может. Вместо подчинения дирижёру, каждый музыкант в джазовом ансамбле прислушивается к другим музыкантам, чтобы заметить момент, когда те возьмут на себя лидерство. Джазовые артисты могут никогда не встречаться, не иметь никаких репетиций и даже ничего не знать друг о друге до совместного исполнения композиции.

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

Обычно, в организациях, разработчики объединяются в команды. Команды возглавляются ведущими команд (team lead), то есть тем разработчиком, который говорит от лица команды.

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

Варианты

совершать закупки для будущего продукта; отвечать за целенаправленность средств; могут выносить вердикт на стадии планирования; объединять свои сообщества.
Следующее лектио -- Мастера Церемоний

Термины

Разработчик, Разработка, Профессиональная компетенция, Плановый способ, Оперативно-гибкий способ

Экзамен

Определения

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

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