Что является самым важным, когда необходимо установить инфраструктуру разработки программного обеспечения в компании? [закрытый]

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

Кто-то ответственный, кто знает то, что они делают.

Очевидно, существует много факторов, но здесь те, я сказал бы, крайне важны:

• Наймите умных людей (и заплатите им, что они стоят),
• Выберите хорошие инструменты, подходящие для вида разработки (не идите для дешевых инструментов),
• Установите систему управления версиями и политики
• Установите механизмы тестирования и политики
• Не бойтесь произвести на стороне материал, который Вы не знаете, как сделать

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

Не пытайтесь быть гибкими в технологиях. Сначала запустите путем фокусировки на одной технологии (Java.NET, безотносительно...) и затем переместитесь в другой, если Вы должны. Вы сможете решить проблемы с помощью любых технологий, но очень трудно найти людей хорошими во многих технологиях.

На уровне инфраструктуры Управление исходным кодом - необходимость. Непрерывная интеграция плюс. Займите время для помещения на месте стандартного расположения проекта, которое Вы сможете развить. Это помогает разработчикам переключить проекты. Займите время для помещения на месте хорошего процесса сборки (Муравей, Знаток, в мире Java). Интегрируйте свой процесс сборки с Вашим IDE так, чтобы разработчики не ожидали 5 минут для развертывания их проекта каждый раз, когда они хотят протестировать изменение кода.

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

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

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

Я соглашаюсь с Guillaume: Если Вы хотите создать отдел с нуля, необходимо сфокусироваться. Необходимо создать команду, сделать, чтобы все превратились в их новые обязанности, узнали друг друга и т.д. Попытка войти в слишком много направлений сразу является направлением к отказу.

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

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

Для будущего роста всегда думайте с точки зрения органического роста. Не увеличивайте размер команды на 200%, нанимайте одного нового парня здесь и другого парня (или галлон) там. Медленно создавайте свою команду. Когда Вы берете новый проект, всегда думаете о расширении Ваших экспертных знаний команд. Попробуйте что-то новое каждым проектом. Это может быть новым исходным репозиторием, автоматизируемым ежедневным процессом сборки, новая система для записи спецификаций или документации или даже другой технологии (например, Java, когда Вы обычно разрабатываете в .NET, Delphi или C++). Просто удостоверьтесь, что Вы никогда не пытаетесь сделать большой прыжок в важном проекте. (Я когда-то работал на компанию, которая решила переключиться от VB 6.0 до .NET для самого большого проекта, которого они когда-либо делали попытку прежде. Они выжили. Едва.)

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

Ах да, и smacl является правильным, также: Вам нужен твердый QA/QM, если Вы хотите, чтобы Ваш отдел пережил длительный срок.

Начните наложение (и follwing) Ваши правила QA со дня один. Сохраните их максимально короткими и гибкими. Добавьте, что Вы обнаруживаете, чтобы отсутствовать и вывести то, что оказывается ненужным или непрактичным.

Не уверенный это - то, что Вы хотели знать, но я чувствовал потребность сказать это ;-)

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

Многие из ваших решений очень зависят от вашего конкретного бизнеса и структуры программного обеспечения (единая база кода продукта, SOA, множество проектов и т. Д.). Но в целом вы всегда должны тратить значительное время на разработку базовой инфраструктуры программного обеспечения, которая принесет огромные дивиденды в течение SDLC.

Инфраструктура программного обеспечения

• Исключение из правил именования кодов

• Стратегии обработки Ведение журнала

• Настройки и конфигурация стратегий

• Базовые классы и вспомогательные классы

• Общая архитектура и уровни

  (презентация, фасад , Домен Сущности, хранилища данных и т. Д.)

• Инструменты дизайна, такие как UML 2.0 Требования

• Руководство / Взаимодействие с конечным пользователем

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

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

Удачи.

Raiford
www.blacksaber.com