Полезные и неиспользуемые методы разработки реальной жизни

Question

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

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

Например, мы используем сайт dotproject для нашей команды. Идея заключалась в отслеживании задач, обновлении хода и т. Д. Мы использовали «do, test, if» с ним, и результат был ... мы выбросили его и просто оставили форум, который был чрезвычайно полезен для общения между нами и отслеживания выводов встреч и списков TO DO ... С другой стороны, отслеживание каждой задачи оказалось трудоемким и нереалистичным.

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

Так что мой вопрос: какие методы разработки вы пробовали и находили полезными/неиспользованными?

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

• Внутренняя система отслеживания ошибок (полезная)
• полуавтоматической сборки (каждый разработчик должен поддерживать эквивалент Makefile для того, чтобы системы, чтобы иметь возможность сделать их).
• НЕТ автоматическое тестирование. Тестирование проводится тестовой группой. У нас есть интеграционные тесты и широкие системные тесты.
• Две испытательные лаборатории, одна для тестовой группы, другая для разработчиков (в случае, если им необходимо выполнить тест, который включает в себя более одной машины или для тестирования из машины разработки)
• В целом нет единичного тестирования. Некоторые библиотеки имеют их, но обычно разработчик тестирует свои подразделения по своему усмотрению.
• Полная спецификация с использованием ДВЕРЕЙ.
• Протоколы испытаний. Формальный, написанный в Word.
• Контроль источника (прозрачный футляр). Обычно все делается в основной ветке, всякий раз, когда мы отправляем версию, которую она маркирует, при необходимости для исправлений для этой версии создается ветка.

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

Answer 1

Лично я очень большой поклонник автоматического тестирования (как модульные тесты, так и интеграционные тесты). На мой взгляд, это похоже на защитную сетку - разработчики чувствуют себя более безопасными при смене кода, когда знают, что есть тестовая упряжь, которая может их поймать, если что-то сломает. Это позволяет быстрее вводить новые функции, но, например, удаляет «страх» рефакторинга.

Answer 2

Одна из самых полезных вещей, которую мы представили, - это проект Wiki, чрезвычайно полезный свалка для всех маленьких кусочков информации, плавающих вокруг в голове людей, но слишком тривиальных для записи в полном документе.

Answer 3

В управлении для нашей команды: SCRUM

Answer 4

Будучи вовлечен во всех видах команд разработчиков с различными методиками, мой опыт показывает, что большинство из гибких принципов, как правило, работает отлично. Это, как правило, делает разработку более увлекательной, так как все больше заняты. В более крупных средах разработки основной принцип совместного размещения всех членов команды приносит большие выгоды, особенно когда у разработчиков отдельными информационными аналитиками и тестировщиками. Аналитики, тестеры и разработчики информации работают вместе по каждой функции. Это создает лучший поток информации с минимальными накладными расходами. Это можно сделать еще до Lean development process.

В целом то, что дало нам наибольшую пользу, было тем, что снизило барьеры коммуникации. В практическом смысле компания wiki также помогала, снижая барьер для обмена информацией. Хорошая ошибка/особенности/инструмент отслеживания RFC также очень помогли совместному пониманию среди заинтересованных сторон того, в каком направлении идет проект. И такой инструмент отслеживания не просто должен быть внутренним: уменьшите барьеры для ваших клиентов. Это также помогает в управлении ожиданиями.

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

Паскаль.

Answer 5

this link ... И лично, как разработчик, я предпочитаю сосредоточиться на вещах, которые улучшают мою работу. Я не возражаю, проверяя сайт с сообщением об ошибках, чтобы проверить, сообщаются ли новые ошибки, но мне нужно иметь возможность быстро его просматривать, не пропуская несколько десятков страниц или десятки кликов. Я не против писать технические проекты, прежде чем писать код, если у меня есть инструменты для его правильного написания. Эти инструменты должны быть созданы для повышения производительности с минимальными пушистыми функциями, которые никто не использует. Например, в прошлом я использовал Enterprise Architect для создания моделей UML перед написанием кода. Он работал отлично, но приложение имеет некоторые недостатки и множество функций, которые мне не нужны. Когда я обнаружил Altoma UModel, я быстро перешел на более компактный инструмент для создания UML, который предлагал мне именно то, что мне нужно. Ни больше ни меньше. В принципе, вы должны держать людей сосредоточенными на конечной цели. И конечной целью является создание продукта, который будет использоваться вашими пользователями. Многие команды разработчиков теряются, потому что вместо этого они сосредоточены на других вещах. Ни один из ваших пользователей не заботится о том, как вы создали то, что они используют. Им просто нужен ваш проект для достижения своих целей. Таким образом, наилучшей практикой является то, что делает вашу команду максимально комфортной, включая любого нового члена команды, который присоединился бы к середине любого проекта.