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

Если это имеет значение, мы программируем на С ++.

Довольно легко найти множество лучших практик, и вот список, который мне удалось сформировать:

РефакторингМалые циклы выпускаСтандарт кодированияКоллективная собственностьСистемная метафораСтроганиеВся командаСкрам ежедневных встречПарное программированиеTest Driven DesignПоведенческое развитиеНепрерывная интеграцияКод и дизайн отзывыАктивные заинтересованные стороныПоздний документШирокое использование шаблонов дизайна

Мы уже используем некоторые практики из списка. Некоторые мы не собираемся использовать.

Есть ли хорошие гибкие практики, которые я мог бы добавить в список?

PS Я могу добавить небольшое описание практики, если требуется.

РЕДАКТИРОВАТЬ

Как я уже сказал, мы уже используем некоторые гибкие практики (в основном те, которые оказываются лучшими):

Непрерывная интеграция - это очень хорошая практика. Быстрая обратная связь о последних проверках очень полезна. Время простоя, потому что кто-то сломал сборку, может быть очень неприятным, особенно если оно длится дольше.Системная метафора - она ​​мало помогает, потому что наличие описательных имен классов и функций помогает лучше понять кодСтандарт кода - мы создали стандарт кодирования, прежде чем приступить к кодированию. Использование единого стиля кода - это хорошо, потому что каждый может взять код другого и работать над ним как сам по себе.TDD - до того, как мы начали кодировать, мы настроили среду для простого создания модульных тестов, но только до недавнего времени мы начали применять принципы TDD. Я лично попробовал это несколько лет назад, и это не очень хорошо, но теперь я люблю это. К сожалению, не все члены команды делают это - только половина команды.Ежедневные встречи Scrum - мы пробовали ежедневные встречи, и они шли не очень хорошо. Как и на моей предыдущей работе, ежедневные встречи обычно превращаются в дискуссии продолжительностью более 30 минут. Я думаю, мы пропустили хорошего мастера схватки (или лидера, как это называется?)Рефакторинг - мы провели рефакторинг, но только если кто-то из команды создает запрос на изменение. Мы не делали это так, как нарочно: «Давайте посидим сейчас и уменьшим наш технический долг».Небольшие циклы выпуска - сейчас у нас огромные циклы выпуска (6 месяцев), и в следующем выпуске мы планируем разбить цикл на 4-6 внутренних выпусков.Проверка кода и дизайна - мы провели первоначальную проверку дизайна (как 5 лет назад), и несколько обзоров дизайна некоторых незначительных подкомпонентов в течение этого периода. Мы сделали обзоры кода некоторых классовПоздний документ - мы сделали это для этого выпуска. Только необходимая документация означает написание документации меньше и больше интересного кодирования. Разработчики любят это :)Использование шаблонов дизайна - мы уже используем шаблоны проектирования там, где это необходимо.

Из-за структуры нашей организации мы не можем использовать другие методы, но, как вы видите, список длинный, и вы не можете выбрать все. Кроме того, сейчас у нас всего 4 разработчика ПО, каждый из которых поддерживает приблизительно 80 kLOC и работает над новым материалом. Поэтому мы не можем делать, например, парное программирование или коллективное владение.