Нулевые Прогоны

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

Материалы

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

Текст

Нулевые Прогоны

Если бы автору этих строк предложили оставить только один текст из всех лекций и уроков по руководству проектами в Брацкой Школе, осталась бы это лектио. В разработках по заказам нет ничего более важного, чем общее понимание предмета работы и процесса работы по проекту. Почему?

Представим, что Ваша задача -- это из пункта А попасть в пункт Б. Что важнее всего сделать первым? Определить направление. Потому как если Вы решили идти куда глаза глядят, Вы, по всей видимости, усложняете свою задачу. Чем быстрее Вы стараетесь идти в противоположном направлении, тем дальше Вы удаляетесь от цели.

В Брацком Техсовете, нулевой прогон -- это достижение ответственными за проект общих договорённостей о целях проекта, требованиях к объектам приёмки и их разработке. Название "нулевой прогон" символизирует процесс прохождения по всем имеющимся и возможным деталям продукта и проекта без создания каких-либо объектов приёмки. Проект как бы "прогоняется" вхолостую порожним перед началом более детального планирования и разработки.

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

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

На совещаниях должны обсуждаться вопросы об:

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

Нулевой прогон сравним с нулевым спринтом (Sprint Zero), хотя есть существенные отличия. Концепция нулевого спринта создана исключительно под оперативные проекты. Результат нулевого спринта -- это расставленный по приоритетам объём работ (product backlog). Нулевой прогон имеет целью общее понимание между ответственными за проект.

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

Каждый проект начинается с нескольких стратегических вопросов: как мы будем общаться? Как мы будем управлять проектом и снижать риски? Как мы планируем фазы проекта, чтобы все выпуски были вовремя и в рамках бюджета? Ответы на эти вопросы зависят от того, насколько четко определены технические требования и проектная документация. Очевидно, что менее подробные требования или непоследовательная документация приводят к трудностям в оценке затрат на рабочую силу и разработке плана проекта и увеличивают время, затрачиваемое на общение с заказчиком и командой инженеров.

Цели ответственного поставщика услуг НИОКР заключаются в том, чтобы минимизировать затраты для клиента, наиболее эффективно организовать работу и уменьшить чрезмерное участие клиентов в проекте. Наиболее частая проблема, с которой мы сталкиваемся, заключается в том, что исходная документация клиента (например, предложения или технические задания) обычно описывает в основном бизнес-требования и мало говорит о том, как они должны быть реализованы, содержит неопределенную техническую информацию и не учитывает все факторы, в то время как архитектура не является зрелым и нуждается в улучшении. Все это звучит довольно мрачно, но у нас есть проверенное решение, которое успешно применялось во многих случаях. Нулевой спринт - что это такое

Для решения вышеупомянутых проблем мы используем специальный спринт, который мы называем «нулевым спринтом». Этот спринт позволяет нам:

   создать основную команду, распределить роли и организовать начальный семинар на месте для ключевого инженера / PM для передачи знаний о продукте и требованиях (вернувшись, он / она поделится информацией с остальной частью команды и будет способствовать их вводу) в проект);
   подробно описать архитектуру и дизайн приложения (HLA и HLD), а также технические требования;
   провести высокоуровневую оценку основных компонентов системы и составить список невыполненных работ; и
   разверните CI / CD, подготовьте оборудование, четко определите требуемый стек технологий, выберите оборудование, установите программное обеспечение для работы над проектом и приобретите необходимые лицензии.

Другими словами, нулевой спринт для разработчика программного обеспечения подобен рецепту, по которому шеф-повар может приготовить все для следующего кулинарного шедевра. Это важная часть процесса. Импровизированный обед может получиться отличным, но он потребует гораздо больше времени, усилий и стресса. Что говорится в руководстве по Scrum?

Нулевой спринт - время подготовить команду к проекту. В нашей практике это обычно занимает около двух недель (в зависимости от сложности проекта, требований заказчика и других факторов). Согласно классическому определению спринта в Скраме, это токсичный спринт, возникающий из-за отсутствия понимания основ методологии, и от него следует отказаться, поскольку он не добавляет реальной ценности продукту. Все эти процедуры следует выполнять при планировании спринта. Теория прекрасно объясняет, что и как нужно делать, но применимо ли это к реальным проектам? Приведу несколько примеров из своего опыта.

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

После шести месяцев напряженной и продуктивной работы мы столкнулись с настоящими трудностями. Система работала медленно, некоторые из запланированных функций содержали ошибки и работали не так, как ожидалось, а некоторые было очень сложно реализовать. Команда потеряла мотивацию, и спринты превратились для всех участников в пытку. Это произошло из-за того, что наспех разработанная архитектура не соответствовала требованиям продукта. Наконец, мы убедили клиента потратить дополнительное время (и деньги) на пересмотр архитектуры и реинжиниринг системы. В конце концов, мы опоздали с доставкой на два месяца, клиент понес дополнительные расходы, а отношения внутри команды и с заказчиком были напряженными и враждебными. После такого опыта вы могли бы предположить, что Waterfall предпочтительнее Agile.

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

объекты.

Кстати, Scrum Guide не запрещает какую-либо подготовительную работу, и вы можете называть это как угодно, так почему бы не использовать термин «нулевой спринт», особенно когда все люди, участвующие в проекте, понимают, что это такое и почему? необходим? Вам всегда нужен нулевой спринт?

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

   когда архитектура плохо описана, технические требования и / или риски оцениваются с большими допусками, и требуются дополнительные технологические исследования;
   когда необходимо быстро расширить первоначальный костяк команды и ввести в проект новых инженеров; и
   когда в настоящий момент нет доступного проектного оборудования, инструменты CI / CD не настроены, программное обеспечение не установлено и т. д.

Варианты

Следующее лектио -- Проектные Среды

Термины

Бюджет Проекта, Активы Проекта, Внешние Среды, Внутренние Среды, Проектная Среда, Затраты На Проект, График Проекта, Фактор Предприятия, Рабочий Продукт, Временные Шкалы Проекта

Экзамен

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

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

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