(no subject)
Jul. 28th, 2009 08:19 pmПри определении атомов важно не совершить распространённую ошибку. Часто возможно автоматически разбивать их на части и достичь уровня кода без особых усилий. Но когда доходит до стадии разработки, начинается хаос. Настоящие проблемы не ушли, они просто просочились и стали ужасными внутренними интерфейсами, низкой производительностью, хрупкостью и т.д. Границы атомов моделирования сжимались и сжимались .. пока не стали опять границами всей системы. Доктрина механического дробления без сверки с реальностью привела ко многим трагедиям в разработке.
Уменьшение атомов может быть цикличным, и опытный архитектор находит для этого правильное место, будь то верхний, нижний или средний уровень. Начальные стадии изучения проблемы могут состоять вообще из одного большого атома, который можно передать надёжному сотруднику, чтобы он привёл его в порядок.
По определению мы не можем найти лучшее представление для атома моделирования, иначе бы он не был атомом. Поэтому он не может быть представлен, например, в виде диаграммы Ганта. Он должен быть единой задачей с некоторым оценочным временем решения. Опытные картёжники могут довольно точно оценить необходимое время, хотя и не могут сказать как они это делают, и поэтому бессмысленно спорить с ними. Страх неаргументированного спора часто служит фактором, мешающим делать интуитивные оценки, которые нужны для планирования проекта.
Когда атомы моделирования соединяются, работник может обычно выдать детальный список задач, основанный на чётком понимании того, что надо делать. На этом этапе можно построить или обновить диаграммы Ганта. Во многих проектах, в которых диаграммы составлялись для всего подряд на всех этапах, программисты не могли пользоваться осознанным управлением атомами моделирования. Вместо того, чтобы фокусироваться на проблемах, они должны были доказывать свою компетентность и находились под постоянным давлением, как будто человека можно заставить думать, унижая его - это контрпродуктивно и приводит лишь к стрессам.
Уменьшение атомов может быть цикличным, и опытный архитектор находит для этого правильное место, будь то верхний, нижний или средний уровень. Начальные стадии изучения проблемы могут состоять вообще из одного большого атома, который можно передать надёжному сотруднику, чтобы он привёл его в порядок.
По определению мы не можем найти лучшее представление для атома моделирования, иначе бы он не был атомом. Поэтому он не может быть представлен, например, в виде диаграммы Ганта. Он должен быть единой задачей с некоторым оценочным временем решения. Опытные картёжники могут довольно точно оценить необходимое время, хотя и не могут сказать как они это делают, и поэтому бессмысленно спорить с ними. Страх неаргументированного спора часто служит фактором, мешающим делать интуитивные оценки, которые нужны для планирования проекта.
Когда атомы моделирования соединяются, работник может обычно выдать детальный список задач, основанный на чётком понимании того, что надо делать. На этом этапе можно построить или обновить диаграммы Ганта. Во многих проектах, в которых диаграммы составлялись для всего подряд на всех этапах, программисты не могли пользоваться осознанным управлением атомами моделирования. Вместо того, чтобы фокусироваться на проблемах, они должны были доказывать свою компетентность и находились под постоянным давлением, как будто человека можно заставить думать, унижая его - это контрпродуктивно и приводит лишь к стрессам.