프랙티스의 시대(Time for Practices)

프랙티스의 정의
 프랙티스는 문제의 특정한 부분을 해결하는 체계적이고 검증 가능한 방법을 제공한다. 여기서 주목해야 할 사항은 다음과 같다.

-프랙티스는 문제의 모든 부분을 해결하려고 하지 않는다. 오히려 프랙티스는 문제의 특정부분을 다룬다.
-프랙티스는 마술과 같은것이 아니라 명확히 볼 수 있다는 점에서 체계적이다. 분명한 시작과 끝이 있고 완전한 스토리를 가지고 있다.
-프랙티스는 명백한 목적과 함께 목적 달성 정도를 측정할 수 있는 방법을 제공함으로써 자체적인 검증 방식을 포함하고 있다. 검증 없이는 프랙티스가 완전할 수 없다.

이와 같은 특성 때문에 프랙티스는 개별적으로 개발되고 배우며 적용될 수 있다. 또한 이해라기 쉽고 잘 결합된 업무방식을 개발할 수 있도록 다른 프랙티스와 함께 사용될 수 있다.
 요약하면 프랙티스는 문제에 대한 증면된 접근 또는 해결방식인 셈이다. 프랙티스는 전에 누군가에 의해 실행되었고 다른 사람들과 쉽게 의사 소통할 수 있으며 일관된 결과를 산출하는데 반복적으로 쓰일 수 있는 것이다.

프랙티스의 기원
 프랙티스란 개념은 새로운 것이 아니다. 프랙티스는 소프트웨어 개발에 있어 늘 존재해왔고, 많은 소프트웨어 개발회사들은 자신들의 베스트 프랙티스를 선전하고 있다. 하지만 아무도 프랙티스가 정확히 무엇인지 정의하고, 이를 논리적이고 재사용 가능한 방법으로 서술하고 있지는 못한 것 같다. 실제로는 이미 존재하는 프랙티스를 서로 구분할 수 있고 각각이 제공하는 장점이 무엇인지 히애하며 무엇을 언제 어떻게 사용해야 할지 알기만 하면 선택할 수있는 무수한 프랙티스가 존재한다.
 소프트웨어 개발 커뮤니티에서 프랙티스는 프로세스와 비슷하게 다음의 주요 세 진영이 등장한다.

- 소프트웨어 엔지니어링(Unified Process, Booch, OMT, Responsibility-Driven Design, Shlaer/Mellor, User-Centered Design, Open, Feature-Driven Development 등)
-프로세스 보증 : CMMI, SPICE, Six Sigma, TSP/PSP
-애자일 : XP, Scrum, Crystal Clear, Adaptive Software Development, Organizational Patterns of Agile Software Development

 이들 각 진영은 모두 프랙티스와 연관되있다. Scrum은 분리되고 재사용 가능한 형태로 프랙티스를 이미 소개한 좋은 예이다. Scrum의 프랙티스는 반복적 프로젝트를 계획하고 실행하기 위한 관리 프랙티스로 정의된다. 이는 팀이 사용하는 엔지니어링이나 다른 프랙티스와는 완전히 별개다. 이러한 프랙티스 분리나 다른 프랙티스와 혼합해조화시킬 수 있는 점은 Scrum이 널리 쓰이고 유명해진 이유이기도 하다.
 Rational Unified Process에서 반복적 프로젝트 관리를 서술하는 방식과 Scrum의 방식을 비교하여 보자. RUP는 반복적 프로젝트 관리를 RUP라고 하는 큰 프로세스와 강력히 결합되어 분리할 수 없는 부분으로 묘사하고 있으며 Unified Process 생명주기 유즈케이스, 컴포넌트, 아키텍처 기반 없이는 사용하기 어렵게 서술되어 있다. 이는 고객이 다른 프랙티스들을 모두 적용하지 않고 원하는 프랙티스만 적용하는 것을 어렵게 만들고 있다.