Не могу понять определенный момент в Принципах Agile Manifesto

24

Я читал Принципы Agile Manifesto . Все кажется ясным и разумным, за исключением одного момента:

Простота - искусство максимизировать количество не выполненной работы - очень важно.

Я не понимаю этого. Значит ли это, что не выполненная работа должна быть как-то преувеличена? Если это так, это не имеет смысла.

agile management

— superM
источник

2

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

1

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

30

Удалить комментарий в скобках. Остается только «Простота необходима», что, кстати, является приложением принципа к самому его выражению.

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

Я всегда истолковывал в смысле краткости слова Паскаля : « Я написал бы более короткое письмо, но у меня не было времени». Вам нужно избегать того, что не нужно (из письма, из кода), и это активная задача , а не простой. Это не то, что происходит само по себе.

— Francesco
источник

35

Идея состоит в том, чтобы избежать выполнения ненужной работы, то есть «максимизировать объем не выполненной работы».

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

ЯГНИ - это родственное понятие.

— Йоахим Зауэр
источник

5

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

— Макс

2

@ Макс, я думаю, необходимо предвидеть будущие возможные изменения. Здесь предвидение очень помогает. А разработчики, которых вы описываете, больше похожи на страусов, которые прячутся в песке.

— СуперМ

7

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

15

@ Макс: YAGNI о задержке решений до последнего ответственного момента. То, о чем вы говорите, это откладывает принятие решения до последнего возможного момента, который действительно является Плохой Идеей ™. Дело в том, что у вас никогда не будет меньше информации для принятия решения, чем сейчас. В худшем случае у вас будет та же информация завтра. Но, как правило, вы узнаете что-то к тому времени. В случае , если вы упомянули, вы знаете , что это понадобится, поэтому YAGNI просто не применяется. Попытка применить это действительно глупо в этом случае.

— Йорг Миттаг

2

@ Макс: То, что вы здесь описываете, является полной противоположностью максимизации объема не выполненной работы. Это делает вдвое больше работы.

— фунтовые

5

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

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

— Стюарт Вудворд
источник

4

Эта идея очень похожа на концепцию Toyota Production System (TPS) , которая привела к более универсальному Lean Manufacturing, а затем к применению этих методов в Lean Software Development . TPS значительно предшествует гибкому движению, его корни в производстве в конце 1950-х годов.

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

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

— Томас Оуэнс
источник