2015-03-31 11 views
-2

Моя компания настаивает на том, чтобы внедрить SCRUM в качестве процесса разработки для поддержки и расширения нашей базы кода.SCRUM и устаревший/высокосвязный код

Наша база кода недокументирована, написана множеством технологий и высокосвязанных (глобальные переменные везде, процедурный javascript php-код с около 800 хранимых процедур Oracle PL-SQL на бэкэнд, без объектов, скрытых допущений и т. Д.). Разумеется, нет единичных тестов.

Кроме того, команда разработчиков отличается небольшим опытом в существующем коде и, безусловно, не является кросс-функциональной, поскольку каждый из них обладает конкретными знаниями о технологии (например, javascript, но не PL-SQL).

Когда мы впервые попытались ввести Scrum пару месяцев назад мы с треском провалились, так как

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

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

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

+0

Как используется SCRUM, особенно проблема с устаревшими кодами? Как проблема связана с выбранной философией управления проектами? – Matthew

+0

Мое понимание SCRUM потребует, чтобы в конце спринта были протестированы реализации пользовательских историй. Учитывая, что база кода в ее нынешнем виде не поддерживает модульное тестирование (именно поэтому я назвал его устаревшим кодом), вопрос в том, можем ли мы принять SCRUM. Мы должны либо потратить слишком много времени на реорганизацию кода для модульного тестирования, либо предоставить историю пользователей, которая не тестируется на устройство. – user2465039

+1

Существуют другие типы тестирования, которые можно выполнить в системе, которая нелегка для модульного тестирования. Существует множество инфраструктур интеграционного тестирования. Майкл Перс «Эффективно работает с устаревшим кодом» может быть хорошей книгой для чтения. – Matthew

ответ

1

Scrum - это основа разработки продукта/методология. На самом деле не имеет значения, хорош или плохой код. Или даже если есть код в этом отношении. Вы можете использовать методологию scrum для написания книги (this book был фактически выполнен с использованием scrum).

Причина, по которой вы потерпели неудачу в последний раз, заключалась в том, что схватка не была выполнена должным образом. Обычно при внедрении схватки он не реализуется на 100% в книге.

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

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

Для успешной реализации вашей компании необходимо отправить хотя бы одного человека на сертифицированный курс ScrumMaster® или нанять Scrum Coach.

Если выполнено правильно, однако схватка может потенциально улучшить качество вашей продукции. Scrum - это современная разработка продукта (особенно разработка программного обеспечения). Нет никакой гарантии, что схватка исправит ваши проблемы, но есть причина, по которой majority of organisations использует схватку для разработки программного обеспечения.

0

Сертификаты показывают, что вы следили за ходом, не то, что вы хорошо, что вы делаете смешно :)
Ваш Scrum решение:
Шаг 1. Создание многофункциональных команд, каждая команда с таким разнообразные блюда. Ввести «парное программирование», чтобы люди учились друг у друга ...
Шаг 2. Рассмотрите свою «базу кода» как один новый проект MEGA! Ваша команда Scrum/s начинает разбираться с ней в модулях: один фрагмент в то время.
Шаг 3. Организуйте каждый модуль, чтобы он содержал одно приложение из вашей «базы кода» и имел дело с ним: начальная оценка, планирование спринта, отставание продукта и т. Д. - Scrum!
Ваш XP Решение:
Шаг 1. Принесите тренера XP, чтобы ПОЕЗДАТЬ своих людей! Через пару дней интенсивного обучения вы сможете начать с него (с тренером RIGHT). У вас будут кросс-функциональные команды, парное программирование, непрерывная итерация и т. Д.
Шаг 2. Рассмотрите свою «базу кода» как один новый проект MEGA! Ваша команда XP начинает разбираться с ней в модулях: один фрагмент в то время. (Проворный, я тебя люблю!)
Шаг 3. Держите тренера в течение первых трех месяцев ... Он вам понадобится!
Наслаждайтесь!

+0

Я очень ценю ответ. Однако я думаю, что вы снова применяете мои первоначальные мысли. В частности, я считаю, что SCRUM нельзя применять, потому что: Шаг 1 не может быть выполнен (команда не является многофункциональной, как я уже сказал), шаг 3 не может быть выполнен (высокосвязный код не позволяет организовывать модули a, содержащие одно приложение из нашего код-основание). Я что-то упускаю? – user2465039

+0

Не зная самых интимных деталей вашей рабочей среды и вашего проекта, я не могу сказать, может ли какой-либо из Scrum или XP или RUP или DSDM или любой другой метод Agile или Waterfall быть успешным в вашей ситуации. Я говорю, что шаги, приведенные в моем ответе, являются логическими шагами в среде AGILE! Если вы (как компания или техническая команда) не хотите, или вы не можете принять их, это просто то, что у вас есть в руках. –

+0

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