Как вы обрабатываете планирование/сроки для программистов?

Ответ 1

Во-первых, вам нужно различать сроки и оценки.

• Крайние сроки исходят из внешних источников, например, "Функция X должна быть готова к выставке".
• Оценки исходят из внутренних источников, например: "Функция X займет N недель".

Как правило, программисты должны создавать оценки, а продажи/маркетинг создадут предельные сроки.

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

Полезные подсказки для dev (ведет):

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

Полезные советы для маркетологов/создателей крайних сроков:

• Не переопределяйте оценку с заданным сроком.
• Если крайний срок конфликтует с оценкой, единственными реальными вариантами являются: (a) разработчики работают сверхурочно; (б) требования к предельному сроку обрезаются или (c) срок пропущен.
• Объясните, почему крайний срок важен и какова цель крайнего срока функции ( "клиент X подпишет шестизначный контракт" ).
• Понять, что люди, которые считают, что они не могут соответствовать агрессивным срокам, не будут мотивированы.

Ответ 2

Программисты Крайние сроки для HATE по очень веским причинам!

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

Из моего личного опыта я потратил более недели на получение "простой" оболочки script для работы, которую я бы оценил примерно через час. С другой стороны, потребовалось около недели, чтобы написать синтаксический анализатор для определения данных COBOL (включая все странные COMP COMP-3 OCCURS, переопределяющие SYNC и слабые байты), которые я оценил примерно через два месяца.

Другая большая проблема заключается в том, что перед трудными программистами-программистами пропустить передовую практику и начать взлом. Таким образом, экономия около 50% времени кодирования, но добавление 300% к времени тестирования и отладки.

Ответ 3

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

Ответ 4

Разработчики должны участвовать в создании крайних сроков. Если они произвольны и созданы без ввода от разработчиков, то они имеют право жаловаться. Проекты законно получают временные ограничения от бизнеса, но ресурсы и функции должны быть скорректированы для компенсации. Эти корректировки не могут быть сделаны без участия разработчиков (не говоря уже о BA, QA и операционных персонажах).

Ответ 5

Единственные разработчики/разработчики программного обеспечения, с которыми я встречался, которые ненавидят сроки, считают это по одной из двух причин:

• Они полностью дезорганизованы, и знайте, что они не крайний срок, и поэтому им не нравятся потому что, когда они пропускают крайний срок это заставляет их выглядеть плохо.
• Они не имеют проблемы с предельными сроками, поскольку как тот, кто понимает работа связана с установкой крайний срок. Наихудшие сроки сделанные менеджерами, пытающимися продать проект и сказать "3 недели? Нет проблемы! ", а затем что у них есть 3 недель для создания рабочей версии офиса MS и воссоздать Интернет для генерального директора маленький ребенок.

Ответ 6

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

Если кто-то из высшего руководства просто диктует, что "Feature X должен быть сделан Y", не имея никакого представления о том, как долго это может произойти (некоторые вещи намного сложнее реализовать, чем они звучат) что Плохая Вещь. Однако, если они работают с разработчиками, чтобы оценить объем необходимых усилий и сбалансировать то, что требуется остальной части компании, тогда это обычно хорошо работает.

Ответ 7

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

Ответ 8

Регулярные обзоры имеют решающее значение:

• Перечислите основные этапы и результаты.
• Разбить его на мелкие куски
• Создайте коллекцию меньших оценок
• Сделайте сроки разумными.

У вас должны быть крайние сроки, но в равной степени эти предельные сроки должны быть реалистичными и измеримыми. Перемещение спецификации вокруг будет раздражать разработчика - это может быть неизбежно, но не бойтесь переместить вещи (после обсуждений).

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