Где грань между полным отсутствием планирования и параличом анализа? - PullRequest
6 голосов
/ 19 марта 2009

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

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

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

Ответы [ 5 ]

6 голосов
/ 19 марта 2009

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

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

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

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

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

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

3 голосов
/ 19 марта 2009

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

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

3 голосов
/ 19 марта 2009

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

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

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

2 голосов
/ 19 марта 2009

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

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

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

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

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

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

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

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

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

1 голос
/ 20 марта 2009

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

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

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

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

...