스타일쉐어에서 PM을 맡고 있는 박성환입니다. 저희 팀은 2년 가까이 스크럼을 기반으로 개발을 해오고 있습니다. 그러면서 스크럼을 저희 방식에 맞게 약간씩 수정한 부분들을 한번 정리해보는게 좋을 것 같다싶어 이 슬라이드를 작성하게 되었습니다.
목차
1. 이 슬라이드를 만드는 이유 : 어떤 이유로 우리팀의 스크럼에 대한 내용을 슬라이드로 만들었는지에 대한 내용을 적어보았습니다. 이 슬라이드의 ‘목적’이라고도 할 수 있습니다.
2. 간단한 정리 : 스크럼에 대해 잘 모르시는 분들을 위해 간단하게 주요 내용을 정리해보았습니다.
3. 스타일쉐어팀의 기본 스크럼 방식 : 각 팀마다 스크럼 방식이 다를 텐데 주요 내용(스프린트 주기, 스토리 포인트, 사용중인 서비스)에 대해 정리했습니다.
4. 변경한 규칙 : 지난 반년동안 우리팀에 맞게 약간씩 바꾼 스크럼 규칙들을 나열해보았습니다.
5. 다만, 아직까지 남아있는 고민 : 아직 저희팀도 문제점은 있지만 개선방향을 못잡은 내용에 대해 적어보았습니다.
6. 스크럼이 조직에 잘 녹아들기 위한 조건 : 다른 조직에서도 여러 이유로 스크럼을 도입해봤지만 실패도 해보고 매끄럽게 진행도 해보면서 느꼈던 차이점에 대해 개인적인 경험을 정리해보았습니다.
몇몇 조직에서 스크럼을 경험해보고 다른 방식들도 겪어보면서 제 개인적인 생각엔 스크럼은 ‘공유’가 바탕이된 문화라고 생각합니다. 서로간의 일하는 방식, 문제점에 대해 쉽게 공유할 수 있는 환경을 만들어주는데 도움을 많이 주는 것 같습니다. 또 이런 문화가 잘 바탕이 되어 있는 조직일 수록 더 매끄럽게 돌아갔던 것 같습니다.
이 슬라이드가 다음 스크럼마스터에게도 좋은 도움이 되었으면 하고, 큰 도움은 되지 않겠지만 스크럼을 사용중인 다른 조직에게도 참고할수 있는 내용이 되길 바랍니다. 보시고 궁금하신 내용이나 의견들은 이메일 혹은 트위터를 통해서 언제든지 문의주시면 성실히 답변드리겠습니다. 감사합니다.
스타일쉐어에서 PM을 맡고 있는 박성환입니다. 저희 팀은 2년 가까이 스크럼을 기반으로 개발을 해오고 있습니다. 그러면서 스크럼을 저희 방식에 맞게 약간씩 수정한 부분들을 한번 정리해보는게 좋을 것 같다싶어 이 슬라이드를 작성하게 되었습니다.
목차
1. 이 슬라이드를 만드는 이유 : 어떤 이유로 우리팀의 스크럼에 대한 내용을 슬라이드로 만들었는지에 대한 내용을 적어보았습니다. 이 슬라이드의 ‘목적’이라고도 할 수 있습니다.
2. 간단한 정리 : 스크럼에 대해 잘 모르시는 분들을 위해 간단하게 주요 내용을 정리해보았습니다.
3. 스타일쉐어팀의 기본 스크럼 방식 : 각 팀마다 스크럼 방식이 다를 텐데 주요 내용(스프린트 주기, 스토리 포인트, 사용중인 서비스)에 대해 정리했습니다.
4. 변경한 규칙 : 지난 반년동안 우리팀에 맞게 약간씩 바꾼 스크럼 규칙들을 나열해보았습니다.
5. 다만, 아직까지 남아있는 고민 : 아직 저희팀도 문제점은 있지만 개선방향을 못잡은 내용에 대해 적어보았습니다.
6. 스크럼이 조직에 잘 녹아들기 위한 조건 : 다른 조직에서도 여러 이유로 스크럼을 도입해봤지만 실패도 해보고 매끄럽게 진행도 해보면서 느꼈던 차이점에 대해 개인적인 경험을 정리해보았습니다.
몇몇 조직에서 스크럼을 경험해보고 다른 방식들도 겪어보면서 제 개인적인 생각엔 스크럼은 ‘공유’가 바탕이된 문화라고 생각합니다. 서로간의 일하는 방식, 문제점에 대해 쉽게 공유할 수 있는 환경을 만들어주는데 도움을 많이 주는 것 같습니다. 또 이런 문화가 잘 바탕이 되어 있는 조직일 수록 더 매끄럽게 돌아갔던 것 같습니다.
이 슬라이드가 다음 스크럼마스터에게도 좋은 도움이 되었으면 하고, 큰 도움은 되지 않겠지만 스크럼을 사용중인 다른 조직에게도 참고할수 있는 내용이 되길 바랍니다. 보시고 궁금하신 내용이나 의견들은 이메일 혹은 트위터를 통해서 언제든지 문의주시면 성실히 답변드리겠습니다. 감사합니다.
2. 리뷰 할 줄 아니?
● 리뷰?
o 꽤 많은 개발자가 리뷰를 하지 않는다!
o 리뷰는 귀찮다!
o 리뷰를 혼나는 걸로 생각한다!
o 그 외 …
● 하지만, 리뷰는 반드시 필요한 존재
o 좋은 리뷰 한 번이 뒤에 벌어질 대형 참사를 막음
● 근데, 리뷰하는 방법을 잘 몰라요...
4. 리뷰를 실패하게 만드는 것들 (일부)
● 헐뜯기/잘난 척
o “니가 저번에 날 씹었겠다...”, “이런 것도 몰라?”
● 샛길로 새기
o “우리 땐 몇일 밤 새가며 하곤 했는데…”
● 계획없는 리뷰, 사소한 지적만 하기
o “아, 그건 템플릿 패턴으로, 그게 뭐냐면…”
o “여기 오타, 저기 오타, 지금 보니까, 여기도 있네요.”
● 봐주기
o “A가 만든거야, 잘 봐줘.”, “대충하고 빨리 끝내자”
● 그 외
o 작성자 마인드, 두 마리 토끼, 방어적 태도
5. 리뷰의 목적
● 수정 공수 줄이기!!
o 잠재적인 문제를 미리 발견해서 뒤에 벌어질 수정
비용을 절감하는 것이 리뷰를 실행하는 가장 큰 목
적
● 비용 효과가 높은 문제를 지적하는 것이 중
요
● 리뷰 == 인적 비용 발생
o 이 비용을 지출한 것 이상의 결과를 얻을 수 있도록
리뷰는 효과적이어야 함
6. 리뷰를 잘 하려면
● 계획적이어야 함
o 리뷰에도 올바른 순서가 있음
o 기본이 되는 사고 방식과 표준 순서를 익혀야 함
● 리뷰 참가자의 역할에 맞는 활동 필요
o 리더, 리뷰어, 작성자의 세 가지 역할
● 리뷰의 목적을 분명히 해야 함
7. 리뷰의 4단계
● 리뷰의 4단계
o 준비 → 문제 검출 → 문제 지적(리뷰회의) → 수정
및 확인
o 리뷰의 시작과 끝
§ 어떤 문제를 검출할지 생각하는 것 부터
§ 문제의 수정을 확인하는 데까지
● 각 단계 별로 리더, 리뷰어, 작성자는 역할에
맞는 활동 수행
8. 리뷰 준비
리더 리뷰어 작성자
1. 검출할 문제 유형 선전
- 처리량 감소, 복잡한 UX 등 몇 가
지 문제 유형을 5~10개 정도로 도
출
2. 지침이 되는 시나리오 작성
- 문제 유형별로 어디를 어떻게 검
출할지 구체적 기술
3. 간단한 리뷰 실시
- 문서 포맷 맞추는 등의 목적으로
간단한 리뷰를 초기 실시
4. 리뷰어 선정과 시나리오 배분
- 시나리오별로 리뷰어 선정
5. 문서 배포와 고지
- 문서 작성자로부터 문서를 받아
리뷰어에 배포, 수집 일정 공지
1. 시나리오 만들기
- 필요에 따라 리뷰어가 추가
2. 시나리오 순서 결정
- 수정 공수나 리스크가 큰 시나
리오와 운선순위를 기준으로 리
뷰 순서 결정
3. 시나리오 확인과 참고 문서 준
비
- ERD, 기획서 등 필요한 문서를
미리 준비
4. 검출 방법과 체크 범위 검토
- 시나리오별로 체크할 범위를 압
축해서 집중력 유지
5. 문제 검출 일정 잡기
- 가능한 빨리 시작해서 시간이
부족하지 않도록 함
- 제대로 된 문서
를 만들기 위해
노력
- 의문이 생기면
간단 리뷰 등으로
바로 확인
- 리뷰어 배려: 문
서 구조를 통일하
고, 오탈자 등을
최대한 교정
9. 리뷰어, 문제 검출
● 시나리오 순서 결정
o 누락, 애매함, 오류 순서로 진행
§ 누락: 어떤 내용이 쓰여 있어야 할지 미리 생각하고 검토
§ 애매함: 여러 의미로 해석 가능하거나 부족한 부분
§ 오류: 여러 번 읽을수록 발견하기 쉬우므로 마지막 진행
● 검출 방법
o 누락: 사전에 들어가야 할 내용 미리 생각
o 애매함: 문서를 읽을 대상을 고려해 검토
§ 예, 이것, 저것들, 처리하다
o 오류
§ 문서 내의 부정합: 자료 타입, 길이, 범위, 시간대 등
§ 문서 외적이 요소와의 부정합: 개발 표준, 외부 연동
10. 리뷰어, 문제 검출
● 시나리오는 한 번에 하나씩 검토
● 문제 발견시 그 시점에 바로 기록
o 메모 정도만 하고, 리뷰 과정에 방해가 되지 않도록 자세한 기
록은 1개 시나리오 검토 후에 기록
● 시나리오 다시 보기
o 1개 시나리오 검토 후, 어느 부분을 어떻게 검토했는지 메모
§ 리뷰가 진행되어 간다는 심적 안정감 얻음
o 본인의 지식이 낮다고 생각되면, 리더와 교체 논의 필요
● 문제기록표 작성
o 문제의 심각성, 수정 공수, 문제의 복잡도 등 고려해서 기록
§ 단순 오타, 부정합 등은 문서에 표기해서 작성자에 바로 전달
o 문제 기록표 항목: 문제 유형(시나리오), 위치, 내용
11. 리뷰 회의의 목적
● 리뷰어가 문제를 지적하여 중요 문제를 빠짐
없이 검출하는 것
● 문서나 시스템을 리뷰어나 작성자가 어느 정
도 이해하고 있는지 서로 파악
● 불필요한 활동(교육, 정보 공유)을 하면 리뷰
회의의 목적에 소홀해지기 쉬움
12. 리뷰 회의 준비
리더 리뷰어 작성자
1. 지적될 문제 상정
- 지적된 문제 유형을 다시 확인하고,
완료 기준을 미리 정의
2. 회의 계획 수립
- 예상 소요 시간 등을 고려해서 회의
일자, 몇 회로 할지를 결정
- 기록 담당자를 별도 지정
3. 문제기록표 수집과 확인
- 문제 기록표를 수집하고, 미리 확인
- 이해할 수 없는 문제, 설명 부족, 리뷰
부족 등에 대비
4. 회의실 준비
- 회의실 예약하고, 설비와 좌석 배치 등
을 미리 고려
5. 회의 시작 선언
- 회의의 목적과 마음가짐을 상기시키
면서 회의 시작
1. 검출한 문제의 우선순위 결정
- 중요한 문제를 놓치지 않도록 우선
순위 결정
2. 지적할 문제에 대한 설명 준비
- 미리 설명 내용을 준비
3. 마인드의 재인식
- 불필요한 발언을 하지 않도록 자세
준비
- 작성자의 태도를 바꾸려 하지 말
고, 문제 지적에 집중
리뷰 중 좋았던 점 준비: 회의에서 언
급하면 분위기가 좋아짐
- 사전에 관련 문서
나 보조 자료 준비
- 정신 가다듬기
뻘소리 방지용 암호 준비: 예, 고참개발자가 만담을 하면 ‘리프(leaf) 노드'라고 주의를 줘서 중요하지 않은 얘기를 그만
하도록 함
13. 리뷰 회의
리더 리뷰어 작성자
1. 지적된 문제 내용의 이해와 공유
- 우선순위에 따라 시나리오마다 문제
지적을 진행하고, 리뷰어로부터 설명
을 들음
2. 유사한 중요 문제의 검출
- 문제마다 심각도를 결정하고, 유사
문제가 없는지 확인
3. 주제를 벗어났을 때 궤도 수정
- 자기과시, 만담, 교육 등이 시작되면
제지해야 함
4. 시나리오 완료 확인
- 시나리오에 따른 문제 지적을 다 했
는지 재차 확인
5. 회의 종료
- 의문점이 남아 있는지 확인
- 문제에 대해 수정과 확인 담당자를
지정
- 기록담당자로 하여금 문제일람표를
바로 공유하도록 지시
1. 문제 검출 방법 설명
- 어떤 문서의 몇 쪽에서 어떤 방법
으로 검출했는지 설명
2. 문제 지적
- 심각도가 높은 것 부터 지적하고,
내용을 이해할 수 있게 설명해야 함
3. 문제 지적 종료
- 기록 담당자가 정리할 수 있게 도
움
4. 다른 리뷰어의 지적에 대한 이해
- 자기 차례 끝났다고 끝난 게 아님
- 다른 리뷰어의 지적에서 새로운
문제를 발겨하기도 함
- 지적된 문제에 대한
이해와 감사의 마음
필요
- 지적 받은 문제를
정확히 이해하기 위해
노력함
- 문서 수정은 회의
종료 후에 진행
14. 수정과 확인
● 리뷰가 물거품이 되지 않도록 지적 받은 문
제를 반영해야 함
o 리더, 리뷰어도 수정 작업에 협조
● 진행 순서
o 1. 문제 이해와 순서 결정
§ 기억이 선명하게 남아 있을 때 바로 진행
o 2. 수정과 자기 체크
o 3. 리뷰어의 확인
§ 리뷰어는 나라면 어떻게 수정했을지 미리 생각하고, 수정 문서를
리뷰 진행
o 4. 리더의 최종 확인
§ 수정 공수가 커지는 문제 위주로 확인
§ 최종 리뷰 보고서 작성 (검출수, 리뷰회의 소요 시간 등)
15. 기타 내용
● 재발 방지 회의
o 리뷰 과정에서 지적된 문제가 왜 발생했는지 원인을
분석하고 재발 방지책 검토
● 프로젝트 후 회고
o 리뷰에서 놓친 문제를 파악해서 예방방법 검토
o 문제 유형과 시나리오 정련
o 불필요한 시나리오는 제거
● 리뷰 기법
o 워크스루, 인스펙션, 테크니컬 리뷰
16. 요약
● 리뷰를 잘 하려면,
o 올바른 방식으로 진행해야 함
§ 준비 → 문제 검출 → 문제 지적 → 수정/확인
o 리뷰 마인드 필요 (이게 어쩌면 가장 중요)
§ 리더, 리뷰어, 작성자는 각자 역할에 따라, 리뷰가 실패하지 않도
록 리뷰에 임해야 함
● 책에 대한 소감
o 약간은 지루한 점도 있지만,
o 개발 리더라면 읽어봐야 할 책이라 생각됨