소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기 때문에, 문제가 되는 것은 변화가 아니다. 그보다는 변화를 극복하지 못하는 우리의 무능력이 문제다. extreme programming. Kent Beck.

• 짧은 주기로, 작동하는 소프트웨어(MVP,Minimum Viable Product)를 만들어가면서 커뮤니케이션의 비용을 최소화 하고 이슈사항에 바로 대응하며 개발하는 방식이 애자일 소프트웨어 개발방식(↔폭포수 개발방식(water fall))

• 스크럼을 포함한 애자일 방법론들은 애자일 선언문의 중점가치를 계승

스크럼*은 혁신을 창출하는 역동적인 아이디어 싸움에 참여하는 다기능팀을 의미한다. Jeff Sutherland

*스크럼은 럭비에서 경기를 재개하기 위해 팀원이 서로 밀착하여 형성하는 전술 대형을 가리킴

• 5~9명으로 구성되는 소규모의 다기능팀이 제품 개발을 완성하기 위해 스프린트(sprint)라는 업무주기를 반복

• Project Owner가 관리하는 ‘해야할 일들의 목록(Product backlog)’에서 ‘스프린트 동안 해야하는 일들(Sprint backlog)’을 스스로 결정하고 완수하여 매 스프린트마다 결과물(increment)을 산출

• 스크럼마스터(scrum master)는 팀이 성과를 낼 수 있도록 조력하는 역할 수행
  • 팀이 과제를 완수할 수 있도록 필요한 자원을 지원하거나 장애요소를 제거하며 프로세스를 인도

스크럼에서는 30일을 주기로 실제 동작하는 소프트웨어를 만들면서 프로젝트를 진행하며,

팀의 스크럼 적응도 및 진행 상황에 따라 1주~4주의 유연성을 가질 수도 있음

• 솔루션에 포함할 기능 및 개선점에 대한 우선순위를 부여

• 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과 제공(MVP)

• 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공

• 날마다 15분정도 회의를 가짐(daily scrum meeting)

• 항상 팀 단위로 생각

• 원활한 의사소통을 위하여 열린 공간을 유지

• Product Owner
  • 제품 백로그를 관리, 통제할 수 잇는 권한을 가진 사람으로 PO는 단 한명이어야 함
  • 고객 및 조직 가치에 기반하여 제품 백로그 항목들의 우선순위를 결정하고, 매 스프린트의 결과를 검토하여 우선순위를 지속적으로 조정, 관리

• Scrum Master
  • 스크럼의 가치와 실천법에 대한 이해를 바탕으로 현장에 맞는 실천법을 정립하여 실제로 프로젝트에서 실행될 수 있도록 이끔
  • 일일 스크럼회의(daily scrum meeting)를 주관하여 팀의 진척도를 모니터링하고, 팀의 생산성에 악영향을 미치는 정책, 절차, 구조를 공론화하여 처리함
  • 기존의 프로젝트 관리자와는 달리 업무를 지시, 통제하지 않으며, 팀의 성공적인 목표 달성을 돕기 위해 필요한 자원을 지원하거나 장애물을 제거하는 조력자 역할

• Daily Scrum Meeting
  • 매일 어제 한일, 오늘 할일, 해결해야 할 장애/문제 요소를 공유하는 회의(매일 15분 정도)
  • 모든 참여자가 보고가 아닌 수평적으로 공유 차원에서 진행해야 하며 팀원이 아니면 발언권은 없음

• Product Backlog
  • 제품 완성에 필요한 특성, 기능, 개선점 등 제품의 모든 요구사항을 우선순위에 따라 나열한 목록
  • 제품 백로그는 확정, 고정된 것이 아니라 사업 환경이나 변화에 따라 지속적으로 업데이트됨
  • 우선순위가 높은 백로그는 낮은 백로그보다 더 명확하고 상세하게 기술됨

• Sprint Backlog
  • 하나의 스프린트 동안 완료할 과제들의 목록