빙 둘러 말하기로 프로젝트 위키에다가 써 보았다.
물론 프로젝트 위키에다가 썼으므로 팀원만 보겠지 ㅎㅎ…

---

스크럼 이걸 왜 하나요?

원활한 개발을 방해하는 요소들은 셀 수 없이 많습니다. 하지만, 그런 방해 요소들을 적극적으로 해결하고자 하는 노력은 그에 비해 턱없이 부족합니다. 늦어지는 기획, 너무 잦은 회의, 본부장의 잦은 간섭, 협업 요청에 대한 동료의 무응답, 작업을 더디게하는 수많은 요소들은 오늘도 우리 주위에 산재해 있습니다. 하지만, 이런 것들에 문제를 제기하면 왠지 분위기가 어색해질 것 같고 눈치가 보여서 포기하고 맙니다. 결국 시간이 갈수록 즐겁게 개발 할 수 있는 환경은 사라져갑니다. 스크럼은 목표를 달성하는데 방해가 되는 요소들을 그 즉시 해결해야 한다고 이야기합니다.

• http://resoneit.blogspot.kr/2012/10/blog-post_30.html
• 현재 상황에서 우리 mcc-backoffice 개발팀은 온전한 프로젝트 매니징을 기대할 수 없는 상황 (내가 대충 땜빵하고 있지만.. @yh.jang )
• 또한 언제나 그렇듯이 깊은 이해가 없는 방법론 도입은 그다지 효과가 없다.
• 따라서 앞서 인용한 개발저해요소 를 제거하는 데 촛점을 맞추고 나머지를 천천히 도입해야 할 것.
  • 프로젝트 팀이 아닌이상 프로젝트에 관여할 수 없어야 한다.
    • 누구라도 프로젝트에 관여하려면, 팀의 일원이 되어야 한다.
    • 팀의 일원이 되었으면, 협업 방법을 익히고 커뮤니케이션 하라.
    • 협업 방법을 익혔으면, 자신이 하는 일을 기록하고 그 일을 책임져라.
  • 프로젝트 리더가 프로젝트 팀을 구성한다.
    • 생각보다 협업은 어렵고 팀은 성장할 시간이 필요하다.
    • 모든 프로젝트는 팀의 성장도에 따라 다른 퍼포먼스를 보일 것이다.
  • 스프린트가 끝나기 전에 제품 사양이 변경되는 경우가 없어야 한다.
    • 제품이 나오기 전에, 제품의 유효성은 알 수 없다.
    • 프로젝트 팀은 매 스프린트 마다 피드백 가능한 작동하는 프로토타입을 만드는것을 목표로 한다.
    • 제품 사양 변경은 프로토타입을 검토하고 나서 해도 절대 늦지 않다.
  • 프로젝트의 모든 부분이 테스트 가능한 상태를 유지해야 한다
    • 급격한 사양변경 혹은 제품 기반이 변경되었을때 이를 견디게 해주는 필수요소다.
    • 급격한 변경에도 견딜수 있으므로 파괴적인 구조개선을 통해 단순하고 견고한 체제를 구축하는것이 가능.