Что вы поставите в первые пару итераций в Agile?

Как я понимаю, идея с Agile методологиями заключается в том, что вы предоставляете что-то функциональное и часто. Приложение получает свой окончательный прирост формы после приращения.

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

Что доставляется клиенту на этих первых итерациях? Как вы показываете прогресс в правильном направлении при создании кода скаффолдинга?

Это типично иметь 2-недельные спринты.

Для меня первый спринт или 2, вероятно, будут иметь меньше «видимых» особенностей, чем более поздние спринты по этой точной причине (для некоторого незначительного описания «меньше»).

При этом, конечно же, вам не понадобится 2 недели, чтобы построить всю эшафот и ничего в видимом интерфейсе, чтобы показать это.

Возможно, вы не конкретизируете каждый элемент лесов в первом спринте или 2. Возможно, части могут подождать и быть добавлены позже.

Возможно, ваш первый спринт имеет «Создать веб-страницу X с фиктивными данными», чтобы вы могли получить что-то блестящее, чтобы показать вашему клиенту. И затем следующий спринт имеет «Изменить веб-страницу X, чтобы использовать данные из базы данных».

Agile Manifesto предполагает, что рабочее программное обеспечение более ценно, чем исчерпывающая документация, и среда Scrum использует это понятие, чтобы предложить, что поставка протестированного рабочего программного обеспечения с деловой ценностью является требованием каждого спринта.

Зачем? Ну, между прочим, дизайнеры и разработчики часто становятся жертвами траты времени на элементы YNNI (они вам никогда не понадобятся). К сожалению, те рамки, о которых вы говорите, часто являются большой проблемой в этой области. Разработчики начинают встраивать все, что может поддерживать фреймворк, и вдруг у вас есть 3 месяца, и у вас нет ничего, что можно было бы продемонстрировать для бизнеса. Тогда оказывается, что фреймворк даже не поддерживает то, что им в итоге нужно.

Таким образом, предлагаемый подход состоит в том, чтобы создать только то, что действительно необходимо сейчас, и выполнить это сейчас.

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

Часто есть некоторые ключевые вещи, которые абсолютно необходимо установить, прежде чем что-либо можно будет доставить, такие как настройка окружения и тому подобное. Для этого многим командам полезно иметь «Спринт 0», в котором заложены основы. Спринт 0 может быть немного длиннее, чем ваши другие спринты, поскольку он не применяется к вашему бэклогу или сбою продукта, но все равно должен быть ограничен по времени.

Что доставляется клиенту на этих первых итерациях?

Что имеет наибольшую деловую ценность для пользователя. Например, если приложения имеют сложные бизнес-правила, первые итерации будут содержать только те бизнес-правила, закодированные в виде кода. Клиент должен быть доволен, пока у вас есть код для этих бизнес-правил. (Проблема на самом деле убедить клиента принять такую ​​вещь совершенно иная.) Например, вы можете показать бизнес-экспертам клиента свои модульные / приемочные тесты, которые выражают то, что должен делать домен, и этот код передает его с зеленым результатом. Или даже лучше, чтобы бизнес-эксперты помогли создать эти тесты.

Существует также вопрос

Вы могли бы построить структуру или основы

То, что я считаю, намного важнее, чем то, что фактически доставлено. Для Evolutionary Design очень важно то , что вы должны создавать архитектуру со временем, а не пытаться создавать ее в начале. Что касается основы, это обычно означает какую-то базу данных или структуру пользовательского интерфейса. В этом случае есть идея: « Хорошая архитектура - это та, которая позволяет вам откладывать важные решения ». И выбор базы данных или пользовательского интерфейса является важным решением. Например, вы можете использовать только хранилище данных в памяти, вместо того, чтобы пытаться использовать БД с самой первой итерации.

То, что мы пытаемся сделать, - это предоставить на первых итерациях максимально простое приложение (привет версия того, что мы предоставляем). В этом мы видим 3 важных преимущества:

• Настройте процедуру доставки (всегда одна из самых сложных частей imho) (получите среды, серверы на месте, обновите безопасность для этой среды). Поскольку мы будем доставлять часто, важно сделать это правильно как можно скорее.
• Дайте пользователям первые сведения о том, как будет выглядеть приложение. Это помогает пользователям и разработчикам понять, чего они действительно хотят и что им нужно.
• Иметь базовое представление о том, как будет выглядеть архитектура приложения (приложение должно охватывать основные «слои» или компоненты приложения).

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

Это неправильно, так как вам не нужно создавать каркас, который вы можете использовать в будущем. Идея состоит в том, чтобы построить только то, что нужно (см. Также YAGNI ).

В нулевом спринте нужно готовиться к реальной работе. Многие люди спорят о том, что должно быть сделано в этом спринте, но, на мой взгляд, все кончено, когда вы можете начать работать над элементами в отставании. Этот шаг включает в себя настройку ПК, настройку процесса сборки, выбор каркасов и т. Д.

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

Что доставляется клиенту на этих первых итерациях? Как вы показываете прогресс в правильном направлении при создании кода скаффолдинга?

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

Если ваш вопрос «как выбрать то, что входит в итерацию X?», Посмотрите на эти видеокасты (видео для итерации 0 A и часть B).

Вы можете доставить практически все, что захотите. Идея построения инфраструктуры просто неправильна / не проворна / неустойчива.

Например: создание полнофункционального приложения Hello World может быть построено за несколько часов. Подготовка сервера (даже временного) в облаке или в качестве виртуальной машины может быть выполнена за несколько часов.

Этого достаточно, чтобы начать развиваться . Затем, если вам нужен CI, вы можете добавить историю CI, если вам нужен физический сервер, обязательно добавьте историю для этого.

Но начните доставку в первый день и никогда не останавливайтесь!

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

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

Часть гибкого подхода заключается в том, чтобы клиент был близко, поэтому документация не нужна, потому что все, что вам нужно сделать, это взять трубку / отправить электронное письмо, и это ожидается. Ожидания клиентов должны быть установлены соответствующим образом, и любая выполненная работа должна быть очень краткой и НУЖНОЙ . Нет позолоты, нет «Тебе это может понадобиться» и т. Д. Постройте то, что вам нужно, чтобы перейти на B.

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

Если вы договорились о сроках с клиентом, если вы собираетесь выполнить это соглашение, клиенту, вероятно, будет все равно, что вы делаете 1-го или 2-го. Вы всегда можете показать им результаты модульных тестов, но если вы скажете, что после спринта 2 (или 3) у вас будет кое-что посмотреть, это будет иметь сильный приоритет. Ожидается, что клиенты будут разумными, как и разработчики, и оба работают над одной и той же целью. Завершенный проект, который отвечает потребностям клиента и работает как ожидалось. Так что беспокойство о том, что после спринта 1 ничего не видно, является спорным вопросом, потому что клиент просто хочет убедиться, что после спринта 20 проект будет завершен (-ish).