Как большое количество разработчиков может записать программное обеспечение вместе или без громоздкого процесса или без программного обеспечения низкого качества?
Я работаю в компании с сотнями людей программное обеспечение записи для по существу того же продукта. Качество программного обеспечения должно быть высоким, потому что столько людей зависит от него (не в последнюю очередь сами разработчики). Из-за этой каждой главной проблемы привел к новой проверке - или автоматизированный или руководство.
В результате процесс поставки программного обеспечения становится еще более обременительным. Таким образом, это требует большего количества разработчиков, которые... хорошо Вы видите, что это - порочный круг.
У нас теперь есть проблема с выпуском программного обеспечения быстро - время выполнения заказа даже для изменения одной строки кода для очень серьезной проблемы составляет по крайней мере один день.
Какие методы Вы используете для ускорения предоставления программного обеспечения в крупной организации при тихом поддержании качества программного обеспечения?
4 ответа
Я также работаю в большой и громоздкой организации. Я успешно реализовал несколько методологий гибкой разработки программного обеспечения , но две, в частности, я считаю особенно ценными.
Итеративная и инкрементальная разработка - Сделайте цикл выпуска коротким и плотным. Если в большой команде вносятся многочисленные изменения между выпусками, вы можете столкнуться с кошмаром интеграции.
Крупные организации склоняются к большим планам проектов с длительными сроками разработки. Боритесь с этим. Планировать проект на год не имеет смысла, если все ваше восприятие может измениться после первых двух недель разработки. Научите своих заинтересованных лиц привыкнуть к идее создания небольших инкрементальных выпусков и адаптации к постоянно меняющимся требованиям.
Автоматические модульные тесты - это отличный способ убедиться, что вы выпускаете качественное программное обеспечение. Наихудшие ошибки вызваны, казалось бы, невинными изменениями кода, которые имеют непредвиденные последствия в другом месте. Комплексные модульные тесты, возможно, лучший способ отловить этот вид ошибки. Если вы можете перейти на разработку, управляемую тестированием или разработку, управляемую поведением , еще лучше.
В любой крупной организации будут посредственные разработчики. Это факт жизни. Автоматическое модульное тестирование - отличный способ следить за ними. Попросите одного из ваших лучших разработчиков написать для них свои модульные тесты. У вас будет уверенность, что по крайней мере их код работает (даже если он уродлив).
И, пожалуйста, прочтите Тест Джоэла: 12 шагов к улучшению кода .
Мудрые, но мрачные высказывания:
Фред Брукс: Добавление программистов в поздний проект делает его позже .
Джерри Сассман: Программисты соединяют параллельно, как резисторы.
Кто-то еще: Стоимость проекта - это количество программистов, умноженное на продолжительность расписания.
Что-то, что может сработать:
Организуйте проект так, чтобы было базовое приложение, созданное одним или двумя людьми, предпочтительно управляемое через язык. Затем позвольте всем программистам быть пользователями ядра посредством кодирования на этом языке.
Есть много способов улучшить процесс, но ключевым компонентом является модульность . Четко разделив обязанности (как в коде, так и в организации) и определив четкие и последовательные интерфейсы, одна большая команда может работать так же, как и множество маленьких команд, связанных вместе.