소프트웨어 개발 프로세스 개선의 본질에 대한 고찰과 실천적인 방법 제시

1. 개발 프로세스 개선에 대한
고찰

2. About me
정도현
• 일본 Mamezou소속 컨설턴트
• 개발 프로세스 도입 및 개선
• 클라우드 컴퓨팅 아키텍처 구축
• InfoQ Japan 필진
• Qcon Tokyo 2015,2016 기획위원
• 블로그
• http://moreagile.net

3. 근무처소개
• 주식회사 Mamezou(豆蔵)
• 2000년5월 설립
• 마메조 홀딩스 그룹산하 IT컨설팅 전문회사
• 일본내 자바와 OOP 패러다임 보급에 크게 기여한 회사로 유명
• 주요업무
기업대상 – IT전략 책정,IS부문지원,자체개발 지원
임베디드 – 프로세스개선, 기술도입지원, 품칠개선, 엔지니어링교육
SIer/ISV – 요구개발, 프레임웍
교육 - 소프트웨어 엔지니어 육성 및 트레이닝
• InfoQ 일본 파트너
• QCon Tokyo 주관사

4. 프로그래머를 위한 팟케스트
나는 프로그래머다
• iamprogrammer.io
• 임백준(임작가), 김호광(데니스),
정도현(정개발)
• ‘개발자들을 위한 유쾌한 팟캐스트’를
모토로 언어, 패러다임, 개발환경등을
주요 주제로 하여 매주 60분 분량 방송
• 나프다 미트업
• 6월24일
• 마이크로소프트 코리아 본사(광화문 앞) 11층
• 테마 : 개발자의 생존전략

5. 오늘의 주제
어떻게 하면 더 개발을 잘할 수 있을것인가?

6. 첫번째 질문
어떤 사람을 채용해야 하나요?

7. 성실하고 인성은 좋으나
실력이 부족한사람
VS
싸가지는 없어보이지만
실력이 뛰어난사람

8. 애자일 개발이란 무엇인가?

9. 애자일 소프트웨어 개발 선언
우리는 소프트웨어를 개발하고, 또 다른 사람의 개발을
도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고
있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.

10. 두번째 질문
여러분이 애자일 개발에서 기대하는것은
무엇입니까?

11. 세번째 질문
애자일 개발은 무엇입니까?

12. 화물신앙

13. cargo cult
인과관계를 혼동하여 부차적인 것을
중요한 원인으로 믿는 것

14. 애자일 개발을 도입한 프로젝트들이
성공할 수 있었던 이유
개발자에
대한 신뢰
개선을
허락
스스로
결정
주인의식
/자부심
성과

15. 프로세스 개선을 위한 도구들

16. PDCA사이클
Plan
DoCheck
Adjust

17. 프로덕트 기반 메니지먼트
• 프로젝트
• 한정적인 기간동안 수행
• 인원이 재 구성됨
• 외주 위주로 개발을 진행할 경우
PDCA를 제대로 실행하기 어려움
• 리스크가 높음
• 시설비용중심 관리에 적합
• 프로덕트
• 제품의 라이프사이클과 동일
• 동일한 인원으로 수행
• PDCA 사이클이 올바로 기능할 수
있음
• 리스크가 낮음
• 운영비용중심 관리에 적합

18. 전통적인 시설 기반 인프라

19. 클라우드 기반 인프라

20. 회고의 실천적 방법 - KPT법
• Keep-Problem-Try
• 정례화에서 일상화로
• 구체적으로
• 생산성을 의식한다
• 진척회의는 별도로 진행

21. 배움의 선순환
• 회사는 배움의 장이 되어야 한다
• 구글에서는 모든것에 대하여 회고를 진행한다
• 잘 된것, 잘 못한것 모두 대상으로 진행
• 절대 비난하지 말 것
• 솔직하게 진행하지 않으면 결국 형식뿐인 빈 껍데기가 되어 버린다
• 배우는것을 좋아하고 즐기는 사람을 채용하라

22. 모던 개발을 위한 모범사례들

23. TiDD
Ticket Driven Development

24. No ticket, No commit

25. 코드리뷰

26. Pull Request
Issue
Ticket
• Branching
Coding
• UnitTest
CI
• Regression
test
• Static
analysis
Pull
Request
• Code
Review
• Merge

27. 코드리뷰의 원칙
• 기계의 일은 기계에게, 사람의 일은 사람이
• 정적 코드 분석
• 체크리스트
• 가독성과 사양
• 테스트 코드도 대상에 포함
• 리뷰어는 최소 2명 이상
• 상대방에 대한 존중

28. 자동화 테스트

29. 왜 자동화 테스트는 중요한가?
• 기술적 부채 vs 기술적 자산
• 이자가 붙음
• 버그 발견 -> 테스트 케이스 추가
• 리팩토링에 대한 부담 저하
• 전체적인 코드 품질 향상
• 심리적 안정감, 만족감
• 테스트 코드가 세부적인 사양 문서를 대체

30. 좋은건 알지만 시간이 없어서…

31. 똑같은일을 계속해서 반복 하게 될 것을
생각하면 어느쪽이 더 시간 절약이 되는가?

32. 자동화 테스트의 오버헤드 관리
• 자율 or 강제
• 얼마나 작성해야 하는가?
• 코드 커버리지 보다는 사양 커버리지
• 내부 가이드라인을 작성하고 개선시켜 나가야 함
• Unit Test or E2E Test
• CI가 함께 하지 않으면 하나마나임

33. 문서화

34. 왜 문서화는 중요한가?
• 문서화는 커뮤니케이션의
일부
• 읽는 사람을 배려
• 언어가 가진 불완전성을 보완
• 기술적 부채 vs 기술적 자산
• 이자가 붙음
• 애자일 선언문에 대한 해석
• 꼭 필요한 문서를 꼭 필요한
만큼만 만들것

35. 문서화 오버헤드 관리
• 정보를 중복해서 관리하지 않는다
• 임시 문서와 유지 문서 두가지로 나누어서 관리
• 임시 문서는 구현 시기의 커뮤니케이션을 보조하는 역할
• 유지 문서는 소스코드와 라이프 사이클을 함께하는 장기 정보
• 구현 프로세스의 장점을 도입
• 페어 프로그래밍(몹 프로그래밍), 리뷰, 사양에 대한 검증(BABOK)
• 표준 언어를 사용
• UML, BPML

36. 팀운영

37. 독립적이면서 작은 팀
• 아마존의 피자 두판 팀: 팀 인원수는 피자 두판으로 끼니가 해결
될 수 있는 인원 이하로 유지하라.
• 잘 정의된 인터페이스: 팀은 회사의 나머지 부분들과 효율적으로
의사소통을 할 수 있도록 적절한 의사 소통 통로를 지녀야 한다.
• 완벽하게 독립적으로 운영하라: 팀에게 최대한의 자치권을
부여하라.
• 자율성과 책임성: 스스로 결정하고 스스로 책임지도록 하라.
구글은 모든 서비스에 사용할 언어와 미들웨어, 플랫폼을 아무런
제약없이 팀 내부에서 자체적으로 결정할 수 있다.대신, 그에 따른
책임도 스스로 져야만 한다.

38. 실패를 대하는 자세

40. 실패에 대한 진실 혹은 오해
• 실패는 성공의 어머니?
• 2번째 사업이 성공할 확률
• 첫번째 사업 성공시 : 34%
• 첫번째 사업 실패시 : 23%(첫 사업의 성공확률과 비슷함)
• 수치심과 죄책감
• 워싱턴DC 교도소 수감자들을 대상으로 한 심리학 연구

41. 결론

42. 모든것은 순환한다

43. 개발의 악순환
잦은 인원교체
커뮤니케이션
비용 증가
관리되지 않는
기술적 부채
주인의식 결여
폭탄돌리기

44. 개발의 선순환
적절한
근무사이클
커뮤니케이션
비용 감소
기술적 부채의
관리
기술적 자산에
투자
높은성과와
만족도

45. 문화
채용
업무
학습
조직과
팀
승진과
해고

46. 선순환의 출발점은 ‘사람’
• 소프트웨어 기업에 있어서 사람은 가장 중요하면서 대체불가능한
자산이다.
• 사람은 부품이 아니며 대체 불가능하다.
• man-month기반 관리는 개발자의 긍지와 주인의식을 무너트린다.
• 사람은 자산이지 원가 절감의 대상이 아니다.
• 개발자가 회사에게 있어서 소중한 존재라는것을 느낄 수 있도록
하라
• 자신이 소중하게 다루어진다는 것을 느낄수록 더 열심히 일한다.

47. 첫번째 질문
어떤 사람을 채용해야 하나요?

48. 성실하고 인성은 좋으나
실력이 부족한사람
VS
싸가지는 없어보이지만
실력이 뛰어난사람

49. 실력은 어떻게 검증하는가

50. 인성은 어떻게 검증하는가?

51. 마이너스 생산성의 존재

52. 인성과 적성 모두
타협의 대상이 될 수 없다

53. 추천 서적

54. 감사합니다