Как вы избегаете технического долга, сохраняя при этом истинную гибкость, т.е.: избегая нарушения YAGNI и избегая BDUF?

Ответ 1

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

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

Я очень сильно рекомендую книги Майка Кона по гибкому планированию:

• Использованы пользовательские истории
• Agile Estimating and Planning

Обновление: После разъяснения об исключении YAGNI и BDUF в течение итерации...

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

Чтобы избежать , нарушающего YAGNI, я бы очень четко рассказал о том, что клиент ожидает для функции в рамках итерации. Только выполняйте работу, которая сопоставляется с тем, что ожидает клиент. Если вы думаете, что нужно добавить что-то лишнее, создайте для него новую функцию и добавьте ее в backlog of work. Затем вы убедите клиента увидеть его преимущества; так же, как клиент будет настаивать на выполнении функции в определенный момент времени.

Ответ 2

Было интересное обсуждение Технического долга на основе вашего определения, сделанного на HanselMinutes пару недель назад - Что сделано. Основы шоу заключались в том, что если вы измените определение "Готово", чтобы увеличить воспринимаемую скорость, то вы соберете Технический долг. Следствием этого является то, что если у вас нет правильного определения "Готово", вы, скорее всего, приобретете список предметов, которые необходимо будет завершить до выпуска, независимо от методологии проектирования.

Ответ 3

Вы, кажется, говорите, что "YAGNI" подразумевает "быстрый и грязный". Я этого не вижу.

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

• Тестируемое развитие (TDD), как процесс, является хорошим способом избежать YAGNI. Код, который только что "в случае, если он будет полезен", как правило, непроверен и трудно тестируется.
• TDD также в значительной степени устраняет принуждение к BDUF: когда ваш процесс начинается, садясь и начинающий делать что-то, что действительно обеспечивает ценность, вы не можете предаваться BDUF.
• TDD, поскольку практика проектирования означает, что большой дизайн появится, когда вы приобретете опыт и устраните реальный код.
• Непрерывная интеграция означает, что вы разрабатываете свой процесс, чтобы ваш продукт был в принципе освобожден в любое время. Это означает, что у вас есть интегрированный процесс качества, который пытается предотвратить падение качества основной линии.

По моему опыту, основными формами технического долга являются:

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

Не уверен, что это ответили на ваш вопрос, но мне было весело писать его.

Трой Демонбрюн прокомментировал:

Нет, это не мое дело... "быстро и грязно" = (непреднамеренно рискуя техническим долгом при попытке придерживаться YAGNI "). Это не значит, что YAGNI только быстро и грязно. грязный" - это то, что я использовал, чтобы процитировать Мартина Фаулера в его описании Технического долга

Избегание YAGNI - это еще один способ сказать KISS. YAGNI увеличивает технический долг. Между тем, избегая YAGNI и сохраняя низкий технический долг, между ними не возникает напряженности.

Я думаю, что я все еще могу пропустить суть вашего вопроса.

Ответ 4

Я нахожу Роберта Мартина Test Driven Development (TDD) помогает в решении этих проблем.

Почему?

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

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

Ответ 5

"Традиционный" ответ XP - это рефакторинг в сочетании с автоматическим модульным тестированием.

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

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

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

Ответ 6

Просто выполните простейшую вещь, которая работает. Я согласен с Айенде, когда он говорит, что ключ к гибкости заключается в том, чтобы "отправить его, часто". Такой регулярный цикл релиза будет означать, что у BDUF нет времени, и он также будет отговаривать разработчиков от нарушения YAGNI.

Ответ 7

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

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

Ответ 8

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

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

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

Я, возможно, не захочу, но, может быть, я буду, потому что в моем конкретном бизнесе/компании/отделе это происходит, или мне это нужно, но у меня просто нет времени, чтобы не было так быстро и грязно взломать деньги и держите мою работу, или мне может понадобиться, и рефакторинг позже будет болью в заднице, которая будет стоить в 10 раз больше, чем просто делать это сейчас с нуля, и у меня есть время СЕЙЧАС.

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

Изменить: Кстати, TDD - это противоположность YAGNI, с которой вы строите тест, даже зная, нужны ли вам они. Серьезно, перестаньте слушать академиков! Там нет волшебного способа создания программного обеспечения.

Ответ 9

Разумеется, гибкость будет держать ваш TD в любом проекте?

Тот факт, что вы реализуете то, что хочет клиент, т.е. с их обратной связью, сохраняет TD до минимума,

Ответ 10

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

В моем последнем месте работы я работал над устаревшим кодом, но был в контакте с людьми, разрабатывающими новый код, используя (предположительно) Agile и TDD.

Теперь TDD должен быть Red - Green - Refactor: записывать неудачные тесты, выполнять минимум, чтобы пройти тест, а затем переделать код, чтобы сделать его более удобным для обслуживания, убедившись, что он все еще проходит тест.

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

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

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

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

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