SW품질에 대한 오해를 바로 잡고 보다 효과적인 대안을 제시합니다,
SW개발 과정에서 품질을 저하시키는 주요 원인인 지킬 수 없는 "Deadline"의 문제점을 설명 하며 데드라인이 지켜지지 않는 이유와 이를 해결할 수 있는 방안을 제시합니다.
또한 좋은 품질의 소프트웨어를 개발하기 위해 필요한 조직 문화의 문제점과 해결책도 설명 합니다.
5. Uncertainty Principle - II
QA 업무의 특징 및 문제점
• QA 범위와 QA 기간을 동시에 정확히 알 수 없다.
• QA 범위를 정의 하면 QA 기간이 불명확해 지며, QA기간을 확정하면
QA 범위가 불명확해진다.
• 아무리 노력해도 줄일 수 없는 QA기간의 임계값이 존재
• 초기 투입 인원 대비 인력을 늘리는 경우에도 Communication에 의한
손실로 인하여 줄일 수 있는 기간에 한계가 있으며 때로는 인력 투입으로
인해 기간이 더 늘어난다.
6. Uncertainty Principle - III
Seok’s Suggestion(Not Suck !)
• 목표 QA 범위와 기간 중 하나를 선택 한다.
• 한가지가 고정되면 다른 한가지를 추정 하고 보정 할 수 있는 예측
시뮬레이션을 활용 한다.
• WBS 가중치 방법 등
• 업무의 규모 및 특성에 맞는 적당한 투입 입력수가 존재 한다
• 통계 데이터를 수집 하고 분석하여 최적의 값을 찾아야 한다
• 조직에 가장 잘 맞는 시뮬레이션 모델을 개발 하고 발전 시켜 나가야 한다
7. 적절한 QA 기간?? - I
개발팀 설문 조사 결과
• 2주
왜 2주일까?
• 1주라고 말하기엔 짧은 것 같고 빨리는 끝났으면 좋겠고….
• 제품 규모에 따른 기준 QA 기간 부재
• 개발팀은 QA 시작 시점에 QA가 자신들과 동등한 수준의 제품 정보를
가지고 있는 것으로 생각 하는 경우가 많음 (자신들이 알기 때문에 남들도
알고 있는 것으로 착각)
8. 적절한 QA 기간?? - II
Seok’s Suggestion (Not Suck !)
• 제품 규모별 QA 기간에 대한 데이터 수집 및 제공
• Iteration을 통한 QA 기간의 수렴 값을 결정 하여야 한다
• 개발팀 또는 기획팀에 의한 QA 기간 산정 금지
• QA 기간은 품질 목표에 맞추어 추정 되고 변경 되어야 한다.
9. 적절한 QA 기간?? - II
Seok’s Suggestion (Not Suck !)
• 개발 프로세스 끝 단에 한정된 QA 활동을 상위로 이동
(Moving Quality Upstream)
• 개발 과정 초기부터 참여 하여 개발자와 동등한 수준의 제품 정보를
가져야 한다.
• 제품 개발 단계에 맞추어 테스트가 수행 되어야 한다.
• 위의 모든 조건을 만족 시킬 경우 프로세스 끝 단의 QA기간이 2주일
수도 있다.
10. Deadline은 왜 지킬 수 없는가?? - I
테스트 범위 및 품질 목표는 늘 변화 되며 상향 조정 되는
경향을 갖는다.
• 테스트 시작 후 이해도가 증가 할 수록 업무 범위가 늘어남
• 특정 오류로 인하여 추가적인 테스트가 불가능한 상태 발생
• 테스트 수행 중 오류 수정 모듈에 대한 Regression Test
수행 기간이 반영 되지 않음 (동시에 여러 개의 패치를
테스트 하고 있는 상황이 자주 연출 됨)
• Deadline은 고정이지만 요구사항은 고정되지 않는다.
11. Deadline은 왜 지킬 수 없는가?? - II
Seok’s Suggestion (Not Suck !)
• Agile Practice인 Incremental Implementation을 이용
• 테스트 수행 결과를 이용하여 Deadline을 예측 하여 보정 하여 나감
• 최소한의 QA 기간이 보장 되어야 함
14. The Management Paradox - II
독재와 무의미한 칭찬 만으로 얻을 수 있는 것은 반감 뿐이다.
• 일정을 목표로 한 관리 방법 지양
• 적절한 방법을 통한 Data의 축적 및 활용 (예: Agile Practices)
15. Culture
No culture can live if it attempts to be exclusive.
- 마하트마 간디[Mohandas Karamchand Gandhi , 1869.10.12 – 1948.01.30]
16. 한국에는 너클볼 투수가 없다 - I
너클볼의 정의
• 투수가 던진 공이 거의 회전하지 않고 홈플레이트(home plate)에서 예측
불가능하게 변하는 특성을 갖는 구질
17. 한국에는 너클볼 투수가 없다 - I
너클볼의 장점
• 공을 세게 던질 필요가 없다 (세게 던지면 회전이 발생 하여 안됨)
• 정통파 투수에 비하여 피로가 덜하여 더 많은 이닝을 소화 하며 자주 등판 할 수 있다.
• 활동 기간이 길다 (40대에도 왕성 하게 활동 한다)
너클볼의 단점
• 익히기가 어려우며 오랜 시간이 걸린다
• 너클볼을 받을 수 있는 포수가 드물다
• 기술이 완성 되기 이전에 사용 하면 난타를 당할 확률이 높다 (평균 구속 100Km 이하)
• 기술이 완성 되기 까지 기다려 주는 지도자가 드물다
18. 한국에는 너클볼 투수가 없다 - II
QA 업무의 특징 및 문제점
• 긴박하고 짧은 Deadline 상황 에서 업무가 진행 된다
• 새로운 기술을 익히고 성숙 하게 만들 시간적 여유가 없다
• 새로운 기술에 대한 관리자의 믿음을 얻는 것에 실패할 확률이 높다
• 몸으로 때울 수 있는 다양한 방법이 있다
• 정말 부지런 하고 손이 빠른 사람이 많다
19. 한국에는 너클볼 투수가 없다 - III
• Seok’s Suggestion (Not Suck !)
• 신기술 습득을 장려 하는 조직 분위기 확립
• 신기술 적용에 의한 단기간의 실패를 인정 하고 실패로부터 배울 수 있는 문화
확립 (실패를 비난 하는 분위기에서는 절대 개선 불가능)
• 외부에 의하여 실현 불가능 하게 주어지는 Deadline이 아닌 QA 담당자가
현실적으로 가능한 Deadline을 잡을 수 있는 환경 및 프로세스
• 담당자들의 신기술 습득을 위한 끊임없는 노력 (빠른 손은 30대만 되어도
느려지기 시작 한다)
• “예전부터 이렇게 잘 해왔어” 이 말 제발 하지 맙시다.
20. Sinking Boat - I
증상
• 급한 일을 진행 하느라 중요한 일을 하지
못함
• 인력을 늘려 보지만 급한 일은 더 빨리
증가 함
• 물 퍼내다 지쳐 멈추면 다 같이 빠져 버림
21. Sinking Boat - II
Seok’s Suggestion (Not Suck !)
• 급한 일과 중요한 일 사이의 조화 필수
• 전체 업무에서 반드시 중요한 일을 진행 하는 비율 설정
• 중요한 일의 비율을 급한 일보다 작게 설정 할 수 있지만 0이 되어서는 안됨
• 급한 일이 일정 비율을 넘어서게 될 때 더 이상의 업무 할당이 되지 않는 문화 정착
• “이게 하던 방식이야” 말하지 않기
23. Negative Metrics - II
영향
• QA의 업무를 Defect Detection 수로 관리 할 경우 QA는 Defect detection부분에 역량을 집중
하게 된다.
• 불행히도 Detection 에 집중 하면 개발프로세스에서 defect는 감소 하는 것이 아니라 증가 하는
경향이 있다.
• QA는 Quality에 집중 하지 않으며 Defect의 수에만 집중 하게 된다.
• 발견되기 쉬운 Defect들만 보고 되며 치명적인 Defect은 사용자가 발견 한다.
• 개발자들은 Defect을 은폐 하려는 경향을 갖게 된다 (코드 라인 수를 증가 시켜 오류 비율을 낮춤)
• 개발자들과 QA간의 상호 불신이 확대 된다
24. Negative Metrics - III
Seok’s Suggestion (Not Suck !)
• 어떠한 Metric도 비난의 목표나 수단이 되어서는 안됨
• 특정 Metric의 수치적 개선을 목표로 삼지 않고 Metric의 본질적
목표를 이해 하고 이용 어떠한 Metric도 사용 의도에 따라 Negative
Metric이 될 수 있음을 명심
25. 눈치만 보는 - I
경향
• 어떠한 의견도 개진 하지 않음
• 스펙 등 중요한 커뮤니케이션 내용이 잘 못 된
경우에도 이야기 하지 않음
• 잘 못 된 부분을 발견 하여도 절대로 이야기 하지
않음
• 자기 방어가 필요한 경우에만 열정으로 대화에
참여함
26. 눈치만 보는 - II
원인
• 독재자에 의하여 지배 당할 경우
• 나만 모른다는 불안감
• 이야기 함으로써 자신이 공격의 대상이 되지
않을까 하는 불안감
• 추가적인 일을 더 만들게 되지 않을까 하는
불안감
• 자신과 관련된 업무가 아니기 때문
27. 눈치만 보는 - III
Seok’s Suggestion (Not Suck !)
• There are no Dumb Questions
• 어떠한 의견도 경청되는 조직 문화 정착 (Freedom for Everyone)
• 개인이 의견을 표현 할 수 있는 다양한 채널 제공
• 내가 모르면 남들도 모른다. (자신감 필수, 집단 지성의 활용)
28. 압력, 야근 그리고 끓는 물 속의 개구리 - I
압력과 납기일의 상관 관계에 대한 오해
• 압력을 가하면 납기를 어느 정도 단축 할 수
있다.
• 어느 정도의 효과 라는 것도 무시 하지 못할
정도의 수준이다.
• 그러므로 압력을 사용 하는 것은 적절한
방법이다.
29. 압력, 야근 그리고 끓는 물 속의 개구리 - II
야근의 진실
• 압력이 가해지면 야근이 증가 한다.
• 야근이 많아 지면 정상 근무 시간을 낭비 하고 야근 시간에 해결 하려는 경향이 나타난다
• 야근을 통하여 업무 지연에 대한 책임을 회피 한다. (나 이렇게 고생 하니까 뭐라 하지마!)
• 야근을 통하여 추가적인 업무 할당에 저항한다.
30. 압력, 야근 그리고 끓는 물 속의 개구리 - II
끓는 물 속의 개구리
• 업무가 과도 하게 주어지면 담당자는 추가
적인 업무 할당에도 반응 하지 않게 됨
• 할 수 있는 업무량을 벗어 났으므로 추가된
업무량이 아무리 많더라도 신경 쓰지 않게 됨
• 어느 순간 Burnout 되어 버림
31. 압력, 야근 그리고 끓는 물 속의 개구리 - II
Seok’s Suggestion (Not Suck !)
• 근무 시간에 집중할 수 있는 환경 조성
• 야근을 근면과 혼돈하지 말 것
• 야근을 보상의 대상으로 삼지 말 것
• 야근은 필요 악이 아닌 그냥 악임을 인식할
것
32. Communication
The greatest problem in communication is the illusion that it has been accomplished.
- 조지버나드 쇼[George Bernard Show , 1856.07.26 - 1950.11.02]
33. Fortress - I
정의
• 비밀 주의 또는 혼자 다해야 직성이 풀리는
특성을 가진 사람
특징
• 단독 작업으로 인하여 업무에 오류 개입 될
확률 높음
• 협업 문제
• 당사자 이직 시 문제 발생
34. Fortress - II
원인
• 강한 자의식
• 비난 받을 수 있다는 두려움
• 실패에 비난 하는 조직 문화에 의한 영향이 많음
• 독재자 밑에서 일을 하고 있는 경우
• 동료에 대한 신뢰 부족
• 협업 관계가 아닌 경쟁 관계로 인식
• 자신이 아는 것 만을 최고의 가치로 생각
• 나도 이렇게 배웠어…
35. Fortress - III
Seok’s Suggestion (Not Suck !)
• 개인이 업무를 독점 하지 못하도록 제도화
• 협업에 대하여 보상하는 문화
• 실패를 비난 하지 않으며 실패로부터
배우는 조직 문화
• 상대방의 불안감을 인지 하고 공감
• 자발적으로 성 밖으로 나오도록 유도
36. Pair Programming - I
안 하는 또는 못하는 이유
• 둘이 한가지 일을 하면 능률이 떨어질 것이라는 선입견
• 둘이서 한 가지 일을 같이 하면 논다는 주변의 인식
• 서로 감시 한다는 느낌
• 혹시라도 망신 당하지 않을까 하는 두려움
• Pair Programming을 할 수 없는 좁은 책상
• 대화를 하며 업무를 진행 하면 타인에게 방해가 되는 환경
37. Pair Programming - II
Seok’s Suggestion (Not Suck !)
• Pair Programming을 할 수 있는 물리적 환경 지원
• Pair Programming 시간을 업무에 명시
• 협업에 대한 보상
• 팀원 간의 신뢰 및 비난 하지 않는 문화
38. Conclusions
There is no greater mistake than the hasty conclusion that opinions are worthless
because they are badly argued.
- 토마스 헉슬리[Thomas Henry Huxley , 1825 - 1895]
39. 사심이 많이 포함된 결론
• 무릎이 닿기도 전에 알 수 있는 방법은 없다.
• 성벽 허물기
• 소통하기
• 다양한 문화의 Melting pot
• 진화 하는 조직