Выборы Способа — различия между версиями
Gary (обсуждение | вклад) (→Материалы) |
Sonya (обсуждение | вклад) |
||
| (не показано 20 промежуточных версий 3 участников) | |||
| Строка 3: | Строка 3: | ||
==Материалы== | ==Материалы== | ||
| − | Предшественник этого ''Лектио'' -- [[ | + | Предшественник этого ''Лектио'' -- [[Глубина и Роли]]. |
===Иллюстрации=== | ===Иллюстрации=== | ||
| Строка 9: | Строка 9: | ||
</gallery> | </gallery> | ||
| − | ===Текст=== | + | ===Текст (HTML)=== |
| − | :<p><strong>Выборы Способа</strong></p><p> | + | :<p><strong>Выборы Способа</strong></p><p>Обычно, у тех заказчиков, которые активно вовлечены в разработки имеются свои особые требования к проектам. В частности, заказчик может установить способы разработки. Если заказчик способов не устанавливает, руководитель проекта предпринимает решение какими способами будет осуществляться разработка. Это решение может быть итогом консультаций с кураторами проекта.</p><p>Не существует единого алгоритма для выбора способов, и, в теории, любая разработка может быть предпринята любым. Однако четыре показателя могут быть особенно важны для рассмотрения:</p><ol type="a"><li><p><strong>Предсказуемость</strong> проекта, то есть определённость с объёмом работы и прогнозируемость факторов, которые влияют на эту работу. Если заказчик требует предпринять проект плановым способом (Waterfall) в неопределённых условиях, заказчик должен быть готов и открыт к частому пересмотру планов. Оперативно-периодический (iterative) способ не требует предварительного планирования.</p></li><li><p><strong>Способность</strong> разработчиков действовать независимо. В оперативно-гибких проектах (Agile project) разработчики не имеют подробного объёма работ; обычно, они работают с заданиями на продукт. Если разработчикам нужны детальные инструкции, то предпочтительнее применять остальные способы.</p></li><li><p><strong>Вероятность</strong> глубокой вовлечённости куратора продукта в разработку. При работе над неопределённым продуктом важно быстрое принятие решений куратором продукта и его доступность для консультаций. Опять же, если куратор продукта не максимально доступен разработчикам, оперативно-гибкий способ (Agile) не будет эффективен.</p></li><li><p><strong>Определённость</strong> в том, что важнее для заказчика -- сделать рабочий продукт дешевле или быстрее. Планирование снимает риски не той работы или работы не над тем продуктом, но любое планирование занимает время. То есть, большая глубина планирования имеет тенденцию сократить расходы на разработку, но при этом увеличить сроки всего проекта.</p></li></ol><p>В природе редко встречается исключительно белый или чёрный цвет и проект обычно предпринимается комбинацией нескольких способов.</p><p>В этом разрезе интересно взглянуть на планирование, как на отдельную разработку, ведь план также является продуктом разработки. Работа над планом редко предпринимается плановым способом; если да, то трудно себе представить план для разработки плана для разработки плана!</p><p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, для того чтобы определиться со способом разработки проекта нужно:</p> |
| − | |||
| − | |||
| − | |||
| − | <p> | ||
| − | < | ||
| − | |||
| − | < | ||
| − | <p> | ||
| − | < | ||
| − | < | ||
| − | <p> | ||
| − | <p> | ||
| − | |||
| − | |||
| − | |||
| − | <p><i>А теперь, выберите, пожалуйста, лучшее завершение следующего предложения.</i> Судя по тексту выше, :</p> | ||
===Варианты=== | ===Варианты=== | ||
| − | : | + | :учитывать определённость объёма работ, способность разработчиков действовать по плану или независимо, доступность куратора, определенность заказчика, что ему необходимо./ распланировать все процессы разработки будущего проекта, посовещаться с ответственными за проект./ проанализировать все данные о будущем проекте./ подстроиться под законодательство и устав проекта. |
:Следующее лектио -- '''[[Нулевые Прогоны]]''' | :Следующее лектио -- '''[[Нулевые Прогоны]]''' | ||
===Термины=== | ===Термины=== | ||
| − | :[[ | + | :[[Разработка]], [[Куратор продукта]], [[Объём работ]], [[Рабочий продукт]], [[Оперативно-гибкий способ]], [[Плановый способ]] |
| − | |||
==Экзамен== | ==Экзамен== | ||
Текущая версия на 14:10, 27 сентября 2022
Выборы Способа (здесь и далее по тексту -- Лектио) -- это часть урока Суть Проектных Начал. В Брацкой Школе, уроки делятся на так называемые лектио, каждое из которых состоит из микролекции и одного или нескольких заключительных вопросов. Урок, в свою очередь, относится к практическому семинару Выбор Профессии.
Содержание
Материалы
Предшественник этого Лектио -- Глубина и Роли.
Иллюстрации
Текст (HTML)
Выборы Способа
Обычно, у тех заказчиков, которые активно вовлечены в разработки имеются свои особые требования к проектам. В частности, заказчик может установить способы разработки. Если заказчик способов не устанавливает, руководитель проекта предпринимает решение какими способами будет осуществляться разработка. Это решение может быть итогом консультаций с кураторами проекта.
Не существует единого алгоритма для выбора способов, и, в теории, любая разработка может быть предпринята любым. Однако четыре показателя могут быть особенно важны для рассмотрения:
Предсказуемость проекта, то есть определённость с объёмом работы и прогнозируемость факторов, которые влияют на эту работу. Если заказчик требует предпринять проект плановым способом (Waterfall) в неопределённых условиях, заказчик должен быть готов и открыт к частому пересмотру планов. Оперативно-периодический (iterative) способ не требует предварительного планирования.
Способность разработчиков действовать независимо. В оперативно-гибких проектах (Agile project) разработчики не имеют подробного объёма работ; обычно, они работают с заданиями на продукт. Если разработчикам нужны детальные инструкции, то предпочтительнее применять остальные способы.
Вероятность глубокой вовлечённости куратора продукта в разработку. При работе над неопределённым продуктом важно быстрое принятие решений куратором продукта и его доступность для консультаций. Опять же, если куратор продукта не максимально доступен разработчикам, оперативно-гибкий способ (Agile) не будет эффективен.
Определённость в том, что важнее для заказчика -- сделать рабочий продукт дешевле или быстрее. Планирование снимает риски не той работы или работы не над тем продуктом, но любое планирование занимает время. То есть, большая глубина планирования имеет тенденцию сократить расходы на разработку, но при этом увеличить сроки всего проекта.
В природе редко встречается исключительно белый или чёрный цвет и проект обычно предпринимается комбинацией нескольких способов.
В этом разрезе интересно взглянуть на планирование, как на отдельную разработку, ведь план также является продуктом разработки. Работа над планом редко предпринимается плановым способом; если да, то трудно себе представить план для разработки плана для разработки плана!
А теперь, выберите, пожалуйста, лучшее завершение следующего предложения. Судя по тексту выше, для того чтобы определиться со способом разработки проекта нужно:
Варианты
- учитывать определённость объёма работ, способность разработчиков действовать по плану или независимо, доступность куратора, определенность заказчика, что ему необходимо./ распланировать все процессы разработки будущего проекта, посовещаться с ответственными за проект./ проанализировать все данные о будущем проекте./ подстроиться под законодательство и устав проекта.
- Следующее лектио -- Нулевые Прогоны
Термины
- Разработка, Куратор продукта, Объём работ, Рабочий продукт, Оперативно-гибкий способ, Плановый способ
Экзамен
Определения
Вопросы экзамена
- Использование подвижного Подхода для разработки в Брацкой Школы лучше всего можно классифицировать как:
Актив проекта . Фактор предприятия . Проектная среда . Все остальные ответы по существу верны.
