1. 인포뱅크 오종인
ohjongin@gmail.com / @ji5
효과적인 개발 방법론

2. Undocumented Agile
인포뱅크 오종인
ohjongin@gmail.com / @ji5

3. 쥐어짜기?
CMMI3

4. http://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Characteristics_of_Capability_Maturity_Model.svg/500px-Characteristics_of_Capability_Maturity_Model.svg.png
CMMI
4 MKDC

5. http://upload.wikimedia.org/wikipedia/commons/thumb/e/ec/Characteristics_of_Capability_Maturity_Model.svg/500px-Characteristics_of_Capability_Maturity_Model.svg.png
CMMI
5 MKDC
개인의 역량에 따라 프로젝트의 성공과 실패가 좌우
프로세스/품질의 정량적 측정
관리/통제 성과 예측이 가능
프로젝트가 아닌 조직을 위한 프로세스가 존재
조직 프로세스를 변경하여 프로젝트에 적용
프로세스 하에서 프로젝트가 통제되는 수준
일정이나 비용과 같은 관리 프로세스 중심
지속적인 개선

6.  PD : Product Description
 CR : Change Request
 FSR : Feature Specification Requirement
 SRS : Software Requirement Specification
 SDS : Software Design Specification
 SCM : Software Change Management
Inspection Inspection Inspection Inspection
http://blog.savageminds.com/wp-content/uploads/2011/09/graph.003.png
PD CR FSR SRS SDS Code SCM TestBuild
CMMI (MKDC development process)
6 TESLA

7. 자동차 리콜 사례
vs.
http://www.technologyreview.com/view/523621/tesla-motors-over-the-air-repairs-are-the-way-forward/
7 Agile

8. 자동차 리콜 사례
Over-the-Air
vs.
http://www.technologyreview.com/view/523621/tesla-motors-over-the-air-repairs-are-the-way-forward/
8 Agile

9. 자동차 리콜 사례
Over-the-Air
vs.
결함 복구 비용
http://www.technologyreview.com/view/523621/tesla-motors-over-the-air-repairs-are-the-way-forward/
9 Agile

10. 애자일 소프트웨어 개발 선언문
Manifesto for Agile Software Development
공정과 도구보다 개인과 상호 소통을,
포괄적인 문서보다 제대로 동작하는 소프트웨어를,
계약에 대한 협상보다 고객과의 협력을,
계획을 따르는 것보다 변화에 대응하는 것을 더 중요시한다.
http://agilemanifesto.org/iso/ko/
10 But,

11. 그런데, 막상 해보면 생각처럼 잘 안 된다...
http://cfs3.tistory.com/upload_control/download.blog?fhandle=YmxvZzI2NDkyQGZzMy50aXN0b3J5LmNvbTovYXR0YWNoLzAvNDkuanBn
11 Iteration
Scrum
Iteration
Kanban
Code Review
Pair Coding
Retrospective

12. Iteration
12 CI

13. Continuous Integration (지속적인 통합)
http://www.in2it.be/wp-content/uploads/2013/12/Continuous-Integration-Workflow.png
13 Before

14. Before
배포 관점
 많은 배포 시간이 소요
예) 개발서버: 2, 상용서버: 20
 수작업으로 인한 휴먼 에러 발생
예) 일부 라이브러리 or 서버만 배포
품질 관점 (테스트)
 단위 테스트
- 개발 시 테스트 코드를 작성, 개발 완료 후 삭제
- 테스트 코드 형상 관리 안됨
 통합 테스트
- 수작업으로 수정 부분에 대해서만 테스트
- 다른 모듈에서 오류 발생
 코드 품질 관리
- 구조적으로 코드 리뷰에 어려움이 있음
담당 개발자가 직접 수행하는 부분
1.개발
2.단위 테스트(?)
개발자 PC 개발 서버
3. 빌드/배포
4.통합 테스트
git
5. commit/push
상용 서버
6. 배포
14
형상 관리
After

15. After
CI 도입으로 인한 자동화
개발자PC git CI Server
4.Pull
6. 단위테스트
7. 코드 분석
개발 서버
상용 서버
9.통합 테스트
8.배포
10.배포
1.개발
2.단위 테스트
15
형상관리
3.Push
5. 통합 빌드
8.Reporting
TO-BE

16. 개발자PC
TO-BE
소스 형상관리
Lib. 형상관리
Internet
Open source
repository
문서 형상관리 이슈 형상관리
CI 서버 개발 서버
Server Farm
(Staging, Scale, ...)
상용 서버
정적분석
Stakeholders
OTA 서버
CI

17. 개발자PC
TO-BE
소스 형상관리
Lib. 형상관리
Internet
Open source
repository
문서 형상관리 이슈 형상관리
CI 서버 개발 서버
Server Farm
(Staging, Scale, ...)
상용 서버
WIKI JIRA
Nexus
Jenkins
정적분석SonarQube
GitLab
Stakeholders
OTA 서버
CI

18. 개발자PC
CI 적용 사례
소스 형상관리
Lib. 형상관리
Internet
Open source
repository
문서 형상관리 이슈 형상관리
CI 서버 개발 서버
Server Farm
(Staging, Scale, ...)
상용 서버
정적분석
Stakeholders
OTA 서버
Jenkins

19. Jenkins
19
http://4.bp.blogspot.com/-DRBmWNMWO54/T_VrEO5M9BI/AAAAAAAAAQk/YdVM3dOkWR0/s1600/JenkinsDashboard.png

20. Refactoring
20

21. Refactoring
21

22. 뭐가 문제지?
QCD

23. Quality vs. Cost vs. Delivery
23
http://www.aivosto.com/project/help/pm-complexity.html
Technical Debt

24. Technical Debt (기술부채)
24
워드 커닝햄(Ward Cunningham)에 의해 고안된 멋진 은유
 빠르지만 지저분한 방식으로 일하면,
회계에서 말하는 부채와 유사한 기술 부채로 압박
회계 부채와 같이, 기술 부채는 지저분하면서 빠른 방법을 사용했기 때문에
추가 개발 노력을 기울임으로써 이자를 지불
이자를 계속 내기로 선택하거나 지저분하고 빠른 방식의 설계를 리팩토링으
로 개선하여 원금을 상환
원금을 갚으려면 비용이 들지만, 앞으로 지불할 이자가 줄어드는 이점
Complexity

25. Cyclomatic Complexity(복잡성 지표)
25
http://www.aivosto.com/project/help/pm-complexity.html
소프트웨어 한 Unit 내(Method 혹은 Function)의 코드 복잡도 정량적 지표로 많이 사용되는
Cyclomatic Complexity 는 1976년 McCabe가 고안한 소프트웨어 지표
복잡도 v(G) = edges – nodes + 2
복잡도 v(G) = 분기문 + 1
edge가 총 9개, node가 8개
Cyclomatic Complexity는 9 – 8 + 2 = 3
분기문 2개
Cyclomatic Complexity는 2 + 1 = 3
Metrics

26. Metrics
26 Git

27. 개발자PC
Git
소스 형상관리
Lib. 형상관리
Internet
Open source
repository
문서 형상관리 이슈 형상관리
CI 서버 개발 서버
Server Farm
(Staging, Scale, ...)
상용 서버
Jenkins
정적분석
Stakeholders
OTA 서버

28. 28
http://www.travelbrochures.org/wp-content/uploads/2014/01/gold-dollar-sign.jpg

29. gitlab
29

30. Merge Request
30
http://gitlab.org/images/screens/gitlab_project_mr.png

31. 개발자PC
협업
소스 형상관리
Lib. 형상관리
Internet
Open source
repository
문서 형상관리 이슈 형상관리
CI 서버 개발 서버
Server Farm
(Staging, Scale, ...)
상용 서버
wiki
정적분석
Stakeholders
OTA 서버

32. Confluence
https://confluence.atlassian.com/download/attachments/411109514/MenuChanges.png?version=1&modificationDate=1380775469275&api=v2

33. Confluence
 생산되는 모든 문서와 자료는 Confluence에 저장
 영구적이고 유일 공간이라는 개념이 중요
 email은 휘발성 instant messaging이고 notification 도구
 email에 전달하고자 하는 내용이 포함되면 안됨 (wiki 링크 포함)
 필요 시 wiki page를 MS-Word 또는 pdf로 export 후 email 첨부
 문서를 꾸미는 시간보다 내용을 작성하는데 집중
 불가피한 상황을 제외하고 기본 옵션은 모두에게 공개
 눈사람 만들기와 같아 문서가 쌓이고 시간이 지날수록 가치가 급격히 증대
 Hierarchy 고민보다 우선 문서 작성하고 refactoring
 폴더 구조로 찾기보다 검색으로 문서를 찾아가기
 email daily summary notification 활용
33 JIRA

34. JIRA
34

35. JIRA
35

36. 끝날 때 까지는 끝난 것이 아니다
36 Cooperation

37. 37 Trello
협업 – 결국은 사람!

38. Trello
38 Kanban
http://techli.com/wp-content/uploads/2012/07/Screen-Shot-2012-07-09-at-10.33.40-PM.png

39. Kanban
39
각 단계별 작업자가 생산량을 필요 이상으로 생산하는 사례
모든 공정에서 생산량을 균형 있게 통제하는 정보시스템
순서가 정해진 공정에서 작업의 순서를 통제하는데 사용
Kanban은 JIT의 하위 개념
JIT : Just In Time
XP

40. XP – Planning poker
http://www.slideshare.net/vineet/planning-poker
Burn-down chart

41. XP – Burn down chart
Guideline

42. Kanban Task
Guideline
Task는 최대한 작은 단위로 쪼개기 (가급적 1일 이하 단위 업무로)
Task의 단위는 상대적인 수치로 피보나치 수열 값을 사용
업무량 Planning Poker를 통해서 결정하면 좋으나 초기에는 권장하지 않음
업무량 예측에 Margin을 잡지 않도록 하는 것이 중요
업무량 및 일정 예측에 실패했다고 비판하면 안됨
업무량은 정확하지 않아도 되며 작은 단위로 나눌수록 정확해 짐
항상 최신 상태로 유지되는 것이 중요
관리자가 보고를 따로 받으면 안됨. 공유 목적
Task가 급증하거나 관리가 안되면 화이트보드 기반 Kanban을 사용
Offline 도구 특유의 장점을 필요 시 활용
42 Whiteboard

43. Task 카드
1
일부 삼성 단말과
갤럭시넥서스에서 발생하는
IME memory leak 대응
3/25

44. Retrospectives
44
http://cfs8.tistory.com/image/4/tistory/2008/08/06/19/27/48997cafadd22

45. 45
http://cfile24.uf.tistory.com/image/2725C435510CBCE3166888
Retrospectives
ESVP

46. Measure Everything

47. 47

48. 결론
48
 문제의 인식이 해결의 시작!
 사람의 문제가 아니고 조직 문화의 문제!
 상호 신뢰와 즉각적인 커뮤니케이션!
 속력 못지 않게 방향도 중요!
 상황에 맞춰서 도구를 적절하게 활용!