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

Question

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

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

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

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

Итак, мой вопрос: какие методы разработки вы пробовали и нашли полезными / бесполезными?

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

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

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

Answer 1

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

Answer 2

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

Answer 3

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

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

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

Паскаль.

Answer 4

Как руководство для нашей команды: SCRUM

Answer 5

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