SW 의 품질임도형

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

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

요구사항

가장 중요한 것 .

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

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

충분히 검토되어야 .

SW 수정은 비용이크다 . 뒤로 갈 수록 비용이 엄청나게 커 진다 .

요구사항 - 설계 - 구현 - 검증 - 배포

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

구현된 코드는 수정이비싸다 .SW 수정의 부작용을 파악하기가 아주 어렵다 .

일단 코드가 변경되면 0.5 개의 버그 발생 .

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

함수 divide(a, b)

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

Spec by Example

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

애자일 지속적으로 보여주고 피드백 받자 .

하지만 충분히 대비되어 있어야 가능 .

일정

모든 것을 좌우한다 . 적절하지 않을 경우 모든 것이 희생된다 .

- 기능 , 성능- 조직 , 팀원- 품질- 개선 , 프로세스 , 매출 , 비용

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

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

SW 프로젝트 성공이란 ? 다음 3+1 을 만족할 때

- 일정- 투입 자원- 기능- 그리고 , 품질

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

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

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

중요한 건 예측 가능성 .

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

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

솔직해야 . 믿어야 .

비용

대부분 인건비 .

필요 인력관리 , 분석 , 설계 , 기술 검토 , 구현 , 테스트 , 배포 ,

인프라 구축 , 교육 , 유지보수 , 운영 , 고객 응대 ...

대부분 개발자관리 , 분석 , 설계 , 기술 검토 , 구현 , 테스트 , 배포 ,

인프라 구축 , 교육 , 유지보수 , 운영 , 고객 응대 ...

개발 업무는 신규기능추가와 버그픽스 .

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

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

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

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

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

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

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

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

다시 품질이 좋은 선순환 .

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

품질

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

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

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

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

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

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

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

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

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

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

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

가능하면 기능 구현단계부터 품질에 집중해야 한다 .

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

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

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

삽질 vs 가치

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

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

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

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

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

품질 향상 방법

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

관리가 아닌 지원으로 .

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

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

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

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

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

멍석 깔아주어야한다 .

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

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

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

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

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

개발 문화

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

품질을 추구할 수 밖에 없는 개발 습관 .

당연하게 몸에 배어 있는 개발 방식- “ ”설계 후 구현- “리뷰 "- “ ”테스트 케이스- ...

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

그런 팀원과

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

개발문화는 품질을 위한 절대 사항 .

- 유일한 방법- 어쩌면 동의어

훌륭하다는 SW 업체는 전부 개발문화가있다 .

반대로 개발문화 여부가 훌륭한 SW 업체 여부의 기준이 되기도 한다 . 서류로 존재하지 않는다 . 억지로 있는척 하지 못한다 .

개발자에게 개발방식 물어보면 그대로 드러난다 .

문화다 . 프로세스나방법론이 아니다 .

- 종이 위의 것이 아니다 .- 개발 문화가 있는 곳은 종이 위의 것이 없다 .- 관리로 되지 않는다 .

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

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

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

개발자와 품질

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

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

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

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

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

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

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

스스로 편하자고 하는 것이다 .

회사에 대한 믿음 . 지속적으로 개발자를 지원할 것이라 믿자 .

그리고 최선을 다하자 .

So, What?

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

정리

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

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

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

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

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