우선 클래스 상속 구조의 메소드 재정의를 통해서 구현하는 방식이었던 기존 스프링 테스트 지원 기능은
테스트 컨텍스트 프레임웍으로 넘어오면서 완전히 애노테이션을 기반으로 하는 이벤트 방식으로 변경되었습니다.
내용을 파악하는 첫 번째 방법 중의 하나가 가장 밀접하게 사용되는 스테레오타입(애노테이션)을 파악하는 일입니다.
나아가 이 애노테이션의 호출 흐름과 범위를 인식하는게 중요합니다.
그래서 간단히 정리해봤습니다.
애노테이션이 호출되는 순서대로 나열했고, 바운더리는 Test Class 수준, Test Instance 수준, Transaction 수준으로 나누었습니다.
특히나 데이터베이스와 연동하여 테스트를 할 시에는 Transaction 관련 스테레오타입의 앞 뒤를 명확히 이해하는 것이 중요합니다.
현장에서 '갑'의 역할로 스크럼을 처음 접하다보니 책에서 설명하는 것과 또 다른 시각으로 생각할 수 있는 좋은 기회가 되고 있습니다. 이 내용은 따로 정리해서 공유할 수 있을 것 같습니다.
일단 책 내용을 발췌해봤습니다. (특정한 기준없이 책에 나오는 순서대로 나열했습니다. 굵은 줄도 역시나 제 생각을 기준으로 했습니다...)
# 스프린트가 진행되는 동안에 선택된 항목을 절대 변경하지 않는다.
- 효과 : 약속이 변경되지 않을 것이라는 확신이 있기 때문에... 팀은 정해진 일을 완료하는데만 집중, 제품 책임자는 항목 선정에 심사숙고
# 스프린트 종료 시점에 실제로 '완료'되어 작동하는 제품이 나와야 한다
# 스크럼 역할
- 제품 책임자: 제품의 기능을 식별하여 우선순위를 매겨 목록을 만들고, 우선순위를 정함
- 팀: 고객에 사용하게 될 제품을 개발
- 스크럼 마스터: 제품 그룹이 스크럼을 배우고 적용하여 비즈니스 가치를 획득하도록 도움
# 스크럼 마스터와 제품 책임자가 같은 사람이면 안 된다
# 제품 백로그는 제품의 수명이 다할 때까지 존재한다
# 제품 백로그는 오로지 하나만 존재한다
# 제품 백로그 상의 추정치는 '절대적인 단위'보다는 '점수'로 표현하는 상대적인 추정치가 일반적이다
# 스프린트 시작할 때 스프린트 계획회의를 한다
# 일일 스크럼 시에는 다음 세 가지만 보고한다
1) 지난 일일 스크럼 이후 무엇을 완료하였는가?
2) 다음 회의 때까지 무엇을 마무리할 계획인가?
3) 일하는 데 어떠한 방해나 장애요인들이 있는가?
# 스프린트의 소멸차트는 작업을 마무리하기까지 얼마만큼의 일이 남았는지 보여준다
# 매 스프린트의 5~10%를 반드시 제품 백로그를 구체화하는 작업에 할애애야 한다(반나절/2주일 1 스프린트)
# 스프린트 종료시 스프린트 검토회의를 한다
# 스크럼 마스터는 스프린트 계획 때 정한 '완료의 정의' 중 완료하지 못한 내용에 대해서는 반드시 제품 책임자에게 알려야할 책임이 있다.
# 스프린트 검토 후 스프린트 회고 활동을 한다.
# 검토 회의 중 한 가지 방법으로 '잘 되고 있는 것'과 '더 잘할 수 있었던 것'으로 나누어 생각해본다.
# 스프린트 회고 후 릴리스 백로그 및 소멸차트를 갱신한다.
# 남은 작업을 처리하기 위한 '릴리스 스프린트'가 필요할 수도 있다. 하지만 이는 스프린트 진행 상에 무언가 취약점이 있다는 증거다.
# 진정한 스크럼의 혜택은 좋은 것과 나쁜 것을 여실 없이 드러내고 조직이 스스로 수준을 향상시킬 수 있는 기회를 갖는 것이다.
Prev
Rss Feed
