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

Материал из Брацка Правки
Перейти к: навигация, поиск
(Текст)
(Термины)
 
(не показано 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), то есть тем разработчиком, который говорит от лица команды.

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

Варианты

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

Термины

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

Экзамен

Определения

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

Чтобы создать Объем Проекта для планирования вашей работы, вам необходимо описание будущего.________________