Мы следим за Scrum за разработку программного обеспечения в нашей организации. Хотя у нас есть справедливый опыт работы с Scrum, мы перестаем выпускать хороший исходный код в конце дня. Люди говорят о объединении экстремального программирования (XP) с Scrum для получения прогнозируемых результатов.
Я просмотрел материалы Extreme Programming, но не смог получить хорошую картину.
Как Scrum и Extreme Programming используются в разработке программного обеспечения?
Scrum - это гибкая методология управления проектами. В нем не рассматриваются методы, необходимые для создания "товаров" любого рода, но вместо этого дает нам процесс, который приведет нас с самого начала к видению конечного продукта независимо от фактического процесса разработки. Процесс Scrum не говорит вам о том, как создать качество. Он показывает вам, каково качество, где ваши проблемы, и бросает вызов вам исправить их.
Экстремальное программирование - это гибкая методология разработки программного обеспечения. Это дает нам процесс создания программного обеспечения гибким и продуктивным способом. Он занимается, хотя и не специализируется на управлении процессом разработки, и в основном фокусируется на инженерных практиках, необходимых для доставки программного обеспечения с качеством.
При принятии Scrum для целей разработки программного обеспечения, инженерные практики импортируются из гибкой практики разработки программного обеспечения, чаще всего из XP. Эта практика - это те, которые могут быть приняты таким образом, который будет отделен от остальной практики развития. Чаще всего эти методы: Разработка, рефакторинг и парное программирование с использованием тестов, а также истории пользователей, хотя это никоим образом не требуется в Scrum или единственный способ сделать что-то (просто настоятельно рекомендуется). Agile Modeling - еще один распространенный источник гибких инженерных практик.
Итак, при смешивании Scrum и XP, который, безусловно, является наиболее распространенным микс, вы используете все артефакты управления Scrum, например. Спринты, ежедневные Scrums, ретроспективы, диаграммы сжигания и т.д. И добавление XP TDD, рефакторинг, парное программирование и JIT-дизайн через User Stories.
Конечно, Scrum является Scrum, так вы начинаете, и вы постоянно адаптируете (рефакторинг, если хотите) процесс, чтобы отвечать на ваши конкретные потребности в организации.
Осмотреть и адаптировать.
Серебряная пуля
Нет никакой магической сыворотки, чтобы сделать команды успешными только потому, что они используют Scrum/XP/Agile et.all; Найдите свои узкие места и устраните их по очереди.
Обновление. Некоторые считают, что мой ответ недостаточно полезен. Я утверждаю, что "проворные шрамы" оставили меня таким образом (наденьте мою полезную шляпу) Возможно, вам стоит прочитать Scrum и XP из траншей
Scrum нечего сказать о программировании.
По моему мнению, вы не можете быть "гибкими" без практики разработки программного обеспечения, которые позволят вам на техническом уровне быстро реагировать на изменения: инкрементный дизайн, модульное и приемочное тестирование, рефакторинг, непрерывная интеграция, совместное использование кода.
Это больше всего, что нужно, например, высокий уровень участия ваших клиентов и эффективное общение внутри команды и вне ее.
Наряду с другими книгами, упомянутыми здесь, Искусство гибкого развития Джеймса Шор и Шейн Уорден - лучшая книга по гибкой разработке программного обеспечения есть.
[править] Некоторые ссылки на источники, упомянутые здесь другими людьми:
Scrum и XP из траншей от Henrik Kniberg (отличная презентация на infoq.com)
Как прагматический программист (как упоминал Джим Ферранс), так и Clean Code - отличные ресурсы для гибкого программиста. Вы также можете взглянуть на книги в экстремальной серии программ.
Практики Scrum подходят для сотрудничества и установления приоритетов с владельцем продукта. Однако сам по себе Scrum не будет поддерживать устойчивые темпы команды разработчиков.
Основное внимание в XP уделяется инженерным практикам. Такие практики, как разработка, основанная на тестах (TDD), общая база кода, простой и эволюционный дизайн, парное программирование, автоматическое тестирование, непрерывная интеграция, технический долг и т.д.
Из всех технических практик TDD труднее всего изучать, и в целом инженерные практики имеют более высокую кривую обучения, чем методы управления (Scrum). Тем не менее, без инженерных практик код будет доходить до такой степени, что вы не сможете поддерживать скорость. Причина в том, что код будет дольше и дольше тестироваться и стать хрупким для изменения.
Если вы собираетесь заниматься инженерными практиками, лучше всего включить в команду технического или инженерного тренера. Тренер обеспечит интро-обучение для каждой практики, а через пару быстро распространит практику через команду.
Scrum и XP - отличное совпадение. Некоторые исследования показывают, что объединение Scrum и XP приводит к наиболее эффективным гибким командам. Учитывая, что каждый фокус отличается, но дополняет друг друга, вам будет разумно использовать Scrum и XP для любой из ваших гибких команд.
Scrum - это Agile-процесс для управления проектами, и поэтому он не влияет на качество кода, отличное от его жесткой направленности на всегда наличие потенциальной поставляемой системы в конце каждого двухнедельного "спринта". Сохраняя короткие спринты и получая ежедневную обратную связь, руководитель проекта получает гораздо лучшее представление о том, сколько усилий предпринимают новые функции для реализации, и команда хорошо разбирается в относительной важности каждой новой функции.
Вам все еще нужно усердно работать над программированием. На это много замечательных книг (таких как McConnell Code Complete, а Hunt и Thomas Прагматический программист), и вы должны внимательно изучить их и применить их к своей работе.
Вы пишете плохой код, потому что:
Я не уверен, что любой из них связан с Agile/Scrum.
Каждый отдельный разработчик, его стиль, умения и желание всегда впитываться в новую информацию имеют как отношение к качеству кода, так и успех конечного продукта в качестве процесса разработки.
Если у вас нет нужных людей, техника PM не поможет вам. Сначала найдите нужных людей, людей, которые могут производить хороший код отдельно, и только потом беспокоятся о их объединении в команде. Один человек может подорвать все усилия команды.
На стороне примечания, одна вещь, которую я ненавижу о SCRUM, является ежедневной встречной встречей. Yarrr.
Криш, Какова ваша позиция? менеджер команды? Я обнаружил, что лучшее, что нужно сделать, как лидер команды Scrum, - поставить проблему перед командой и позволить команде придумать решение. Например, мы всегда были вне цели в конце спринта. Итак, в одном обзоре спринта, я поставил вопрос "дайте мне количество часов, которые представляют возможности нашей команды для спринта". Было три результата:
Мы используем программные средства (OnTime в нашем случае) для отслеживания всех важных мер и обсуждения нашей статистики после каждого спринта. Кроме того, у нас есть практика изменения по крайней мере одной вещи в каждом спринте.
Надеюсь, что это поможет, пожалуйста, не стесняйтесь спрашивать больше
Матей
Взгляните на эту матрицу, в которой сравниваются SCRUM и XP, сделанные Джеймсом Шор. Кстати, я нашел его book весьма полезным, если вы хотите понять XP. Есть также некоторые статьи, которые могут дать вам представление о некоторых трюковых практиках.
Методика SCRUM очень популярна. Лучший способ для компании-производителя программного обеспечения использовать SCRUM может состоять в том, чтобы выполнить SWOT-анализ на индивидуальном уровне для каждого из программистов. Соедините программистов с использованием XP в определенной части процесса разработки проекта. Затем, выходя из SWOT-анализа, используйте Sashimi или другой жизненный цикл проекта, основанный на нестандартных SWOT. Хотя это похоже на большой беспорядок дерьма в проекте, нет никакой "серебряной пули" для идеальной методологии или жизненного цикла для команды. Менеджер проекта должен понимать и назначать роль каждого члена, исходя из того, где он или она чувствует, что они будут более продуктивными в проекте. просто мои 2 цента.
В дополнение к agile/scrum, я рекомендую следующее (некоторые идеи должны быть реализованы руководством... так что удачи):
Что значит "хороший код"? Почему хороший код важен? Вы говорите об ремонтопригодности - для этого нужен хороший код или хорошая документация? Вы говорите о надежности - для этого нужен хороший код или хорошие тесты и документированные требования? Etc
Используйте здравый смысл, устанавливайте рациональные системы критериев и оценок, старайтесь игнорировать необоснованные утверждения о успехе, приписываемые какой-либо технике или инструменту.