Scrum for Team System와 Microsoft내의 Scrum사용

https://www.scrumforteamsystem.com/en/default.aspx

Scrum for Team System이라는 Visual Studio Team System의 플러그인을 Conchango라는 SI 회사에서 공개했습니다. VSTS의 좋은 점 중 하나는 이전의 Rational 제품처럼 RUP로만 모든 것을 권장하는 것이 아니라 다른 방법론의 Guidance를 패키지로 제공할 수 있다는 것이겠습니다. 물론 기본적으로도 Agile과 CMMI라는 이름의 Guidance를 제공합니다.

Scrum은 Agile Manifesto에 참여한 방법론 중 하나로 Sprint라는 짧은 주기의 기간을 두어서 지속적으로 팀 내외부 커뮤니케이션을 통해서 변화를 반영합니다. 매일 혹은 며칠 단위로 정해진 작은 시간동안 회의를 통해서 어떤 변화가 있어야 하며, 어떤 변화가 있는가를 추적해서 반영을 하고 기록을 합니다. 요즘에는 마이크로소프트 내에서도  새로운 프로젝트에 이런 Sprint를 두어서 Backlog를 작성하는 사례를 종종 보게 됩니다. 이런 변화는 물론 현재는 전사적인 것이라기 보다는 각기 다른 프로젝트/프로덕트 팀들이 자신들의 일의 능률을 위해서 적용하는 것입니다.

재미난 사실은 이 Scrum은 한 예라는 것입니다. Scrum 뿐만아니라 TDD/XP/Agile관련 방식들이 어떤 배경의 어떤 사람이 프로젝트에 관여했고, 누구한테 영향을 받느냐에 따라 여러가지가 도입됩니다. 기존의 방법 뿐만 아니라 새로 고안된 방법들도 마찬가지입니다. 정당성만 정확히 하면, 아무도 이를 막지 않습니다. 게다가, 성공적이면 사례가 되어 비즈니스 유닛 단위로 확대가 될 수도 있습니다.

또 한가지 예를 들면, 회사에서 개발한 Team Foundation Server가 있습니다. 회사에서 개발했지만, 기존에 사용하던 제품이 있기 때문에 사용을 독려는 하더라도 사용할 의사가 없는 제품유닛들은 자신들의 판단대로 진행합니다. "제품의 사용으로 성공사례가 되겠다."부터 "우리는 전환할 예산이 부족하다."등등 다양한 이유가 있겠죠.

이 예들이 한 제품유닛으로 구성된 제품이라면 이런 내용이 별로 의미가 없고 당연하다고 생각할지도 모르겠습니다만, 이는 한 제품의 수십개의 다른 팀들이 각기 다른 것을 사용할 수도 있다는 이야기입니다. 온라인 회사에서 팀별로 다른 툴이나 언어를 사용한다는 것과는 상이한 이야기입니다. 개인적으로 처음에는 생소하고 신기했던 기억이 괜히 생각나서 끄적여봅니다.