품질 = 유지보수성 = 생산성. 회사는 개발자를 믿고 지원하고, 개발자는 회사를 믿고 실천하고. 테스트 케이스, 빌드 시스템, CI, 문서화, 리뷰는 품질을 위한 최소이다.

1. SW의 품질
임도형

2. 임도형
- 개발 문화
- 삽질 증오

3. - 요구사항
- 일정
- 비용
- 품질
- 삽질 vs 가치
- 품질 향상 방법
- 개발 문화
- 개발자와 품질

4. 요구사항

5. 가장 중요한 것.

6. 모든 것의 시작.
- 분석, 설계, 구현
- 일정
- 매출, 비용, 이익

7. 모든 것의 기준.
- 구현
- 일정
- 인수 테스트

8. 충분히 검토되어야.

9. SW 수정은 비용이 크다.
뒤로 갈 수록 비용이 엄청나게 커 진다.
요구사항 - 설계 - 구현 - 검증 - 배포

10. from http://www.allofsoftware.net/2008/11/srssoftware-requirements-specification.html

11. 구현된 코드는 수정이 비싸다.
SW 수정의 부작용을 파악하기가 아주 어렵다.
일단 코드가 변경되면 0.5개의 버그 발생.

12. 아주 명확해야.
명확하지 않으면 임의의 것으로 구현된다.
암묵적인 요구사항은 존재하지 않는다.

13. 함수 divide(a, b)

14. “a, b를 입력 받아 a를 b로 나눈 값을 반환한
다.”

15. Spec by Example

16. 요구사항은 변경된다.
변경될 수 밖에 없다.
하지만 불필요한 변경은 피하자.
그리고 변경에 대비하여 구현하자.

17. 애자일
지속적으로 보여주고 피드백 받자.
하지만 충분히 대비되어 있어야 가능.

18. 일정

19. 모든 것을 좌우한다.
적절하지 않을 경우 모든 것이 희생된다.
- 기능, 성능
- 조직, 팀원
- 품질
- 개선, 프로세스, 매출, 비용

20. 쫀다고 지켜지지 않는다.
대신 오직 악영향만 있다.

21. 언제 어디서나 개발자는
“시간이 없어서”

22. SW 프로젝트 성공이란?
다음 3+1을 만족할 때
- 일정
- 투입 자원
- 기능
- 그리고, 품질

23. 비용, 기능, 품질을 희생하면서까
지 일정을?

24. 품질을
포기하면서까지 쪼아야 할까?

25. 쪼게 될걸 알면서
무리하게 일정을 잡아야 할까?

26. 중요한 건 예측 가능성.

27. 준수가능해야.
- 일정 자체의 늦고 빠른 것은 문제가 아니다.
- 준수되어 사업에 문제가 없게.

28. 개발자의 의견을 기반으로.
- 우겨봤자, 지켜지지 않는 일정이다.
- 그럴 경우 품질을 포기하고 ‘쪼기’만 남는다.

29. 솔직해야. 믿어야.

30. 비용

31. 대부분 인건비.

32. 필요 인력
관리, 분석, 설계, 기술 검토, 구현, 테스트, 배포, 인프라
구축, 교육, 유지보수, 운영, 고객 응대 ...

33. 대부분 개발자
관리, 분석, 설계, 기술 검토, 구현, 테스트, 배포, 인프라
구축, 교육, 유지보수, 운영, 고객 응대 ...

34. 개발 업무는
신규기능추가와 버그픽스.
신규기능추가와 버그픽스는 기존 코드를 기반으로 한다.
기존 코드에 추가적인 작업이 유지보수 이고.
기존 코드가 엉망이면 유지보수 어렵다.

35. 결국 대부분이 유지보수 비용.
초기 개발의 3배 이상.

36. 유지보수 비용 절감이 핵심.
비용을 줄이려면 유지보수 비용 절감에 집중해야.

37. 유지보수가 쉬우면,
- 버그 적고, 잡기 쉽다.
- 신규 개발 쉽다.
- 새로운 프로젝트와 새로운 기술 습득, 역량 강화
- 동기 유발. 이탈 적다.
- 결과적으로 품질 좋고, 다시 유지보수 쉽다.

38. 유지보수가 어려우면,
- 버그 많고, 잡기 어렵다.
- 신규 개발 어렵다.
- 업무 대부분이 버그 픽스. 신규 개발 없고, 역량강화 없다.
- 동기 유발되지 않고, 이탈 많다.
- 결과적으로 품질 안 좋고, 다시 유지보수 어렵다.

39. 유지보수가 쉬워야,
- 개발이 쉽고, 버그 적고, 개발자 행복하고
- 일정 잘 지키고, 비용 적고, 매출 좋고, 회사 행복하고

40. 품질이 좋아야,
- 개발이 쉽고, 버그 적고, 개발자 행복하고
- 일정 잘 지키고, 비용 적고, 매출 좋고, 회사 행복하고

41. 높은 품질이 저비용의 핵심.
품질이 좋으면 유지보수 쉽고,
비용이 적고, 개발자 행복하고, 회사 행복하고,
다시 품질이 좋은 선순환.

42. 품질에 목숨걸어야.
개발 한번으로 치고 빠질 것 아니면.

43. 품질

44. 유지보수성.
- 이후의 개발을 쉽게 할 수 있는 것.

45. 품질이 낮으면,
- 시스템 파악이 어렵다.
- 테스트가 어렵다.
- 협업이 어렵다.
- 버그 발생이 쉽다.
- 코드가 어렵다.

46. 품질이 낮으면 생산성이 떨어진다.
- 일정 못 맞춘다.
- 버그 많다.
- 개발자는 지치고, 피곤하고, 싸우고, 이탈한다.

47. 생산성은 개발자의 노력과 무관하다
.
- 역량과는 관계있다.
- 단기적으로 아무리 노력해도 장기적으로 차이 없다.
- 오히려 오버하면 지친다.

48. 개발의 본질은 기존 코드의 수정.
- 수정하면 버그가 생긴다.
- 기존 코드가 후지면 수정도 어렵다.

49. HW 품질과 다르다.
- 불량품만 골라낼 수 없다.
- 불량 자체를 제거해야 한다.

50. HW식 품질 관리는 부적절.
- 배포전 테스트 방식으로 품질을 관리할 수 없다.
- SW QA는 테스터가 아니다.
- 전체 프로세스에 관여해야 한다.
- 무엇이 유지보수를 어렵게 하는지 관여해야 한다.

51. 고객만족과 관계 없다.
- 요구사항 조차 만족 못하면 배포하면 안된다.
- 요구사항 만족한다고 품질 있는 것이 아니다.

52. 개발자와 회사 행복과
관계 있다.

53. 품질은 존재한다.
품질을 부정/무시하면 비용절감은 없다.

54. 품질에 크게 신경써야 한다.
이전 기능구현에 집중했다면,
이젠 유지보수를 위한 품질에 집중해야 한다.
가능하면 기능 구현단계부터 품질에 집중해야 한다.

55. ‘기술 부채’
단기적 성과를 위해 품질을 포기한 경우

56. 신규 개발 인력이 따로 있다면
이미 품질에 문제가 있는 상황.

57. 신규 개발 인력이 따로 있다면
- 대놓고 차별이 생긴다. 벽이 생긴다.
- 동기 유발되지 않는다.
- 이탈한다. 비용이 커진다.
- 치고 빠지기식 개발. 품질 신경쓰지 않는다.
- 악순환.

58. 삽질 vs 가치

59. 삽질 의존 개발.
- 시간 비례하여 결과가 나온다.
- 개발자의 역량과 관계 없다.
- 무척 낮은 생산성
- 동기부여되지 않고 계속 이탈한다.

60. 가치 지향 개발.
- 결과가 시간과 비례하지 않는다.
- 개발자의 역량과 크게 관계 있다.
- 높은 생산성
- 동기부여되어 계속 유입된다.

61. 핵심 차이는 품질지향.
- 삽질에서는 품질 필요 없다.

62. SI에서는,
- 치고 도망가기 전략.
- 품질 신경 안쓴다.
- 무조건 사람 수 위주이고, 당연히 삽질 의존 개발.

63. 타협은 없다.
- 하나를 선택하고,
- 대내외적으로 공표하고,
- 계획하고,
- 실천해야 한다.

64. 품질 향상 방법

65. 개발자 스스로 하게 해야 한다.

66. 관리가 아닌 지원으로.

67. 일반 관리 방법은 되려 악영향.
- 출퇴근 관리
- 짜잘한 보고서와 업무지시
- 일방적 지시
- 일방적 요구사항과 일방적 일정

68. 측정이 어렵다.
- 역량, 개발 결과, 품질
- 일반적 관리에 의한 평가는 악영향만 준다.

69. 삽질 위주에서는
일반 관리 방법이 좋다.

70. 품질은 개발자가 원하는 바.
- 스스로 행복하고 싶다.
- 스스로 역량 강화하고 싶다.
- 스스로 삽질하고 싶지 않다.
- 스스로 몸값 올리고 싶다.
- 스스로 뻐기고 싶다.

71. 하지만 스스로 못하고 있다.
“시간이 없어서”

72. 멍석 깔아주어야 한다.

73. 믿고 지원하고.
- 개발자가 학습하고 실천할 여유를 주어야 한다.

74. 믿고 기다리고.
- 학습기간 동안 생상성은 떨어진다.

75. 진짜 지원해야
- 명확한 요구사항
- 합리적 일정
- 일관된 정책
- 개발자 교육, 세미나, 스터디 지원
- 자잘한 비용

76. 개발자에게 갖어야 할 믿음,
“최선을 다하여 개발할 것이다.”

77. 개발자에게 주어야 할 믿음,
“훌륭한 SW 개발을 계속 지원할 것이다.”

78. 개발 문화

79. 개발 습관.
당연하게 몸에 배어 있는 개발 방식

80. 품질을 추구할 수 밖에 없는
개발 습관.
당연하게 몸에 배어 있는 개발 방식
- “설계 후 구현”
- “리뷰"
- “테스트 케이스”
- ...

81. 몸에 배어 있어야
습관이다.

82. 그런 팀원과

83. 그런 팀원과
그런 팀원으로 구성된 조직.

84. 개발문화는
품질을 위한 절대 사항.
- 유일한 방법
- 어쩌면 동의어

85. 훌륭하다는 SW업체는 전부 개발
문화가 있다.
반대로 개발문화 여부가 훌륭한 SW업체 여부의 기준이
되기도 한다.
서류로 존재하지 않는다. 억지로 있는척 하지 못한다. 개
발자에게 개발방식 물어보면 그대로 드러난다.

86. 문화다.
프로세스나 방법론이 아니다.
- 종이 위의 것이 아니다.
- 개발 문화가 있는 곳은 종이 위의 것이 없다.
- 관리로 되지 않는다.

87. 행동 패턴이다.
- 습관으로 배이기까지 무척이나 오래 걸린다.
- 습관이 될 때까지 무척 고통 스럽다.
- 개발자의 노력과 경영자의 지원이 필요하다.
- 크게 지속적으로.

88. 몸에 배어 있는 습관
머리가 아닌 몸에.

89. 선순환.
- 경영진의 믿음, 지원
- 개발자의 노력
- 개발문화 형성
- 품질 향상, 유지보수 용이, 가치 개발, 개발자 동기 유발
- 역량있는 개발자 유입

90. 개발자와 품질

91. 개발자도 경험 없다.
- 어렵풋이 느끼고는 있지만, 대부분 경험하지 못한다.
- 이미 경험해 봤으면 삽질스런 개발 못한다.
- 익숙하다면 이미 비싼 몸값.

92. 많은 실천사항들.
리뷰, 문서작성, 짝 코딩, 테스트 케이스, 지속적 통합, 자
동화, 리펙터링, 코딩 기준, ...

93. 효과 없다?
- 몸에 배일 시간이 없다.
- 팀 전체가 할 기회가 없다.

94. 정말 최선을 다해 봤는가?
- 습관 들이는 것은 어렵다.
- 공부해야 하고
- 익숙치 않은 것 신경써야 하고,
- 꾸준히 해야 하고
- 더우기 당장 결과가 안나온다.

95. 삽질을 인정못한다.
예
- SVN
- maven
- test case

96. “시간이 없어서”
- 언제까지?

97. 개인 역량.
결국 그런 품질의 개발을 할 수 있는 것 자체가 개인 역량
이다.
손해 볼 것 없다.
스스로 편하자고 하는 것이다.

98. 회사에 대한 믿음.
지속적으로 개발자를 지원할 것이라 믿자.
그리고 최선을 다하자.

99. So, What?

100. “시간이 없어서...”
“개발자가...”

101. 정리

102. 생산성은 품질로 결정된다.

103. 품질은
개발자도, 회사도
행복하기 위한 것.

104. 회사는 개발자를 믿고,
개발자는 회사를 믿고.

105. 지속적인 노력과 실천으로 개선하
자.

106. 필수 실천 사항.
- 자동화(빌드, 테스트, 배포, …)
- 테스트 케이스
- CI
- 리뷰
- 설계