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

Напишите код, протестируйте его, поместите в файл .zip и отправьте клиенту. Бонусные баллы за TDD и контроль версий.

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

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

Примечание: если это имеет значение, мы, прежде всего, магазин Microsoft .NET. И мы смотрим на гибкие практики, такие как XP и Scrum, но нам, возможно, придется серьезно изменить их, чтобы они работали в нашей компании.

Я бы разбил его на разделы, такие как

• Текущий штат - имена и должности (в идеале с фотографиями)
• Заявки, логины к ним, данные, которые нужно знать, и запросы на разрешение, которые были отправлены
• Закладки на сайтах компании и ключевых внешних сайтах, имеющих отношение к бизнесу
• Приложения, которые компания использует для связи, электронной почты, бронирования конференц-зала, sharecreen
• Процедуры для связанных с компанией действий, таких как Расходные квитанции, бронирование поездки
• Настройка машины разработчика. Подробно опишите процесс настройки новой машины для разработчиков. Обычно это «ожидается», чтобы занять всего один день, но на самом деле это обычно занимает 3-5 дней.
• Процесс разработки, как работа отслеживается, назначается и обновляется и какие инструменты используются.
• Как проверить, что проверить, когда проверить, где проверить.
• Стандарты кодирования, включая соглашения об именах файлов и стандарты для конкретных языков.
• Как обрабатывать ошибки, где их документировать, как их исправлять.
• Процесс развертывания, каковы основные вещи, которые нужно знать для производства.
• Как документировать, что документировать, когда документировать.
• Где материал «есть», например, местоположение (я) для кода, данных, стандартов, документации, ссылок и других активов.

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

Для каждого раздела я бы постарался написать его с точки зрения новичка. Самое главное будет убедиться, что это действительно имеет смысл для новичка. Ваш босс, очевидно, не тот человек, который может это проверить, поскольку он не является целевой аудиторией. Он прав хотеть этого, просто убедитесь , что содержание не заканчивается испытывается на него. Кроме того, у «новичка» есть только «1 неделя» как у новичка ... и только одна точка зрения. Поэтому вполне вероятно (и рекомендуется), что документ будет уточняться с каждым новым сотрудником. На самом деле, это очень хорошая задача - назначить их на первую неделю, то есть «Обновить руководство для новичка».

Для Agile / SCRUM:

Самая сложная часть работы с Agile и SCRUM - это «действительно».

Для чтения я бы начал с http://agilemanifesto.org/ и пошел оттуда.

Я также прочитал бы известный http://www.halfarsedagilemanifesto.org/, который добавляет вес к факту, что вам действительно нужно принять все аспекты, чтобы это работало. Если вам придется сильно модифицировать Agile для своих организаций, вполне вероятно, что люди хотят получить выгоды - без использования правильных процессов. Этот факт сам по себе должен быть представлен, чтобы отразить любую полусмысленность.

Похоже, вам придется ввести некоторые практики, прежде чем документировать их!

а) Контроль источников - как вы храните свои источники и делаете контроль версий

б) Управление выпуском и отслеживание - как вы делаете сборку, нумеруете релиз, сравниваете текущий релиз-кандидат с предыдущим выпуском

c) Управление проблемами - как вы отслеживаете ошибки в своих выпусках.

Это довольно простые вещи, но их реализация может занять много времени (и, возможно, стоить денег).

Темы, которые я бы включил в справочник разработчика:

• Роли / должности в отделе и их соответствующие обязанности
• Требования к программному обеспечению компьютера разработчика (т.е. необходимая среда разработки)
• Где и как получить доступ к хранилищу исходного кода
• Используемые инструменты разработки (например, IDE)
• Стиль кодирования / стандарты
• Стандарты документации
• Процесс тестирования
• Процесс сборки
• Процесс развертывания
• Поддержка и процесс управления проблемами
• Где взять самую последнюю версию этого руководства

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

Использование контроля источника

• Какой инструмент управления исходным кодом вы используете.
• Синтаксис общих команд / инструментов в IDE.
• Стратегия ветвления / слияния.
• Какой должна быть единица коммита? Как долго это слишком долго, чтобы файл был извлечен / не зафиксирован?
• Какой уровень «донесенности» обозначает фиксация / регистрация? Собирает? Юнит тесты проходят? Отзыв?
• Что ожидается включить в заметки для фиксации / регистрации.
• Процедуры отката.