brunch

매거진 애쉬의 서재

라이킷 19 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by ASH Oct 26. 2022

좋은 프로덕트 팀은 단순하게 일하는 데 집중합니다

사용자 스토리에서 뽑은 226개의 핵심 파트 (2)

이번 사용자 스토리 후반부는 유저 스토리를 사용할 때의 주의점과 익스트림 프로그래밍(이하 XP) 위주의 내용으로 구성되어 있다. 책에서도 말하듯 '유저 스토리 (혹은 사용자 스토리)'는 완벽한 업무 방식이 아니다. 때로는 조직과 구성원의 상황에 따라 전통적인 워터폴 방식과 PRD가 더 유용할 수도 있다. 중요한 것은 애자일이냐 워터폴이냐가 아니라, 우리 조직에 가장 잘 맞는 업무 방식이 무엇인지를 찾는 것이다.

조직에서 애자일과 유저 스토리 업무 방식을 채택하기로 결정했다면, 어떻게 이 방식을 조직에 뿌리내리게 하고, 어떻게 더 효율적으로 운영할 것인지를 고민해야 한다. 더 작은 단위에서는 어떻게 더 좋은 유저 스토리를 쓰고 전달할까 하는 고민도 필요하다. 애자일과 유저 스토리 기반으로 업무를 하는 조직의 구성원들이 이 책을 통해서 더 좋은 유저 스토리를 쓰고, 고객에게 더 좋은 가치를 주는 제품을 만들어 내길 바란다.

사용자 스토리 - 교보문고

애자일(Agile) 프로그램의 활용법과 사용자가 필요한 소프트웨어 개발에 대한 내용을 담고 있는『사용자 스토리』. 이 책은 사용자 스토리를 수집하는 현실적인 방법과 상황에 따른 대처 방법,

www.kyobobook.co.kr

자주 논의하는 주제

스토리가 아닌 것

1. 스토리가 무엇인지 더 잘 이해하려면 스토리가 아닌 것에는 무엇이 있는지 살펴보는 것이 중요하다.

사용자 스토리는 IEEE 830이 아니다

2. 시스템의 요구사항을 IEEE 830 수준으로 자세하게 문서화하다 보면 장황해지기 쉽고 실수하기도 쉬우며 시간도 많이 든다. 또한 이러한 수준으로 작성된 문서는 그 문서를 읽는 사람이 큰 그림을 보지 못하게 만드는 경우가 많다.

3. 사용자의 목적이 그대로 사용자 스토리가 되는 것은 아니지만, IEEE 830 문서는 요구사항들을 나열한 것인 반면 사용자 스토리는 사용자의 목적을 기술한다. 새로운 산출물로부터 얻고자 하는 사용자의 목적에 초점을 맞춤으로써 사용자의 필요를 더 잘 만족시키는 솔루션을 얻을 수 있다.

4. 사용자 스토리를 이용하면 초기부터 각 스토리의 개발 기간을 추정하게 된다. 고객은 프로젝트 팀의 속도와 개별 스토리의 개발 비용을 알 수 있다. 또한 모든 이터레이션에 할당할 만큼의 스토리들을 작성하고 나면 더 이상 스토리를 추가할 수 없음을 알 수 있다.

사용자 스토리는 유스케이스가 아니다

5. 유스케이스는 시스템과 하나 이상의 행위자(actor) 사이의 상호작용을 기술한다. 여기서 행위자는 사용자나 다른 시스템을 말한다.

6. 주 성공 시나리오(main success scenario)는 유스케이스에서 성공적인 실행 경로에 대해 기술한다. 확장(extensions) 부분은 유스케이스에서 성공적인 실행 경로 이외의 다른 경로들을 정의한다. 확장 부분은 주로 에러 처리에 사용되지만, 성공적인 실행 경로지만 다소 부차적인 의미를 가지는 경로를 기술하는 데에도 사용된다.

7. 사용자 스토리와 유스케이스 간의 명백한 차이점 중 하나는 다루는 범위(scope)가 다르다는 점이다. 둘 다 비즈니스 가치를 기술하는 데 적합한 크기지만 사용자 스토리는 제약 조건을 두어, 일정 계획에 사용하기 편리하도록 작은 범위를 다룬다. 유스케이스는 대부분 사용자 스토리보다 훨씬 큰 범위를 포함한다.

8. 사용자 스토리와 유스케이스는 그 완결성에도 차이가 있다. 제임스 그레닝은 “스토리 카드에 인수 테스트를 더하면 기본적으로 유스케이스와 동일하다"라고 언급한 바 있다. 그는 사용자 스토리가 유스케이스의 주 성공 시나리오에 대응되고, 그 사용자 스토리에 대한 테스트들이 유스케이스의 확장 부분에 해당한다고 말한다.

9. 유스케이스와 사용자 스토리의 또 다른 중요한 차이점은 그 수명(longevity)에 있다. 유스케이스는 개발 기간이나 유지보수 기간에 계속 사용된다. 반면 사용자 스토리는 그것을 개발한 이터레이션이 지나서까지 계속 사용하도록 만들어진 것이 아니다.

10. 또 다른 차이점으로, 유스케이스는 그렇게 하지 말 것을 권장함에도 불구하고 사용자 인터페이스에 관한 세부사항을 포함하는 경우가 많다는 점이다. 이렇게 되는 데는 몇 가지 이유가 있다. 첫째, 유스케이스는 보통 분량이 많으며, 별도로 사용자 인터페이스 요구사항을 집어넣을 적절한 곳이 없어서 그것이 유스케이스에 포함되어 버리기 때문이다. 둘째, 유스케이스를 작성하는 사람들이 사업 상의 목적보다는 소프트웨어 구현 사항에 너무 일찍부터 초점을 두기 때문이다.

11. 보통 프로젝트 초기에는 어떤 가정에 기반하여 사용자 인터페이스를 설계하면 안 된다. 초기부터 사용자 인터페이스에 관한 세부사항을 포함시키면 분명 문제가 발생한다. 사용자 스토리를 사용하면, 사용자 인터페이스는 고객과 대화하면서 다루게 된다.

12. 핵심 유스케이스는 기술적인 내용 혹은 구현 사항에 대한 가정을 제거한 유스케이스다. 핵심 유스케이스와 관련해 흥미로운 점은 사용자의 의도가 곧장 사용자 스토리로 해석된다는 것이다.

13. 유스케이스와 사용자 스토리의 또 다른 차이점은 작성 목적(purpose)이 다르다는 점이다. 유스케이스는 고객과 개발자가 모두 읽고 이해할 수 있는 형식으로 작성된다. 그 목적은 고객과 개발 팀 간의 합의를 문서화하는 데 있다. 반면에 사용자 스토리는 릴리즈나 이터레이션의 계획을 세우는 데 도움을 주기 위해 작성되고, 사용자의 상세한 요구들에 관해 대화를 나누기 위한 매개체로서 사용된다.

14. 유스케이스는 일반적으로 분석 작업의 결과물로 작성되지만 사용자 스토리는 분석 작업에 이용할 수 있도록 메모 형태로 작성된다.

사용자 스토리는 시나리오가 아니다

15. 상호작용 설계에서의 시나리오와 유스케이스에서의 시나리오는 다르다. 사실 일반적으로 상호작용 설계 시나리오가 더 광범위하고 포괄적인 내용을 담는다.

16. 캐롤은 시나리오가 다음 요소들을 포함한다고 말했다.

• 설정(settings)

• 행위자(actors)

• 목표(goals) 혹은 목적(objectives)

• 행위(actions) 및 사건(events)

17. 설정은 스토리가 발생하는 곳이다. 각 시나리오는 한 명 이상의 행위자를 포함한다. 시나리오는 여러 행위자를 가질 수 있다. 유스케이스에서 시스템이 행위자가 될 수 있는 것과 다르게, 상호작용 설계 시나리오에서 행위자는 항상 사람이어야 한다. 시나리오에서 각 행위자는 하나 이상의 목적을 이루고자 한다. 행위자를 구분한 것과 마찬가지로 목적도 주목적(primary goals)과 부 목적(secondary goals)으로 구분한다. 캐롤은 행위와 사건을 시나리오의 ‘줄거리(plot)'라 불렀다. 행위와 사건은 행위자가 목적을 이루기 위해 수행하는 일련의 단계와 그에 대한 시스템의 반응을 의미한다.

18. 사용자 스토리와 시나리오의 주요 차이점은 그것이 다루는 범위와 그 상세함에 있다. 시나리오는 사용자 스토리보다 훨씬 더 상세한 내용을 담고 있으며 보통 여러 사용자 스토리를 포함한다.

왜 사용자 스토리인가?

19. 요구사항을 기술하기 위한 많은 방법 중에서 사용자 스토리를 선택해야 하는 이유는 무엇인가?

• 사용자 스토리는 구두 의사소통을 강조한다.

• 사용자 스토리는 모든 사람이 이해할 수 있다.

• 사용자 스토리는 계획 수립에 적합한 크기다.

• 사용자 스토리는 반복적 개발에 효과적이다.

• 사용자 스토리는 세부사항을 나중에 고려할 수 있게 한다.

• 사용자 스토리는 기회주의적 설계를 지원한다.

• 사용자 스토리는 참여적 설계를 유도한다.

• 사용자 스토리는 암묵적 지식을 구축한다.

구두 의사소통

20. 무언가를 기록하는 것은 장점이 있기는 하다. 단기 기억의 한계, 주의력의 분산, 다른 일로부터의 방해 등을 극복할 수 있게 도와주기 때문이다. 하지만 불명확하게 기록된 내용이라든가 여러 의미가 있는 단어 등 혼동을 일으키는 요인이 너무 많다. 이러한 것들은 요구사항을 기록하는 것에서 요구사항에 대해 대화를 나누는 것으로 초점을 옮김으로써 제거할 수 있다.

21. 구두 의사소통 역시 언어이기 때문에 기록을 통한 의사소통에서 나타나는 문제점들이 어느 정도 동반된다. 그러나 고객, 개발자, 사용자가 대화를 나눌 때에는 서로 즉각적인 피드백을 주고받을 수 있으며, 이는 상호 학습과 이해를 증진시킨다. 그리고 기록된 것에서 느끼는 것과 같은 명확성과 정확성에 대한 잘못된 인상이 대화에서는 배제된다.

22. 사용자 스토리를 사용하는 목적은 우리가 바라는 기능들의 모든 세부사항까지 문서로 자세히 기록하자는 것이 아니다. 오히려 나중에 개발자와 고객이 대화를 이어갈 수 있을 정도의 내용을 담은 짧은 문장들을 기록하자는 것이다.

23. 요구사항 문서에 쓰여있는 각 문장이 완벽하더라도 여전히 두 가지 문제가 존재한다. 첫째, 사용자는 소프트웨어가 개발됨에 따라 더 많은 것을 배우게 되고, 자신이 원하는 것을 더 구체적으로 알게 된다. 둘째, 각 부분의 완벽함이 전체의 완벽함을 보장하지 않는다. 따라서 완벽한 요구사항보다 훨씬 가치 있는 것은 ‘적절한 스토리'와 ‘잦은 대화'를 병행하는 것이다.

사용자 스토리는 이해하기 쉽다

24. IEEE 830 스타일의 소프트웨어 요구사항 명세서와 비교할 때 유스케이스와 시나리오는 사용자와 개발자가 모두 이해하기 쉽다는 장점이 있다. IEEE 830 스타일의 문서는 사용자가 이해하기에는 너무 기술적인 용어를, 개발자가 이해하기에는 너무 특정 분야의 고유 용어를 포함한다.

25. 스토리는 유스케이스나 시나리오보다 더 이해하기 쉽다. 시나리오를 통해서는 상호작용이라는 기본적인 특성을 파악하기가 더 어렵다. 스토리는 간명하고 항상 고객과 사용자의 가치를 표현하도록 작성되기 때문에 비즈니스를 하는 사람이든 개발자든 쉽게 이해할 수 있다.

사용자 스토리는 계획 수립에 적절한 크기다

26. 사용자 스토리는 계획 수립에 적합한 크기로 되어 있다. 너무 크지도 않고 그렇다고 너무 작지도 않은 딱 적당한 크기다. 소프트웨어 요구사항 명세서 상의 수천, 수만에 달하는 문장을 검토한다면, 거기에 우선순위를 부여하는 것이 어려울 수밖에 없다는 것을 알게 될 것이다.

27. 유스케이스나 상호작용 설계 시나리오의 경우에는 그 반대의 문제를 안고 있다. 항목 하나하나의 크기가 너무 크다는 것이 문제다. 몇십 개의 유스케이스나 시나리오에 우선순위를 부여하는 것이 쉬울지는 몰라도, 그 결과는 별로 유용하지 않을 것이다. 왜냐하면 중요한 내용을 각각 조금씩은 담고 있기 때문이다.

사용자 스토리는 반복적 개발에 효과적이다

28. 사용자 스토리는 반복적 개발과 함께 사용할 수 있다는 커다란 장점이 있다. 코딩을 시작하기 전에 스토리를 모두 작성할 필요는 없다. 몇 가지 스토리를 작성한 후 그것들을 코딩하고 테스트한 뒤 이 과정을 필요한 만큼 반복하면 된다. 스토리를 작성할 때는 우리가 원하는 만큼 적절한 수준의 세부사항만 작성하면 된다. 즉 스토리를 작성한 다음에도 더 상세한 수준으로 반복해서 수정해 나가기가 쉽기 때문에 반복적 개발에 아주 효과적이다.

스토리는 세부사항을 나중에 고려할 수 있게 해 준다

29. 스토리를 사용하면 세부사항들을 나중에 고려할 수 있도록 하는 장점이 있다. 초기에는 단지 프로젝트의 목적을 기술하는 수준에서 시작하여 세부사항들이 필요할 때 내용을 추가해 나가는 것이다.

30. 이러한 특징은 시한부 프로젝트에 아주 도움이 된다. 프로젝트 팀은 재빨리 몇 가지 스토리를 작성하여 시스템의 전반적인 윤곽을 잡을 수 있다. 그중에서 가장 중요한 스토리에서 시작해 세부사항을 추가하여 바로 코딩에 착수할 수 있다.

스토리는 기회주의적 개발을 지원한다

31. 높은 수준의 요구사항들을 한 번에 코드로 바꾸는 마법은 없다. 스토리는 프로젝트 팀이 요구사항에 대해 다양한 수준으로 생각하고 이야기 나눌 수 있게 해 준다.

스토리는 참여적 설계를 유도한다

32. 사용자 스토리도 시나리오와 마찬가지로 사람들의 참여를 유도한다. 시스템의 특성에 대해 이야기하는 것이 아니라 사용자가 시스템을 사용하는 목적을 이야기함으로써 시스템에 관해 더 흥미로운 대화를 나눌 수 있다. 많은 프로젝트들이 사용자의 참여 부족으로 실패하고 있다. 스토리는 소프트웨어 설계에 사용자를 참여하게 하는 손쉬운 방법이다.

33. ‘참여적 설계(participatory design)’ 기법에서는 사용자들이 소프트웨어의 기능을 설계하는 팀의 일원이 된다. 단지 ‘다기능 팀(cross-functional)을 구성하고 사용자들을 포함시켜라'와 같은 관리 계명을 따르기 위함이 아니라, 요구사항 분석과 소프트웨어 설계에 사용자들이 직접 관여하기 때문이다.

34. 스토리와 시나리오는 사용자들이 쉽게 이해할 수 있으므로 사용자가 소프트웨어 설계에 참여하도록 유도한다. 게다가 사용자가 자신의 요구사항을 스토리로 만드는 데 익숙해지면 그것으로 이득을 보게 되는 개발자로서는 더욱더 사용자의 참여를 독려하게 된다. 이러한 선순환 구조는 소프트웨어를 개발하는 사람이나 사용하는 사람에게 모두 유익하다.

스토리는 암묵적 지식을 구축한다

35. 스토리는 직접 대화하는 것을 강조하기 때문에 팀 전체에 암묵적 지식을 쌓도록 해준다. 개발자와 고객이 대화를 많이 나눌수록 팀에 더 많은 지식이 축적된다.

왜 스토리를 택하지 않나?

36. 사용자 스토리를 사용하는 것의 단점 중 하나는 대규모 프로젝트에서 스토리가 많을 때 스토리 사이의 관계를 이해하기 어렵다는 점이다. 이 같은 경우에는 사용자 역할을 사용하거나 개발에 들어가기 전까지는 적당한 수준 이상으로 스토리를 유지함으로써 문제를 다소 완화할 수 있다.

37. 유스케이스는 본래부터 계층적인 구조를 띄고 있으므로 요구사항이 많은 작업에 유용하다. 유스케이스는 주 성공 시나리오, 확장 등을 통해 여러 사용자 스토리에 해당하는 내용을 하나로 나타낼 수 있다. 두 번째 문제는 요구사항 추적성(requirements traceability)이 요구되는 경우 사용자 스토리 외에 문서를 추가로 작성해야 할지도 모른다는 것이다.

38. 마지막으로 스토리는 팀 내의 암묵적 지식을 강화한다는 점에서는 훌륭하지만, 매우 큰 규모의 팀에서는 이 장점이 그대로 적용되지 않는다. 규모가 큰 팀에서는 기록이 필요한 대화도 있다. 그래야 팀 전체에 그 정보가 전달될 수 있기 때문이다. 그렇지만 많은 사람들이 조금의 지식을 가질 것인가 혹은 적은 사람들이 많은 지식을 가질 것인가에 대한 절충안이 필요하다는 것을 염두에 두기 바란다.

스토리 냄새 카탈로그

너무 작은 스토리

39. 작은 스토리는 추정이나 일정을 계획할 때 흔히 문제가 된다. 그 이유는 작은 스토리에 대한 작업 추정치는 구현 순서에 따라 크게 달라질 수 있기 때문이다. 스토리를 한 이터레이션 내에서 처리하기 위해 나누는 것은 좋지만, 그렇다고 하더라도 나눌 필요가 있을 때까지는 합친 상태로 두는 것이 좋다.

상호 의존적인 스토리

40. 스토리들이 상호 의존적인 경우 이터레이션을 계획할 때 개별적으로 다루는 것이 어렵다. 어떤 스토리를 이터레이션에 추가하려면 다른 스토리도 함께 추가해야 하는 상황이 발생하는 것이다. 그 다른 스토리를 위해 또 다른 스토리를 추가해야 하는 등 이터레이션을 계획하기 어렵게 된다. 스토리가 너무 작거나 스토리를 적절하게 나누지 못했을 때 이러한 현상이 발생한다. 스토리들이 너무 작아서 상호 의존적인 것 같다면 간단히 그것들을 하나로 합쳐서 해결할 수 있다.

금도금

41. ‘금도금(goldplating)’이라는 용어는 개발자가 불필요한 기능들을 추가하는 것을 말한다. 개발자는 흔히 고객에게 필요한 것 이상을 구현하곤 한다. 거기에는 몇 가지 이유가 있다. 첫째, 몇몇 개발자는 멋진 기능으로 고객을 놀라게 해주고 싶어 한다. 둘째, 짧은 이터레이션 단위로 빠르게 진행하는 스토리 주도의 프로젝트에서는 개발자들이 지속적인 개발로 인해 극심한 압박을 느끼게 된다. 이런 경우 금도금은 개발자들이 잠시나마 압박에서 벗어날 수 있게 해 준다. 마지막으로 개발자는 프로젝트에 자신만의 흔적을 남기는 것을 즐긴다. 몇 가지 자신만의 기능을 추가하는 행위는 이를 위한 한 방편이다.

42. 개발자들은 고객이 우선순위를 부여한 스토리에 충실해야 한다. 만약 새로운 스토리에 대한 좋은 아이디어가 있다면 고객에게 제안하여 그것이 다음 이터레이션에 포함될 수 있도록 상의하는 것이 바람직하다.

43. 프로젝트에서 개발자들이 금도금 행위를 과도하게 한다면, 각자 진행하는 작업 내용을 더 가시화함으로써 이를 막을 수 있다. 마찬가지로, 이터레이션 종료 시점에 고객과 기타 이해관계자 앞에서 새롭게 추가된 모든 기능을 자세히 시연하는 이터레이션 검토 회의를 하게 되면 금도금 행위를 했는지 파악하는 데 도움이 된다.

너무 상세한 스토리

44. 스토리에 너무 상세한 부분까지 포함시키는 것은 대화를 나누는 것보다 문서화하는 것에 더 가치를 두고 있다는 것을 나타낸다.

사용자 인터페이스와 관련된 세부사항을 너무 일찍 포함시키기

45. 프로젝트 팀은 프로젝트를 진행할 때 은연중에 사용자 인터페이스에 대한 가정을 가지고 스토리를 작성하는 경우가 있다.

너무 앞서 생각하기

46. 사용자 스토리를 사용하는 가장 근본적인 이유는 모든 요구사항을 사전에 식별해낼 수 없다는 데 있다. 훌륭한 소프트웨어는 이터레이션을 반복하면서 세부사항들을 추가함으로써 만들어지는 것이다. 스토리는 확정적인 것이 아니며 이후 버전들에서 세부사항들을 쉽게 추가할 수 있기 때문에 반복적 접근법에 잘 맞는다.

스토리를 너무 많이 나누기

47. 개발자와 고객이 다음 이터레이션에서 개발할 스토리를 고를 때, 스토리를 나누어야 할 경우가 생긴다. 일반적으로 계획 시 스토리를 나누는 이유는 다음 두 가지 중 하나다.

• 1. 스토리가 너무 커서 이터레이션에 포함할 수 없다.

• 2. 스토리가 서로 다른 우선순위의 하위 스토리들을 포함하고, 고객이 그중에서 우선순위가 높은 하위 스토리들만 다음 이터레이션에서 구현하기를 원한다.

48. 이 두 가지 이유가 문제 되는 것은 아니다. 스토리를 너무 자주 나누는 것 같다면, 단지 이터레이션 길이를 맞추느라 나눌 필요 없는 스토리를 나누기보다 남은 다른 스토리들을 훑어보고 그중에서 정말 나누어야 할 스토리를 찾아보는 것이 좋다.

고객이 우선순위 부여를 어려워함

49. 고객이 우선순위를 부여하는 것을 어려워한다면 우선 스토리의 크기를 살펴보라. 스토리가 너무 크면 우선순위를 부여하기 어렵다. 또한 비즈니스 상의 가치를 표현하지 않은 스토리에 우선순위를 부여하는 것이 어렵다. 각 스토리가 어떠한 형태로 다시 작성되어야 하는가는 고객의 기술적 지식에 따라 달라질 수 있는 것이므로, 가장 좋은 방법은 고객이 직접 스토리를 작성하게 하는 것이다.

스크럼에서 사용자 스토리 사용하기

스크럼은 반복적이고 점진적이다

50. 스크럼은 반복적이고 점진적인 프로세스다. 반복적(iterative) 프로세스는 계속적인 정련 작업을 통해 진행되는 프로세스를 의미한다. 개발 팀은 제품을 일단 만들어 본다. 이렇게 처음 만든 제품은 불완전하며 취약한 부분도 있다는 것을 알고 있다. 만족스러운 결과가 나올 때까지 그러한 부분들을 반복적으로 정련해 나간다. 소프트웨어는 이터레이션마다 더 상세한 부분들이 첨가되면서 개선된다.

51. 점진적(incremental) 프로세스는 소프트웨어를 여러 부분으로 나누어 각 부분을 개별적으로 개발하고 전달하는 프로세스를 의미한다. 증가분(increment)에 해당하는 각 부분은 그 자체로 온전한 기능을 수행한다. 증가분의 규모는 다양하다. 각 증가분은 코딩뿐만 아니라 테스트까지 완전히 마치게 되며, 일반적으로 한번 완성된 증가분에 대해서는 재작업하지 않을 정도가 되도록 해야 한다.

스크럼 팀

52. 스크럼 팀은 일반적으로 네 명에서 일곱 명의 개발자로 구성한다. 자신의 전문 분야만을 담당하기보다는 ‘모두 함께 한다'는 자세를 공유한다.

53. 스크럼 팀은 자기조직적(self-organizing)이다. 즉 스크럼 팀에는 ‘메리는 코딩을 맡고 빌은 테스트를 담당한다'와 같은 관리 지침이 존재하지 않는다. 그렇기 때문에 스크럼 팀에서는 프로그래머, 아키텍트, 테스터와 같은 역할 명칭을 잘 사용하지 않는다. 팀원들이 무엇을 할지는 전적으로 팀원들이 결정한다.

54. 스크럼 팀은 개발자 외에 특별히 제품 소유자(product owner)와 스크럼마스터(ScrumMaster)의 보조가 필요하다. 제품 소유자의 주된 역할은 필요한 기능들을 제품 백로그에 추가하고 우선순위를 부여하는 일이다. 스크럼마스터는 프로젝트 관리자와 비슷한데, 다만 그들의 역할은 관리자보다 리더에 가깝다.

55. 스크럼 팀은 자기조직적이고 스프린트를 완료하기까지 많은 자유가 주어지므로 스크럼마스터는 팀을 이끌기보다 팀에 봉사하는 역할을 수행한다. 스크럼마스터는 보통 프로젝트의 진행에 방해되는 장애물을 제거하거나 팀이 스크럼 프로세스에서 규정하는 몇 가지 간단한 규칙들을 잘 따르도록 도움으로써 팀에 봉사한다.

제품 백로그

56. 제품 백로그는 제품에 필요한 모든 기능을 담은 주 목록이다. 프로젝트를 시작할 때, 처음부터 필요한 기능을 모두 파악하기 위해 노력하는 일은 없다. 보통 제품 소유자와 개발 팀이 모여 가장 명백한 기능들을 우선 기록한다. 거의 대부분 이렇게 하는 것만으로도 첫 번째 스프린트의 작업량보다는 충분히 많게 된다. 제품 백로그는 나중에 제품과 고객에 관하여 더 많이 알게 됨에 따라 늘어나거나 변경될 수 있다.

스프린트 계획 회의

57. 스프린트 계획 회의(sprint planning meeting)는 스프린트를 시작할 때마다 열린다. 회의는 보통 하루 종일 하며, 제품 소유자, 스크럼마스터, 팀의 개발자 전체가 회의에 참석한다.

58. 스프린트 계획 회의의 전반부는 제품 소유자가 팀에게 제품 백로그에 남아 있는 항목 중에서 우선순위가 높은 항목들을 설명한다. 팀원들은 회의 후반부에 스프린트 백로그로 옮길 항목들을 결정할 수 있도록 충분한 질문을 통해 각 항목들을 숙지한다.

59. 팀원들과 제품 소유자는 함께 스프린트 목표(spirnt goal)를 정의한다. 스프린트 목표는 해당 스프린트 동안 팀이 이루고자 하는 것을 간략히 기술한 것이다. 스프린트의 종료 시점에 하는 스프린트 검토 회의(sprint review meeting)에서 해당 스프린트의 성공 여부는 제품 백로그의 개별 항목들을 구현했는지 여부가 아니라 스프린트 목표를 달성했는지에 따라 평가된다.

60. 일단 스프린트가 시작되면 개발 팀만이 스프린트에 작업을 추가할 수 있다. 제품 소유자라도 생각을 바꾸어 추가 기능을 요청하는 것은 안 된다. 스프린트에 작업을 추가하는 것은 오직 팀 자체에서 일정에 여유가 있다고 판단한 경우에만 이뤄진다.

61. 만약 스프린트를 변경해야 할 만큼 중요한 일이 발생한다면 진행 중인 스프린트 자체를 취소하고 스프린트 계획 회의를 다시 열어서 새로운 스프린트를 시작한다.

62. 제품 백로그의 항목들을 선택하여 스프린트 백로그에 추가하면서 각 항목을 작업 단위로 확장하게 된다. 제품 백로그의 항목 하나가 스프린트 백로그에서 여러 개로 확장됨으로써 팀은 더 효과적으로 작업을 분담할 수 있다.

스프린트 검토 회의

63. 각 스프린트에서는 잠재적으로 출시 가능한 형태의 증가분을 제품 소유자에게 인도해야 한다. 즉 스크럼 팀은 스프린트를 마쳤을 때 소프트웨어의 일부분이기는 하지만 테스트까지 모두 마친, 사용 가능한 형태를 완성해야 한다.

일일 스크럼 회의

64. 일일 스크럼은 짧은 시간 내에 업무에 큰 지장 없이 프로젝트의 진행 상황을 체크할 수 있게 해 준다. 일일 스크럼에서 각 팀원들은 다음 세 가지 질문에 대답한다.

• 1. 어제 무엇을 했는가?

• 2. 오늘 무엇을 할 것인가?

• 3. 장애요소는 무엇인가?

65. 일일 스크럼이 스크럼마스터에 의해 진행되어서는 안 된다. 회의의 목적 중 하나는 개발자들이 동료들 앞에서 이행 약속을 하는 것이다. 이행 약속을 하는 대상은 관리자나 회사 측이 아닌 바로 동료들이다. 쟁점사항 해결을 위해 나중에 모일 팀원들을 정하는 것은 괜찮지만 회의 중에 문제를 해결하려 해서는 안 된다.

스크럼에 스토리 추가하기

66. 제품 백로그의 각 스토리는 사용자나 제품 소유자에게 가치 있는 내용을 기술해야만 한다. 제품 백로그에 사용자 스토리만을 넣도록 제한함으로써 제품 소유자가 우선순위를 부여하는 것이 훨씬 쉬워진다. 사용자 스토리로 작성된 백로그 항목들은 제품 소유자가 이해할 수 있는 용어로 기술되어 있으므로 제품 소유자가 기능 간 우선순위를 비교하는 것이 더 쉬워진다.

67. 스프린트 계획 회의 동안 제품 소유자와 팀은 제품 백로그에서 우선순위가 가장 높은 항목들은 논의한다. 그리고 나서 팀은 해당 스프린트 동안 수행할 항목을 골라낸다. 그리고 필요에 따라 항목들을 더 작은 작업 단위로 나누어 스프린트가 진행되는 동안 개발자들에게 할당한다.

그 밖의 주제

비기능 요구사항 처리하기

68. 모든 것을 스토리 형태로 표현해야 한다는 강박관념은 사용자 스토리를 사용하는 데 장애물이 될 수 있다. 프로젝트를 진행하다 보면 적어도 몇 가지 요구사항은 스토리로 표현하기가 어렵다는 것을 느끼게 된다. 흔히 이러한 요구사항들은 시스템의 비기능 요구사항인 경우가 많다.

69. 비기능 요구사항은 시스템과 관련된 다양한 요구사항을 표현한다. 다음은 비기능 요구사항과 관련된 시스템 특성들이다.

• 성능(performance)

• 정확성(accuracy)

• 이식성(portability)

• 재사용성(reusability)

• 관리용이성(maintainability)

• 상호운용성(interoperability)

• 가용성(availability)

• 사용성(usability)

• 보안(security)

• 용량(capacity)

70. 비기능 요구사항들은 시스템의 동작 방식에 제약을 가하는 경우가 많다. 제약사항은 그 내용을 카드에 기록하고 ‘제약사항'이라고 표시해 두는 것이 좋다. 제약사항들을 만족하는지 확인하기 위해서는 자동화된 테스트를 사용하라.

사용자 스토리와 사용자 인터페이스

71. 애자일 기법들은 사용자 인터페이스를 설계하는 것에 관한 이슈들을 무시한다는 지적이 있다. 사용자 인터페이스 설계에 대한 전통적인 접근법이 선행 설계(upfront design)에 과도하게 의존하여 빅뱅과 같이 짧은 기간에 전체적인 구현이 이루어지는 반면, 애자일 프로세스는 대단히 반복적으로 접근하기 때문이다. 사용자 인터페이스가 큰 비중을 차지하는 애플리케이션이라면 스토리 기반의 애자일 접근법을 따르는 것이 갖는 잠재적 리스크를 이해해야 한다.

72. 사용자 인터페이스가 제품 성공 여부의 매우 중요한 부분을 차지한다면 사용자 인터페이스를 프로젝트 시작부터 신중히 고려할 필요가 있다.

버그 스토리

73. 버그 수정이 보통의 스토리 하나를 구현하는 것과 비슷한 시간이 걸린다면 버그를 다른 스토리와 마찬가지로 취급할 수 있다. 다만 쉽게 수정할 수 있는 버그는 몇 개씩 묶어서 스토리로 취급한다.

부록

익스트림 프로그래밍의 개요

역할

74. XP에서 고객 역할은 스토리를 작성하고, 스토리의 우선순위를 결정하며, 스토리가 제대로 개발되었는지 확인하기 위한 테스트를 작성하고 실행하는 책임이 있다. XP의 고객 역할은 개발 중인 시스템의 사용자가 맡겠지만, 반드시 그런 것은 아니다. 사용자가 아닌 경우에는 제품 관리자나 프로젝트 관리자, 혹은 비즈니스 분석가가 고객 역할을 맡을 수 있다.

75. XP에서 프로그래머 역할은 넓은 기술 영역을 포괄한다. XP 프로젝트에서는 대개 프로그래머, 설계자, 데이터베이스 관리자 등과 같은 구분을 하지 않는다. XP를 적용하지 않는 프로젝트에서는 특정 개인에게 부여될 만한 업무를, XP 프로젝트에서는 팀 전체가 공유하여 처리하는 것을 지향한다.

76. 대부분의 방법론이 프로그래머에게 단위 테스트를 작성할 것을 요구한다. XP에서는 이러한 요구를 특히 강조하여 모든 프로그래머가 자신이 작성한 모든 코드에 대해 자동화된 단위 테스트를 작성하도록 요구한다.

12가지 실천법

77. XP는 12가지 실천법을 특징으로 한다.

• 작은 릴리즈

• 계획 게임

• 리팩터링

• 테스트

• 짝 프로그래밍

• 유지 가능한 페이스

• 팀 코드 소유

• 코딩 표준

• 단순한 설계

• 메타포

• 지속적인 통합

• 현장 고객

78. 작은 릴리즈. XP 프로젝트는 1주에서 3주 길이의 이터레이션을 단위로 하여 진행된다. 사용자 스토리 형태로 기술된 기능들은 한 이터레이션 내에서 완전히 구현되어 사용자에게 인도된다. 일부 기능만 구현하여 전달하는 것은 안된다. 모든 기능을 구현했지만 품질이 떨어지는 것도 안 된다. 각 이터레이션을 마치는 시점의 코드는 완전히 동작하고 모든 테스트를 통과해야 하며 즉시 사용할 수 있어야 한다.

79. 보통 프로젝트를 시작하면서 이터레이션 길이를 결정한다. 처음 결정한 이터레이션 길이는 프로젝트를 마칠 때까지 일정하게 유지해야 한다. 이터레이션 길이는 보통 1주 혹은 2주며 길어도 4주를 넘기면 안 된다. 이터레이션 길이를 결정할 때는 사용자에게 실제적인 가치를 전달할 수 있는 선에서 가능한 짧게 한다. 두 길이를 놓고 고민될 때는 짧은 것을 선택한다.

80. 이터레이션은 엄격한 타임박스다. 이터레이션 마지막 날에 이틀을 더 작업하자고 결정해서는 안 되며, 일정에 따라 정확히 이터레이션을 종료하여야 한다. 이터레이션에 대한 협상은 (품질의 높고 낮음이 아니라) 작업량을 줄이거나 늘이는 것을 의미한다.

81. 계획 게임. ‘계획 게임’은 릴리즈 계획이나 이터레이션 계획 활동을 XP가 부르는 이름이다. 계획 게임에서는 개발자와 고객이 협업하여 향후 작업이 어떻게 진행될지 예측한다. 계획을 시작할 때는 이미 고객이 작성한 사용자 스토리가 있고, 각 스토리에는 개발자들이 추정한 작업량 혹은 비용이 할당되어 있다.

82. 릴리즈 계획은 개발이 어떠한 모양으로 진행될 것인지에 대한 초기 가정이라 할 수 있으며, 이터레이션 계획에서 우선순위의 변경이 반영될 것이다. 우선순위의 변경은 개발 팀의 실제 작업률을 알게 되거나 개발자들이 각 스토리의 실제 비용을 더 잘 알게 됨에 따라 발생한다.

83. 리팩터링. 리팩터링은 노출되는 동작을 변경하지 않으면서 코드를 개선함으로써 코드를 재구성하고 재작성하는 것을 말한다. 프로그래머에게 리팩터링은 권장사항이 아닌 필수사항이다. 이렇게 함으로써 코드에 내재되어 천천히 드러나는, 그러면서도 해결하기 어려운 결함들을 방지할 수 있다.

84. 테스트. XP 프로젝트에서는 개발자들이 자동화된 단위 테스트를 작성하며, 고객이 인수 테스트를 작성한다. 프로그래머가 하는 단위 테스트뿐만 아니라, 고객 테스트도 XP에서 중요한 요소다. 각 사용자 스토리를 대상으로 고객은 해당 스토리가 고객이 기대하고 가정한 모습에 맞게 개발되었는지 확인하기 위한 테스트를 정의해야 한다. 많은 경우 고객이 작성한 인수 테스트는 폭포수 모델의 요구사항 문서를 대체한다.

85. 짝 프로그래밍. 짝 프로그래밍은 프로그래머 두 명이 키보드와 모니터를 공유하여 같이 코드를 작성하는 것을 말한다. 한 명이 키보드를 담당하여 직접 코드를 타이핑하며 현재 진행 중인 몇 줄의 코드에 집중하는 동안 다른 프로그래머는 어떠한 방향으로 진행되어야 하는지 발생할 수 있는 문제는 없는지 좀 더 넓은 시각으로 코드가 작성되는 것을 지켜보게 된다. 짝 프로그래밍을 할 때는 서로의 역할과 짝을 자주 바꾸어야 한다.

86. 유지 가능한 페이스. XP 팀은 유지 가능한 페이스로 일하는 것을 미덕으로 본다. 이러한 믿음은 일관되게 활기찬 페이스로 일하는 경우가 장기간 유지하기 어려운 페이스로 일하는 경우보다 장기적으로 훨씬 성취도가 높다는 데서 기인한다.

87. 팀 코드 소유. 모든 코드는 모두의 소유다. 이러한 팀 소유 방식을 따르게 되면 어떤 개발자(개인 혹은 짝)도 아무 코드나 수정할 수 있다. 개인 소유는 응집도가 높은 설계와 각 모듈의 책임이 잘 분배되도록 하기 위해 사용된다. XP에서는 이러한 짐을 테스트 주도 개발에서 맡는다. 견고한 단위 테스트 집합을 통해 변경 사항이 예상치 못한 부작용을 낳지 않음을 보증한다.

88. 코딩 표준. XP 팀은 소스 코드를 집단 소유하기 때문에 모든 개발자가 코딩 표준을 따르는 것이 중요하다. 코딩 표준은 주요 규칙들을 정의하고 팀 구성원들이 코드를 작성할 때 따라야 하는 관례들을 담고 있다. 여기에는 변수나 메서드의 명명법과 소스 코드 레이아웃 등이 포함된다.

89. 단순한 설계. XP 팀은 고객이 요구하는 기능을 인도할 수 있는 한 가장 단순한 설계를 유지할 것을 목적으로 한다. 켄트 벡은 설계가 가장 단순한 형태임을 나타내는 네 가지 제약사항을 정의했다.

• 1. 실행 코드와 테스트 코드가 프로그래머의 의도를 명확히 담고 있다.

• 2. 중복된 코드가 없다.

• 3. 시스템은 가장 적은 클래스들을 사용한다.

• 4. 시스템은 가장 적은 메서드들을 사용한다.

90. 메타포. XP 팀은 전체 시스템을 대상으로 사용될 수 있는 메타포를 찾음으로써 단순한 설계를 가능하게 한다. 메타포는 차명자들이 시스템을 어떻게 생각하고 있는지 참조할 수 있는 틀을 제공한다.

91. 지속적인 통합. XP 팀은 적어도 매일 통합한다. 통합에서 발생한 문제는 발생한 즉시 해결된다.

92. 현장 고객. XP에서는 벽이 사라지고 고객이 개발 팀과 같은 자리에서 팀의 일부가 되는 상황을 바람직하게 본다. 고객은 스토리와 인수 테스트를 작성하며 수시로 발생하는 질문에 즉각적으로 답을 제시한다.

93. 현장 고객은 사용자 스토리를 성공적으로 도입하는 데 필수적이다. 스토리를 사용하면 고객과 개발자가 대화를 많이 해야 하기 때문이다. 고객이 현장에 없다면 발생하게 되는 지연으로 인해 프로젝트의 진행을 예측하는 데 혼란이 야기될 것이다.

4가지 가치

94. XP에서는 실천법과 함께 의사소통, 단순함, 피드백, 용기의 4가지 가치를 중요시한다. XP는 의사소통의 가치를 강조하지만, 모든 의사소통을 동일하게 취급하지는 않는다. 직접 이야기를 나누고, 응답하고, 제스처를 보이거나 화이트보드에 그림을 그리면서 설명할 수 있는 대면(face-to-face) 의사소통을 가장 중요하게 여긴다.

95. 단순함의 가치는 XP 팀이 문제를 해결할 때 내일 일어날 거라고 예상하는 문제보다는 오늘 당면한 문제에 집중하기 위함이다. XP 팀은 현재 이터레이션에 할당된 기능을 개발하는 데 필요한 것 이상의 기능을 지원하기 위해 시스템을 설계하지 않는다. ‘제대로 동작하는 가장 단순한 것(the simplest thing that could possibly work)’ 을 하는 데 초점을 둔다.

96. XP 팀은 피드백의 가치를 중요시한다. 피드백이 빨리 이뤄질수록 더 좋다. 고객은 팀의 구성원으로 개발자들과 같은 공간에 자리함으로써 팀과 끊임없는 상호작용과 인수 테스트를 작성하면서 피드백을 제공한다.

97. 마지막으로 XP 팀은 용기의 가치를 중요시한다. 메타포를 이용하고 리팩터링과 테스트 주도 개발을 실천함으로써 단순한 설계를 유지할 수 있기 때문에 이러한 용기를 낼 수 있다.