Как получить личную практику в методологии разработки в супертяжелом весе?

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

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

Кроме того, просто на работе в течение некоторого количества месяцев / лет.

С помощью простого языка или нового API можно взломать игрушечную тестовую программу, прочитать, умышленно сделать ошибки, чтобы увидеть, что происходит, и т. Д. Подобно тому, как стать хорошим велосипедистом или играть на музыкальном инструменте, практика необходима. Легко взять флейту и тратить полчаса каждый день; Нет необходимости присоединяться к оркестру или быть постоянным консультантом по флейте. Но как практиковать действия по разработке программного обеспечения, которые являются большими, сложными, с участием команд, и большая часть которых заключается в общении и планировании, во избежание недоразумений и превышении графиков и бюджетных ограничений?

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

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

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

Во время первой части нам было рекомендовано разделить 16 человек на группы по четыре человека. Каждой команде из четырех человек приходилось вырабатывать предложения по структуре команды (в условиях нехватки времени), после чего применялся процесс перестрелки, чтобы принять решение, какая структура команды может быть наилучшей и должна использоваться для второй части семинара. ,

К сожалению, в первой части мы допустили ошибку, пытаясь дать каждому из 16 человек работу в рамках предполагаемой структуры команды. Эта ошибка привела к хаосу во втором тайме - потому что 16 человек слишком много, чтобы решить такую ​​задачу. Рабочим решением, возможно, было бы снова разделить 16 человек на более мелкие команды или выбрать 3 или 4 человека для основной работы, но в самый разгар мы упустили возможность увидеть это.

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

Начните с контрольного списка . (Вы знали, что это был первый шаг, верно?)
Убедитесь, что в контрольном списке перечислены все стандартные документы для вашего текущего проекта. то есть. Диаграмма UML, функциональная спецификация, высокоуровневые и низкоуровневые конструкции и т. Д. Разработчик системы во мне предложит использовать RTVM (матрица проверки прослеживаемости требований)

Выберите пример программы для работы. Если вы не можете придумать его, поищите в Google «code katas» или ознакомьтесь с архивом проблем Google Codejam. Или просто построить калькулятор. :-)

Создайте функциональную спецификацию для вашей программы-примера. Затем перейдите к высокоуровневому дизайну, UML-диаграмме и т. Д. Постройте его по спецификации. Попробуй это. Каждый раз, когда вы обнаруживаете существенный недостаток в вашей спецификации (как определено вашими текущими рабочими практиками), вам необходимо вернуться к этой стадии SDLC и пересмотреть, прежде чем двигаться дальше.

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

После того, как вы несколько раз прошли цикл проектирования / сборки / тестирования / повторения, вы приобретете навыки и опыт работы с «тяжеловесными» компонентами, которые вас сейчас беспокоят. Итерации также покажут вам взаимосвязь между различными этапами и сгенерированной документацией. Ценный урок показывает, как 5-минутное изменение кода может иметь многочасовой эффект пульсации в других местах из-за обновлений документов и требований к тестированию.

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

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

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