Толпа и экстремальное программирование (XP): лучшие практики [закрываются]

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

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

При внедрении Scrum для целей разработки программного обеспечения инженерные практики импортируются из практики гибкой разработки программного обеспечения, чаще всего из XP , Эти практики - это те, которые могут быть приняты способом, не связанным с остальными методами разработки. Чаще всего это: Разработка через тестирование, рефакторинг, парное программирование и пользовательские истории , хотя они ни в коем случае не требуются в Scrum или являются единственным способом решения задач (просто настоятельно рекомендуется) , Agile Modeling - еще один распространенный источник практик гибкой инженерии.

Короче говоря, при смешивании Scrum и XP, что, безусловно, является наиболее распространенным сочетанием, вы используете все артефакты управления Scrum, например

Исследуй и адаптируй
Нет серебряной пули

Не существует волшебной сыворотки, чтобы сделать команды успешными только потому, что они используют Scrum / XP / Agile et.all; Найдите свои узкие места и устраняйте их по одному

Обновление : Некоторые считают, что мой ответ недостаточно полезен. Я утверждаю, что «шрамы от гибкости» оставили меня таким образом - (Наденьте мою полезную шляпу) Может, вам стоит прочитать Scrum и XP из окопов

Прагматичный программист (как упомянул Джим Ферранс) и Чистый код отличные ресурсы для гибкого программиста. Вы также можете взглянуть на книги из серии экстремального программирования.

Scrum ничего не говорит о программировании.

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

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

Наряду с другими упомянутыми здесь книгами, Art of Agile Development Джеймса Шора и Шейна Уордена - лучшая книга по гибкой разработке программного обеспечения.

[править] Некоторые ссылки на источники, упомянутые здесь другими людьми:

Непрерывная интеграция

Рефакторинг

Scrum и XP из окопов Хенрик Книберг (отличная презентация на infoq.com )

Практики Scrum подходят для сотрудничества и определения приоритетов с владельцем продукта. Однако сам по себе Scrum не может обеспечить устойчивый темп для команды разработчиков.

Основное внимание XP уделяется инженерным практикам. Такие практики, как разработка через тестирование (TDD), общая база кода, простой и эволюционный дизайн, парное программирование, автоматическое тестирование, непрерывная интеграция, технический долг и т. Д.

Из всех инженерных практик TDD труднее всего изучить, и в целом инженерные практики требуют более высокого обучения, чем методы управления (Scrum). Однако без инженерной практики код дойдет до такой степени, что вы не сможете поддерживать скорость. Причина в том, что код будет все больше и больше тестироваться и станет хрупким для изменения.

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

Скрам и XP - отличное совпадение. Некоторые исследования показывают, что сочетание Scrum и XP приводит к созданию наиболее эффективных гибких команд. Учитывая, что каждый фокус индивидуален, но дополняет друг друга, вам будет разумно использовать как Scrum, так и XP в любой из ваших Agile-команд.

Некоторые исследования показывают, что сочетание Scrum и XP приводит к созданию наиболее эффективных гибких команд. Учитывая, что каждый фокус индивидуален, но дополняет друг друга, вам будет разумно использовать как Scrum, так и XP в любой из ваших Agile-команд.

Некоторые исследования показывают, что сочетание Scrum и XP приводит к созданию наиболее эффективных гибких команд. Учитывая, что каждый фокус индивидуален, но дополняет друг друга, вам будет разумно использовать как Scrum, так и XP в любой из ваших Agile-команд.

Вы пишете плохой код, потому что:

1. Ваша команда не знает, как это сделать.
2. Никто из уполномоченных не проверяет, утверждает, требует хорошего кода.
3. Вам не дано достаточно времени?
4. Слишком много полагаться на плохой устаревший код.
5. Не предоставлять подходящие инструменты (контроль исходного кода, среда разработки, средства связи и т. д.)

Я не уверен, что что-то из этого имеет отношение к Agile / Scrum.

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

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

Кстати, одна вещь, которую я ненавижу в SCRUM, - это ежедневные стендап-встречи. Yarrr.

Scrum - это гибкий процесс управления проектами, поэтому он не влияет на качество кода, за исключением того, что он сосредоточен на том, чтобы всегда иметь потенциальную поставляемую систему в конце каждого 2- 4 неделя «спринта». Делая спринты короткими и получая ежедневную обратную связь, менеджер проекта гораздо лучше понимает, сколько усилий требуется для внедрения новых функций, а команда получает хорошее представление об относительной важности каждой новой функции.

Вам все еще предстоит тяжелая работа по программированию. Есть много замечательных книг по этому поводу (например, McConnell Code Complete и Hunt and Thomas The Pragmatic Programmer ), и вам следует внимательно изучить их и применить в своей работе.

В дополнение к agile / scrum, я рекомендую следующее (некоторые идеи должны быть реализованы руководством ... так что удачи):

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

Криш, каково ваше положение? менеджер команды? Я обнаружил, что лучшее, что может сделать руководитель Scrum-команды, - это поставить проблему перед командой и позволить команде предложить решение. Например, в конце спринта мы всегда отставали от цели. Итак, в одном посте-обзоре спринта я поставил вопрос: «Назовите мне количество часов, которое представляет возможности нашей команды для спринта». Было три результата:

• мы никогда не были ближе к нашей отметке
• число было выше моей оценки: -))
• все члены команды приложили дополнительные усилия

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

Надеюсь, это поможет, не стесняйтесь спрашивать больше

Матей

Что значит «хорошо» код'? Почему важен хороший код? Вы говорите о ремонтопригодности - нужен ли для этого хороший код или хорошая документация? Вы говорите о надежности - нужен ли для этого хороший код или хорошие тесты и документированные требования? И т. Д.

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

Взгляните на эту матрицу передового опыта, сравнивающую SCRUM и XP, созданную Джеймсом Шором. Кстати, я нашел его книгу весьма полезной, если вы хотите понять XP. Есть также несколько статей , которые могут дать вам представление о некоторых из этих практик.