Где грань между полным отсутствием планирования и параличом анализа?

Question

За очень короткое время работы в области программирования я видел две крайности:

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

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

Answer 1

По своему личному опыту Я обнаружил, что "решения" - это моя горлышко от бутылки .

Если это так, то:

1. Перечислите все ваши варианты дизайна
2. Выберите вариант (ы) (выберите несколько, если вы не можете определиться с одним)
3. Перечислите риски лучшего варианта (ов)
4. Для каждого риска продумайте решение, затем составьте убедительное доказательство концепции и напишите его.
5. Если ваше доказательство концепций доказывает, что оно НЕ будет работать, бросьте эту опцию и выберите другую.

«Доказательство концепции» - это минимальное приложение, чтобы доказать что-то. (мои обычно 1-6 часов)

Если у вас есть ситуация, когда 2 или более вариантов равны, дайте себе ограничение по времени (например, 5 минут, а не 2 месяца) и примите решение ... любое решение, и не оглядывайтесь назад.

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

Answer 2

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

Если вы можете, в начале проекта, заявить, что вы хотите покрыть определенный процент требований на этапе планирования, например, 80-90%. Таким образом, есть четкая цель, и вы не стремитесь к совершенству. Вы можете вернуться к планированию и анализу позже, только не позволяйте ему что-то делать.

Answer 3

Первоначальное планирование должно быть примерно O (log n), где n - ожидаемое общее время разработки.

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

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

Answer 4

Я думаю, что это зависит от 2 факторов:

• длина проекта

  • Это 1 недельный проект?
  • Это годовой проект?
  • Или где-то посередине?

• риск изменений, вносимых в проект

  • Являются ли они архитектурными по природе, потенциально влияющими на многие исходные коды?
  • Или вы просто добавляете новую функцию?

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

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

2 самые большие ошибки, которые вы можете сделать в дизайне:

1. Attemping to design EVERYTHING (you will fail)
2. Designing NOTHING before implementation

Нахождение счастливой среды между этими двумя является ключом к успешному проектированию и планированию.

Answer 5

Великолепные вопросы - без абсолютного ответа - вот что делает опыт значимым. Опыт работы в том числе:

• сколько деталей вы можете получить от любого пользователя / спонсора и от этой конкретной группы
• сколько деталей нужно вашей текущей команде (технические / бизнес-уровни)
• насколько ваши спонсоры / пользователи открыты для помощи во время разработки (насколько гибка ваша команда - включает ли она спонсора / пользователя?)
• насколько хорошо вы выявляете пробелы

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

Чем сложнее, стоимость / время ограничены, жизненно важны, тем больше предварительных работ - чем меньше, тем больше деталей вы можете детализировать по мере выполнения работы (от прототипа до производства)