Что замедлило разработку вашего проекта и как вы его преодолели?

Question

Что-нибудь замедлило разработку проекта, над которым вы работали, и если да, то как вы его улучшили?

1. Недавно мы внедрили непрерывную интеграцию для решения проблемы постоянно нарушенной сборки.

2. Для повышения качества кода мы ввели обзоры кода.

3. Клиент постоянно изменял статические данные (поиски), поэтому мы внедрили процесс управления изменениями вокруг него.

4. Связь с нашими оффшорными коллегами была сложной, поэтому мы представили офисный коммуникатор

Мне было бы интересно услышать о вещах, которые замедлили вашу команду, и о том, как вы их обошли.

Answer 1

Наша самая большая потеря производительности - это когда разработчики не достигают точки, когда они " программируют в зоне ".

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

Answer 2

Чтение Stackoverflow.com и поиск ответов на вопросы пользователей занимают довольно много времени. Ох ... подожди ...

Answer 3

Лично я обнаружил, что чрезмерное усердие менеджеров проектов в прошлом вызывало очень медленное развитие. PM, которым нужны очень точные спецификации и встречи для освещения проекта и т. Д., Возникает много проблем, и иногда вам просто нужно сказать им, как мало вы делаете. Кроме того, я обнаружил, что изменения в сознании клиентов потеряли меня много времени в прошлом, и я работаю над процессом выхода, когда клиенты будут платить за потраченное время, когда они передумают.

Answer 4

Номер один намного больше всего на свете: Неспособность адекватно или точно определить требования .

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

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

Answer 5

Если большая часть разработки происходит на шельфе, то

1. Убедитесь, что ваши оффшорные коллеги имеют лучшие доступные аппаратные / программные ресурсы. Я видел это как серьезную причину потери производительности. Оффшорный подрядчик предоставит своим разработчикам устаревшие версии средств разработки. Их машины разработки будут иметь плохие конфигурации (объем ОЗУ и т. Д.), Что приведет к серьезным потерям производительности. Исходя из требований, убедитесь, что как для оффшорных, так и для локальных разработчиков имеется одинаковое программное и аппаратное обеспечение, доступное для разработки.

2. Более того, проблемы с сетью на разных континентах действительно замедляют развитие. Во многих проектах, в которых я работал, оффшорные команды подключались к базам данных, расположенным в США, что значительно замедляло разработку / тестирование. Это большой демотиватор, когда для бывших. выполнение одного запроса на выбор занимает несколько секунд.

Answer 6

Некоторые вещи, тормозящие проект:

• Многосайтовая (оффшорная) связь (иногда даже распределенная команда). Я пытался настроить время коробочных конференций (статус, уточнение требований) и со строгим контролем вещей, которые будут обсуждаться. Конечно, с протоколом встречи в конце, поэтому никаких дальнейших обсуждений о том, что было решено.

• Непрерывные изменения от клиента. Они, как правило, устные, спрашивают непосредственно команду разработчиков, фрагментируя команду разработки / тестирования. Я использую, чтобы заставить единственную точку связи, когда дело доходит до изменений - панель управления изменениями. Обработка изменений (анализ, техническое решение, планирование и т. Д.) Осуществляется и в этой панели управления. Выводы документированы. Небольшие изменения планируются и обрабатываются как единое целое ради эффективности.

• Обновление технической документации - это выглядит как замедление с точки зрения разработки, но обычно окупается другими действиями (обработка изменений, обсуждение с заказчиком, включение и т. Д.). Так и должно быть сделано :). То, что не должно быть сделано, состоит в том, чтобы поместить слишком много деталей, добавляет небольшую ценность. Тем не менее, правильная степень детализации ... нет правила, чтобы выяснить это:).

• Я почти забыл: «Анализ - Паралич»: слишком много думать (о техническом решении). Задуматься и т. Д. Это определенно замедлит развитие в целом. Принятие прагматичного подхода может помочь.