이 문서는 오디오 버전 다운로드:오디오 버전
스크럼 및 극단적인 프로그래밍(XP)은 확실히 매우 정렬되어 있습니다. 사실,당신이 걸어서서 팀을 하나의 이러한 프로세스할 수 있는 힘든 시간을 신속하게 여부를 결정을 걸었에 스크럼 팀 또는 XP 팀이 있습니다. 차이점은 종종 매우 미묘하지만 중요합니다. 가 있다고 생각하는 네 개의 주요 차이점 스크럼 및 XP:
- Scrum 팀이 일반적으로 반복 작업(라고 스프린트)에서 두 개의 주나 한 달이 깁니다., XP 팀은 일반적으로 1 주 또는 2 주 길이의 반복으로 작업합니다.
- 스크럼 팀은 스프린트의 변경을 허용하지 않습니다. 면 스프린트는 회의 계획을 완료하고 약속을 제공하는 제품의 백로그 항목의 설정 항목을 변경되지 않의 끝을 통해서 스프린트. XP 팀은 반복 내에서 변경하기가 훨씬 더 쉽습니다. 한 팀이 시작되지 않은 작업에서 특정 기능의 새로운 기능에 해당할 수 있는 사이즈로 교체 XP 팀의 반복에 대한 대 unstarted 기능입니다.,
- 익스트림 프로그래밍 팀은 엄격한 우선 순위 순서로 작업합니다. 개발 될 기능은 고객(스크럼의 제품 소유자)이 우선 순위를 정하고 팀은 그 순서대로 작업해야합니다. 반면 스크럼 제품 소유자는 제품 백로그의 우선 순위를 지정하지만 팀은 백로그 항목을 개발할 순서를 결정합니다. 스크럼 팀이 우선 순위가 가장 높은 항목에서 작업하도록 선택하지 않는 것을 본 적이 없습니다. 그리고 스크럼 팀은 두 번째로 중요한 작업을 선택할 가능성이 큽니다., 그러나 어떤 시점에서 하나의 우선 순위가 높은 항목되지 않을 수 있습 잘 맞는 스프린트에 대한 계획되고,어쩌면 사람들에서 작동해야한 것이 정신에 의해 작동에 우선 순위가 높은 항목입니다. 또 어쩌면 그것은 작품에게 낮은 우선순위목(말#10 는 제품에 백로그신#6)기 때문가 팀에서 작업 할 수 있는 코드#10 것을 구현했습니다.
- Scrum 은 엔지니어링 관행을 규정하지 않습니다., I love XP 엔지니어링 방법,특히 같은 것들을 테스트 기반의 개발에 초점을 자동화된 테스트,페어 프로그래밍,심플한 디자인,refactoring 니다. 그러나 내가 생각한 그것의 실수를 팀에게 말”당신은 자기 조직,우리는 당신을 신뢰하지만,당신이해야 하는 이러한 특정 엔지니어링 방법….”이것은 혼란을 야기하는 혼합 된 메시지를 팀에 보냅니다. 나는 XP 관행을 좋아하지만 그들을 의무화하는 것을 좋아하지 않는다. 나는 팀이 스스로 가치를 발견하기를 원한다.
이들은 스크럼과 XP 사이의 작고 종종 미묘한 차이입니다., 그러나 그들은 팀에 지대한 영향을 미칠 수있다. 팀에 대한 나의 전형적인 조언은”스크럼으로 시작한 다음 자신의 XP 버전을 발명하는 것입니다.”XP 관행은 훌륭하지만 가장 잘 작동하며 팀이 위임 된 것보다 스스로 발견하면 가장 눈에 띄게 커밋합니다. 나는 데 도움이 팀을 이렇게 나의 코치에 의해 묻는 질문,”이것이 버그가 일어났다면 우리가 하고 있는 테스트 기반의 개발은 무엇입니까?”그리고”우리가 페어링한다면 그 실수를 저질렀을까요?”나는 거리에서 떨어져 작은 대상이 될 진정한 XP 를 찾을 수 있습니다., 팀이 그 목표를 세우고 황소의 눈을 때릴 수 있다면 훌륭합니다. 그러나 그렇지 않은 경우 해킹 가능성이 있습니다(예:자동화 된 테스트 또는 TDD 없이 리팩토링). 스크럼은 그 자체로 단순히 추가 초점과 타임 박스 반복을 통해 큰 개선을 가져 오는 큰 황소의 눈입니다. 그런 다음 XP 관행을 추가하기위한 좋은 출발점입니다.