Younghoe.Info (final edition)

다음은 Ron Jeffries가 권하는 스크럼(Scrum) 계획 절차다.

1. Product owner writes story on whiteboard, and explains it.
2. Briefly discuss how the story will be tested.
3. Developers briefly brainstorm and list technical steps needed.
   (Similar to tasks but we’re not going to do the work, nor track it that way.)
4. Repeat until enough stories are on the board.
5. Look at the list, draw the line where you’re confident you can accomplish everything above the line.
6. Commit
7. Do stories as a unit, not broken into tasks.
8. Burn stories, not tasks.

꼭 스크럼을 쓰지 않더라도 반복(Iteration)과 같은 짧은 주기의 작업 계획에 적용할 수 있다. Product owner의 요구 사항 설명으로 시작한다. 2번 항목은 매우 중요하다. 무엇을 기준으로 요구 사항 충족을 판단할까? 그러나 현장에서 보면 고객이 요구 사항을 명확하게 정의할 수 없는 경우가 부지기수이다. 화면이 있는 시스템에 대한 요구 사항이 아니라 다음과 같은 상황이라면 더욱 그러하다.

• 한 번도 써 본 일이 없는 새로운 시스템 구현
• 프레임워크나 라이브러리 구현
• C/S 기반의 시스템만 쓰던 사용자가 웹 기반 시스템 요건을 정의할 때

설령, 요구 사항을 정의했다고 하더라도 검증 기준 혹은 테스트^[각주:1] 기준을 수립하는 일은 더욱 어려울 수 있다. 그런 상황이라면 owner가 누구인지 분명히 밝혀 고객이 주인의식은 잃지 않게 한다. 주인의식이 애초부터 없거나 자라나지 않는 경우라면 매우 위험하다. 종종 일시적으로 구성한 TFT가 고객을 대변하는 곳이 있다. 특히, TFT가 시스템 최종 사용자와 관계가 전혀 없는 경우라면 지속하는 주인의식을 기대하긴 어렵다. Ron Jeffries도 스크럼 성공의 장벽으로 해당 내용을 지적한 바 있다..

한편, 7번 역시 매우 중요한 내용이다. 문맥이 내포한 의미를 Chris Sims가 풀어 설명하는 글이 있다. 유사한 사례를 경험한 바 있으니 바로 그 기억이 찾아온다. 스크럼을 처음 적용할 때 기존 관행에 젖어서 요구 사항^[각주:2]을 개별 작업자가 공수 산정이 가능하게끔 잘게 쪼개서 계획을 세운 바 있다. 이런 방식은 애자일의 기본적인 접근 방식에 반하는 Big-Bang 스타일이다. 애자일 기반으로 작업 관리를 할 때, 기존 유산과 어떻게 조화를 이룰지 고민해야 한다. 여기서 말하는 유산의 예로는 WBS, 조직의 진척 산정 방식, 기존에 만들어 놓은 PMS의 입력 방식, 그리고 나를 포함한 팀원의 사고방식 등이 있다.