Download as PDF, PPTX
![[AIS 2018][Team Practice] CMMI 기반 환경의 애자일-투씨드](https://cdn.slidesharecdn.com/ss_thumbnails/teampracticetwo-180620000540-thumbnail.jpg?width=640&height=640&fit=bounds)
![[오픈소스컨설팅]Session 6. scrum과 jira 기반의 소프트웨어 개발 프로세스](https://cdn.slidesharecdn.com/ss_thumbnails/session6-161124012853-thumbnail.jpg?width=640&height=640&fit=bounds)
![[webinar_공유용] 팀 규모에 맞게 Atlassian Jira 활용 확장하기.pdf](https://cdn.slidesharecdn.com/ss_thumbnails/webinarjira-241007061411-560f80fd-thumbnail.jpg?width=640&height=640&fit=bounds)
![[H3 2012] 스마트모바일 환경에서의 App.품질관리전략](https://cdn.slidesharecdn.com/ss_thumbnails/d3-121105220000-phpapp02-thumbnail.jpg?width=640&height=640&fit=bounds)
Undocumented agile.dist
- 1. 인포뱅크 오종인 ohjongin@gmail.com /@ji5 효과적인 개발 방법론
- 2.
- 3.
- 4.
- 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.
- 8.
- 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.
- 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 Opensource repository 문서 형상관리 이슈 형상관리 CI 서버 개발 서버 Server Farm (Staging, Scale, ...) 상용 서버 정적분석 Stakeholders OTA 서버 CI
- 17. 개발자PC TO-BE 소스 형상관리 Lib. 형상관리 Internet Opensource 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.
- 20.
- 21.
- 22.
- 23. Quality vs. Costvs. 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.
- 27. 개발자PC Git 소스 형상관리 Lib. 형상관리 Internet Opensource repository 문서 형상관리 이슈 형상관리 CI 서버 개발 서버 Server Farm (Staging, Scale, ...) 상용 서버 Jenkins 정적분석 Stakeholders OTA 서버
- 28.
- 29.
- 30.
- 31. 개발자PC 협업 소스 형상관리 Lib. 형상관리 Internet Opensource repository 문서 형상관리 이슈 형상관리 CI 서버 개발 서버 Server Farm (Staging, Scale, ...) 상용 서버 wiki 정적분석 Stakeholders OTA 서버
- 32.
- 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.
- 35.
- 36. 끝날 때 까지는끝난 것이 아니다 36 Cooperation
- 37. 37 Trello 협업 –결국은 사람!
- 38.
- 39. Kanban 39 각 단계별 작업자가생산량을 필요 이상으로 생산하는 사례 모든 공정에서 생산량을 균형 있게 통제하는 정보시스템 순서가 정해진 공정에서 작업의 순서를 통제하는데 사용 Kanban은 JIT의 하위 개념 JIT : Just In Time XP
- 40. XP – Planningpoker http://www.slideshare.net/vineet/planning-poker Burn-down chart
- 41. XP – Burndown 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.
- 45.
- 46.
- 47.
- 48. 결론 48 문제의 인식이해결의 시작! 사람의 문제가 아니고 조직 문화의 문제! 상호 신뢰와 즉각적인 커뮤니케이션! 속력 못지 않게 방향도 중요! 상황에 맞춰서 도구를 적절하게 활용!