Как получить хороший дизайн при использовании гибких методов?

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

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

Проблема: сложность получить хороший дизайн

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

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

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

Вопрос : У кого-нибудь был подобный опыт? Неправильно ли я применяю SCRUM или на что мне следует обратить внимание, если я хочу развиваться небольшими шагами и при этом получить хорошо разработанное программное обеспечение? Или я должен запланировать историю проекта перед тем, как начать собственное кодирование? Считается ли это хорошей практикой, по крайней мере, для функций, которые являются более сложными, чем в среднем?

РЕДАКТИРОВАТЬ - ПРИМЕЧАНИЕ

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

Например, меня не волнует (слишком много) хороший дизайн, если мне нужно реализовать простой компонент, который (1) должен быть готов как можно скорее, (2) будет использоваться только один раз, (3) не будет используется другими частями системы (YAGNI).

Меня интересует хороший дизайн, когда компонент (1) будет использоваться несколько раз и в нескольких различных выпусках продукта, (2) необходимо поддерживать и расширять с течением времени, (3) имеет много других компонентов в зависимости от него ,

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

Тогда не делай этого.

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

В более общем случае я видел 3 вещи, которые я сделал, чтобы получить хороший дизайн в Agile:

• На самом деле занимаюсь дизайном - многие места, которые я видел, начинали свой спринт и просто начинали ковбойствовать. Вы получите плохой дизайн таким образом. Agile не меняет процесс разработки плана - кода - тестирования - выпуска, он просто сокращает его до более детальных фрагментов. В начале спринта садитесь по мере необходимости и на самом деле разрабатывайте свое решение.

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

• Будь прагматиком - я рассказал об этом выше. Agile это инструмент, и, как и любой инструмент; это не относится ко всем проблемам. Если не имеет смысла применять к какому-либо компоненту, не применяйте его там. Ваша цель - поставлять хорошее программное обеспечение; не забывай это

Это очень возможно реализовать небольшими шагами и получить хорошо структурированный обслуживаемый код. Теоретически это очень просто: если вы гарантируете, что код хорошо структурирован после каждого изменения, он всегда будет хорошо структурирован. Ваш код становится плохо структурированным, потому что вы продолжаете добавлять код, когда вам нужно проводить рефакторинг.

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

«Хорошо продуманный» субъективен

Что значит «хорошо продуманный» для вас? Владельцу продукта? заказчику?

Является ли «хорошо продуманный » целью владельца продукта? цель клиента? или только ты?

Является ли то, что вы считаете "не очень хорошо продуманным", все еще оправдывающим ожидания Владельцев продукта и радующим клиента? Тогда это довольно "хорошо продумано" .

Достаточно хорошо и ЯГНИ

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

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

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

SCRUM

_{Гибкая методология, которую можно записать, не является гибкой методологией ». - Джаррод Роберсон}

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

Большинство магазинов, в которых я работал, имеют так называемые Sprint ZERO, Sprints для старших членов команды, чтобы набросать общую архитектуру или тему продукта.

Истории, которые превышают, скажем, 20, обычно разбиваются до тех пор, пока они на самом деле не станут несколькими 3 - 5 баллами. Одна из этих историй гласит: «Нам, как команде, нужно встретиться, чтобы обсудить, как мы собираемся разработать эту функцию, чтобы у нас было как можно меньше технических долгов, если бы отводилось время».

Обычно

В общем, хорошо продуманная система достаточно хороша и следует за YAGNI.

Agile и SCRUM, в частности, как реализация Agile, больше рассказывают о том, как сделать продукт максимально прозрачным для владельца продукта / спонсоров.

Это не о техническом дизайне и архитектуре. Это больше философия о том, как подходить к поставке программного обеспечения, которое отвечает потребностям и ожиданиям клиентов. Если нет того, что вы называете «хорошо разработанными» деталями, это само по себе не является недостатком, так как это не является фундаментальной частью философии.

Мы работаем со Scrum в течение нескольких месяцев, и я хочу поделиться своим опытом относительно вашей проблемы.

Несколько месяцев назад мне дали большой кусок для реализации. У меня были готовы все спецификации, поэтому я должен был соответственно реализовать новые функции. Задача была занять около 5-6 недель (как я подсчитал). Я провел первую неделю, работая только над дизайном. Задача была немного сложной: существовал главный объект, который, как я заключил из спецификации, имел 15 разных состояний, а пользовательский интерфейс должен был иметь разные поведения для каждого состояния.

Я разработал весь рабочий процесс, а также структуру и классы БД.

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

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

Задний взгляд 20-20. Если у вас была информация в начале проекта, чтобы выяснить все это, а затем написать код через несколько недель, я предлагаю вам сделать это.

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

Зачем кому-то с историей успешных проектов падения воды переключиться на гибкую методологию?

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