Я пытаюсь определить, какие гибкие методы мы будем использовать, и мне трудно определить список гибких лучших практик. Я бы хотел, чтобы мой список был с технической точки зрения (инженерный угол зрения) и должен определить, как инженеры SW должны подходить к разработке. Список должен быть связан с управлением как можно меньше.
Если это имеет значение, мы программируем в С++.
Довольно легко найти множество лучших практик, и это список, который мне удалось сформировать до сих пор:
- Рефакторинг
- Небольшие циклы выпуска
- Стандарт кодирования
- Коллективное владение
- Метафора системы
- Планирование игры
- Целая команда
- Ежедневные собрания Scrum
- Программирование пар
- Тестируемая конструкция
- Поведенческая разработка
- Непрерывная интеграция
- Обзор кода и дизайна
- Активные заинтересованные стороны
- Документ опоздал
- Широкое использование шаблонов проектирования
Мы уже используем некоторые из методов из списка. Некоторые из них мы не будем использовать.
Есть ли хорошие гибкие методы, которые я мог бы добавить в список?
PS Я могу добавить небольшое описание практики, если потребуется.
ИЗМЕНИТЬ
Как я уже сказал, мы уже используем некоторые гибкие методы (в основном, практики, которые оказались лучшими):
- Непрерывная интеграция - это очень хорошая практика. Быстрая обратная связь с последними регистрационными записями очень полезна. Имея время простоя, потому что кто-то сломал сборку, может быть очень неприятно, особенно если это длится дольше.
- Метафора системы - она мало помогает, потому что наличие описательных имен классов и функций помогает лучше понять код
- Стандарт кода - мы создали стандарт кодирования, прежде чем попасть в кодировку. Использование единообразного стиля кода является хорошим, потому что любой может взять другой код и работать над ним, как на нем.
- TDD - перед началом кодирования мы настроили среду для легкого создания модульных тестов, но только до недавнего времени мы начали применять принципы TDD. Я лично пробовал это несколько лет назад, и все прошло не так хорошо, но теперь мне это нравится. К сожалению, не все члены команды делают это - только половина команды.
- Ежедневные встречи Scrum - мы пробовали ежедневные встречи, и они не шли так хорошо. Как и в моей предыдущей работе, ежедневные встречи обычно превращаются в дискуссии продолжительностью более 30 минут. Наверное, мы пропустили хорошего мастера схватки (или лидера, как он называется?).
- Рефакторинг - мы делали рефакторинг, но только если кто-то из команды создает запрос на изменение. Мы специально не сделали этого: "Давайте теперь сидим и уменьшаем нашу техническую глубину".
- Небольшие циклы выпуска - сейчас у нас огромные циклы выпуска (6 месяцев), а для следующего выпуска мы планируем разбить цикл на 4-6 внутренних выпусков.
- Обзор кода и дизайна - мы сделали первоначальный обзор дизайна (например, 5 лет назад) и несколько обзоров проектов некоторых второстепенных субкомпонентов в течение этого периода. Мы провели обзор кода некоторых классов
- Документ поздно - мы сделали это для этой версии. Только требуемая документация означает, что написание документации становится менее интересным. Разработчики любят это:)
- Использование шаблонов проектирования - мы уже используем шаблоны проектирования, где это необходимо.
Из-за структуры нашей организации мы не можем использовать другие методы, но, как вы видите, список длинный, и вы не можете выбрать все. Кроме того, теперь мы всего лишь 4 разработчиков ПО, каждый из которых поддерживает около 80 кЛОК и работает над новым материалом. Поэтому мы не можем выполнять, например, парное программирование или коллективную собственность.
