Рекомендации по своевременной доставке программного обеспечения

Question

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

Как ты придерживаться графика и достичь этого рубежа 1.0?
Каков ваш подход к итеративная доставка?

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

Answer 1

<Ол>

Сосредоточьтесь на функциях, а не на задачах реализации.

Работайте итерациями (например, еженедельно или раз в две недели).

Разместите рабочие функции в своей промежуточной среде в порядке приоритета.

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

Будьте готовы вырезать сферу из менее важных функций. Материал всегда занимает больше времени, чем вы думаете.

Обязательно заранее набросайте интерфейс (если он есть) и покажите его потенциальным пользователям.

Тестируйте, тестируйте и тестируйте еще немного. Это кажется нелогичным, но экономит больше времени, чем занимает.

Answer 2

Это, вероятно, утопический сценарий ;-). Но в любом случае, если не будет ползучести функций, очень хорошей команды и четко определенных требований без каких-либо проблем со связью, то, вероятно, лучшим способом доставить продукт вовремя будет

<Ол>

Еженедельная встреча с командой для оценки текущего статуса (PM с командой, если есть PM)

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

Отслеживание плана проекта и делегирование работы (руководитель группы должен знать индивидуальные сильные стороны каждого члена команды для надлежащего делегирования работы).

Тестирование может быть автоматизировано настолько, насколько позволяет технология.

Право собственности на работу каждого члена команды.

Конец рабочего дня сводится к тому, насколько человек увлечен своей работой.

Просто мои 2 пайса; -)

Answer 3

Вопрос. Как крупный программный проект опаздывает на год? Ответ. Один день за раз!

Это не дает ответа на ваш вопрос, но я думаю, что это указывает на необходимость придерживаться вашего графика - если вы даже опаздываете на один день, вам нужно как-то его догнать. (К сожалению, остальная часть «Мистического человека» посвящена тому, что в большинстве проектов «как-то» нет ...)

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

Answer 4

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

Answer 5

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

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

Answer 6

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

• плохо определённая сфера применения
• ползучесть функций
• отсутствие знаний предметной области
• большие команды с проблемами коммуникации
• немотивированные/некомпетентные разработчики

Answer 7

Узнайте, какие критически важные функции предназначены для клиента. Защитите прогресс на них. Часто очень верно, что 80% успеха приходится на 20% работы.

Answer 8

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

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

Answer 9

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

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

http://shipcamp.com